Are old SCSI tape drives not all created equal?

[Mouse]

> To my surprise, not all SCSI tape drives are created equal.  I was
> under the mistaken assumption that all SCSI tape drives would pretty
> much be abstracted the same way by the SCSI interface.

That's the ideal.  As you discovered, the world is far from ideal.

> Question: So, even though some tape drives physically have a SCSI
> interface, are they different in some other way such as to require
> special software to use them?

Probably.  See below for a brief discussion of what "SCSI" is and how
it's relevant.

> Or maybe there were different SCSI standards?  Or is the standard
> simply imperfect?

I feel reasonably sure each of those holds part of the explanation.

Another issue, especially relevant on this list, is that some drives
date to before the standards were in their current form; they may
conform to early drafts, drafts which are incompatible with the spec we
know today.  Other drives don't conform to any known document, whether
deliberately (customer lockin?) or not (sloppy firmware authors?).

So, yes, some drives - especially older ones - may need drive-specific
code.

SCSI is more than just the physical interface.  Traditional SCSI is a
parallel interface, with a bunch of signals and grounds.  But, layered
atop the physical interface, there is also a command/response protocol
which is, strictly, independent of the physical layer.  (I have seen it
said that the SCSI protocol is very similar to both ATAPI and SAS,
probably because it influenced their design, though I haven't read
enough of any of them to really have a good handle on it myself.)

In particular, a drive may conform to the mechanical and electrical
interface but still be completely off the wall when it comes to the
command/resposne protocol.  To pick a simple example, to read from a
tape[%], current SCSI sends a 0x08 command, which consists of one byte
of opcode, one byte of flag bits, three bytes of buffer length, and one
byte of control bits.  There is no technical reason a drive maker
couldn't implement reads as a 0x72 opcode followed by two bytes of
buffer length and one byte of flag bits; it's not done because
customers would complain that it doesn't work with stock systems and
would switch to other makers which _do_ use the standard commands.

But, drives made before the spec was baked might use nonstandard
commands, especially for operations whose specs were in a state of flux
when the drive was designed.  Look at NetBSD's st.c driver and search
for its quirk table and you can find a list of drives which are known
to need unusual interfacing in various ways.  For example, a drive
identifying itself as "ARCHIVE " and "VIPER 2525 25462" apparently
needs to have a READ done in order to get good MODE SENSE data under at
least some circumstances (ST_Q_SENSE_HELP).

And, of course, some drives may want to support features for which
there is no standardized command.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B