Messages in this thread | | | Date | Mon, 17 Jun 2002 10:15:12 -0700 | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: /proc/scsi/map |
| |
> The idea behind using hotplug to solve the problem is that with scsimon, a > hotplug insertion event is generated for every SCSI device as it is added. > The script is provided with the information the kernel knows (host, channel, > pun lun, model and vendor inquiry strings---see www.torque.net/scsimon.html
Make that http://www.torque.net/scsi/scsimon.html ... that page is linked from the http://linux-hotplug.sourceforge.net links page, and I'm glad to see it's been updated recently.
> for details). The hotplug script then does the remaining processing to > extract the ID from the device (by ioctls, sending down SCSI commands etc.) > and then binds it into the /dev/volume nodes using the identifier it > determines. > > The result is that however you move the device around (between controllers or > even change its id), it will always show up as its unique /dev/volume name. > > The key philosophy is that the code to make the policy decision for assigning > a unique name isn't cluttering up the kernel, it's in user land where it can > be easily customised.
I think that's a good approach for packaging that naming policy, though I'm not quite sure where it stands in relation to "driverfs". As with "usbfs" it seems to me that there need to be both low-level "topological" and higher level "logical/policy-driven" names. And I'd prefer not to see a multiplicity of approaches for anything except the bus-specific parts (which in this case is "SCSI" even if the transport may be USB); I think I'm not alone in that.
Also, given what I noted earlier about stable IDs, I think SCSI_HOST should be a stable string ID, not an integer that can easily get switched around during system boot.
- Dave
- 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/
| |