Re: Potential problem with reading data from usb devices with ugen(4)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	Hello.  Several of you have asked in various ways what other OS's
expect and do with the ugen(4) interface. Here's what I've pared it down to
in terms of the fixes I'm working to implement on the ugen(4) driver for
NetBSD.

1.  Transactional integrity.  Libraries like the libimobiledevice library,
which uses the libusb1 library to talk to the ugen(4) interface, expect to
know how many bytes are read or written to the underlying USB device on
each read or write call to the ugen(4) file descriptor.  Our ugen(4)
concatinates these transactions into as few read or write  calls as
possible as it passes data up to or down from the user level process.  My
fixes correct this problem.

2.  Other OS's have a working poll(2) with their ugen(4) interfaces in the
sense that poll(2) will actually query the device itself to see if there's
data ready to be read from it.  The NetBSD poll(2) interface for ugen(4)
always says there's data to be read and then blocks on the subsequent
read(2) call if there is not.  My changes will accurately reflect if there
is data to be read from the USB device and thus allow callers to avoid
getting blocked in the read(2) call.


	I don't have a patched ugen(4) driver quite ready for testing, but I
hope to soon!

-thanks
-Brian