Hi!
> > 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.
Thomas, it is not his fault. There was big discussion on l-k about
ioctls() and I used usb as example where it is
performance-critical. Then I forwarded the result.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- 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:14 EST