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

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