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

Reply via email to