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
For example, PCI by default doesn't have very good unique information.
About the best it can do is something like munging together:
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
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
This information should be exported, I agree. But, we could theoretically
achieve a state where every device discovered gets a call to
[ 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. ]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/