Subject: Re: usb control endpoint exclusive access
To: Greg Troxel <email@example.com>
From: Berndt Josef Wulf <firstname.lastname@example.org>
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.
Every man who says frankly and fully what he thinks is doing a public service.