Re: [PATCH] /proc/scsi/map

[sullivan <sullivan@austin.ibm.com>]

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