"do ata" scsi command?

"do ata" scsi command?

[Jeff Garzik]

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.

Thanks,

	Jeff

Re: "do ata" scsi command?

[Jens Axboe]

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.

-- 
Jens Axboe

Re: "do ata" scsi command?

[Jeff Garzik]

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

Re: "do ata" scsi command?

[Jens Axboe]

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!

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

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
need the equivalent of sg for ata taskfiles, basically.

Honestly, I think you are getting lost in stupid details. What do you
need this interface for? Is it really performance critical? Main
objective of HDIO_DRIVE_TASKFILE is just to enable user apps to do
whatever they want, they don't necessarily need super duper that last 1%
performance that you could get elsewhere. We are talking diagnostics and
that sort of thing.

Please don't keep reminding me why I've always thought it's a stupid
idea to shoe horn scsi over ata.

-- 
Jens Axboe

Re: "do ata" scsi command?

[Jeff Garzik]

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

Re: "do ata" scsi command?

[Jeff Garzik]

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.


Based on private responses as well as Jens' response, I think my initial 
post must have been terribly unclear.  Let me restate:

I have chosen the standard, existing scsi-generic nterface as the one by 
which raw taskfiles will be sent to devices.  The taskfile will be 
wrapped inside a SCSI cdb.  To me this solution is the most flexibility 
for least cost.

So, what opcode do I choose for "send taskfile"?  Either (a) pick a 
vendor-specific one, or (b) someone else already chose an opcode.

So my post was really these questions:  a or b?  if b, what opcode?

(see, existing interfaces satisfy my needs :))

	Jeff

Re: "do ata" scsi command?

[Jens Axboe]

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

Re: "do ata" scsi command?

[Jens Axboe]

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.
> 
> 
> Based on private responses as well as Jens' response, I think my initial 
> post must have been terribly unclear.  Let me restate:
> 
> I have chosen the standard, existing scsi-generic nterface as the one by 
> which raw taskfiles will be sent to devices.  The taskfile will be 
> wrapped inside a SCSI cdb.  To me this solution is the most flexibility 
> for least cost.

Aha, and how do you wrap an ata command nicely into a scsi cdb? I can
only see it getting ugly.

> So, what opcode do I choose for "send taskfile"?  Either (a) pick a 
> vendor-specific one, or (b) someone else already chose an opcode.
> 
> So my post was really these questions:  a or b?  if b, what opcode?

Irk! I can't believe you are suggesting something like this. Jeff,
please do yourself a favor and think about what you are saying for a
second.

> (see, existing interfaces satisfy my needs :))

I can transport maneur on the back seat of my car if I needed to,
doesn't necessarily make it a brilliant idea just because it's doable.

-- 
Jens Axboe

Re: "do ata" scsi command?

[Jeff Garzik]

Jens Axboe wrote:
> How would you shoehorn any given ata command into a scsi
> command?


Make up a vendor-specific scsi opcode, say 0x70.  Define this opcode 
such that it carries the ATA taskfile registers as cdb parameters.  Look 
at the taskfile as passed in the cdb to classify it (a la 
req_file->data_phase in drivers/ide).  Then execute it.

	Jeff

Re: "do ata" scsi command?

[Jens Axboe]

On Fri, May 16 2003, Jeff Garzik wrote:
> Jens Axboe wrote:
> >How would you shoehorn any given ata command into a scsi
> >command?
> 
> 
> Make up a vendor-specific scsi opcode, say 0x70.  Define this opcode 
> such that it carries the ATA taskfile registers as cdb parameters.  Look 
> at the taskfile as passed in the cdb to classify it (a la 
> req_file->data_phase in drivers/ide).  Then execute it.

As I wrote in the last email, I think this is about the ugliest idea (or
close to) I've ever heard. You can't just go around making up opcodes.

-- 
Jens Axboe

Re: "do ata" scsi command?

[Jeff Garzik]

Jens Axboe wrote:
> Aha, and how do you wrap an ata command nicely into a scsi cdb? I can
> only see it getting ugly.

With 16-byte cdbs it's doable.  With 12-byte it's not.


> Irk! I can't believe you are suggesting something like this. Jeff,
> please do yourself a favor and think about what you are saying for a
> second.


I have.  :)  I think you're missing the additional complexity of doing 
it any other way...

	Jeff

Re: "do ata" scsi command?

[Jeff Garzik]

Jens Axboe wrote:
> As I wrote in the last email, I think this is about the ugliest idea (or
> close to) I've ever heard. You can't just go around making up opcodes.

That's the purpose of vendor-specific opcode ranges.

	Jeff

Re: "do ata" scsi command?

[Andries Brouwer]

On Fri, May 16, 2003 at 12:35:43PM -0400, Jeff Garzik wrote:

> I have chosen the standard, existing scsi-generic nterface as the one by 
> which raw taskfiles will be sent to devices.  The taskfile will be 
> wrapped inside a SCSI cdb.  To me this solution is the most flexibility 
> for least cost.
> 
> So, what opcode do I choose for "send taskfile"?  Either (a) pick a 
> vendor-specific one, or (b) someone else already chose an opcode.
> 
> So my post was really these questions:  a or b?  if b, what opcode?

0xAA ?

(have you seen rfc2143 ?)

Re: "do ata" scsi command?

[Luben Tuikov]

Jeff Garzik wrote:
> In terms of a userspace interface for my ata-over-scsi gadget, I would
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The main point.

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

I read the whole thread.

It seems like you want what the 3ware LLDD is doing.  The format
and specs are closed, but the implementation is open: ioctl
and a char device ioctl.

What you lose is the block/scsi synchronizaion, but if you want
to support _closed_ vendor extensions, that's what you get.

Unless what you want to support has a command mapping already
in SCSI?  Did you check SBC-2, SMC-2, SCC-2, SES-2?  Wouldn't
you find any CDB's there which would fit in?  My guess is not.

Did you also check the mode pages, etc?

-- 
Luben

Re: "do ata" scsi command?

[Luben Tuikov]

Andries Brouwer wrote:
> On Fri, May 16, 2003 at 12:35:43PM -0400, Jeff Garzik wrote:
> 
> 
>>I have chosen the standard, existing scsi-generic nterface as the one by 
>>which raw taskfiles will be sent to devices.  The taskfile will be 
>>wrapped inside a SCSI cdb.  To me this solution is the most flexibility 
>>for least cost.
>>
>>So, what opcode do I choose for "send taskfile"?  Either (a) pick a 
>>vendor-specific one, or (b) someone else already chose an opcode.
>>
>>So my post was really these questions:  a or b?  if b, what opcode?
> 
> 
> 0xAA ?
> 
> (have you seen rfc2143 ?)

This is for a communications device, which according to the
spec is obsolete, but most importantly it's not a block device
opcode.

But the idea isn't new -- AFAIR, the 3ware LLDD/userspace tools
use(d) 0x80 XDWRITE EXTENDED (16) which is _optional_ for block devices.
For what pupose, it's closed, but it will have something to do with
the hdwr array management/id.

-- 
Luben

Re: "do ata" scsi command?

[Jeff Garzik]

Luben Tuikov wrote:
> It seems like you want what the 3ware LLDD is doing.  The format
> and specs are closed, but the implementation is open: ioctl
> and a char device ioctl.
> 
> What you lose is the block/scsi synchronizaion, but if you want
> to support _closed_ vendor extensions, that's what you get.

This is for programming the drive via userspace.  Same purpose as 
HDIO_DRIVE_TASKFILE.  I would rather move non-essential stuff to 
userspace where possible.  Sending taskfiles directly allows one to 
validate the driver without other parts of the kernel getting in the 
way.  That allows me to narrow down problems to my driver, or 
not-my-driver.  :)

But since it's _far_ more contentious than I thought it would be, I'll 
just put it off until later.


> Unless what you want to support has a command mapping already
> in SCSI?  Did you check SBC-2, SMC-2, SCC-2, SES-2?  Wouldn't
> you find any CDB's there which would fit in?  My guess is not.

I would like to create a target that is fully verifyable as SCSI-2, and 
eventually SCSI-3.  So I _do_ want to support such mappings.  But that 
is parallel to the capability of talking directly to the ATA device.

	Jeff

Re: "do ata" scsi command?

[Douglas Gilbert]

Jens Axboe wrote:
> On Fri, May 16 2003, Jeff Garzik wrote:
> 
>>Jens Axboe wrote:
>>
>>>How would you shoehorn any given ata command into a scsi
>>>command?
>>
>>
>>Make up a vendor-specific scsi opcode, say 0x70.  Define this opcode 
>>such that it carries the ATA taskfile registers as cdb parameters.  Look 
>>at the taskfile as passed in the cdb to classify it (a la 
>>req_file->data_phase in drivers/ide).  Then execute it.
> 
> 
> As I wrote in the last email, I think this is about the ugliest idea (or
> close to) I've ever heard. You can't just go around making up opcodes.

Jens,
This subject is going to come up in the future. I'm
thinking about Serial Attached SCSI (SAS) which was
demo-ed at CeBit and various alliances are trying to
get to market by the end of this year.

In SAS we have a pure SCSI command set protocol (SSP),
a management protocol (SMP) and a protocol for tunnelling
the ATA/PI command set/task file over an SAS link (STP)**.
The idea is that users will be able to plug either SAS
or SATA disks into their RAID backplanes.

So we are likely to get a SAS HBA in the SCSI subsystem
(from Justin??) that is an initiator for those three
protocols. How do we handle STP??


** devices called expanders placed between the SAS HBA
and the SATA devices will provide fanout and the
SATA to STP physical/link mapping.

Doug Gilbert

Re: "do ata" scsi command?

[Luben Tuikov]

> In SAS we have a pure SCSI command set protocol (SSP),

Those are not command set protocols, they are _transport_
protocols (specific to the SAS interconnect).  (Command Set
Protocols are things like SBC, RBC, MMC, etc, i.e. ``above''
SAM-3/SPC-3.)

> a management protocol (SMP) and a protocol for tunnelling
> the ATA/PI command set/task file over an SAS link (STP)**.
> The idea is that users will be able to plug either SAS
> or SATA disks into their RAID backplanes.
> 
> So we are likely to get a SAS HBA in the SCSI subsystem
> (from Justin??) that is an initiator for those three
> protocols. How do we handle STP??

STP talks to the ATA application layer (IDE layer).
Its only (business-political) purpose is to allow SATA
over the SAS interconnect.

Overall, that'd be one complicated LLDD if it supported all three...

-- 
Luben