initramfs and where user space truly begins
Posted Jul 13, 2006 4:55 UTC (Thu) by dlang
(✭ supporter ✭
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)
to post comments)