On Mon, Apr 10, 2000, Thomas Sailer <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
>
> > I actually partially implemented a patch to create seperate nodes for
> > each endpoint on device through devfs obviating the need for using
> > ioctl's like this. I only got control working, but if there's interest,
> > I'll finish it.
>
> I thought about this too, but:
>
> 1) It doesn't solve Viro's raves about ioctl's, as the main cause
> for the ioctl's is the inherent structure in the USB transactions
> that isn't easily mapped to a stream of bytes
Bulk easily maps.
Control can write the setup packet, then any data afterwards. If writing
data to the device, the write() call can return the error. If reading
data from the device, a read() call can return the error.
I think Interrupts and Isochronous pipes could work.
> 2) Gives you atomicity problems.
> Assume a program needs two endpoints, it opens the first,
> then sleeps for whatever reason, in the mean time the
> device gets unplugged and a new device plugged in which
> gets the same device number, then the program wakes up
> and opens the second ep, which will now be an ep of
> the new device.
>
> Granted, this race is very small, but nevertheless
> there 8-)
How about requiring an application to have one node open at all times it
intends to use it. Then, if a device node is still open, it won't reassign
that usb id to a new device?
Perhaps it can be a main device node (the node which returns
descriptors) or something similar.
> But I don't care overly much which way we do it,
> I think it's more important to arrive at a stable API
> in the near future...
How about using devfs? Are there any issues with using devfs instead of
usbdevfs (as the filesystem)?
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
