What's needed to fix user-space device enumeration? [LWN.net]

Back in April, LWN looked at udev, a simple user-space daemon which handles the dynamic creation and removal of device nodes. Udev is an answer to devfs which uses hotplug events and sysfs to manage the device tree in user space. Things have been fairly quiet on the udev front - at least, on the public lists. That changed, however, when Steven Dake posted a patch aimed at fixing some problems he sees with how udev works. At that point, it become clear that an off-list discussion has been going on for some time.

Mr. Dake has a list of four problems that he is trying to fix with his patch, which creates an event queue within the kernel and a virtual device for retrieving events from that queue. These problems are:

The current implementation (which invokes /sbin/hotplug for each device event) has performance problems when the number of devices is large.
There is no policy controlling how many /sbin/hotplug processes can be created simultaneously, a shortcoming which can lead to out-of-memory situations.
/sbin/hotplug is not available during the early part of the system initialization process, so early device enumeration is not possible.
Hotplug events can be processed out of order, leading to device directory corruption.

The posting elicited some strongly-worded responses. The general view is that the first three of the problems listed above do not actually exist. The cost of /sbin/hotplug is small relative to the cost of device probing and initialization, so, in the real world, system load and performance are not problems. Early initialization can be handled with initramfs or by reconstructing things in user space from the sysfs tree. The hotplug developers thus feel no pressure to "fix" any of those problems. Linus also chimed in with a condemnation of event daemon schemes.

When the dust settled, however, the problem of event reordering remained. Device events can come quickly, and the vagaries of scheduling, page faults, etc. can cause them to be processed in an order different from that in which they were generated. Some fairly complicated schemes were presented for dealing with this problem, but they were set aside when Andrew Morton suggested the (in retrospect) obvious: add a sequence number to hotplug events. With a unique, increasing sequence number, it is simple for a user-space process to detect (and fix) misordered events. Problem solved.

to post comments

What's needed to fix user-space device enumeration?

Posted Jun 22, 2003 15:22 UTC (Sun) by pimlott (guest, #1535) [Link]

With a unique, increasing sequence number, it is simple for a user-space process to detect (and fix) misordered events. Problem solved.

I'm not a kernel hacker, but I don't think it's that simple. Say hotplug writes the sequence number to a file when it finishes processing an event. When it gets an event, it checks the file against the sequence number of the event. Say event 8 comes in, and the file contains 6. What does hotplug do? It waits for the file to turn 7, of course. What if that never happens? Ok, there better be a timeout. After the timeout, you need to make sure 8 happens before 9, which may also have been waiting.

All doable, but it's a lot of work just to reverse the event stream -> processes transformation done by the kernel.