Fusb and select(2)

GNU Radio
1

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.”

2

On Sunday 15 October 2006 11:53, [email protected] wrote:

[*] Not counting threads. Quoting Alan Cox: “Computers are state
machines. Threads are for people who can’t program state machines.”

USB’s IO model is not well suited to select() style applications since
it
doesn’t allow it to tell the OS how much data should be read in advance
(since there is no real way for a USB device to flag it has data to be
sent
to the app).

Async. IO is a much closer match but support for that in your OS may be
limited. (Especially for raw device nodes and USB in particular)

3

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

4

On Sat, Oct 14, 2006 at 07:23:18PM -0700, [email protected]
wrote:

//
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:[email protected]?subject=subscribe

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