vm_iomap_memory() [LWN.net]

By Jonathan Corbet
April 17, 2013

The -rc7 stage of the kernel development cycle is normally considered to be the wrong time to add new driver API functions; most developers attempting such a thing could expect to get a response that is less than 100% encouraging. But, if you're Linus, you can get away with such things. So, after looking at too much messy driver code, Linus added a new helper function for drivers that need to map a physical memory range into a user-space process's memory:

    int vm_iomap_memory(struct vm_area_struct *vma, phys_addr_t start, 
			unsigned long len);

This function is a wrapper around io_remap_pfn_range() that takes care of a number of details specific to the virtual memory subsystem so that driver code need not worry about them. No drivers have been converted for 3.9, but one can expect that process to begin in the 3.10 cycle.

(Log in to post comments)

size_t

Posted Apr 18, 2013 8:08 UTC (Thu) by epa (subscriber, #39769) [Link]

Any reason why the length parameter is an unsigned long rather than a size_t?

size_t

Posted Apr 18, 2013 9:49 UTC (Thu) by arnd (subscriber, #8866) [Link]

size_t is for pointers, while the "len" argument refers to a phys_addr_t, and it's not good style to add those two.

While it would be correct to use "phys_addr_t len" as well, that would be unnecessarily slow for the case of 64-bit phys_addr_t on a 32 bit machine, because we know that the actual mapping is a virtual address.

size_t

Posted Apr 18, 2013 10:31 UTC (Thu) by epa (subscriber, #39769) [Link]

Ah... my lack of kernel programming shows through. I had assumed there was no difference between a pointer and an address, but outside of the cushioned world of user space there certainly is.