Re: gadget file storage with variable maxpacket

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.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel