[email protected] said:
> I agree it would be nice to get the ID via user space, but it is not
> that hard to get the ID, and trying the various SCSI INQUIRY pages
> that supply the ID is not complicated.
OK, how about some hardware scenarios:
I've a scsi array (an LSI 6298) which has no WWN page (0x83) but does have a
serial number in the VPD page. However, the VPD serial number is an
identifier for the array *controller* and thus is the *same* for all the LUNs.
For this beast I have to add in the LUN number to the VPD serial number to
get a unique identifier per device. Worse, the LSI 6298 is multi path. Now I
get a different "unique" identifier depending on path (because different
controllers give different VPD serial numbers), so if I want to identify it
uniquely, I have to use some property of the LUN, like partion UUID.
Or, what about an old 8 bit EMC symmetrix. They have no WWN page and they
embed both a LUN and a *path* identifier in the VPD serial number. To get the
globally unique ID for this one, I have to strip off the path part.
> FYI the various SCSI ID pages and such are described in the SCSI
> primaray command for example the following:
> ftp://ftp.t10.org/t10/drafts/spc3/spc3r07.pdf
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
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