Re: "do ata" scsi command?

[Jens Axboe <axboe@suse.de>]

On Fri, May 16 2003, Jeff Garzik wrote:
> 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 

Yes it is yet another interface, I agree...

> 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 

That's basically a block layer property. As long as you queue through
the request queue, then you have this syncronization.

> 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.

Bullshit, only if you do a half-assed implementation.

> >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.

Clearly we are not speaking the same language, since a scsi command
submission interface cannot possibly satisfy the full need for ata. It's
pretty simple. How would you shoehorn any given ata command into a scsi
command?

-- 
Jens Axboe