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

[Daniel O'Connor]

On Saturday 06 May 2006 03:19, Greg Troxel wrote:
> > 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.

OK, a pity.

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

Right.

> 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.

OK.

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

Indeed, I just wanted to make sure you didn't implement a hack when the real 
thing would be easier :)
(ie if NetBSD did AIO then no kernel mods would be necessary)

> I think it comes down to two issues:
>
> 1) Do we want the user-space program to explicitly schedule all the
>    hardware reads?

I am not sure, but I think the answer is no (for the USRP case especially)

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

Yes :)
[since AIO has hooks deep in the kernel]

> 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 to be honest, but I believe it's just a queue of reads.

> 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.

Absolutely, it would also be difficult to ensure standards compliance, etc..
IMO not worth it for this one application. I remember there where plenty of 
subtle bugs fixed in the FreeBSD implementation and even then it is still an 
optional API due to potential bugs.

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

I should try using it in FreeBSD and see if it works in practice :)

Good luck with your implementation!

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

pgpLDXUf90rls.pgp
Description: PGP signature