initramfs and where user space truly begins

Posted Jul 13, 2006 10:49 UTC (Thu) by nix (subscriber, #2304)
Parent article: initramfs and where user space truly begins

Yes. The kernel devs are in a bit of a bind.

If they leave initramfs as it is now, completely replaceable by the builder, then the builder's existing initramfs setup will continue to work: but nothing new can be moved out of the kernel into early userspace without requiring the builder to update that setup.

If they switch over initramfs so that the user can add things to an existing klibc-based system, they allow migration of extra init work from the kernel, and shoot a lot of existing users in the foot (e.g. those of us with busybox+uClibc-based initramfses are in trouble, because busybox won't build with klibc; there are a lot of other programs that won't either; will e2fsprogs's fsck work when linked against klibc? What about mdadm?)

(And use of initramfs is common not just by distro kernels but also by those of us who keep our root filesystems in LVM on MD, so as to get a combination of LVM expandability and RAID robustness, let alone anyone who uses an encrypted root filesystem on a network block device or anything elaborate like that, as you said. I know I had my root filesystem on a network block device for a few weeks solely to let me keep running while I recovered from a major disk failure: that's what pushed me to RAID in the first place).

to post comments

initramfs and where user space truly begins

Posted Jul 13, 2006 15:49 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

nothing says that your initramfs can't have some programs with klibc and some whilt glibc (although that does waste some space)

they are working on getting the programs that you mention to run with klibc so it's a temporary problem (and one that will be easier to fix once klibc is included with the kernel, which will ease the maintinance burden that's involved with tracking kernel changes, allowing for more time to be spent on any changes to klibc that need to be done)

initramfs and where user space truly begins

Posted Jul 13, 2006 16:26 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

IIRC Rob Landley was using words like 'no chance' regarding getting large parts of busybox to work (please correct me if I'm talking nonsense, Rob, my memory is hazy right now due to insomnia).

initramfs and where user space truly begins

Posted Jul 14, 2006 5:09 UTC (Fri) by dlang (guest, #313) [Link]

not all the work needs to be done by Rob or the busybox developers

remember that maintaining a large patch out-of-kernel is a significant drain on a projects resources, once it can move into the kernel that drain is stopped and the time can be spent on other things, including (in this case) plugging the holes tha prevent it from working with more apps (to a large degree anyway, they don't want to have to support every function call forever)

initramfs and where user space truly begins

Posted Jul 13, 2006 15:51 UTC (Thu) by cventers (guest, #31465) [Link] (1 responses)

Well, unless klibc implements things uClibc doesn't, why couldn't a user
using busybox and uClibc with initramfs not continue to use uClibc and
build the kinit stuff against it?

I agree that it's a tough call but I think it's an exciting, neat and
clean idea to move more of that boot policy out of the kernel. There's
nothing more irritating to me than watching the kernel panic because the
VFS can't mount root, and then having to juggle boot CDs to go in and fix
it. Having dash available right then to step in would be convenient :)

initramfs and where user space truly begins

Posted Jul 13, 2006 16:27 UTC (Thu) by nix (subscriber, #2304) [Link]

Indeed this seems ideal :) it could be done easily by simply allowing the kinit toolchain to differ from that used for everything else (so you could put your uClibc toolchain in there instead).

(I can't recall if this is already done.)