login
Search
Greg Kroah-Hartman released version 007 of udev for the 2.6 kernel [forum], an "implementation of devfs in userspace using sysfs and /sbin/hotplug." He says:
"I think with the ability to capture the output of the CALLOUT rule, combined with the ability to put format modifiers in the CALLOUT program string, we now have everything in place to emulate the existing devfs naming scheme. Anyone want to verify this or not?"
Read on for the complete changelog.
From: Greg KH [email blocked] To: linux-hotplug-devel, [email blocked] Subject: [ANNOUNCE] udev 007 release Date: Sun, 23 Nov 2003 16:29:01 -0800 I've released the 007 version of udev. It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-007.tar.gz udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run. Please see the udev FAQ for any questions about it: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ Note: The CALLOUT rule format has changed. If you have a config file using this rule, please change it to follow the new order. See the man page for the proper style. The major changes since the 006 release are: - better parsing of the udev.permissions file - string owner and group names in the udev.permissions file will now work if you build against glibc. - fix the CALLOUT rule to look the same as the other rules. - add format char for CALLOUT rule output - support arguments in callout exec - add ability for CALLOUT program to accept format modifiers. - drop Makefile.klibc. To build using klibc, use: make KLIBC=true - updated man page documenting new changes. Again, many thanks to Kay Sievers, for lots of great patches in this release. Thanks also to Marco d'Itri and Olaf Hering, both of whom submitted patches for this release. I think with the ability to capture the output of the CALLOUT rule, combined with the ability to put format modifiers in the CALLOUT program string, we now have everything in place to emulate the existing devfs naming scheme. Anyone want to verify this or not? The full ChangeLog can be found below. udev development is done in a BitKeeper repository loacated at: bk://linuxusb.bkbits.net/udev Daily snapshots of this tree can be found at: http://www.codemonkey.org.uk/projects/bitkeeper/udev/ Many thanks to Dave Jones for managing this. thanks, greg k-h Summary of changes from v006 to v007 ============================================ <md:linux.it>: o fix segfault in parsing bad udev.permissions file Greg Kroah-Hartman: o update default config file with a CALLOUT rule, and more documentation o updated the man page with the latest format specifier changes o added ability to put format specifiers in the CALLOUT program string o tweak udev-test.pl to report '0' errors if that's what happened o only build klibc_fixups.c if we are actually using klibc o add support for string group and string user names in udev.permissions o add getgrnam and getpwnam to klibc_fixups files o remove Makefile.klibc o add udev-test perl script from Kay Sievers <kay.sievers@vrfy.org> which blows away my puny shell scripts o added debian's version of udev.permissions o change to 006_bk version Kay Sievers: o format char for CALLOUT output o more namedev whitespace cleanups o support arguments in callout exec o namedev.c - change order of fields in CALLOUT o namedev.c whitespace + debug text cleanup o man page with udev.permissions wildcard Olaf Hering: o static klibc udev does not link against crt0.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email blocked] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Pseudo filesystems on Linux
I'm not keen on the whole udev thing - it doesn't address the problems that actually having a /dev directory creates. Really, we should have a "pseudofs" filesystem that covers /dev, /proc and /sys. Instead of being in userspace, this filesystem should be in kernel space, and only readable and writable by the kernel itself. Perhaps we would also have to introduce some kernel functions that would only be available to Linux system administrators to allow changing the permissions of files in /dev (i.e. setting which users could use which devices). These functions would not need to be applied to /proc or /sys because these files always belong to 'root'.
Besides, what is the point of putting devfs,sysfs,procfs in /etc/mtab? This only gives admins the opportunity to mount these in non-standard locations. Is this the 'freedom' to mount anywhere? No, because mounting these in non-standard locations would cause problems with a huge number of Linux applications! We all need standards anyway. For that reason, "pseudofs" (which would make devfs,procfs,sysfs obsolete) should not be shown in /etc/mtab.
Another problem with udev is that it mounts a temporary file system on top of an existing /dev directory, but udev is not started until after init (Linux boot sequence goes Kernel->Init->Daemons). Udev is one of the daemons, of course. However, Init needs /dev/console and /dev/null on the underlying filesystem (under the temporary one udev creates) in order to function correctly. So, this means that people who say that on modern Linux distros, device files are created dynamically on startup, are wrong. In fact, many distro vendors do not realise that udev mounts on a temporary filesystem, and create a full devfs under it anyway (what a waste of disk space - note that pseudo files are marked as size 0 bytes on disk but they must still have a metadata section to store their permissions)! To solve the problem with Init, the udev daemon should be started between the Kernel and Init in the boot process.
Finally, why does udev mount a temporary filesystem that is limited to 1MB in size (see above - pseudo files do take up space)? If somebody has a lot of hardware in their machine, udev will fail because it will run out of disk space for creating devices. Udev should simply be 'mount'ed without the '-o size=xxxx' option. This change can be applied easily, by simply modifying the udev daemon script, although it would be really irritating to receive the 'out of space' error, because you can't unmount the udev directory. Fortunately, a workaround is 'umount'ing the directory with the '-l' option (lazy umount), altering the daemon script as above, then restarting the udev daemon.
Unfortunately, I'm only speculating here - I don't know anything about C or C++ programming so I wouldn't be able to program such a "pseudofs" interface, but I can give useful advice because I am quite a tinkerer (that's what I like about Linux - you can fiddle with it to your heart's content and possibly make it better).
PS: Have I missed anything here?