Messages in this thread |  | | Date | Mon, 17 Jun 2002 12:07:06 -0700 | From | Patrick Mansfield <> | Subject | Re: [linux-usb-devel] Re: /proc/scsi/map |
| |
On Mon, Jun 17, 2002 at 11:42:05AM -0500, James Bottomley wrote:
> OK, how about some hardware scenarios: >
> Ah, but that's the scsi-3 spec which (finally) cleaned up this unique name > business. However, for SCSI-2 and before, it was an unholy mess, as the two > examples above illustrate. I agree that for all modern devices which are > SCSI-3 SPC compliant, then just asking for the WWN page probably works. The > question is what to do about all the legacy hardware out there? > > James
Yes, legacy or broken devices need vendor specific code to get a unique serial number or uid, but it is not clear to me that putting the code in user space is better or worse than kernel space. Maybe we need to see some implementations.
For user space get-id code:
What happens at boot time? Do we now need special stripped copies of user space get-id commands to boot from scsi (for use with initrd)? Do we just wait until the system is booted before getting/setting the ID's?
If I build without sg or /proc, should SCSI ID's still be available?
How can I efficiently handle multi-path code without overallocating N Scsi_Devices (where N is the number of paths to each Scsi_Device)?
For kernel implementations, we could add a special entry in the device_list or have a new list mapping vendor+product to a get-the-id function.
Module code could be created that contains the functional code to get an ID, and adds a pointer to the function in device_list or some other list.
User or kernel code could supply a table with a VPD page to use, and an offset or such within the page to a serial number, and flags for other special usage such as appending the LUN value to the serial number.
-- Patrick Mansfield - 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/
|  |