Alternative to: Proposal for Writable Device Identifiers

Tom Coughlan coughlan at
Mon Feb 9 06:03:43 PST 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* coughlan at (Tom Coughlan)
George Ericson wrote:

>To set your proposed identifier, there are already functions in SCC
>called Report/Set_Peripheral_Device_Identifier.

The proposal is for a writable device identifier that can be used by
operating systems as the basis for device naming.  There are two problems
with using the Report/Set_Peripheral_Device_Identifier to do this:

1) The writable device identifier needs to be setable for all device types,
not just SCC devices.  Every peripheral that the o.s. user can interact
with needs an o.s. device name.  

2) The writable device identifier needs to be setable for SCC volume sets,
since these are the "devices" that the application client addresses for
user data.  There is a SCC Report/Set Identifier function for Component 
devices and Peripheral devices, but none for Volume sets.

>On your proposal for a new type 4h to be used in the device identifier
>page, I don't see how this is different from type 0h.  

The vendor may use the vendor-specific identifier (type 0h) for some other
completely different purpose.  We must be able to distinguish between a
user written identifier (proposed type 4h) and any other identifiers that
the vendor may put in the Device identification page.  Otherwise, the o.s.
device name will not be what the user intended.  

>I interpret (rash I know) Inquiry vital products data page to already be
>defined to return identifiers set by Set_Peripheral_Device_Identifier as
>type 0h.

Maybe, but that assumption seems tenuous enough to require confirmation with 
the vendor for every product.

The key issue is that the o.s. needs to set and report one writable
persistent identifier for the Volume set, to serve as the basis of the
Volume set's name.

>I don't see a need to generate new mode select/sense pages for these.
>The above commands are sufficient.

I do not agree, for the reasons stated above.

>Two enhancements I would support in
>*	The ability to remove an identifier. 
>	For instance, define bit 0 of byte 10 in the
>       Set_Peripheral_Device_Identifier command as delete.
>*	The ability to set multiple identifiers.  
>	For instance, 
>*	define bit 2 of byte 10 in the Set_Peripheral_Device_Identifier
>	command as add_new.  Otherwise over-write first identifier.
>*	define bit 0 of byte 10 of the
>       Report_Peripheral_Device_Identifier command as report_multiple.  If
>       report_multiple is set, the let bit 7 of byte 0 of the
>       Report_Peripheral_Device_Identifier parameter list be defined as
>       not_last.  Return as many identifiers as possible within the bounds
>       defined by Allocation length.

It would be nice to use the same format and conventions as the Inquiry
device identification page, especially if this data will be reported in
that page also.  It's probably too late for that though.

>A corollary enhancement to Inquiry vital products data page is to
>explicitely allow multiple identifiers of the same type to be returned.

It wouldn't hurt, though I (rashly) thought it was quite clear that multiple
identifiers of the same type were allowed.  One could certainly imagine 
the need for multiple identifiers with the same type, but different values
for Code set or Association. 


* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list