The status of dynamic devices in 2.6
The loss of devfs bothers a relatively small number of people; of the large distributions, only Gentoo uses devfs. But those users have tended to be a little unhappy with the alternatives - many people who have looked at udev (which was first examined here back in April) have concluded that it is not yet ready. Many of the features of devfs are still missing, udev does not yet handle all types of devices, and support for the devfs naming scheme has been slow in coming. As a result, devfs users feel left out in the cold.
What some observers may have missed is that udev development has taken off in the last couple of months. udev 003, released on October 16, was mostly the work of its original author, Greg Kroah-Hartman. Since then udev has picked up its own development community and evolved considerably. The current release as of this writing (udev 008) is a much stronger offering, and several new features are queued up for the 009 release as well. Among other things, udev now offers:
- A FAQ
file of its own.
- A "callout" option which allows difficult devices to be set up with an
external program.
- Ability to build with klibc for embedded or initramfs usage.
- Proper disk partition support.
- Printf-style formatted dynamic name support.
- Regular expression pattern matching in rules.
- Symbolic link support.
...and quite a bit more. At this point, udev contains something close to the full set of features needed to enable it to replace devfs.
The problem is not yet entirely solved, however. udev depends on sysfs for the information needed to configure device nodes, and not all devices have complete sysfs support at this point. Thus, for example, udev will not yet work with input devices, misc devices, and some others. Certain kinds of subtleties (distinguishing CDROM drives from regular disks, for example) are not yet there. The fault is not with udev itself, but with the information (or lack thereof) that it gets from the kernel. In many cases, patches to add the relevant devices to sysfs are in circulation, but have not yet been merged into 2.6. Once that support has been added, the picture will be nearly complete.
There is one remaining question from devfs users, however, which has earned its own place in the FAQ: dynamic loading of drivers. devfs has the capability to create a device node while deferring loading of the appropriate driver module until a user program actually opens that device node. udev cannot do that, and there is no plan to add that support. In the 2.6 world, driver modules are loaded by the hotplug mechanism when the device is detected, so there is no need to load them at open time. This approach bothers some users who prefer not to load drivers for rarely-used devices, but most users will be able to live with it.
(See also: the udev 008 man page for
information on how udev works, and
Robert Love's HOWTO on using udev
with the development version of Fedora).
Posted Dec 11, 2003 3:42 UTC (Thu)
by denials (subscriber, #3413)
[Link] (3 responses)
Posted Dec 11, 2003 5:04 UTC (Thu)
by xanni (subscriber, #361)
[Link] (2 responses)
Posted Dec 17, 2003 10:11 UTC (Wed)
by mwilck (subscriber, #1966)
[Link] (1 responses)
One of the few aspects of LWN I am annoyed about.
Posted Dec 17, 2003 14:49 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Dec 11, 2003 4:48 UTC (Thu)
by cameronrich (guest, #12643)
[Link] (2 responses)
Consider the MTD flash driver which is tightly integrated with flash addresses and partitions (each partition is a "file" and 1 or more sectors make up a partition). To make flash sectors available to an application, the kernel must be tweaked - and devfs allows them to become available when the system is rebooted. This driver relies heavily on devfs. As an embedded developer, we wouldn't consider 2.6 until this feature was fully operational or at least replaced with something similar...
Posted Dec 11, 2003 8:50 UTC (Thu)
by gregkh (subscriber, #8)
[Link]
Posted Dec 11, 2003 8:54 UTC (Thu)
by Ross (guest, #4065)
[Link]
Posted Dec 19, 2003 2:06 UTC (Fri)
by obi (guest, #5784)
[Link]
It's not really hardware that is "hotplugged", is it?
From the article:Mandrake 9.2 uses devfs...
The loss of devfs bothers a relatively small number of people; of the large distributions, only Gentoo uses devfs.
Mandrake uses devfs too, at least my 9.2 install defaults to it. But they tend to be early adopters, so I wouldn't be surprised to see Mandrake 10 roll out with a 2.6 kernel and udev.
Mandrake 9.0 and 9.1 also use devfs by default.
Mandrake 9.2 uses devfs...
Yes, and this is not the first time I have read such a statement in LWN, showing that LWN does not regard Mandrake as a "major distribution".Mandrake 9.2 uses devfs...
The reason I wrote things the way I did was that I was under the impression that Mandrake had backed away from devfs in its more recent releases. I don't currently have a Mandrake system around (one can only run so many distributions at once) so I couldn't easily check that. My mistake.
Mandrake 9.2 uses devfs...
Many embedded systems use it too. Using mknod is just not a practical option in some cases.The status of dynamic devices in 2.6
For block devices udev works just fine today.The status of dynamic devices in 2.6
So yes, your embedded system can look at using 2.6 with udev if you must
require the functionality of not knowing exactly what devices your system
has. But since you specified the reconfiguration, why use devfs or udev at all? Why not a static /dev which would save you lots of time and testing.
If the filesystem doesn't support devices you can use a tmpfs /dev,The status of dynamic devices in 2.6
though it would eat some RAM.
Will udev create a "tun" node when I load the universal tun/tap driver (devfs does)? The status of dynamic devices in 2.6