Hi, On Wednesday 16 May 2007 19:38, Alan Stern wrote: > On Wed, 16 May 2007, Hans Petter Selasky wrote: > > On Wednesday 16 May 2007 18:25, Alan Stern wrote: > > > On Wed, 16 May 2007, Hans Petter Selasky wrote: > > > > It is very clear to me that non-blocking memory allocation at the > > > > point of starting an USB transfer will require extra error handling > > > > in the USB device driver code! > > > > > > It's not so clear to me. > > > > In my new USB stack, I pass all endpoint and buffer size information > > to "usbd_transfer_setup()" at attach time: > > > > For example: > > Irrelevant. This doesn't affect the need for error handling later on. > > > > > My "usbd_transfer_start()" returns "void". Your "usb_submit_urb()" > > > > returns "int". > > > > > > URB submission has other failure possibilities than lack of memory. > > > Those other things have to be checked for regardless. > > > > Yes, but that is because you allow too many parameters in the URB to be > > changed between USB transfers. > > No; it's because unforeseen events can occur. For example, the device > may have been unplugged or suspended.
On FreeBSD it will never happen that you call the equivalent of "usb_submit_urb()" after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. Therefore you don't have to check anything when starting or stopping a USB transfer on FreeBSD [new stack]. > > > > > Pre-allocating everything you need simply saves code, hence you only > > > > check once if you got the memory or not. > > > > > > It doesn't save code. You need to check for the memory when you > > > allocate it, no matter when that is done. > > > > Yes, but it is a difference doing it once at attach or doing it every > > time you start a transfer. > > Above you said it "saves code". That is wrong. > > > > One allocation = one check. > > > The total code size is the same if you do the allocation early and only > > > once or if you do it late and many times. > > > > > > It does save execution time. But that's a different matter; it also > > > wastes data space. > > > > Yes, it wastes some memory, but that is just how it is. Get used to it > > :-) > > > > I have some times been thinking that USB endpoint descriptors should have > > supplied some information on the maximum bandwidth supported, so that the > > USB devices can allocate appropriate buffers. > > The manufacturers would probably get it wrong anyway. Yes, probably. --HPS ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
