attached MC Op Codes

Hans Ridder ridder at zso.dec.com
Fri Dec 9 10:51:40 PST 1994


John Lohmeyer wrote:
>Hans-Gabriel Ridder wrote:
>>Note that I never seen X3T9.2/92-006r1, so just slap me if I'm way off
>>base on anything, but I'm not too thrilled with what it appears to be
>>doing to the standard.
>
>I am sending a copy of the document to you by separate email.  If anyone 
>else wants a copy, drop me a note.  It is also on the SCSI BBS as 
>94-006r1.txt.

Thanks!  (again)  That's better service than an ftp-by-mail server.  ;-)

>Actually, [drivers deciding which opcode to use] isn't quite what I had
>in mind.  In fact, I did not expect to see drivers written to deal with
>both attached and non-attached medium changers, but I do not want to
>preclude such drivers if they are indeed useful.

OK, but not doing it in the driver just moves the problem.  At least for
applications that want to support the maximum number of medium changer
implementations possible (that's one reason for standards.)  Some
software somewhere is going to have to check if the medium changer is
attached or not.  If it isn't in the driver then it's just moved higher
up.  Like in the application.

One thing I hope that device standards do is reduce or eliminate the
number of these sorts of checks applications (or drivers, for that
matter,) have to make.

>The intent of the committee decision to support attached medium
>changers was to simplify life for low-end changer applications.

And that's a fine goal.  One that I agree with.  But I believe the
solution is flawed, and it's unraveling.

>The SCSI-2 medium changer model uses a separate LU (perhaps on a
>separate SCSI device) from the one or more LUs that read and write the
>medium. [...]  But there is no defined way for an initiator to discover
>(through the interface) the association of the separate LUs.  This
>association is changer and/or system specific.

What about the READ ELEMENT STATUS Data transfer element descriptor?

>The intent of the attached medium changer model was to permit simple
>changer devices to share the same LU with the read/write device.  This
>solves the association problem and enables some simple changer products
>(e.g., a device with 6 pieces of media and a single CDROM reader).
>These products can share a single SCSI protocol chip and a single
>processor between the changer function and the player function.

They could share the protocol chip and processor and also use a separate
LUN for the medium changer.  I know of several products that already do
this.

>They will happen (have happened?) whether or not we choose to document
>them.

Perhaps, but if it is not documented, they will not be SCSI-<n>
compliant and the market will decide.  I don't think you really believe
the purpose of the committee is to merely document what the vendors are
doing.

>The problem we were attempting to solve is the association problem, not
>the inability of some systems to cope with nonzero LUNs.  Of course,
>this solution also helps with that problem.
>
>A second problem that was being addressed was the need for a separate
>medium changer driver.  The attached medium changer model was simple
>enough to imbed the changer control in the device driver.  This is why
>I did not expect common driver software.

Both of these can already be solved without X3T9.2/92-006r1.  A device
with a medium changer as a separate LUN could correctly fill in the SCSI
ID, LU, and NotBus fields of the READ ELEMENT STATUS Data transfer
element descriptor, solving the association problem just as well as the
attached medium changer proposal.  The driver of the read/write device
could check all the other LUNs on the same SCSI ID and provide the
medium changer driver functionality, solving the separate driver
problem.

For that matter, a device with a medium changer as a separate SCSI ID
could also correctly fill in the Data transfer element descriptor, and
the read/write device driver could also check other SCSI IDs for a
medium changer device and provide the driver functionality.

>John

-hans
--
  Hans-Gabriel Ridder <ridder at zso.dec.com>
  Storage Management Software
  DECwest Engineering, Bellevue, Washington, USA
  "I'd rather be writing MACRO-20!"




More information about the T10 mailing list