> 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/