I just upgraded my kernel to 2.6.14, and I remember discussions about that version, udeveventrecorder, initramfs, and getting rid of coldplug -- and the whole hotplug package -- happening several times now.
What I'm wondering is, for anyone that doesn't think an initramfs is good, why do you think that? The way I see it, it's another part of a Linux system (more specifically, the kernel) that we haven't really touched on before because it wasn't needed. With a move like replacing coldplug, it might become necessary, which I guess I see as just another opportunity to teach readers more about Linux -- in this case, what happens in "early userspace", before init gets started. (But I'm still not entirely sure whether it *is* needed or not, or whether it's even what upstream recommends anymore. If not, then I wouldn't put an initramfs in just to teach about it; IMO the system should be used for something if it's there.) (From what I remember of the various options that Alexander has proposed in the past, the initramfs seems to be the cleanest anyway. Why walk sysfs, like udevstart does in v6.1, when you can just save the events as the various built-in drivers create their kobjects? Same with loading modules -- why try to regenerate the lost events, when you can just save the originals?) I do remember some objections about requiring cpio to be installed on the host -- but an initramfs doesn't. True, one option is to have cpio installed on the host, then making a cpio.gz archive, then pointing the kernel at that while configuring it. But another option is to have the usr/gen_init_cpio binary from the kernel create the cpio archive for us, and that doesn't (maybe "doesn't always") require the cpio binary. We can either have a directory which the gen_init_cpio binary will create a cpio archive from (this may require cpio, I haven't tested it), or we can write a control file, which gen_init_cpio will interpret (I've done this on a system without cpio, and it works). The file's format is given by running usr/gen_init_cpio --help from the top level directory of the kernel source tree. The kernel documentation (early-userspace/README) recommends using klibc, but that's not strictly required either. As long as you don't do name lookups in the other binaries (or otherwise require the nss stuff), glibc will work fine. Yes, it'll be about 700K bigger, but what's 700K of RAM that's used by files that will be deleted soon anyway? Not much, IMO. We could even have an LFS-specific initramfs "package" that extracts into a directory containing everything -- the control file (containing references to LFS's bash, glibc, some basic devices, the udev files that are needed, and a couple other executables), the /init shell script, and that would be about it -- and give a sort of overview of the way it works on the page where we use it compiling the kernel. The initramfs itself is certainly something that I'd have loved to learn about from the LFS book (figuring out how to put one together, how it does what it does, etc.). I admit, I may be different than most people that way, but I don't know. (I'm also not sure I got everything I need in my initramfs, but that's what this upcoming reboot is for. ;-) )
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
