Re: [PATCH 00/10] sg buffer copy helper functions

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

 



On Wed, 12 Mar 2008 09:28:56 +0900
FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:

> On Wed, 12 Mar 2008 09:14:00 +0900
> FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:
> 
> > On Tue, 11 Mar 2008 16:09:26 -0400 (EDT)
> > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > > On Tue, 11 Mar 2008, FUJITA Tomonori wrote:
> > > 
> > > > On Mon, 10 Mar 2008 16:10:36 +0200
> > > > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> > > 
> > > > > Have you had a look at drivers/usb/storage/protocol.c usb_stor_access_xfer_buf() ?
> > > > > It looks like it could also use these, but there they have a twist where they want
> > > > > to do it in parts. Do you think that the code there could also use the helpers 
> > > > > presented here somehow? (I know that one of the USB guys was asking about it)
> > > > 
> > > > I've not. If the USB people are eager to use the new APIs, I'll try
> > > > though I prefer to keep them simple.
> > > 
> > > It would be great if the code could be removed from usb-storage and put
> > > in a central library.  The problem is, as Boaz mentioned, that some of
> > > the subdrivers need to transfer their data in pieces.
> > 
> > I'm fine with add a trick for USB to the APIs as long as USB people
> > inspect and test the trick ;)
> > 
> > 
> > > It may be that the device is able to send or receive only a few blocks 
> > > at a time, or it may be that the blocks aren't stored in continguous 
> > > locations on the device.  Either way, the drivers need to do multiple 
> > > transfers, each starting from where the previous one left off.
> > > 
> > > It shouldn't be too hard to adjust your code to make this work.  
> > > Instead of passing sgl and nents directly to sg_copy_buffer(), pass a
> > > pointer to a structure containing fields for sgl, nents, n, sg_off, and
> > > sg_copy.  Then the caller could retain the ending values for use in a
> > > later call.
> > > 
> > > Does this sound reasonable?
> > 
> > How about this?
> > 
> > diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> > index a3d567a..8951e3c 100644
> > --- a/include/linux/scatterlist.h
> > +++ b/include/linux/scatterlist.h
> > @@ -213,6 +213,13 @@ int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int, gfp_t,
> >  		     sg_alloc_fn *);
> >  int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
> >  
> > +int sg_copy_buffer(struct scatterlist **sgl, unsigned int nents,
> > +		   unsigned long *offset, void *buf, int buflen, int to_buffer);
> > +int sg_copy_from_buffer(struct scatterlist *sgl, unsigned int nents,
> > +			void *buf, int buflen);
> > +int sg_copy_to_buffer(struct scatterlist *sgl, unsigned int nents,
> > +		      void *buf, int buflen);
> > +
> 
> It enables us to simplify usb_stor_access_xfer_buf like this, I think
> (it's not tested).

I fixed some minor issues (comments, warning, etc) and I've uploaded
the patchset:

git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git sg-copy

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux