Alan wrote:
I do not wish to completely eliminate the current behavior, which passes
through all opcodes to the ATAPI device. You cannot guarantee that
ATA_16 is never used for a vendor-reserved opcode, for example.
For 16 byte commands via SG_IO you know the command is 16 bytes long as
the command length is passed in hdr->cmd_len which becomes rq->cmd_len.
Is that not sufficient to avoid this ATA_16 test if you pass it on to the
required functions ?
Well, its a question of whether you are executing the supplied cdb as an
ATA command or a SCSI command. If executing as an ATA command, libata
needs to intercept it (as Mark's patch does), because few if any ATAPI
devices support the ATA_16 command in the firmware.
The current behavior treats everything as SCSI commands, passed to the
firmware (if a bit massaged, a la INQUIRY), which means there is no way
for userspace to directly address the underlying ATA bus outside of
libata-scsi.
Or am I misunderstanding things completely? :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
