On Sun, Oct 29, 2006 at 03:33:39PM +0200, Benny Halevy wrote: > >though. > > > I'm not sure I understand exactly when these helpers are to be used. > Can you point me at more info please? > Does this solve the dependency of scsi on struct request for buffer mapping? > (i.e. will this be used in the scsi_init_io() path instead of calling > blk_rq_map_kern() > or the calls to the block layer in scsi_merge_bio()?) No, not at all. It's intended to replace the direct calls to the dma mapping helpers (or kmap calls) in the low level scsi drivers. That way they don't need to know how we represent the storage for the <request_buffer, request_bufflen, use_sg, sglist_len> tuple given the we plan to change it and 95% of the driver don't need to know the details, they just want to dma map whatever is there. > >We might aswell change scsi_execute_async to just support bidi and varlen > >commands in the end. There's very few user and having yet another API > >to submit scsi commands doesn't sound very helpfull. > > > cool. and what about scsi_execute? are you ok with changing it too or > would you > rather add a new synchronous API call for bidi. The reason I'm asking is > that > it doesn't currently allocate a scsi_io_context and therefore it's more > efficient > than the async api. My vague feeling is that I'd prefer not to touch scsi_execute because it's used quite a lot and also in relatively fasthpathes. We'll have to decice whether to update it, introduce a wrapper like scsi_execute_bidi or just opencode that in the callers if there are only a few. > > - you submit your patch that fixes the scsi_execute comment typo > > - you submit your patch to add the VARLEN_CDB opcode > > - you start converting as many as possible drivers to the > > above wrapper API (I already had a big FC card vendor signed up > > for this, but no updates so far..) > > > fine with me, if ok with them too, please send them my way so they can send > us whatever they've done already. I haven't seen anything yet, that's why I added the sneaky comment here. I expect the relevant parties will answer this mail next week ;-) - 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
