initramfs and where user space truly begins [LWN.net]

initramfs and where user space truly begins

Posted Jul 13, 2006 4:55 UTC (Thu) by dlang (guest, #313)
Parent article: initramfs and where user space truly begins

I started playing with linux around the 0.99 days and have been makeing my living with it since the 2.0 days, when I started you _had_ to compile your own kernels. I still do for ease of maintinance and performance reasons (and yes, I also drive a stick-shift, I like having control :-)

during the last 10 years of makeing my living with Linux the only time I have used initrd or initramfs is when booting a new distro (useually only long enough to download the kernel source and recompile) I don't like the extra step of updateing the boot filesystem and matching the right one to the right kernel. As such I am among those who have been nervous at the claims that everything that can move out of the kernel must do so.

however with initrd and klibc/kinit it can be possible to have the straightforward make menuconfig && make && make install process produce a single object that is enough to boot the system (satisfying my desires) while still splitting functions out of the kernel itself into userspace. as long as this is available it really doesn't matter much to me what moves where.

I would say that the line of what should be part of the kernel tree and what shouldn't needs to be based on what is needed to function and drive the hardware. As such udev and alsalib should probably be included. software suspend code may belong there as well (there are only a small number of ways to do the job, and they tie in fairly tightly with the kernel itself, besides the debate over if it should be kernelspace or userspace to begin with), but cluster membership works quite well seperatly (and you have quite a few different options to choose from) with the other things being even further out.

alsa is a particularly good item to look at, it's half in the kernel and have in a userspace library, but the API that everyone is supposed to use is the library, not the kernel. As such it could be argued that the kernel API's really aren't relevant and the library should be packaged with the kernel (it's not today becouse of the kernelspace and userspace dividing line, but maby it should be)

David Lang

to post comments

initramfs and where user space truly begins

Posted Jul 13, 2006 10:53 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

With initramfs you can do all of that too: in fact the initramfs build process is much *easier* for the builder than the initrd ever was, because the build system can put together the cpio archive for you and compress it.

Plus, there's *no* danger of finding that you've managed to lose the initrd that corresponds to some kernel, and now you can't boot it anymore, or finding that your initrd has changed but your kernel hasn't (perhaps you had one initrd in use by several kernel images) and now you can't boot it either.

And anything that zaps pivot_root(2) and the other mass of wildly variable and variously bizarre historic horrors that initrd has accumulated to switch to the real root *has* to be good. A tiny C program to close all fds, rm -rf /-on-one-filesystem, chroot(), and execve() is all you need to use to switch from initramfs. :)

initramfs and where user space truly begins

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

however there's still the need (currently) to prepare the initramfs manually before building the kernel.

while it's optional this isn't a problem (I just ignore the option entirely), but if/when it's made mandatory this seperate manual step should be automated.

initramfs and where user space truly begins

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

There's no need to do that, unless by 'prepare' you mean 'tell the kernel build infrastructure which files should go into initramfs'. I can see no way to automate *that* without eliminating all the configurability (of course there should be a default that uses kinit if kinit becomes mandatory, and the kinit patches do indeed provide such a default).

initramfs and where user space truly begins

Posted Jul 13, 2006 16:40 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

any portions that the kernel requires (kinit for example) need to be pulled in automagicly.

this could be as simple as having a directory under the source three /initramfs such that anything that's in there gets used to create the initramfs (and the kernel compiles kinit and any other required pieces and puts them in there)

or any other method of makeing a default initramfs that provides hooks so that the distros can add their own stuff in.

the point I'm looking for is that today you can make a monolithic kernel by make *config && make and then use the resulting file on any compatable machine and it's sufficiant to boot the machine. if initramfs is made mandatory then it needs to be equally simple to manage.

initramfs and where user space truly begins

Posted Jul 14, 2006 11:55 UTC (Fri) by nix (subscriber, #2304) [Link]

It already is: there is a default initramfs source file which contains everything needed for kinit; you can add stuff to it as you wish.