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

On Thu, 17 May 2007, Hans Petter Selasky wrote:

> If you need to do Async stuff, then you have to do it in a separate thread or 
> in a so-called task-queue. Else you are in for great trouble! That was the 
> big "sin" in the old USB stack on FreeBSD: Calling synchronous USB callbacks 
> from everywhere, like ioctl/read/write - callbacks.
> 
> Is that a problem on Linux also?

It's hard to answer; your use of terminology is peculiar.  The word
"synchronous" does not mean capable of blocking; it means that the
routine waits until a result is received.  It is not directly related
to whether the routine runs in a process context (which can sleep) vs.
an atomic context (one which isn't allowed to sleep).

Referring to a callback as "synchronous" doesn't make sense.  A
callback doesn't send a message -- it _receives_ a message -- and hence
it doesn't need to wait for any result.

In Linux, the USB callbacks are generally atomic.  Does that answer 
your question?

> On Linux I see no locks used in the USB drivers, so they are solely protected 
> by interrupt-level mechanisms.

That's an awfully strange thing to say.  No locks used in the USB
drivers?  Good lord, they are full of locks!  Semaphores, mutexes, 
spinlocks -- you name it, it's in there.

> My rule is that: Synchronous or blocking calls _must_ happen in a config 
> thread that you can wait for. Else asynchronous calls on pre-allocated 
> transfers can happen anywhere.

What distinguishes a "config" thread from any other kind of thread?  
What distingishes threads you can wait for from threads you can't wait 
for?

What's wrong with a config thread that you can't wait for making a
blocking call?  Who cares if you can't wait for it? -- the thread will 
still carry out the call okay.

> The problem clearly appears on Linux SMP because:

What problem?  Or should I say, Which problem?

> a) No locks are in the USB drivers (then they must be all so-called "Giant" 
> locked)

You must be living in some sort of fantasy land if you really believe 
this.  Or else you're looking at a version of Linux from 8 years ago.

> b) You don't pre-allocate transfers, resulting in synchronous/blocking calls 
> everywhere, and no-one thinks about what can happen then :-)

Your reasoning is illogical.  Why does allocation have to be blocking?  
In code paths which can't block, we do non-blocking late allocation.  
And we do think about what can happen.

Alan Stern


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