Mark Bellon recently announced
release of a tool called "User-Space Device Enumeration," or "uSDE". uSDE
maintains a directory full of device nodes based on hotplug events and
information found in sysfs. It is thus intended to be a user-space
replacement for the devfs filesystem.
Few doubt that the objectives for uSDE make sense. But quite a few
developers have asked why the uSDE developers went off and created their
own system, rather than working on udev (which recently released version 005). Given that the two projects
appear to be trying to do exactly the same thing, it seems strange that the
work is being done twice.
According to Mr. Bellon, uSDE was developed because udev wasn't up to the
needs of Carrier Grade Linux. What needs they were trying to meet are not
entirely clear; his posting is full
of language like "Aggressive device enumeration. Multiple concurrent
policy execution and management." In fact, the actual requirements
imposed by the CGL specification are minimal; as posted by Greg Kroah-Hartman:
OSDL CGL specifies that carrier grade Linux shall provide
functionality such that a device's identity shall be maintained
when it is removed and reinstalled even if it is plugged into a
different bus, slot, or adapter. "Device identity" is the name
of the device presented to user space, and this identity is
assigned based on policies set by the administrator, e.g., based
on location or hardware identification information.
Meeting this requirement with existing tools is not that hard to do.
uSDE appears to be the result of a different design approach. It uses a
complicated plugin architecture to implement different device naming
policies. As a whole, it is rather larger and more complex than udev. It
does provide some functionality that udev is still lacking, including a
devfs emulation module. In general, it shows the signs of having had more
developer time put into it than udev.
But, while uSDE may be a little further developed than udev, it looks set to
lose the fight for developer support and mindshare. The development of
udev has followed the informal rules of kernel hacking: it has been done in
the open, with feedback received along the way. It also doesn't hurt that
udev is the project of a core kernel developer. uSDE, instead, has been
developed in isolation, in competition to an established project,
and was late to enter the public arena. Whether or
not uSDE is, in fact, a better solution, the way in which it has been
developed has put it at a disadvantage relative to its competition.
to post comments)