Re: New USB stack on FreeBSD w/Linux emulation layer coming

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?

  
> 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?

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.

Seems to me that your "Linux emulation" is missing some important
characteristics!

- Dave

-------------------------------------------------------------------------
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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel