Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD

[Greg Troxel]

"Daniel O'Connor" <address@hidden> writes:

> On Thursday 04 May 2006 11:58, Daniel O'Connor wrote:
>> It would be nice if you could do a readv() and then
>> poll/kqueue/select/signal to see when an iovec has been filled, however I
>> suspect that would require severe modification of the kernel internals.
>
> Ah now I think about it, this is called "aio_read" :)
>
> I don't know how widely supported it is - in FreeBSD it's optional (via a 
> kernel option or KLD).

This seems to be a POSIX 1003.2 feature.  It doesn't exist in NetBSD.

This is essentially what the Linux USB driver does, but apparently
without using a standard interface.

> It does allow you to enqueue read requests and then later check if they have 
> been completed. IMO this is the best match for the USB IO model, but my USB 
> fu is fairly weak.

It's a reasonable match, but it's far more general than what the USRP
needs.  The problem arises because we're trying to use the USRP like a
traditional data input device, where data arrives and is buffered.
The current NetBSD ugen(4) code, and it seems the Linux code without
fusb, overload the read system call to both move data to userspace and
to inititiate a read operation over the USB.  aio (like Linux fusb)
allows one to avoid the temporal coupling of this overloading.

I don't see any reason why continuous read mode and aio are mutually
exclusive - one could still do an async read.

I think it comes down to two issues:

1) Do we want the user-space program to explicitly schedule all the
   hardware reads?

2) Is continuous read mode easier to implement than AIO?

I find user-space code managing lots of pending reads to be more
complex than it ought to be when we really want to just say "start
reading and keep going".

I didn't find a clear explanation of how AIO works with multiple
outstanding reads on the same file descriptor. 

I'm not sure how hard AIO is to implement - the kernel already is
doing things async and the read system call is in tsleep.  But it's
harder to do that than continuous read mode.


Thanks for pointing out aio, though - I had forgotten about that.


-- 
        Greg Troxel <address@hidden>