From: Jens Axboe <jens.axboe@xxxxxxxxxx> Subject: Re: RFC: SCSI Generic version 4 interface Date: Thu, 7 Dec 2006 09:30:20 +0100 > On Thu, Dec 07 2006, FUJITA Tomonori wrote: > > From: Jens Axboe <jens.axboe@xxxxxxxxxx> > > Subject: Re: RFC: SCSI Generic version 4 interface > > Date: Thu, 7 Dec 2006 09:06:59 +0100 > > > > > On Thu, Dec 07 2006, FUJITA Tomonori wrote: > > > > From: Jens Axboe <jens.axboe@xxxxxxxxxx> > > > > Subject: Re: RFC: SCSI Generic version 4 interface > > > > Date: Tue, 7 Nov 2006 16:31:48 +0100 > > > > > > > > > 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. > > > > > > > > sg4 can be implemented on bsg nicely, I think. But why does the > > > > current bsg support sg3 partially? Do you plan to add the rest of sg3 > > > > (which doesn't work nicely) to bsg? > > > > > > What parts of sg v3 are missing? It's been a while since I implemented > > > that stuff, so I forget if I knowingly left out some features. > > > > SG_FLAG_MMAP_IO, indirect IO, probably I miss something more. > > bsg chooses the best way to handle the buffers on its own right now, in > my opinion sg has grown too many "features" that aren't very useful. I agree. But if bsg replaces sg3 code, it supports the full features, doesn't it? If bsg does not replace sg3 code, we have more duplication. I think it would be nice for bsg to support only sg4 (does not support some of the old sg3 interfaces) and not add sg4 support to sg.c and scsi_ioctl.c (of course they can share some code). Oh, bsg's sg3 doesn't work on 32-bit userspace and 64-bit kernel too if applicationos use the iovec interface, does it? > If the buffer and length are properly aligned, bsg does direct > io. If not, it does indirect. Yeah. > mmap io may be useful, we could add that if anyone is actually using > it. sg mmap io is tricky. sg_io_hdr doesn't have a mapped address, instead, the sg driver keeps a mapped address when an application calls mmap (that means sg cannot handle multiple mmap io requests simultaneously). - 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
