Subject: Re: usb control endpoint exclusive access
To: Greg Troxel <>
From: Berndt Josef Wulf <>
List: tech-kern
Date: 05/17/2005 07:07:27
On Monday 16 May 2005 20:43, Greg Troxel wrote:
> I wonder if there should be a mask in the minor number to indicate
> alternative exclusivity semantics.  The exclusive open is almost
> certainly there because a number of USB-using programs expect that
> once a device is opened no other program will access it.
> Alternatively, GNU Radio could be modified to only open the control
> endpoint in one place.  But if Linux allows multiple opens, then we
> probably need to at least optionally do that - it doesn't seem
> intrinsically crazy and it seems easier to allow multiple opens than
> fight it.

As Linux permits this behavior I see little chance for Linux based projects to 
use the BSD approach. The solution to this is to either fix this in the 
kernel or just submit to the widespread notion that BSD is good for server 
applications but a pain in the neck to use with applications utilizing new 
emerging technologies and concepts.

Current issues that I'm facing are 

1) Data bandwidth of USB2.0 interface not up-to-spec on the ugen device

The ugen device currently bottoms out at 8MB/sec. In order to utilize the full 
potential of the USRP a sustainable data bandwidth of 32MB/sec is required.  
NetBSD would need some extra magic to pull equal with Linux, which  supports 
a sustained databandwidth of >32MB/sec.

2) Lack of support for multiple access to USB control endpoint

On USB devices endpoint 0 (control endpoint) is used to set up and configure 
the interface. Applications that run multiple programs requiring access to 
different endpoints on the same device need shared access the control 
endpoint. This works fine on Linux, but no go on BSD as it won't permit 
shared access to the control endpoint.

3) No support to open devices for read and write access by separate processes

Applications that run two programs, one to send and another to receive data 
accessing the same device, e.g. audio device, although in a different modes 
not interfering which each other, won't work on BSD due to the exclusive 
behavior of the devices. 

I resolved issues 2 and 3 by means of a local work around, but have no 
solutions to improve the data bandwidth. 

It would be nice if we could make the old Dinosaur step dance! Meanwhile I 
will have to rely on Linux in the interim.

cheerio Berndt
Every man who says frankly and fully what he thinks is doing a public service.
[Leslie Stephen]