> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B