We've got a couple goals for udev: 1) dynamic replacement for /dev 2) device naming 3) API to access info about current system devices Splitting these goals into separate subsystems: 1) udev - dynamic replacement for /dev 2) namedev - device naming 3) libsysfs - a standard library for accessing device information on the system. Udev ------ Udev will be responsible for responding to /sbin/hotplug on device events. It will receive the device class information along with device's sysfs directory. Udev will call the name_device function from the naming device subsystem with that information and receive a unique device name in return. Udev will then query sysfs through the libsysfs for specific device information required for creating the /dev node like major and minor number. Once it has the important information, udev will create a /dev entry for the device, add the device to the in memory table of current devices, and send notification of the successful event through a D-BUS message. On a remove call, udev will remove the /dev entry, remove the device from the in memory table, and send notification. Udev will consist of a command udev - to be called from /sbin/hotplug. It will require the in memory dynamic database/table for keeping track of current system devices, and a library of routines for accessing that database/table. Udev will not care about "how" devices are named, that will be separated into the device naming subsystem. It's presented a common device naming API by the device naming subsystem to use for naming devices. namedev ---------- From comments people have made, the device naming part of udev has been pushed into its own "subsystem". The reason is to make this as flexible and pluggable as possible. The device naming subsystem, or namedev, will present a standard interface for udev to call for naming a particular device. Under that interface, system administrators can plug in their own methods for device naming. We would provide a default naming scheme. The first prototype implementation could simply take the sysfs directory passed in with the device name function, query sysfs for the major and minor numbers, and then look up in a static device name mapping file the name of the device. The static device naming file could look just like devices.txt in the Linux kernel's Documentation directory. Obviously, this isn't a great implementation because eventually we'd like major an minor numbers to be dynamic. The default naming scheme in the future would have a set of policies to go through in order to determine the name of the device. The device naming subsystem would get the sysfs directory of the to be named device and would use the following information in order to map the device's name: 1) Label info - like SCSI's UUID 2) Bus Device Number 3) Topology on Bus 4) Kernel Name - DEFAULT System administrators could use the default naming system or enterprise computing environments could plug in their Universal Unique Identifier (UUID) policies. The idea is to make the device naming as flexible and pluggable as possible. The device naming subsystem would require accessing sysfs for device information. It will receive the device's sysfs directory in the call from udev and use it to get more information to determine naming. The namedev subsystem will include a standard naming API for udev to use. The default naming scheme will include a set of functions and a static device naming file, which will reside in /etc or /var. libsysfs -------- There is a need for a common API to access device information in sysfs. The device naming subsystem and the udev subsystem need to take the sysfs directory path and query device information. Instead of copying code so each one will have to readdir, etc., splitting this logic of sysfs calls into a separate library that will sit atop sysfs makes more sense. Sysfs callbacks aren't standard across devices, so this is another reason for creating a common and standard library interface for querying device information.