Yes, ATAPI devices are very similar to SCSI devices, but there are
some small differences.
When I originally wrote the ATAPI --> SCSI host adapter emulation driver,
I added a small SCSI command translation layer in an attempt to cater for
the various ATAPI/SCSI differences, thus allowing the high level Linux SCSI
drivers and the user space applications which are using the /dev/sg interface
to use ATAPI devices unmodified.
Some of the differences which we encounterd up to this point:
- ATAPI cdroms / ATAPI direct access devices
Unfortunately, SFF-8020 and SFF-8070 specify that the "Ansi Revision"
and the "Response Data Format" fields in the INQUIRY packet command
should be set to 2 and 1 respectively (Interestingly, for ATAPI tapes,
QIC-157 specifies "Ansi Revision 2, Response Format 2", probably to
be compatible with the SCSI specifications).
This first caused problems when using ATAPI PD-CD devices (which
are using multiple logical units) -- the Linux SCSI subsytem is
checking the "SCSI Revision" field, and doesn't probe for multiple
luns for devices which are SCSI-0 compliant.
--> I patched the "Ansi Revision" field from 0 to 2.
- We are usually using READ-6/WRITE-6 in the sr.c and sd.c drivers.
Unfortunately, ATAPI devices usually support only the SCSI-10/SCSI-12
variants of various commands.
--> I added a SCSI-6 to SCSI-10 transformation for READ-6/WRITE-6
for ATAPI CDROM and PD-CD drives.
However, the firmware of some ATAPI drives appear to be fully
compatible with the SCSI models -- for example, the ATAPI IOMEGA
ZIP supports READ-6/WRITE-6 directly even though it is not required
to support the commands by the specification.
- MODE_SENSE6/MODE_SELECT6 are being frequently used
--> I added a (buggy) transformation to MODE_SENSE10/MODE_SELECT10,
mainly for CDROMVOLCTRL ioctl in sr.c.
- ATAPI CD-R/CD-RW drives were not working as is with older
versions of cdrecord. This was eventually caused by the above
bug in the transformation of MODE_SENSE/MODE_SELECT.
Joerg added direct support for MODE_SELECT10/MODE_SENSE10 to
the newer versions of cdrecord.
- The ATAPI specifications require that the "PF" bit in the
MODE_SENSE packet command would be set.
Unfortunately, since the "response data format" field in the
INQUIRY command is being set to 1 and not patched to 2 by the
kernel, the ATAPI CD-R drives appear to be "SCSI-1" compatible,
which was causing some ATAPI CD-R drives to be incompatible
(interestingly, some CD-R drives seem to work either way).
At this point, we are wondering which is the preferred way to handle
such ATAPI --> SCSI transformations.
In contranst to my original viewpoint, I now tend to think that handling
the small differences between ATAPI and SCSI devices is best handled at
the application layer, rather than in the ide-scsi driver.
This has the disadvantage that programs will be less likely to work "as is",
but it does have the advantage of being much more flexible.
As suggested by Joerg, it would be best to add a method which will allow us
to disable the layer, at least for access through the /dev/sg driver. The
last patch implemented the following translation options:
- No translation.
- Enabling the ATAPI->SCSI translation layer just for the
kernel (sr, sd, etc).
- Enabling the ATAPI->SCSI translation layer for both
the kernel and for access through /dev/sg.
which were selected using /proc/ide/hdx/settings.
Itai suggested that adding ioctls to the /dev/sg driver would be more
flexible than using /proc/ide to the users of the sg device driver.
I'm currently thinking of the following ioctl scheme:
SG_EMULATED_HOST: (add to sg.c)
returns 1 for emulated SCSI host adapters, 0 for
real SCSI host adapters.
and adding the following ioctls to the ide-scsi driver (and
a mechanism which will call a host adapter specific ioctl
function from scsi_ioctl):
SG_SET_TRANSFORM: (add to ide-scsi.c)
enables (1) /disables (0) the translation layer for access
through /dev/sg.
SG_GET_TRANSFORM: (add to ide-scsi.c)
asks the kernel whether the translation layer is currently
active for /dev/sg.
Gadi