Re: [PATCH] sg: increase sglist_len of the sg_scatter_hold structure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 08 Aug 2007 12:20:43 -0500
Mike Christie <michaelc@xxxxxxxxxxx> wrote:

> Mike Christie wrote:
> > For drivers like sg and st, do mean the the sg list that is passed to 
> > functions like scsi_execute_async? If we kill that argument, and instead 
> > have sg.c and other scsi_execute_async callers just call blk helpers 
> > like blk_rq_map_user then we would not have to worry about drivers like 
> > sg needing to know about chaining right? I mean sg.c would not every 
> > interact with a scatterlist. It would just interact with a request and 
> > the blk helpers map data for it.
> 
> There should be a return there.
> 
>   The scatterlist that sg and st interact
> > with is bogus. It gets thrown away in scsi_execute_async and is only 
> > used for book keeping.
> 
> I mean currently the scatterlist that sg and st use is bogus and gets 
> thrown away. If we convert sg and st to use blk_rq_map_user then those 
> drivers will not have to interact with a scatterlist at all.

Yeah, we should kill scsi_execute_async. sg should not be the consumer
even if the block layer has functions to allocate chaining sg.

Right now I'm happy as long as scsi-ml has the simple routine to
allocate chaining sg like Jens's branch. So we might easily move it to
the block layer or the block layer might just take care of the sg list
for scsi-ml, etc in the future.
-
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux