asynchronous. I realize that this means the custom application will
not work as written, but it is not okay to break most users of ugen(4).
The major problem is that a bulk read transfer is not an interrupt
saying that X bytes are available -- it is a request to be able to
receive up to X bytes, with T timeout, and S short-transfer-okayness.
The timeout is a software mechanism that ugen(4) provides and cannot
be implemented using asynchronous reads -- the timeout must start at
the time a read is done.
The status of up to how many bytes can be received in this transfer
and whether a short transfer returns data or error is also encoded
at least in ohci(4)'s requests to the controller. Trying to detect
the "maximum width" results in using a single buffer of far too
small when an application requests a large read.
Even if you combat this by replacing all buffers again with the
maximal sized read buffer (1kb) that ugen(4) would allow you to
use before, you don't get the right semantics -- you have to
throw data away or make all the timeouts invalid or make the
short-transfer settings invalid.
There is no way to do this right without extending the ugen(4) API
much further -- it breaks the USB camera interfaces used because
they need a chain of many maximal-width transfers, for example, and
it makes cross-platform support for all the BSDs gratuitously hard.
Instead of trying to do select(2) on a bulk read pipe -- which has
neither the information on desired transfer length nor ability to
implement timeout -- an application can simply use a kernel thread
and pipe to turn that endpoint into something poll-able.
It is unfortunate that bulk endpoints cannot provide the same semantics
that interrupt and isochronous endpoints can, but it is possible to just
use ioctl(USB_GET_ENDPOINT_DESC) to find out when different semantics
must be used without preventing the normal users of the ugen(4) device
from working.
601486239c