Subject: Re: usb control endpoint exclusive access
To: Lennart Augustsson <lennart@augustsson.net>
From: Berndt Josef Wulf <wulf@ping.net.au>
List: tech-kern
Date: 05/18/2005 23:40:19
On Tuesday 17 May 2005 15:44, Lennart Augustsson wrote:
> Berndt Josef Wulf wrote:
> > Current issues that I'm facing are
> >
> >
> > 1) Data bandwidth of USB2.0 interface not up-to-spec on the ugen device
>
> This will require some work.  And the only reasonable way to do
> the work is to have access to a device so you can test it.
> I don't have one.  But maybe I should get one. :)
>
> > 2) Lack of support for multiple access to USB control endpoint

No problems, I can setup access to a standalone system with the USRP 
development board attached.
>
> Just commit your patch to fix this one.  I see no problem with that.

Thanks, this is one problem less on the list

> > 3) No support to open devices for read and write access by separate
> > processes
>
> Now this one is tricky.  Linux has a different semantics for close() in
> the kernel than NetBSD.  Linux calls the device open() every time the
> device is opened and close() every time the device is closed.
> NetBSD calls open() on every open, but close() only on the last close.
> The NetBSD behaviour makes it very difficult to have separate read&write
> processes. :(

I worked around this problem by removing the AUOPEN_READ restriction as shown 
below:

--- /sys/dev/audio.c.orig       2005-05-17 10:24:44.000000000 +0930
+++ /sys/dev/audio.c    2005-05-17 10:27:13.000000000 +0930
@@ -1288,9 +1288,12 @@
        DPRINTF(("audio_open: flags=0x%x sc=%p hdl=%p\n",
                 flags, sc, sc->hw_hdl));

-       if ((sc->sc_open & (AUOPEN_READ|AUOPEN_WRITE)) != 0)
+       if ((sc->sc_open & (AUOPEN_WRITE)) != 0)
                return EBUSY;

+//     if ((sc->sc_open & (AUOPEN_READ)) != 0)
+//             return EBUSY;
+
        if (hw->open != NULL) {
                error = hw->open(sc->hw_hdl, flags);
                if (error)

This is not the correct way, however,  it lets me run the GnuRadio 
gr-audio-oss module unmodified enabling me to execute applications that issue 
separate open() calls for read and write access without any noticeable impact 
on the system.

My previous work around was to modify the GnuRadio gr-audio-oss module to 
access the audio device through a "audio_device" class. This class opened the 
device on the first request and kept count on the processes that had read and 
write access. It allowed multiple read access but only exclusive write 
access. The audio device was closed when the last process  relinquished 
access to the audio device.

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