How soon should we begin to work on a devfs alternative? I've read that Per doesn't like udev. We'll want to at least provide the same level of functionality as devfs did, right? So a nice, clean /dev which reflects installed devices is absolutely paramount. Do we do it in tmpfs? Perhaps, after installation is complete, the user can be asked to run a command which populates a tmpfs mounted on /dev, with their device entries. Is cpio the fastest archiver? Would it slow down booting much, to dump the contents of an uncompressed cpio archive to this empty tmpfs? Because, this cpio archive of /dev could contain the contents of the afore-mentioned populated after scanning sysfs /dev. (perhaps /tmp/dev in that instance, so as not to disrupt the installation shell). Users could tweak permissions, and add additional device nodes--another command (or possibly a 2nd function/argument) could save the tmpfs /dev to the cpio archive, which would preserve permissions, etc. Like a one-time udev_start, without udevd, without hotplug, and with a command which (optionaly) re-saves its state, so that one doesn't need to muck with config files, because one mucks with the device nodes directly. It's just an idea to get a system running cleanly. Personally, I'm going to see how much I can tolerate udev before thinking about things more. P.S. CRUX 2.2 is about January-February far away, yeah? I hope we don't move to GCC4 until at least June. (but that's a huge change, which would probably be called CRUX 3.0, yes?)