"do ata" scsi command?
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
Quoted 9 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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.
Signature · 1 line
Jens Axboe
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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.
Quoted 8 lines
Quoted 3 lines
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 haveHDIO_DRIVE_TASKFILEwhich 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
Quoted 19 lines · Jeff Garzik
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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.Quoted 8 lines
Quoted 3 lines
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 haveHDIO_DRIVE_TASKFILEwhich is getting to be sane on the kernel side after Bart cleaned it up.
Quoted 7 lines
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.
Quoted 8 lines
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 likeHDIO_DRIVE_TASKFILEin this case :) and here's why:
Quoted 5 lines
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 :)
Quoted 8 lines
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!
Quoted 3 lines
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.
Signature · 1 line
Jens Axboe
Quoted 52 lines · Jens Axboe
Quoted 16 lines · Jeff Garzik
Quoted 14 lines · Jens Axboe
Quoted 9 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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.
Quoted 8 lines
Quoted 3 lines
For ATAPI/SCSI like stuff, you have
SG_IO. No need to invent yet another submission interface for that. For ata, you haveHDIO_DRIVE_TASKFILEwhich 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.
Quoted 6 lines
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 likeHDIO_DRIVE_TASKFILEin 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_IOioctl 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_IOuses 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 :)
Quoted 8 lines
Quoted 1 line
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.
Quoted 2 lines
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
Quoted 75 lines · Jeff Garzik
Quoted 74 lines · Jens Axboe
Quoted 22 lines · Jeff Garzik
Quoted 12 lines · Jens Axboe
Quoted 9 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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?
Quoted 6 lines
Quoted 1 line
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 haveHDIO_DRIVE_TASKFILEwhich is getting to be sane on the kernel side after Bart cleaned it up.Quoted 7 lines
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.
Quoted 8 lines
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 likeHDIO_DRIVE_TASKFILEin this case :) and here's why:Quoted 5 lines
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_IOioctl 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_IOuses 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 :)Quoted 8 lines
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."
Quoted 8 lines
Quoted 5 lines
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_TASKFILEis Yet Another Interface. If a SCSI driver simply implements ->queuecommand, the
Yes it is yet another interface, I agree...
Quoted 10 lines
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.
Quoted 8 lines
* 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.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 2 lines
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?
Signature · 1 line
Jens Axboe
Quoted 2 lines · Jens Axboe
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
Quoted 9 lines · Jeff Garzik
Quoted 2 lines · Jens Axboe
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 lareq_file->data_phaseindrivers/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.
Signature · 1 line
Jens Axboe
Quoted 2 lines · Jens Axboe
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
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Jeff Garzik
Quoted 2 lines · Jens Axboe
How would you shoehorn any given ata command into a scsi command?
Quoted 5 lines
Quoted 1 line
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 lareq_file->data_phaseindrivers/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
Quoted 1 line
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.)
Quoted 8 lines
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...
Signature · 1 line
Luben
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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
Quoted 10 lines · Jeff Garzik
Quoted 7 lines · Jens Axboe
Quoted 5 lines · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would prefer to use
/dev/sginstead 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.
Quoted 7 lines
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.
Quoted 4 lines
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.
Quoted 1 line
(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.
Signature · 1 line
Jens Axboe
Quoted 2 lines · Jens Axboe
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.
Quoted 3 lines
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
Quoted 9 lines · Jeff Garzik
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 ?)
Quoted 5 lines · Andries Brouwer
Quoted 2 lines · Jeff Garzik
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.
Quoted 8 lines
Quoted 3 lines
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.
Signature · 1 line
Luben
Quoted 1 line · Jeff Garzik
In terms of a userspace interface for my ata-over-scsi gadget, I would
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The main point.
Quoted 8 lines
prefer to use
/dev/sginstead 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?
Signature · 1 line
Luben
Quoted 6 lines · Luben Tuikov
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.
Quoted 3 lines
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