Re: Potential problem with reading data from usb devices with ugen(4)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  I'm still working away on this ugen(4) driver and I've made a
lot of progress on it.  I now have an implementation question which I'd
like to discuss.  This message is a little long, and I apologize in advance
for the verbosity, but I want to give as much background as I can so that
folks can weigh in here with as much information as possible.

	The read ahead and write behind code in the ugen(4) driver transfer
data from the USB device in question to the user process or from the user
process to the USB device respectively.  Each uses a 16K buffer which is
filled by a series of reads or writes from or to the USB device by the
asynchronous buld read and write routines.  When the data is returned to
the user process in the case of a read call or delivered to the USB device
in the case of a write call, the ugen(4) does not currently respect any
transactional boundaries set up between the user process controlling the
USB device and the USB device itself.  For example, if the user process
writes two consecutive 512 byte blocks of data to its USB device, the
ugen(4) may deliver that data as one 1024 byte USB transaction to the USB
device itself.  Similarly, when the datacomes into the ugen(4) driver from
the USB device, it may be delivered as two 512 byte USB transactions, but
the user process will receive all 1024 bytes from the device in one read(2)
call.  This is a problem for the libimobiledevice library in that it
expects to know how much data was transfered from or to the USB device for
each USB transaction.
	In the case of the write call, I've figured out how to let the write
behind code work while still maintaining transactional boundaries
established by the user process.  The read call, however, is something I'm
finding more challenging and this is where I'd like some guidance.

	The easiest thing I can think of, is toset up an array of buffers in
the endpoint state structure, each of which is the size of the largest USB
packet that could come from the USB device, i.e. 16384 bytes.  Then,
maintain indices which tell the read ahead code which buffer to use for the
next USB transaction and  the read code which transfers data to the user
process which buffers are available for transfer to the user process.
Right now, only one buffer is used, but I can't think of a reliable way of
marking transactional boundaries from the USB device while only using one
buffer.

	I think this is a similar approach to how most ethernet drivers work
in terms of having an array of receive buffers.  So,
my questions are as follows:  

O  Does this seem like a reasonable approach to the problem?

O  Is it better to pre-allocate the buffers at open time, as is
done now for the read ahead and write behind buffers, or is it better to
allocate them as read calls happen?

O  Is there a way to do what I want without having to use additional
buffers that I just haven't thought of?

-thanks
-Brian