docs/overview

   1
   2 Instead of heading in on another "proposal" document, I thought I'd send out
   3 this email describing ideas I've had about udev - thanks to the comments I've
   4 received. The idea is starting to mushroom a bit and I'd like to get people's
   5 comments before I go further down the path.
   6
   7 As I see it, we've got a couple goals for udev:
   8
   9 1) dynamic replacement for /dev
  10 2) device naming
  11 3) API to access info about current system devices
  12
  13 I'd like to split these goals into separate subsystems:
  14
  15 1) udev - dynamic replacement for /dev
  16 2) namedev - device naming
  17 3) libsysfs - a standard library for accessing device information on the
  18 system.
  19
  20 Udev
  21 ------
  22
  23 Udev will be responsible for responding to /sbin/hotplug on device events. It
  24 will receive the device class information along with device's sysfs
  25 directory. Udev will call the name_device function from the naming device
  26 subsystem with that information and receive a unique device name in return.
  27 Udev will then query sysfs through the libsysfs for specific device
  28 information required for creating the /dev node like major and minor number.
  29 Once it has the important information, udev will create a /dev entry for the
  30 device, add the device to the in memory table of current devices, and send
  31 notification of the successful event. On a remove call, udev will remove the
  32 /dev entry, remove the device from the in memory table, and send
  33 notification.
  34
  35 Udev will consist of a command udev - to be called from /sbin/hotplug. It will
  36 require the in memory dynamic database/table for keeping track of current
  37 system devices, and a library of routines for accessing that database/table.
  38 Udev will not care about "how" devices are named, that will be separated into
  39 the device naming subsystem. It's presented a common device naming API by the
  40 device naming subsystem to use for naming devices.
  41
  42 namedev
  43 ----------
  44
  45 From comments Martin has made, I've decided to push out the device naming part
  46 of udev into its own "subsystem". The reason is to make this as flexible and
  47 pluggable as possible. The device naming subsystem, or namedev, will present
  48 a standard interface for udev to call for naming a particular device. Under
  49 that interface, system administrators can plug in their own methods for
  50 device naming.
  51
  52 We would provide a default naming scheme. The first prototype implementation
  53 could simply take the sysfs directory passed in with the device name
  54 function, query sysfs for the major and minor numbers, and then look up in a
  55 static device name mapping file the name of the device. The static device
  56 naming file could look just like devices.txt in the Linux kernel's
  57 Documentation directory. Obviously, this isn't a great implementation because
  58 eventually we'd like major an minor numbers to be dynamic.
  59
  60 The default naming scheme in the future would have a set of policies to go
  61 through, these were given to me by Greg. The device naming subsystem would
  62 get the sysfs directory of the to be named device and would use the following
  63 information in order to map the device's name:
  64
  65 1) Label info - like SCSI's UUID
  66 2) Bus Device Number
  67 3) Topology on Bus
  68 4) Kernel Name - DEFAULT
  69
  70 System administrators could use the default naming system or enterprise
  71 computing environments could plug in their Universal Unique Identifier (UUID)
  72 policies. The idea is to make the device naming as flexible and pluggable as
  73 possible.
  74
  75 The device naming subsystem would require accessing sysfs for device
  76 information. It will receive the device's sysfs directory in the call from
  77 udev and use it to get more information to determine naming. The namedev
  78 subsystem will include a standard naming API for udev to use. The default
  79 naming scheme will include a set of functions and a static device naming
  80 file, which will reside in /etc or /var.
  81
  82 libsysfs
  83 --------
  84
  85 Greg may object, but I believe there's a need for a common API to access
  86 device information in sysfs. The device naming subsystem and the udev
  87 subsystem need to take the sysfs directory path and query device information.
  88 Instead of copying code so each one will have to readdir, etc., I've decided
  89 to split out the sysfs calls into a separate library that will sit atop
  90 sysfs. Sysfs callbacks aren't standard across devices, I beleive this is
  91 another reason for creating a common and standard library interface for
  92 querying device information.
  93
  94 Another reason for libsysfs is it satisfies requirements the LTC RAS team has
  95 for getting current system device information. Rather than keeping tons of
  96 information in udev's in memory database, or even querying that database for
  97 the sysfs directory that will require storing extra reference info in memory,
  98 I've decided the RAS requirements can be fulfilled with a library atop sysfs.
  99 Sysfs contains devices currently on the system.
 100
 101 Applications like the Error Log Analysis piece, for example, can query the
 102 sysfs library for device information. ELA gets specific information in an
 103 error message thanks to the dev_* and soon to be proposed netdev_* macros.
 104 One goal of the ELA is to gather as much information about an erroring device
 105 so service engineers and administrators can diagnose the problem. The ELA
 106 will get an error message with the bus id and driver name of the device. It
 107 will then need to query sysfs for other VPD information.
 108
 109 I've used syfs in the name of libsysfs for a reason, I believe sysfs will be
 110 the device tree to use in the future. Until all VPD info is in sysfs, the
 111 library could also make use of /proc, sginfo, and other sources for device
 112 information under the covers so ELA and other applications don' t need to all
 113 have that knowledge.
 114
 115
 116 I'd like to know what everyone thinks about my proposal to split this all up
 117 into three separate subsystems. All comments are welcome.
 118
 119 Thanks,
 120
 121 Dan
 122
 123