On Monday 02 May 2005 3:45 am, Oliver Neukum wrote: > Am Montag, 2. Mai 2005 03:38 schrieb David Brownell: > > It might well be simpler to just pin whatever (aligned) buffers > > have been passed, ensure they're properly flushed, and then just > > DMA to/from those pages without requiring special DMA mappings > > to be set up first, and without needing special new usbfs calls. > > How would you make sure the buffers passed are DMA-able?
That's the _normal_ DMA mapping issue. Nothing special, like setting up special mmapped areas and using those ... just the routine stuff that filesystem code deals with routinely if it provides zerocopy I/O for user read or write activities. > > I was looking at that sort of stuff a while back, in conjunction > > with seeing how the AIO stuff might replace the rather funky > > USB-specific AIO-ish stuff in usbfs. A lot of the relevant > > infrastructure is already in place. > > Yes, ideally we had files for each endpoint and use AIO. We haven't, > though. That was the point of my suggestion to add a new "usbfs" request to return a new file descriptor for the endpoint. If it's got the AIO support, it'd automatically have normal read/write support. For bulk endpoints, some clear_halt support could be useful. I was rather shocked to notice that gadgetfs AIO support took only a KByte or so of x86 object code, though that wasn't using zerocopy. It might be a bit trickier on the host side, mostly to create that "file per endpoint" hook into usbfs ... but once that's there, that AIO framework should be a good framework to for zerocopy work. - Dave > > As an example, we now have AIO support in "gadgetfs", which I've > > suggested should be the basic model to follow when rewriting > > "usbfs". With a one-to-one mapping between URBs (or usb_requests) > > and kiocbs, an incremental development step might be as simple as > > just adding an ioctl to usbfs to return a new AIO-capable file > > handle for a given endpoint, then using normal AIO calls on that > > to reuse some of the existing zerocopy work ... > > Good idea. > > [..] > > The key point to draw from that is that all this zerocopy stuff > > can (and should!!) be done at layers above usbcore. If the > > layer above -- "usbfs", "usbfs2", or even "usbfs 1.5" -- passes > > URBs with DMA mappings already established, all the nasty/fragile > > usbcore stuff can be left alone. And even "usbfs" could mostly > > be left alone. > > Yes. > > Regards > Oliver > ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
