On Wed, 28 Jan 2009, David Brownell wrote: > > There was a recent proposal on libusb-devel to do almost exactly that: > > add mmap support to usbfs. It would allow the kernel to avoid an extra > > copy on all I/O data. > > I looked at part of this problem several years ago, and > concluded that usbcore (and thus HCDs) *still* shouldn't > try to deal with userspace buffers. Ditto gadgetfs, which > was the context I was looking at. ;) > > It suffices to have something *above* usbcore -- like > usbfs, or usbfs2 (Sarah?? :) take a userspace buffer, > pin its pages, and turn those pages into kernel buffers > that would get handled in the usual way. That was the essence of the proposal. > Of course, un-aligned buffers would still require the > kind of bounce buffering that the "3.5K WUSB packet" > case requires: you couldn't do zerocopy I/O for all > buffers, you'd still need single-copy code paths. User programs expect to jump through hoops for things like alignment when doing zerocopy I/O. As long as the buffer starts at the beginning of the mapped region (i.e., on a page boundary) there shouldn't be a problem. > Key point: keep all that crap out of usbcore, and HCDs. > Putting it in usbfs (or usbfs2) or other drivers is OK; > ditto putting it in library code they could use. Well, usbfs is _part_ of usbcore. :-) I guess you meant the most central parts of the core (mostly urb.c and hcd.c). I still think it would be good to add to the HCDs an ability to treat Bulk transfers much like we do Iso: use a data structure (not necessarily a scatterlist) of buffer addresses (and/or DMA addresses) and lengths. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
