> 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.
Yes, they are pretty much the same thing.
> 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.
Yes, I agree. UUIDs are needed to do any type of persistant naming (well).
As you say, there are varying ways for determining the UUID, and some ways
may not be present for some devices. It will be up to the various driver
levels to determine if they can determine a better UUID than higher level
layers.
For example, PCI by default doesn't have very good unique information.
About the best it can do is something like munging together:
<bus><device><function><class><subclass>
If that device is a network card, the class driver can set the UUID of the
device to the MAC of the device. (Network cards won't be named, but it's
only an example). (Or, the label of a disk).
Further, if the device driver knows an even better way to ID the device,
e.g. via a serial number on the device, it can do so.
Some buses and their driver won't have to worry, since that information is
mandatory in the devices.
> 3. kdev - To create/manage/interface with the device node we need to know the
> kdev.
Sure. I don't have objections to this. It will likely become obvious that
we need this later on...
> 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.
This information should be exported, I agree. But, we could theoretically
achieve a state where every device discovered gets a call to
/sbin/hotplug.
[ With initramfs, we could have the rootfs partition mounted before we
start probing for any devices. As long as that had /sbin/hotplug, and the
means and policy to name devices, it should work. ]
-pat
-
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:25 EST