[PATCH] added initial documentation and gpl licenseudev/v001

1 files changed, 123 insertions, 0 deletions

diff --git a/docs/overview b/docs/overview
new file mode 100644
index 0000000000..6528b058c2
--- /dev/null
+++ b/docs/overview
@@ -0,0 +1,123 @@
+
+Instead of heading in on another "proposal" document, I thought I'd send out 
+this email describing ideas I've had about udev - thanks to the comments I've 
+received. The idea is starting to mushroom a bit and I'd like to get people's 
+comments before I go further down the path.
+
+As I see it, 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
+
+I'd like to split 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. 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 Martin has made, I've decided to push out the device naming part 
+of udev 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, these were given to me by Greg. 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
+--------
+
+Greg may object, but I believe there's 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., I've decided 
+to split out the sysfs calls into a separate library that will sit atop 
+sysfs. Sysfs callbacks aren't standard across devices, I beleive this is 
+another reason for creating a common and standard library interface for 
+querying device information. 
+
+Another reason for libsysfs is it satisfies requirements the LTC RAS team has 
+for getting current system device information. Rather than keeping tons of 
+information in udev's in memory database, or even querying that database for 
+the sysfs directory that will require storing extra reference info in memory, 
+I've decided the RAS requirements can be fulfilled with a library atop sysfs. 
+Sysfs contains devices currently on the system. 
+
+Applications like the Error Log Analysis piece, for example, can query the 
+sysfs library for device information. ELA gets specific information in an 
+error message thanks to the dev_* and soon to be proposed netdev_* macros. 
+One goal of the ELA is to gather as much information about an erroring device 
+so service engineers and administrators can diagnose the problem. The ELA 
+will get an error message with the bus id and driver name of the device. It 
+will then need to query sysfs for other VPD information. 
+
+I've used syfs in the name of libsysfs for a reason, I believe sysfs will be 
+the device tree to use in the future. Until all VPD info is in sysfs, the 
+library could also make use of /proc, sginfo, and other sources for device 
+information under the covers so ELA and other applications don' t need to all 
+have that knowledge. 
+
+
+I'd like to know what everyone thinks about my proposal to split this all up 
+into three separate subsystems. All comments are welcome.
+
+Thanks,
+
+Dan
+
+