Future releases of Solaris will provide this function for binary and source compatibility. However, for increased functionality, use devmap(9E) instead. See devmap(9E)
The mmap() entry point is a required entry point for character drivers supporting memory-mapped devices. A memory mapped device has memory that can be mapped into a process's address
space. The mmap(2) system call, when applied to a character special
file, allows this device memory to be mapped into user space for direct access by the user application.
The mmap() entry point is called as a result of an mmap(2)
system call, and also as a result of a page fault. mmap() is called to translate the offset off in device memory to the corresponding physical page frame number.
The mmap() entry point checks if the offset off is within the range of pages exported by the device. For example, a device that has 512 bytes of memory
that can be mapped into user space should not support offsets greater than 512. If the offset does not exist, then -1 is returned. If the offset does exist, mmap() returns the value returned by hat_getkpfnum(9F)
for the physical page in device memory containing the offset off.
hat_getkpfnum(9F) accepts a kernel virtual address
as an argument. A kernel virtual address can be obtained by calling ddi_regs_map_setup(9F) in the driver's attach(9E) routine. The corresponding
ddi_regs_map_free(9F) call can be made in the driver's detach(9E) routine. Refer to The mmap Entry Point below for more information.
mmap() should only be supported for memory-mapped devices. See the segmap(9E)
and ddi_mapdev(9F) reference pages for further information
on memory-mapped device drivers.
If a device driver shares data structures with the application, for example through exported kernel memory, and the driver gets recompiled for a 64-bit kernel but the application remains 32-bit, the
binary layout of any data structures will be incompatible if they contain longs or pointers. The driver needs to know whether there is a model mismatch between the current thread and the kernel and take
necessary action. ddi_mmap_get_model(9F) can be
use to get the C Language Type Model which the current thread expects. In combination with ddi_model_convert_from(9F) the driver can determine whether there is a data model mismatch between the current thread and the device driver. The device driver might
have to adjust the shape of data structures before exporting them to a user thread which supports a different data model. See ddi_mmap_get_model(9F) for an example.