On Mon, Nov 16, 2015 at 01:29:58PM -0500, Alan Stern wrote: > Allocating memory pages that match the device's DMA mask, for > use as I/O buffers, and locking them so their physical > addresses don't change (and they don't get paged out); > > Mapping those pages into a user process; > > Constructing scatter-gather lists to describe the I/O if the > pages aren't contiguous. > > I don't have much experience in this area. Can you point to good > examples where these things are done or documents describing what is > involved? For example, are the allocating and mapping steps normally > done separately or are they normally combined in an mmap(2) system > call? The answer is probably not what you want to here, but the recommendation is to not bother. Just use the iommu for this one reasonable hardware, or swiotlb for bounce buffering if your systems has more addressable memory than what the hardware can address. This is what we've been doing for block I/O since day 1. > A proposed patch has been posted > (http://marc.info/?l=linux-usb&m=144763502829452&w=2), but I'm not > convinced that it is the best approach. For instance, it always tries > to get contiguous pages and so is vulnerable to memory fragmentation. This looks totally crazy to me. What's the use case for it? -- 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