Re: gadget file storage with variable maxpacket

On Nov 15, 2007 10:06 AM, Alan Stern <[email protected]> wrote:
> On Thu, 15 Nov 2007, ilya wrote:
>
> > so if it is a single-packet transfer, then yes, there is obviously nothing
> > wrong with short packets. i am concerned with transfers that are made
> > up of multiple packets. with INs, if you blindly send out the data that the
> > gadget queues-in [and have maxpacket greater then 512] you will end up
> > sending out a short packet in the middle of this multi-packet transfer and
> > short packet = end of the transfer. so for this case one would have to
> > make sure to concatenate any requests that are less than maxpacket in
> > order not to terminate a transfer prematurely. but now how does the controller
> > driver know that this request is part of a multi-packet transfer and that
> > request is actually a single transfer with size of less than maxpacket; it
> > would have to look at the mass storage commands, which is the file storage
> > gadget's job. with OUTs it is inconvenient because most hardware use
> > buffers that are size of, or multiples of, maxpacket; so with these short
> > packet requests you now have read out a buffer in multiple requests,
> > which adds overhead and is more prone to errors/problems.
>
> Ah, now I understand your point.  Yes, the driver does contain an
> implicit assumption that the maxpacket value evenly divides the sector
> size.
>
> We can fix the problem easily enough.  Just take out the code in
> do_read() and do_write() that handles partial pages, and let the VFS or
> block layer worry about reorganizing the data.

works like a charm; interesting enough, i've tried this before
but ended up crashing my system so i figured that code
was necessary. so why do you do all this page/block alignment
in the first place if VFS can take care of it?

-- ilya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel