Hi, On Thursday 17 May 2007 21:26, David Brownell wrote: > On Thursday 17 May 2007, Hans Petter Selasky wrote: > > On Thursday 17 May 2007 19:44, David Brownell wrote: > > > On Thursday 17 May 2007, Hans Petter Selasky wrote: > > > > I would like introduce a new USB API call, so that my pre-allocate > > > > model will work better with your USB API. ... > > > > > > int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); > > > > To save the "hep" to "struct usb_device" pointer, I would like to have > > "struct usb_device *dev" as an argument. > > Introducing new error paths ... why? As a rule we remove redudancy. > > > > What would such a call do, though? Who would use it, and why? > > > > The call will setup one or two pre-allocated USB transfers for the > > emulation layer between the Linux USB stack and the FreeBSD USB stack. > > So what's a "transfer" ... just a bunch of TDs? And what would be > the advantage to a Linux driver, since the TDs are allocated on > demand in any case?
A "USB transfer" on FreeBSD is equivalent to an URB on Linux. The difference is that on FreeBSD the "USB transfer", struct usbd_xfer, has pointers to pre-allocated TD's, QH's and data-buffers. I want to use one or two USB transfers to move all the USB data from the Linux's URB to a FreeBSD USB transfer. > > The reason for this is to allow Linux USB drivers to tell the FreeBSD USB > > stack that they want larger/smaller buffers. > > > > On Linux this information can be used to reserve EHCI/UHCI/OHCI USB > > transfer descriptors. > > I still don't get it. What's the advantage to Linux? That the Linux USB stack can pre-allocate TD's and QH's on a per-endpoint basis. > > I could imagine a new HCD entry, parallel to endpoint_disable(), > called by usbcore. It could initialize HCD-internal state like > a QH, and maybe ensure that the relevant TD pool isn't empty. > It'd be nice to have a task context for that in all cases. But > that wouldn't be visible outside usbcore... > > > > > On FreeBSD this function will pre-allocate one or two USB transfers > > > > for an endpoint using the given "bufsize" argument. Those FreeBSD USB > > > > transfers will then be used to do all the Linux USB transfers. This > > > > function can block and must have a context. > > > > > > So what's the model ... GPL'd Linux drivers will be modified to > > > incorporate that call, so they'd work better on FreeBSD? > > > > Yes, and under Linux. > > > > As you can see, it is not possible to emulate an on-the-fly allocation > > model by a pre-allocation model. That's why I suggest this API addition. > > All Linux drivers are allowed to assume on-the-fly allocation though. > That's a simpler model than mandatory pre-allocation. In this context, > simpler is better. Why is it simpler than pre-allocation? > > Seems to me that your "Linux emulation" is missing some important > characteristics! --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
