Jens Axboe wrote:
> On Tue, Nov 07 2006, Jeff Garzik wrote:
>> Douglas Gilbert wrote:
>>> I was asked to put together a proposal in May this
>>> year for a new SCSI Generic interface structure. This
>>> is the same structure that is used by the block layer
>>> SG_IO ioctl. A few people have asked whether I had forgotten
>>> that I agreed to write the proposal. So here it is. Those
>>> who have seen it have made comments, some of which have
>>> been incorporated.
>>>
>>> Some shortcomings of the sg version 3 interface are:
>>> - can't handle commands with bidirectional data (either
>>> can the SCSI subsystem at the moment)
>>> - if it was a bit more general it could carry other
>>> request/response protocols (e.g. Task Management
>>> Functions and SMP in Serial Attached SCSI)
>>> - no way of associating a task attribute or task tag
>>> with a SCSI command
>> Why avoid Jens Axboe's bsg?
>>
>> It seems like that is already a good interface for carrying other
>> req/resp protocols.
>
> I don't think Doug is avoiding that (if you are Doug, please do explain
> :-), but rather outlining the next generation command format that bsg
> should support for future use.
In the simplest case this is just the next generation
version of the sg_io_hdr structure used by the SG_IO
ioctl interface. It pitches at about the same level as
modern SCSI transports (e.g. FCP, SAS and iSCSI). It
leaves session and addressing issues, with the exception
(arguably) of tags, to others. The "others" could include
the bsg driver or perhaps a transport layer/driver.
Reference:
SAM-4 version 7 section 5.1 "The Execute command
procedure call"
http://www.t10.org/ftp/t10/drafts/sam4/sam4r07.pdf
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
