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

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

On Sep 24,  3:55pm, Nick Hudson wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} On 09/24/15 15:52, Brian Buhrow wrote:
} > 	I forgot to mention the libusb1 calls do request the
} > USB_SET_SHORT_XFER via ioctl(2).
} This doesn't matter / help here as UGEN_SHORT_OK is ignored for 
} UGEN_BULK_{RA,WB}
} 
} Can you try the idea?
} 
} Thanks,
} Nick
	Hello I implemented a patch to ugen(4) which allows the read ahead
code to permit short reads if the short read flag is set by the calling
process.  (I modified libusb again to make sure it firsts sets the short
read flag before setting the read ahead flag to make sure I do the test I
want.)  
You are right that this changes things, but there's still a problem.  Now,
the first call to ugen_bulkra_intr() happens via the ioctl(USB_SET_BULK_RA:)
as it should.  The next time the read call happens, there's data in the
read buffer, which means we don't return EWOULDBLOCK, but we call  
ugen_bulkra_intr() again and then go to sleep, which locks the process up
in ugenrb again.
	I think what we want to do is call the ugen_bulkra_intr() function
again, but return the data we have to the calling process.
	Here's ugendebug output showing the progression of things with my
commentary.


ugen0: ugenread: 5 -- This is the first call, made from ugen_do_ioctl()
ugenread: BULK_RA req: 4096 used: 0 -- return EWOULDBLOCK HERE

ugenioctl: cmd=80045572 -- setup the next pass from usbmuxd
ugenioctl: cmd=80045574
ugenioctl: cmd=80045571
ugenioctl: cmd=80045573

ugen0: ugenread: 5 -- Now there's data
ugenread: BULK_RA req: 4096 used: 20
ugenread: sleep on 0xce934a68


So, this is progress, but not quite there yet.
-Brian