Messages in this thread | | | From | Bret Indrelee <> | Subject | RE: locking user memory and kiobuf | Date | Mon, 8 Nov 1999 11:23:46 -0600 |
| |
Jeff Garzik [mailto:jgarzik@mandrakesoft.com] wrote: > "Tony E. Bennett" wrote: > > kiobuf sounds perfect for a problem we have. Currently I > use mmap() to map > > pages from __get_free_pages() into user space for dma. > This is not totally > > satisfactory, tho, in part because the resulting group of > pages is not mapped > > contiguously into kernel. > > This is a question I still have unanswered: Does > map_user_kiobuf indeed > map the VM into a _contiguous_ region of physical memory?
I don't think so. There is nothing in there I see that would indicate it does.
It just calls handle_mm_fault() to bring in the necessary pages. See map_user_kiobuf() in the mm/memory.c source file.
For me, this isn't a problem. I've got scatter/gather DMA capability.
> Note struct kiobuf includes an array of pages which causes some of my > confusion. Is it legal/possible to do: > > /* maps in four pages for read/write access */ > err = map_user_kiobuf (WRITE, iobuf, (ulong) vmaddr, > PAGE_SIZE * 4); > > /* manipulate data in chunks greater than PAGE_SIZE */ > phys = page_address(iobuf->maplist[0]); > memcpy (foo, phys, PAGE_SIZE * 4);
The pages should be virtually contiguous in user space, so I think something like this my work.
Does page_address() return a virtual or physical address? To me it looks like it may be a physical address, in which case you would have to do: memcpy (foo, phys_to_virt(phys), PAGE_SIZE *4);
-Bret
------------------------------------------------------------- SBS Technologies, Connectivity Products ... solutions for real-time connectivity
Bret Indrelee, Engineer SBS Technologies, Inc., Connectivity Products 1284 Corporate Center Drive, St. Paul MN 55121 Direct: (651) 905-4731 Main: (651) 905-4700 Fax: (651) 905-4701 E-mail: bindrelee@sbs-cp.com http://www.sbs.com -------------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |