Messages in this thread |  | | | Date | Wed, 28 Jan 1998 16:18:31 +0300 (IST) | | From | Gadi Oxman <> | | Subject | Re: Request for help with cdrecord and HP7100 |
| |
> This mail, however, seems to suggest that there are some on-going > issues with the design of the generic interface, and with some > incompatibilities between the SCSI and ATAPI command sets, and that > these incompatibilities are being hidden in the device drivers.
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
|  |