On Sunday 21 January 2007 3:28 pm, Sarah Bailey wrote: > On Sun, Jan 21, 2007 at 01:00:18PM -0800, David Brownell wrote: > > On Sunday 21 January 2007 12:34 am, Sarah Bailey wrote: > > > Currently uses wait_for_completion() instead of > > > wait_for_completion_interruptible(). > > > > I think you should try to do this with AIO instead. You'll observe > > that if you use AIO properly, the synchronous paths are handled for > > you automatically, so you get both sync and async APIs from the same > > file operations. > > I'd suspected that was the case, but I hadn't found it in the > documentation I've been reading (Linux Device Drivers, 3rd edition; some > kernel source). Is there a better source for documentation on this?
Source code is best. There are also some OLS papers, but ISTR they don't reflect the current framework very closely at all. It's a bit frustrating to track AIO, for various reasons. There's a mailing list that was acting pretty dead last I checked; a couple webpages ditto. Your best resource is probably LKML. > > On the other hand, doing it the way you're doing it here, you only > > get a synchronous API to userspace ... which means there's no way > > applications can leverage I/O overlap to maximize bandwidth usage. > > And we'll never get rid of those ugly usbfs1 AIO kluges. :( > > I was planning to implement async I/O, but I decided to start with > blocking I/O first. I'll look into the automatic handling of > synchronous paths. If you were planning to do AIO, best to do that from the beginning; and not have any sync-only interfaces. > > For bulk endpoints, the functionally complete set of operations > > includes not just I/O, but also setting/clearing halts. How are > > those being handld here? > > As I understand it, halt conditions are removed by sending a packet to > the default control endpoint. In that case, it's up to the user program > to remove halt conditions by writing to a control endpoint. It could be > done with an ioctl, but I'd like to avoid them as much as possible. Agree about avoiding ioctls. That's why gadgetfs manages halts by issuing a "wrong direction" I/O request ... for the peripheral side, setting a halt is the relevant operation. On the host side, clearing one would be more important. (IMO it would be nice if host side user space drivers could avoid making control requests, just like ioctls.) > (There's still some question of how control packets will be handled; see > the RFC on control endpoints.) ... OK. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
