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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:26 EST