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
pgpWJSPBl8oJc.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
