Re: [Discuss-gnuradio] Unable to find USRP

[Eric Blossom]

On Mon, May 16, 2005 at 04:12:01AM +0930, Berndt Josef Wulf wrote:
> On Sunday 15 May 2005 11:28, Eric Blossom wrote:
> >
> > If the ugen driver has code that forces exclusivity, it ought to be
> > simple enough to remove it (at least on end point 0).  Search for
> > EBUSY in the driver source.  It's probably in the first 10 lines of
> > the open routine.
> >
> > Eric
> 
> Thanks for your help. On inspection of the ugen device driver I can confirm 
> that it implements exclusive access to the control endpoint. After modifying 
> the driver to allow multiple access to the control endpoint benchmarks_usb.py 
> works fine.

Glad to hear it.  

Having access to the source for your operating system is really handy!

> I'm not familiar with the USB specifications, but from what you're saying did 
> I understand you correctly that multiple access to USB Control Endpoints is 
> permissible, but access to other endpoints are exclusive to one process? If 
> so, we just found a bug in the kernel.

USB doesn't say much of anything about how the host should behave.  It
does describe the protocol on the wire, but everything above that is
up for grabs.

End point 0, the default control endpoint doesn't support bulk
requests, only command requests (and maybe interrupt requests, not
sure without checking the spec).  Deciding to enforce an exclusive
open restriction seems arbitrary.  Assuming that the driver can see
the open flags, it could examine O_EXCL and then those who wanted the
driver to enforce exclusivity could have it their way too.

Since a USB peripheral is free to interpret the contents of bulk
requests anyway it sees fit, it's not even clear that a mandatory
exclusive open on other endpoints is the right answer either.  (This
restriction doesn't cause us problems, so it's not an immediate
concern.)

> In any case, I'm happy to report that, using a modified kernel, the benchmark 
> utility is working now.

Thanks,
Eric