[PATCH] updated the documentation.
This commit is contained in:
parent
1e7a3f9e11
commit
1c8c0f6212
141
docs/overview
141
docs/overview
|
@ -1,16 +1,11 @@
|
||||||
|
|
||||||
Instead of heading in on another "proposal" document, I thought I'd send out
|
We've got a couple goals for udev:
|
||||||
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
|
1) dynamic replacement for /dev
|
||||||
2) device naming
|
2) device naming
|
||||||
3) API to access info about current system devices
|
3) API to access info about current system devices
|
||||||
|
|
||||||
I'd like to split these goals into separate subsystems:
|
Splitting these goals into separate subsystems:
|
||||||
|
|
||||||
1) udev - dynamic replacement for /dev
|
1) udev - dynamic replacement for /dev
|
||||||
2) namedev - device naming
|
2) namedev - device naming
|
||||||
|
@ -20,47 +15,53 @@ system.
|
||||||
Udev
|
Udev
|
||||||
------
|
------
|
||||||
|
|
||||||
Udev will be responsible for responding to /sbin/hotplug on device events. It
|
Udev will be responsible for responding to /sbin/hotplug on device
|
||||||
will receive the device class information along with device's sysfs
|
events. It will receive the device class information along with
|
||||||
directory. Udev will call the name_device function from the naming device
|
device's sysfs directory. Udev will call the name_device function from
|
||||||
subsystem with that information and receive a unique device name in return.
|
the naming device subsystem with that information and receive a unique
|
||||||
Udev will then query sysfs through the libsysfs for specific device
|
device name in return. Udev will then query sysfs through the libsysfs
|
||||||
information required for creating the /dev node like major and minor number.
|
for specific device information required for creating the /dev node like
|
||||||
Once it has the important information, udev will create a /dev entry for the
|
major and minor number. Once it has the important information, udev
|
||||||
device, add the device to the in memory table of current devices, and send
|
will create a /dev entry for the device, add the device to the in memory
|
||||||
notification of the successful event. On a remove call, udev will remove the
|
table of current devices, and send notification of the successful event
|
||||||
/dev entry, remove the device from the in memory table, and send
|
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.
|
notification.
|
||||||
|
|
||||||
Udev will consist of a command udev - to be called from /sbin/hotplug. It will
|
Udev will consist of a command udev - to be called from /sbin/hotplug.
|
||||||
require the in memory dynamic database/table for keeping track of current
|
It will require the in memory dynamic database/table for keeping track
|
||||||
system devices, and a library of routines for accessing that database/table.
|
of current system devices, and a library of routines for accessing that
|
||||||
Udev will not care about "how" devices are named, that will be separated into
|
database/table. Udev will not care about "how" devices are named, that
|
||||||
the device naming subsystem. It's presented a common device naming API by the
|
will be separated into the device naming subsystem. It's presented a
|
||||||
device naming subsystem to use for naming devices.
|
common device naming API by the device naming subsystem to use for
|
||||||
|
naming devices.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
namedev
|
namedev
|
||||||
----------
|
----------
|
||||||
|
|
||||||
From comments Martin has made, I've decided to push out the device naming part
|
From comments people have made, the device naming part of udev has been
|
||||||
of udev into its own "subsystem". The reason is to make this as flexible and
|
pushed into its own "subsystem". The reason is to make this as flexible
|
||||||
pluggable as possible. The device naming subsystem, or namedev, will present
|
and pluggable as possible. The device naming subsystem, or namedev, will
|
||||||
a standard interface for udev to call for naming a particular device. Under
|
present a standard interface for udev to call for naming a particular
|
||||||
that interface, system administrators can plug in their own methods for
|
device. Under that interface, system administrators can plug in their
|
||||||
device naming.
|
own methods for device naming.
|
||||||
|
|
||||||
We would provide a default naming scheme. The first prototype implementation
|
We would provide a default naming scheme. The first prototype
|
||||||
could simply take the sysfs directory passed in with the device name
|
implementation could simply take the sysfs directory passed in with the
|
||||||
function, query sysfs for the major and minor numbers, and then look up in a
|
device name function, query sysfs for the major and minor numbers, and
|
||||||
static device name mapping file the name of the device. The static device
|
then look up in a static device name mapping file the name of the
|
||||||
naming file could look just like devices.txt in the Linux kernel's
|
device. The static device naming file could look just like devices.txt
|
||||||
Documentation directory. Obviously, this isn't a great implementation because
|
in the Linux kernel's Documentation directory. Obviously, this isn't a
|
||||||
eventually we'd like major an minor numbers to be dynamic.
|
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
|
The default naming scheme in the future would have a set of policies to
|
||||||
through, these were given to me by Greg. The device naming subsystem would
|
go through in order to determine the name of the device. The device
|
||||||
get the sysfs directory of the to be named device and would use the following
|
naming subsystem would get the sysfs directory of the to be named device
|
||||||
information in order to map the device's name:
|
and would use the following information in order to map the device's
|
||||||
|
name:
|
||||||
|
|
||||||
1) Label info - like SCSI's UUID
|
1) Label info - like SCSI's UUID
|
||||||
2) Bus Device Number
|
2) Bus Device Number
|
||||||
|
@ -68,56 +69,28 @@ information in order to map the device's name:
|
||||||
4) Kernel Name - DEFAULT
|
4) Kernel Name - DEFAULT
|
||||||
|
|
||||||
System administrators could use the default naming system or enterprise
|
System administrators could use the default naming system or enterprise
|
||||||
computing environments could plug in their Universal Unique Identifier (UUID)
|
computing environments could plug in their Universal Unique Identifier
|
||||||
policies. The idea is to make the device naming as flexible and pluggable as
|
(UUID) policies. The idea is to make the device naming as flexible and
|
||||||
possible.
|
pluggable as possible.
|
||||||
|
|
||||||
The device naming subsystem would require accessing sysfs for device
|
The device naming subsystem would require accessing sysfs for device
|
||||||
information. It will receive the device's sysfs directory in the call from
|
information. It will receive the device's sysfs directory in the call
|
||||||
udev and use it to get more information to determine naming. The namedev
|
from udev and use it to get more information to determine naming. The
|
||||||
subsystem will include a standard naming API for udev to use. The default
|
namedev subsystem will include a standard naming API for udev to use.
|
||||||
naming scheme will include a set of functions and a static device naming
|
The default naming scheme will include a set of functions and a static
|
||||||
file, which will reside in /etc or /var.
|
device naming file, which will reside in /etc or /var.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
libsysfs
|
libsysfs
|
||||||
--------
|
--------
|
||||||
|
|
||||||
Greg may object, but I believe there's a need for a common API to access
|
There is a need for a common API to access device information in sysfs.
|
||||||
device information in sysfs. The device naming subsystem and the udev
|
The device naming subsystem and the udev subsystem need to take the
|
||||||
subsystem need to take the sysfs directory path and query device information.
|
sysfs directory path and query device information. Instead of copying
|
||||||
Instead of copying code so each one will have to readdir, etc., I've decided
|
code so each one will have to readdir, etc., splitting this logic of
|
||||||
to split out the sysfs calls into a separate library that will sit atop
|
sysfs calls into a separate library that will sit atop sysfs makes more
|
||||||
sysfs. Sysfs callbacks aren't standard across devices, I beleive this is
|
sense. Sysfs callbacks aren't standard across devices, so this is
|
||||||
another reason for creating a common and standard library interface for
|
another reason for creating a common and standard library interface for
|
||||||
querying device information.
|
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
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue