Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

devmap_callback_ctl(9s) [osx man page]

devmap_callback_ctl(9S) 				    Data Structures for Drivers 				   devmap_callback_ctl(9S)

NAME
devmap_callback_ctl - device mapping-control structure SYNOPSIS
#include <sys/ddidevmap.h> INTERFACE LEVEL
Solaris DDI specific (Solaris DDI). DESCRIPTION
A devmap_callback_ctl structure describes a set of callback routines that are called by the system to notify a device driver to manage events on the device mappings created by devmap_setup(9F) or ddi_devmap_segmap(9F). Device drivers pass the initialized devmap_callback_ctl structure to either devmap_devmem_setup(9F) or devmap_umem_setup(9F) in the devmap(9E) entry point during the mapping setup. The system makes a private copy of the structure for later use. Device drivers can spec- ify different devmap_callback_ctl for different mappings. A device driver should allocate the device mapping control structure and initialize the following fields, if the driver wants the entry points to be called by the system: devmap_rev Version number. Set this to DEVMAP_OPS_REV. devmap_map Set to the address of the devmap_map(9E) entry point or to NULL if the driver does not support this callback. If set, the system calls the devmap_map(9E) entry point during the mmap(2) system call. The drivers typically allo- cate driver private data structure in this function and return the pointer to the private data structure to the system for later use. devmap_access Set to the address of the devmap_access(9E) entry point or to NULL if the driver does not support this callback. If set, the system calls the driver's devmap_access(9E) entry point during memory access. The system expects devmap_access(9E) to call either devmap_do_ctxmgt(9F) or devmap_default_access(9F) to load the memory address translations before it returns to the system. devmap_dup Set to the address of the devmap_dup(9E) entry point or to NULL if the driver does not support this call. If set, the system calls the devmap_dup(9E) entry point during the fork(2) system call. devmap_unmap Set to the address of the devmap_unmap(9E) entry point or to NULL if the driver does not support this call. If set, the system will call the devmap_unmap(9E) entry point during the munmap(2) or exit(2) system calls. STRUCTURE MEMBERS
int devmap_rev; int (*devmap_map)(devmap_cookie_t dhp, dev_t dev, uint_t flags, offset_t off, size_t len, void **pvtp); int (*devmap_access)(devmap_cookie_t dhp, void *pvtp, offset_t off, size_t len, uint_t type, uint_t rw); int (*devmap_dup)(devmap_cookie_t dhp, void *pvtp, devmap_cookie_t new_dhp, void **new_pvtp); void (*devmap_unmap)(devmap_cookie_t dhp, void *pvtp, offset_t off, size_t len, devmap_cookie_t new_dhp1, void **new_pvtp1, devmap_cookie_t new_dhp2, void **new_pvtp2); SEE ALSO
exit(2), fork(2), mmap(2), munmap(2), devmap(9E), devmap_access(9E), devmap_dup(9E), devmap_map(9E), devmap_unmap(9E), ddi_devmap_segmap(9F), devmap_default_access(9F), devmap_devmem_setup(9F), devmap_do_ctxmgt(9F), devmap_setup(9F), devmap_umem_setup(9F) Writing Device Drivers SunOS 5.10 24 Jul 1996 devmap_callback_ctl(9S)

Check Out this Related Man Page

devmap_unmap(9E)						Driver Entry Points						  devmap_unmap(9E)

NAME
devmap_unmap - device mapping unmap entry point SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> void prefixdevmap_unmap(devmap_cookie_t dhp, void *pvtp, offset_t off, size_tlen, devmap_cookie_t new_dhp1, void **new_pvtp1, devmap_cookie_tnew_dhp2, void **new_pvtp2); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI). ARGUMENTS
dhp An opaque mapping handle that the system uses to describe the mapping. pvtp Driver private mapping data. off User offset within the logical device memory at which the unmapping begins. len Length (in bytes) of the memory being unmapped. new_dhp1 The opaque mapping handle that the system uses to describe the new region that ends at (off - 1) . new_dhp1 may be NULL. new_pvtp1 A pointer to be filled in by the driver with the driver private mapping data for the new region that ends at (off - 1); ignored if new_dhp1 is NULL. new_dhp2 The opaque mapping handle that the system uses to describe the new region that begins at (off + len); new_dhp2 may be NULL. new_pvtp2 A pointer to be filled in by the driver with the driver private mapping data for the new region that begins at (off + len); ignored if new_dhp2 is NULL. DESCRIPTION
devmap_unmap() is called when the system removes the mapping in the range [ off, off + len ], such as in the munmap(2) or exit(2) system calls. Device drivers use devmap_unmap() to free up the resources allocated in devmap_map(9E). dhp is the mapping handle that uniquely identifies the mapping. The driver stores the mapping attributes in the driver's private data, pvtp, when the mapping is created. See devmap_map(9E) for details. off and len define the range to be affected by devmap_unmap(). This range is within the boundary of the mapping described by dhp. If the range [ off, off + len ] covers the entire mapping, the system passes NULL to new_dhp1, new_pvtp1, new_dhp2, and new_pvtp2. The system expects device drivers to free all resources allocated for this mapping. If off is at the beginning of the mapping and len does not cover the entire mapping, the system sets NULL to new_dhp1 and to new_pvtp1. The system expects the drivers to allocate new driver private data for the region that starts at off + len and to set *new_pvtp2 to point to it. new_dhp2 is the mapping handle of the newly mapped object. If off is not at the beginning of the mapping, but off + len is at the end of the mapping the system passes NULL to new_dhp2 and new_pvtp2. The system then expects the drivers to allocate new driver private data for the region that begins at the beginning of the map- ping (for example, stored in pvtp) and to set *new_pvtp1 to point to it. new_dhp1 is the mapping handle of the newly mapped object. The drivers should free up the driver private data, pvtp, previously allocated in devmap_map(9E) before returning to the system. EXAMPLES
Example 1 devmap_unmap() implementation static void xxdevmap_unmap(devmap_cookie_t dhp, void *pvtp, offset_t off, size_t len, devmap_cookie_t new_dhp1, void **new_pvtp1, devmap_cookie_t new_dhp2, void **new_pvtp2) { struct xxpvtdata *ptmp; struct xxpvtdata *p = (struct xxpvtdata *)pvtp; struct xx_softc *softc = p->softc; mutex_enter(&softc->mutex); /* * If new_dhp1 is not NULL, create a new driver private data * for the region from the beginning of old mapping to off. */ if (new_dhp1 != NULL) { ptmp = kmem_zalloc(sizeof (struct xxpvtdata), KM_SLEEP); ptmp->dhp = new_dhp1; ptmp->off = pvtp->off; ptmp->len = off - pvtp->off; *new_pvtp1 = ptmp; } /* * If new_dhp2 is not NULL, create a new driver private data * for the region from off+len to the end of the old mapping. */ if (new_dhp2 != NULL) { ptmp = kmem_zalloc(sizeof (struct xxpvtdata), KM_SLEEP); ptmp->off = off + len; ptmp->len = pvpt->len - (off + len - pvtp->off); ptmp->dhp = new_dhp2; *new_pvtp2 = ptmp; } /* Destroy the driver private data - Device dependent */ ... kmem_free(pvtp, sizeof (struct xxpvtdata)); mutex_exit(&softc->mutex); } SEE ALSO
exit(2), munmap(2), devmap_map(9E), devmap_callback_ctl(9S) Writing Device Drivers SunOS 5.11 21 Jan 1997 devmap_unmap(9E)
Man Page