> I have got a new challenge with udev. Since version 176 devtmpfs is > *required* in kernel[1]. As I understand this will not work very well > with mdev, our primary /dev handler.
It should work with mdev. However, you might have the same aesthetics issues as me with devtmpfs: it looks like a very half-baked approach, where the kernel does a bit of work, but not all of it, and userspace support is still required to have a complete, fully functional /dev, but exactly to what extent is userspace required is unclear, and changes with versions. The original reason for devtmpfs is to already have a RAM-mounted /dev when init is spawned, so udev can run very early, and init scripts can assume there's a dynamically managed /dev. But this can already be achieved very simply without kernel support ! - Have /dev be a symlink to /mnt/tmpfs/dev - On your root filesystem, have a static /mnt/tmpfs/dev/console device - Replace your init binary with a script that does the following: * close fds 0, 1 and 2 * make a tmpfs of whatever size you want, and mount it on /mnt/tmpfs * mkdir /mnt/tmpfs/dev * mknod /mnt/tmpfs/dev/console c 5 1 * reopen 0, 1 and 2 pointing to that console device * execute into your real init process And there you are, you have a /dev on a tmpfs. As an added bonus, you also have all the rest of /mnt/tmpfs for your own purposes, so you can have your root filesytem read-only and still have a place to write to very early in your init scripts. Apart from the silly idea that init is sacred and can't be replaced with a script, there is basically no good technical reason to use devtmpfs; it's totally redundant. It would be nice if udev kept supporting non-devtmpfs installations, by keeping on creating the device nodes itself. Unfortunately, I expect extremely little technical judgment from the udev authors. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
