[klibc] mkinitrd integration strategy?

[Erik van Konijnenburg]

On Sun, May 29, 2005 at 09:32:45PM +0200, Daniel Thaler wrote:
> Erik van Konijnenburg wrote:
> > ...
> > Thus, we need to find a way to have an initramfs filled partly
> > with files that come with the kernel, partly with files that come
> > from mkinitrd, and to hand over control between both camps
> > at the right time.  And it needs to be flexible enough to cope
> > with an ongoing migration of initialisation processes from
> > kernel space to user space as new kernels are released.
> 
> You can load 2 initramfs archives: One that is built into the kernel
> binary _plus_ a second one loaded by the bootloader like an initrd.
> The built-in archive is unpacked first, meaning that files which are in it
> can be overwritten by the second one.

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.

Thanks,
Erik