Re: [BK PATCHES] initramfs merge, part 1 of N

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> The real advantage to me is two-fold:
> 
>  - make it easier for people to customize their initial system without 
>    having to muck with kernel code or even use a different boot sequence.  
>    One example of this is the difference between vendor install kernels 
>    (using initrd) and a normal install kernel (which doesn't).
> 
>    So I'd much rather see us _always_ using initrd, and the difference 
>    between an install kernel and a regular kernel is really just the size 
>    of the initrd thing.
> 
>  - Many things are much more easily done in user space, because user space 
>    has protections, "infinite stack", and in general a lot better 
>    infrastructure (ie easier to debug etc). At the same time, many things 
>    need to be done _before_ the kernel is fully ready to hand over control 
>    to a normal user space: do ACPI parsing so that we can initialize the
>    devices so that we can use the "real" user space that is installed on
>    disk etc.
> 
>    Sometimes there is overlap between these two things (ie the "easier to 
>    do in user space" and "needs to be done before normal user space can be
>    loaded"). ACPI is one potential example. Mounting the root filesystem 
>    over NFS after having done DHCP or other auto-discovery is another.  
> 

I agree 100% with this.  I don't think <kernel>+<early userspace> will 
ever be smaller than the current kernel, but I have invested quite a bit 
of effort into it for exactly the reasons done above.

klibc binaries might not be what one usually tends to run, but during 
klibc development I could still use standard gdb, strace, and just plain 
"run it off the command line" debugging techniques from a full-blown 
environment.  When that doesn't work (like testing dynamic klibc), 
chroot will usually do the trick.  The compile-test-debug cycle is so 
much faster than for a kernel boot that it's just plain amazing.

	-hpa