Re: Suggested dual human/binary interface for proc/devfs

From: Alexander Viro (viro@math.psu.edu)
Date: Mon Apr 10 2000 - 05:07:23 EST


On Mon, 10 Apr 2000, Thomas Sailer wrote:

> 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

Erm? Even if you s/ioctl()/write()/?

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

Ditto.

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

Unless I seriously misunderstood you, you are going to run into the same
kind of problems in a lot of situations. What about generation number on
inodes? I'll go through the code again, but...

> NB: Not responding to emails is one thing, but then
> complaining 3 months later isn't terribly nice.

?

-
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