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?)
