Alexander Viro wrote:
> Too bad - that's actually an example of people _not_ understanding UNIX.
> Heck, since they got a filesystem to play with, why not create file such
> that writing there would give the effect of monster above?
We've iterated over this at least five times, here once more for you:
- Mapping the structure inherent to the USB messages to a flat
stream of bytes means the need for a parser in kernel space
- Since esp. control messages are bidirectional and the read and
write syscalls are unidirectional, this means a state machine
duplicated in the user space code and the kernel space code;
cumbersome.
- One file per endpoint (versus one file per device, as we
have it now) gives you potential removal races. Suppose
a program needs two endpoints. It opens the first, sleeps
for whatever reasons, meanwhile the user removes the USB
devices and connects another one, which might get the same
device number, now the program wakes up and opens the second
endpoint. The second EP now belongs to a different device.
While small, the race exists.
NB: Not responding to emails is one thing, but then
complaining 3 months later isn't terribly nice.
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:13 EST