Driver porting:supporting mmap ()

http://lwn.net/Articles/28746/

Occasionally, a device driver would need to map an address range into a userprocess ' s space. This mapping can is done into give the process DirectAccess to a device ' I/O memory area, or to the driver ' s DMA buffers. 2.6features a number of changes to the virtual memory subsystem, but, for Mostdrivers, supporing mmap () would be relatively Painless.

Using Remap_page_range () There are two techniques in with for implementing mmap (); Often thesimpler of the two is using Remap_page_range (). This functioncreates a set of page table entries covering a given physical addressrange. The prototype of Remap_page_range () changed slightly in2.5.3; The relevant virtual memory area (VMA) pointer must as passed Thefirst:

    int Remap_page_range (struct vm_area_struct *vma, unsigned long from, unsigned long to
		         , unsigned long size, 
			 Pgprot _t prot);

Remap_page_range () is now explicitly documented as requiring thatthe memory management semaphore (usuallycurrent->mm-& GT;MMAP_SEM) be held when the function is called. Drivers would almost invariably call Remap_page_range () to Theirmmap () method, where this semaphore is already held. So, in otherwords, driver writers don't normally need to worry about Acquiringmmap_sem. If use Remap_page_range () Fromsomewhere other than your mmap () method, however, do is sure youhave the acquired Ore.

Note So, if you are are remapping into I/O space, your may want to use:

    int Io_remap_page_range (struct vm_area_struct *vma, unsigned long from, unsigned long to
		            , unsigned long size, 
			    PGP rot_t prot);

On all architectures other than SPARC, Io_remap_page_range () isjust Another name for Remap_page_range (). On SPARC Systems,however, Io_remap_page_range () uses the systems I/O mappinghardware to provide access to I/O memory.

Remap_page_range () retains its longstanding limitation:it cannotbe used to remap system RAM. Thus, it works in for I/O memoryareas, but not for internal buffers. For this case, it's necessary todefine a Nopage () method. (Yes, if you are are curious, the "markpages reserved" hack still works as a way of getting around thislimitation, but their use is strongly discouraged).

Using vm_operations The other way of implementing mmap are to override the default vmaoperations to set up a driver-specific nopage () method. Thatmethod'll be called to deal with page faults in the mapped area; It isexpected to return a struct page pointer to satisfy the fault. The nopage () approach is flexible, but it cannot being used to remap; Only memory represented in the system memory map can be mapped inthis way.

The Nopage () method made it through the entire 2.5 developmentseries without-changes in the modified 2.6.1 Ease. The prototype for thatfunction used:

    struct page * (*nopage) (struct vm_area_struct *area, 
                           unsigned long address, 
			   int unused);

As of 2.6.1, the unused argument is no longer unused, and Theprototype has to:

    struct page * (*nopage) (struct vm_area_struct *area, 
	                   unsigned long address, 
			   int *type);

The type argument is now used to return the type of the Pagefault; Vm_fault_minor would indicate a MINOR fault-one where thepage was-in-memory, and all is needed was a page table fi Xup. Areturn of Vm_fault_major would, instead, indicate that the Pagehad to is fetched from disk. Driver code using Nopage () toimplement a device mapping would return probably. In-tree code checks whether type is NULL before assigningthe fault type; Other users would are advised to do the same.

There are a couple of the other things worth mentioning. One is so thevm_operations_struct is rather smaller than it being in 2.4.0; The Protect (), swapout (), Sync (), Unmap (), Andwppage () methods have all gone away (they were actually deleted in 2.4.2). Devicedrivers made little use of this methods, and should not be affected bytheir.

There is also one new Vm_operations_struct method:

    Int (*populate) (struct vm_area_struct *area, unsigned long address, 
                    unsigned long len, pgprot_t prot, unsigned long PG Off, 
		    int nonblock);

The populate () method is added in 2.5.46; Its purpose are to "prefault" pages within a VMA. A device driver could certainly implementthis by simply it invoking () method for each nopage the Pagewithin Range, then using:

    int install_page (struct mm_struct *mm, struct vm_area_struct *vma, 
                     unsigned long addr, struct page *page, 
		     pgprot_ t prot);

To create the page table entries. In practice, however, there are no realadvantage to doing things into this way. No driver in the mainline (2.5.67) kernel tree implements the populate () method.

Finally, one use of nopage () are to allow a user process to map Akernel buffer which being created with Vmalloc (). In the past, Adriver had to walk through the page tables to find a struct pagecorresponding to a vmalloc () address. As of 2.5.5 (and 2.4.19), however, all this is needed be a call to:

    struct page *vmalloc_to_page (void *address);

This are not a variant of vmalloc ()-it allocates no memory. It simply returns a pointer to the struct page associated with anaddress obtained from Vmalloc ().