Re: "do ata" scsi command?

[Jeff Garzik <jgarzik@pobox.com>]

Jens Axboe wrote:
> On Fri, May 16 2003, Jeff Garzik wrote:
> 
>>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.
> 
> 
> I think that way of thinking is screwed. You cannot shove everything
> into a SCSI command, you need a lower level interface for that.
> 
> 
>>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).
> 
> 
> Well that's a given, SG_IO ioctl is just one way of doing it. I surely
> wouldn't mind (and have thought about doing myself) binding a given
> device to /dev/sg* (or whatever) and using regular read/write on those
> char devices instead.
> 
> It just so happens that the majority of SG_IO uses is cd burning, and
> it's sufficiently fast for that. I can even drive a scsi disk at full
> throttle with basically cpu cost. So it's not that slow. But I do agree
> with the sentiment. Any form of asynch io won't really fly of course,
> and an ioctl interface isn't actually the holy grail :)
> 
> 
>>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."
> 
> 
> They are too plentiful...
> 
> So make a nicer interface for HDIO_DRIVE_TASKFILE? If you want to add
> Yet Another Command submission interface, you damn well better make it
> the final one!

See, I think about it this way:  HDIO_DRIVE_TASKFILE is Yet Another 
Interface.  If a SCSI driver simply implements ->queuecommand, the 
interface doesn't matter!  Existing code and interfaces takes care of 
the rest.

* If I use HDIO_DRIVE_TASKFILE, that's additional ioctl-handling code in 
a SCSI driver to support two command-submission interfaces, instead of one.

* If I create a better-HDIO_DRIVE_TASKFILE, that's design of a new 
interface, plus additional handling code in a SCSI driver to support two 
command-submission interfaces, instead of one.

* Or, my solution, no additional code, using existing command-submission 
interfaces.

So basically my question back to you is, why should I have two separate 
command submissions interfaces when one will do?  :)

Think about it...   the SCSI layer does all this synchronization and 
command queueing for us.  If the raw taskfile is NOT sent as a SCSI 
command, then suddenly there is tons of additional complexity inside the 
driver to handle taskfile queueing and synchronization of two ATA 
taskfile sources:  standard mid-layer stuff, and HDIO_DRIVE_TASKFILE.


> Let me ask you this then, just to be sure. Do you agree that whatever
> interface that takes a scsi command cannot satisfy all your needs? You

No, I don't agree.

Existing interfaces satisfy my needs.

	Jeff