[klibc] mkinitrd integration strategy?

H. Peter Anvin hpa at zytor.com
Sun May 29 16:02:45 PDT 2005

Erik van Konijnenburg wrote:
> That's an important part of the integration, but I think there's
> more to it:
> * How do I avoid overwriting kernel supplied executables?
>   Will they all be stored in say /kernel, should mkinitrd
>   only use /initrd, or do we simply hope no clashes occur?
>   (Slight variation on this issue: kernel creates a file /x,
>   mkinitrd tries for a directory /x.  Ouch.)
> * Are all kernel executables started before /init runs,
>   or is /init expected to invoke eg /kernel/run-acpi-stuff
>   before starting to load modules?  Perhaps via some
>   kernel supplied rc.d on rootfs?
> For mkinitrd, it would be easiest if the kernel executables
> were all completed before /init starts.
> Hmm, if the kernel executables are completed before /init starts,
> then we could defer loading the second archive until after
> the kernel executables are completed; that way mkinitrd does not
> have to worry about overwriting kernel executables.
> No idea whether that's flexible enough for the kind of stuff that
> will move from kernel space to user space.
> Sorry if this all sounds a bit abstract and too far into the future;
> what I'm trying to do is get an idea of how big the impact for
> mkinitrds will be when klibc get integrated into the kernel and
> user-spacification begins in earnest.

There is definitely a whole slew of these sort of issues.  One thing I 
have considered is to submit as part of integration to invoke /kinit, 
not /init; and let the name /init be invoked after /kinit.

Right now, though, this is a bit of design-in-a-vacuum, which is why I'm 
hesitant to do this discussion now.


More information about the klibc mailing list