Alternative to: Proposal for Writable Device Identifiers

Ericson, George gericson at
Tue Feb 10 05:27:02 PST 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* "Ericson, George" <gericson at>

> -----Original Message-----
> From:	coughlan at [SMTP:coughlan at]
> Sent:	Monday, February 09, 1998 9:04 AM
> To:	Ericson, George; T10 at
> Subject:	Re: Alternative to: Proposal for Writable Device
> Identifiers
> 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.  
	[GME]  Yes.  So minimally, this would require embedding an SCC
device within LUN 0 of a peripheral device.
	Note that Report/Set_Peripheral_Device_Identifier act against a
Logical Unit managed by the SCC device.  There are no restrictions on
type of peripheral device of the Logical Unit named in the
Report/Set_Peripheral_Device_Identifier commands.

> 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.
	[GME]  (You may be confusing LUN format with peripheral type.)
The Report/Set_Peripheral_Device_Identifier commands are capable of
setting and getting identifiers for Volume Set Logical Units.  Volume
Sets belong to the class of Peripheral Devices. The Peripheral device
types are named in SPC in the Inquiry section. Typically a Volume Set
Logical Unit will have peripheral device type SBC or SSC.  

> >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.  
	[GME]  OK, you are distinquishing IDs set by device vendor
supplied driver code or utilities from IDs set by other suppliers of
code/utilities.  I think I know what you are trying to accomplish.
However, here are several questions that should be considered in your
proposal.  I don't have solutions.  
*	If there are several layers of vendors, does only the bottom
layer set type 0 and all others set type 4?  
*	If there are several layers of user added value, then how do
they coordinate to agree on intended format? 

> >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.   
	[GME] A suggested general fix for this is to change the SCC
*	define byte 3 of the Set Peripheral Device/Component Identifier
service action to be the identifier type as defined in Table 111 of

	The default action for existing commands would then defined to
be type 0.

George Ericson

CLARiiON                              A Data General Corporation
Coslin Drive, MS-C44              Tel: 508 480-7349 
Southboro, Ma. 01772             Fax: 508 480-7913

* 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