On Thursday 02 March 2006 22:11, Iain Hibbert wrote:
> On Wed, 1 Mar 2006, Hubert Feyrer wrote:
> > what I wonder is what the benefits of this new USB stack is,
>
> is this completely new, rewritten or just tidied up?

It is completely new. But it also supports the old USB API.

>
> > and what drawbacks the existing one is supposed to have that justifies
> > replacing a working piece of software. And some estimate if it's really
> > easier to replace than to fix.
>
> One thing that I think is very important is that the current USB code has
> no documentation and its quite difficult to understand at first sight.
>
> Any replacement should have better documentation before it is considered,
> is my opinion :)
>
> Also, there is a comment in usbdi(9) to the effect that the OpenUSBDI
> specification looks different now. If new, does this code look like the
> newer spec?  That could be some kind of improvement..

I would not use the OpenUSBDI specification. From what I see one has 
repeatedly got to call allocate functions, like "udi_cb_alloc()" (see p.32), 
during code execution, which is not acceptable. Allocating memory can cause a 
sleep. The idea in my driver is to pre-allocate all required memory during 
attach. Then reuse the transfers, to have a non-blocking model.

The "OpenUSBDI" specification is a single lock model, that does not even 
mention the word mutex. It is possible to map my new USB API to OpenUSBDI, 
but it will all be Giant locked.

--HPS