Alternative to: Proposal for Writable Device Identifiers
gericson at clariion.com
Tue Feb 10 05:27:02 PST 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Ericson, George" <gericson at clariion.com>
> -----Original Message-----
> From: coughlan at star.zko.dec.com [SMTP:coughlan at star.zko.dec.com]
> Sent: Monday, February 09, 1998 9:04 AM
> To: Ericson, George; T10 at symbios.com
> Subject: Re: Alternative to: Proposal for Writable Device
> 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
> with using the Report/Set_Peripheral_Device_Identifier to do this:
> 1) The writable device identifier needs to be setable for all device
> not just SCC devices. Every peripheral that the o.s. user can
> 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
> 2) The writable device identifier needs to be setable for SCC volume
> since these are the "devices" that the application client addresses
> user data. There is a SCC Report/Set Identifier function for
> 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
> >page, I don't see how this is different from type 0h.
> The vendor may use the vendor-specific identifier (type 0h) for some
> completely different purpose. We must be able to distinguish between
> user written identifier (proposed type 4h) and any other identifiers
> the vendor may put in the Device identification page. Otherwise, the
> 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
> >defined to return identifiers set by Set_Peripheral_Device_Identifier
> >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.
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 symbios.com
More information about the T10