[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