1------------------------------------------------------------------------- 2 This is a proposal from the early days of udev. A lot of the things 3 mentioned here are implemented differently and most of the features 4 implemented in udev are not part of that document. 5 This document is only kept in the tree for sentimental reasons. 6------------------------------------------------------------------------- 7 8We've got a couple of goals for udev: 9 101) dynamic replacement for /dev 112) device naming 123) API to access info about current system devices 13 14Splitting these goals into separate subsystems: 15 161) udev - dynamic replacement for /dev 172) namedev - device naming 183) libsysfs - a standard library for accessing device information on the 19 system. 20 21Udev 22------ 23 24Udev will be responsible for responding to /sbin/hotplug on device 25events. It will receive the device class information along with 26device's sysfs directory. Udev will call the name_device function from 27the naming device subsystem with that information and receive a unique 28device name in return. Udev will then query sysfs through the libsysfs 29for specific device information required for creating the /dev node like 30major and minor number. Once it has the important information, udev 31will create a /dev entry for the device, add the device to the in memory 32table of current devices, and send notification of the successful event 33through a D-BUS message. On a remove call, udev will remove the /dev 34entry, remove the device from the in memory table, and send 35notification. 36 37Udev will consist of a command udev - to be called from /sbin/hotplug. 38It will require the in memory dynamic database/table for keeping track 39of current system devices, and a library of routines for accessing that 40database/table. Udev will not care about "how" devices are named, that 41will be separated into the device naming subsystem. It's presented a 42common device naming API by the device naming subsystem to use for 43naming devices. 44 45 46 47namedev 48---------- 49 50From comments people have made, the device naming part of udev has been 51pushed into its own "subsystem". The reason is to make this as flexible 52and pluggable as possible. The device naming subsystem, or namedev, will 53present a standard interface for udev to call for naming a particular 54device. Under that interface, system administrators can plug in their 55own methods for device naming. 56 57We would provide a default naming scheme. The first prototype 58implementation could simply take the sysfs directory passed in with the 59device name function, query sysfs for the major and minor numbers, and 60then look up in a static device name mapping file the name of the 61device. The static device naming file could look just like devices.txt 62in the Linux kernel's Documentation directory. Obviously, this isn't a 63great implementation because eventually we'd like major an minor numbers 64to be dynamic. 65 66The default naming scheme in the future would have a set of policies to 67go through in order to determine the name of the device. The device 68naming subsystem would get the sysfs directory of the to be named device 69and would use the following information in order to map the device's 70name: 71 721) Label info - like SCSI's UUID 732) Bus Device Number 743) Topology on Bus 754) Kernel Name - DEFAULT 76 77System administrators could use the default naming system or enterprise 78computing environments could plug in their Universal Unique Identifier 79(UUID) policies. The idea is to make the device naming as flexible and 80pluggable as possible. 81 82The device naming subsystem would require accessing sysfs for device 83information. It will receive the device's sysfs directory in the call 84from udev and use it to get more information to determine naming. The 85namedev subsystem will include a standard naming API for udev to use. 86The default naming scheme will include a set of functions and a static 87device naming file, which will reside in /etc or /var. 88 89 90 91libsysfs 92-------- 93 94There is a need for a common API to access device information in sysfs. 95The device naming subsystem and the udev subsystem need to take the 96sysfs directory path and query device information. Instead of copying 97code so each one will have to readdir, etc., splitting this logic of 98sysfs calls into a separate library that will sit atop sysfs makes more 99sense. Sysfs callbacks aren't standard across devices, so this is 100another reason for creating a common and standard library interface for 101querying device information. 102