On Thu, Jun 20, 2002 at 01:12:08PM -0700, Patrick Mochel wrote:
<snip>
>
> Sure. Once device class supports materializes, classes will register and
> can be assigned a dynamic major number even (if they don't already have
> one). As devices (and partitions) are discovered, we can assign minor
> numbers (dynamically!), and call /sbin/hotplug to notify userspace of the
> discovery. It can use that information to create device nodes based on
> user-defined policy.
>
<snip>
The driverfs patch for SCSI that was recently posted was the kernel portion of
a device naming project that is intended to support all devices, at least the
ones that implement to driverfs in a standard way. There are three items that
IMHO should be considered as part of the standard set that driverfs requires:
1. device type - It appears that Pat is heading down this path with the class
type support so maybe this is a no brainer. Currently the scsi
driverfs provides a "type" file to contain this info. The current
strings used are taken from the scsi_device_types[] but should be
replaced with the system wide device types that driverfs will provide.
2. uid - Since topology and discovery order of hardware can change, the
driverfs path names to a device are also subject to change. To
easily identify a device I think it's important that the driverfs
bus implementations be responsible for create a unique identifier.
Since each bus and the devices attached to it will have varying
capabilities for identifying themselves the contents for this file
should probably be a variable length string.
Even for older devices that can't do a great job of providing info to
uniquely identify themselves, the driverfs tree provides the nice
topological context to fall back upon that allows at least as
good of a job to be done as we do today.
The scsi patch currently creates uid info from the INQUIRY evpd pages
and makes it available in the name file. I would prefer to see a
new standard uid file and let the name file contain a descriptive
(non-unique) name.
3. kdev - To create/manage/interface with the device node we need to know the
kdev.
Because of coldplugging this information should be available in each driverfs
device directory. Also, adding the driverfs path name on /sbin/hotplug
events and allowing the consumer to retrieve the info from the filesystem might
help simplify some of these implementations too.
The devnaming utility that is based on this strategy is available at
http://www-124.ibm.com/devreg/
I'd welcome any thoughts or suggestions.
- Mike Sullivan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:24 EST