Messages in this thread | | | Date | Mon, 17 Jun 2002 09:53:53 -0700 | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: /proc/scsi/map |
| |
> Any SCSI device can return an ID (i.e. INQUIRY VPD page 0x80 or 0x83), > so the logic need not be in sd. I don't know how removable media should > be handled (not a SCSI device being added/removed from the system), for > tape this is probably not an issue. > ... > >>Here, the usb-storage driver does know about the real device (and already has >>a huge exception table), so it has enough knowledge to probe for an identifier. > > usb-storage could emulate VPD page 0x83 to return the GID, and that could > then be used by the mid-layer or a user level program to extract an ID.
Except that as I recall, that's not practical for all devices; they may not have built in IDs. Hence there need to be topology-based IDs available.
Which is why I had pointed out usb_make_path() ... which returns a stable controller ID for the "CBTU tuple". It isn't going to get re-assigned by changing the bus probe sequence or driver load order. Even PCI has better IDs available than those simple numbers (pci_device.slot_name).
If the driverfs names for all devices are supposed to be using stable IDs (ones that don't change unless at least the hardware gets re-configured) where possible, then those driverfs names will be better answers for the "what is this device's topological ID" than those purely numeric CBTU tuples.
(And they won't address the volume/media/... ID level problems, which are of course a separate issue.)
- 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/
| |