I guess I've always looked at it as just a baby RPC mechanism.
The USB spec itself makes it clear that there are four different
types of RPC targets (device, interface, endpoint, "other"); I've
spent enough time with RPC systems (maybe too much :) that
I'd expect concurrency issues on any nontrivial setup, such as
any multifunction server/device.
With that perspective, I don't see why it'd be confusing or
troublesome ... at least, no more than any other multi-thread
control model. Yes, the Linux USB stack probably needs to
support mutual exclusion there, and as RPCs go it's weak on
addressing and quantity of data exchanged ... but there's virtue
in not needing to reinvent such stuff for new function type.
So, perhaps you can see why I still don't quite see a problem
coming from using the control pipe as allowed by USB.
- Dave
----- Original Message -----
From: "Matthew Dharm" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 24, 2001 11:43 AM
Subject: Re: [linux-usb-devel] Non-input HID - take 2
THe pipe is, IMHO, overloaded. The intent was clearly to have a pipe which
could be used to control the device at the USB level -- address,
enumeration, status, clear HALT, etc. But, vendors put too much
functionality on the endpoint, which makes it confusing and causes all
sorts of problems (race conditions, etc.), especially when a device has two
functions.
Matt
On Tue, Apr 24, 2001 at 11:19:53AM -0700, David Brownell wrote:
> > Just kidding - but *why* was the Default Control Pipe chosen as the main
> > communication pipe? Argh!!!
>
> What's the problem with that? I'm curious. Every interface includes
> endpoint zero (default control pipe) ...
>
>
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
