The problem with all of this is:
a) It depends on queuing
b) It doesn't reserve the bandwidth
Each in itself make it unacceptable.
On the other hand, neither of those is true either. Which is
part of why I don't see any problem ... :)
Although a per frame bandwidth measurement might not be a bad idea. I
wonder if that can be similified some.
The per-frame logic needs to be internal to the HCD ... in fact,
that's how to keep the TT support logic from causing serious damage.
There's no need to expose anything more than success or failure
when submitting an URB.
So if some HCD wanted a less functional scheduling policy (maybe it
ignores request periods), that can/should be transparent to layers
above it ... except that they might notice a bus that seems to have
less reserved bandwidth available than should really be present.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
