Re: "do ata" scsi command?

[Jeff Garzik <jgarzik@pobox.com>]

Jens Axboe wrote:
> On Thu, May 15 2003, Jeff Garzik wrote:
> 
>>In terms of a userspace interface for my ata-over-scsi gadget, I would
>>prefer to use /dev/sg instead of inventing a totally new interface.
>>That, in turn, implies a need for a "do ata taskfile" scsi command,
>>which is sorta like ATAPI in reverse:  we are wrapping a raw ata
>>taskfile inside a scsi cdb.
>>
>>My question is, does an existing standard or spec exist for such an idea?
>>
>>If not, I'll just roll my own.
> 
> 
> For ATAPI/SCSI like stuff, you have SG_IO. No need to invent yet another
> submission interface for that. For ata, you have HDIO_DRIVE_TASKFILE
> which is getting to be sane on the kernel side after Bart cleaned it up.


While technically what you say is correct, I think you're missing what 
I'm aiming for.

Think about it this way:  The SCSI layer provides two or three ways to 
send a SCSI command to a target.  The driver I'm working on presents all 
devices as SCSI, be they ATA or ATAPI.  And underneath the "scsi 
presentation layer", you have ATA[PI] taskfiles as the lower layer.

Userspace has easy and obvious access to the presentation layer.
But how does one directly access the lower layer?

If you like HDIO_DRIVE_TASKFILE, then my preference would be to support 
that ioctl for sending lower layer commands directly to the device, for 
both ATA and ATAPI.  But I don't like HDIO_DRIVE_TASKFILE in this case 
:) and here's why:

ioctl(2) interface itself is very poor and slow compared to 
SCSI-generic's mmap(2) interface.  Also, if you go back to last year 
when Linus was describing his ideal drive command submission interface, 
it purposefully avoided ioctl(2) in favor of a read(2)/write(2) 
interface -- which can be easily extended in one's mind to mmap(2).

So, the goal is to allow efficient userspace access to the taskfile 
submission/response mechanism in my driver, regardless of whether the 
attached device is ATA or ATAPI.  The solution that requires the least 
amount of code, both in the kernel and in userspace, is having a "do 
ata" scsi command.  Because send-scsi-command mechanisms are already 
plentiful in the kernel and userspace, because some of those mechanisms 
are faster than ioctl(2), and because that's heading towards the "Linus 
ideal."

I did consider hdio_drive_taskfile, but that's more code for less 
flexibility, as I see it.  In my case specifically, send-scsi-command is 
essentially talking directly to the low-level driver's standard code path...

The only downside (AFAICS) is that I need to add maybe 50-100 lines of 
code to hdparm.  But I think that's a small price to pay if the keeps 
the driver much more simple.

	Jeff