Re: [Discuss-gnuradio] fusb and select(2)

[Eric Blossom]

On Sat, Oct 14, 2006 at 07:23:18PM -0700, address@hidden wrote:
> Friends -
> 
> As a die-hard old-school unix programmer, I want to be able to grab data
> from a USRP-like device, under control of a main loop based on
> select(2).  The comments in the source code of fusb are not encouraging.
> Quoting from gnuradio-3.0/usrp/host/lib/fusb_linux.cc:
> 
> // Totally evil and fragile extraction of file descriptor from
> // guts of libusb.  They don't install usbi.h, which is what we'd need
> // to do this nicely.
> //
> // FIXME if everything breaks someday in the future, look here...
> 
> static int
> fd_from_usb_dev_handle (usb_dev_handle *udh)
> {
>   return *((int *) udh);
> }
> 
> .. and of course this function is not exported via the public class
> interface.  Worse, what I want is to know when I can read from an
> endpoint, not the raw device.  And when I go to read from an endpoint
> marked as having something, it still doesn't have a nonblocking read,
> that will return as many bytes as are available.
> 
> I don't think my desires are unreasonable.  Has anyone else tried
> to multitask[*] with USB I/O?  I'll hack up fusb if I have to.
> 
>     - Larry
> 
> [*] Not counting threads.  Quoting Alan Cox: "Computers are state
> machines.  Threads are for people who can't program state machines."

  Or want to take advantage of multicore/SMP resources...

Under Linux, I don't think that select works with the asynchronous URB
submission technique that we are using.  We're not using read or
write.  Not sure of the interpretation (if any) of select's
"exception" cases.

The code currently works around this by using a combination of

  ret = ioctl (fd, USBDEVFS_REAPURBNDELAY, &urb);

and

  ret = ioctl (fd, USBDEVFS_REAPURB, &urb);

FYI, the code that implements the usbfs (and the ioctls that we're
using) is in linux/drivers/usb/core/devio.c


This might be a good question for linux-usb-devel
<mailto:address@hidden>


That said, in the not too distant future, we'll be moving to "in band
signaling" on the USB and Gigabit Ethernet.  This is going to result
in a substantial restructuring of the bottom of the usrp libraries
(not to mention the FPGA code.)  I suspect that we're going to end up
with a dedicated real-time process that'll handle muxing and demuxing
the packets to/from the USRP and the other processes that have the
USRP open.  This will probably also have the side effect of allowing
multiple READ opens, allows for example a scope or fft to be attached
to the USRP independent of other processes.  Think of something
vaguely JACK like.

Eric