Next | Prev | Up | Top | Contents | Index

Managing Mapped Memory

The pfxmap() and pfxunmap() entry points receive a vhandl_t object that describes the region of user process space to be mapped. The functions summarized in Table 9-10 are used to manipulate that object.

Functions to Manipulate a vhandl_t Object
Function NameHeader FilesCan Sleep?Purpose
v_getaddr(D3) region.h & types.hNGet the user virtual address associated with a vhandl_t.
v_gethandle(D3) region.h & types.hNGet a unique identifier associated with a vhandl_t.
v_getlen(D3) region.h & types.hNGet the length of user address space associated with a vhandl_t.
v_mapphys(D3) region.h & types.hNMap kernel address space into user address space.

The v_mapphys() function actually performs a mapping between a kernel address and a segment described by a vhandl_t (see "Entry Point map()").

The v_getaddr() function has hardly any use except for logging and debugging. The address in user space is normally undefined and unusable when the pfxmap() entry point is called, and mapped to kernel space when pfxunmap() is called. The driver has no practical use for this value.

The v_getlen() function is useful only in the pfxunmap() entry point--the pfxmap() entry point receives a length argument specifying the desired region size.

The v_gethandle() function returns a number that is unique to this mapping (actually, the address of a page table entry). You use this as a key to identify multiple mappings, so that the pfxunmap() entry point can properly clean up.

Caution: Be careful when mapping device registers to a user process. Memory protection is available only on page boundaries, so configure the addresses of I/O cards so that each device is on a separate page or pages. When multiple devices are on the same page, a user process that maps one device can access all on that page. This can cause system security problems or other problems that are hard to diagnose.


Next | Prev | Up | Top | Contents | Index