On Thu, Sep 8, 2011 at 12:11 PM, Michael Schreckenbauer <grim...@gmx.de> wrote: > Am Donnerstag, 8. September 2011, 16:58:22 schrieb Neil Bothwick: >> On Thu, 8 Sep 2011 11:15:40 -0400, Michael Mol wrote: >> > Perhaps udev's problem is that it's too complex, as a result of having >> > too large a problem scope. > >> The problem, AIUI, is the udev can run any programs specified in the >> rules files, and they may not be available before /usr is mounted. > > Funny thing is, devfs was removed, because of "unfixable race-conditions" > (among other things iirc). What else is this then? > An initramfs is not a proper fix for this design flaw, imo.
Then design the correct solution and implement it. If it's technically sound, it will prevail. I think it's a rather complicated problem with a non trivial solution, but the code is there if you feel like give it a try. devfs was replaced by udev primarily because devfs shoved a lot stuff in the kernel (the rules to create the devide nods) that belongs in users pace. And I agree: the rules to determine what devices nodes gets created by what hardware (that nowadays hardware appears and disappears almost randomly from the kernel point of view), belongs in user space. And guess what? Then to boot you need a minimal user space. And the fool-proof way to get one before mounting anything, is to put it in an initramfs. Embedded systems don't need that, and deal with it in a particular way (device-trees and other stuff). Desktop and servers can use (and I think should use) an initramfs (yes, servers too, especially with eSATA and similar things). The kernel devs have been moving in that direction for a long time. I would not be surprised that the option to not have initramfs will be removed from the kernel in the future, unless you select CONFIG_EMBEDDED=y. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
