Messages in this thread | | | Date | Sat, 02 Nov 2002 04:07:00 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [BK PATCHES] initramfs merge, part 1 of N |
| |
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/
| |