attached MC Op Codes

Lohmeyer, John JLOHMEYE at cosmpdaero.ftcollinsco.ncr.com
Thu Dec 8 15:39:00 PST 1994


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.

>John Lohmeyer wrote:
>>"Ralph Weber -- VMS -- ZKO3-4/U14 wrote:"
>>>
>>> The current operation code usage of the SET CD-ROM SPEED defeats this 
goal
>>> for CD-ROM devices.
>>
>>Perhaps a way out of this box is to define a new and/or optional opcode
>>for the READ ELEMENT STATUS command in the attached medium changer model.
>
>So now every time I want to do a READ ELEMENT STATUS I first have to
>check to see if it's an attached Medium Changer and send one of two
>opcodes?  No thanks!

Actually, that 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.

The intent of the committee decision to support attached medium changers was 
to simplify life for low-end changer applications.  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.  This permits an 
elaborate functionality with multiple robotics and more than one read/write 
device per changer.  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.

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 will happen (have happened?) whether 
or not we choose to document them.

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.

If common drivers are really likely to happen, then I'd suggest that we 
create a new opcode for the READ ELEMENT STATUS command that is valid (and 
recommended) in both models.  The pain of picking which opcode to use would 
still occur for a driver that must work with both SCSI-2 and SCSI-3 changer 
devices, but after a few years, we would all be using the new opcode.

John

 --
John Lohmeyer                      E-Mail: 
 John.Lohmeyer at FtCollinsCO.NCR.COM
NCR Microelectronics                Voice:  719-573-3362
1635 Aeroplaza Dr.                    Fax:  719-574-5462
Colo Spgs, CO 80916              SCSI BBS:  719-574-0424 300--14400 baud




More information about the T10 mailing list