[klibc] [PATCH 1/3] klibc: Add scandir() and alphasort() support.

[Mike Waychison]

On Mon, Aug 1, 2011 at 1:34 PM, maximilian attems <max at stro.at> wrote:
> On Mon, Aug 01, 2011 at 09:53:10AM -0700, Mike Waychison wrote:
>> Looks like I forgot to add the cover sheet that I wrote up for this
>> series that actually explains why I'm doing this.  Here it is:
>>
>>
>> This patchset applies to klibc mainline.
>>
>> This patchset introduces the ability to kinit to execute scripts or
>> executable files present in in the initramfs before switching over to
>> the root filesystem.
>>
>> It is implemented by first implementing scandir() and alphasort() as
>> present in POSIX.1-2008 in klibc itself, and then using that as the
>> basis for iterating and executing files via a run_scripts() call.
>
> I like it very much as kexec-tools and lvm2 also use those functions.
> Didn't yet have time to review the code itself and thus was silent,
> but it is on my TODO.
>
>> This patchset introduces two different drop directories, though this is
>> of course subject to change and these are only presented in an effort to
>> put an example forward.  I currently only have a requirement to run
>> stuff between the time we call do_mounts() and the time we call
>> run_init().
>>
>> These are the directories:
>>
>>       /scripts/after-network: ipconfig is completed, but the root
>>           filesystem isn't yet mounted.
>>       /scripts/after-mount: the root filesystem has just been mounted at
>>           /root.
>
> I am a bit unsure of the naming of those directories, but that is easy
> to fix once consesus is reached.
> The initramfs-tools naming which aboves seems modelled after may not be
> pretty and correct.

Agreed.  I'm not really committed to these directory names either.   I
really don't like the hardcoding that is going on (for these, and for
"/root" elsewhere), though I suspect we are the right track.  We can
always introduce a config file too if we really feel the need to
remove these hardcoded paths.

>
>> I believe this would help both our use-case (where we'd like to do
>> customization of the early-bootup sequence without having to hack kinit
>> too much), and the use case for initramfs-tools, opening the door to
>> replace all the "core" shell there kinit as a C implementation.
>
> I do agree that this seems preferable then the reducing kinit to dust axing.
>
> Related to it I wondered who is loading for you the linux modules or
> do you have udev running for the firmware loading?

At this point, I have no requirement for module loading (and
subsequently firmware loading), though getting that working would be
really nice too at some point (within the next year?).

I'm not familiar with the module loading scheme in initramfs-tools, is
it as simple as processing /conf/modules and loading those guys up?

I think if we are going to support module loading for our setups, we'd
want to do some sort of PCI probing to discover the modules we want to
use (instead of loading up all of them unconditionally), and it would
probably be easiest for us if we continued to do this outside of
kinit, not sure.

>
> As I'm quite inclined with aboves plugin features to package kinit as seperate
> initramfs utility for Debian and Ubuntu.
>
> thank you very much.
>
> --
> maks
>