The Solaris 7 device driver interface/driver-kernel interface provides a high-level, architecture-independent model for DMA. This allows the framework (the DMA routines) to hide such architecture-specific details as:
Setting up DMA mappings
Building scatter-gather lists
Ensuring I/O and CPU caches are consistent
There are several abstractions that are used in the DDI/DKI to describe aspects of a DMA transaction. These include:
DMA object - Memory that is the source or destination of a DMA transfer.
DMA handle - An opaque object returned from a successful ddi_dma_alloc_handle(9F)call. The DMA handle is used in successive DMA subroutine calls to refer to the DMA object.
DMA cookie - A ddi_dma_cookie(9S) structure (ddi_dma_cookie_t) describes a contiguous portion of a DMA object that is entirely addressable by the device. It contains DMA addressing information required to program the DMA engine.
Rather than knowing that a platform needs to map an object (typically a memory buffer) into a special DMA area of the kernel address space, device drivers instead allocate DMA resources for the object. The DMA routines then perform any platform-specific operations needed to set the object up for DMA access. The driver receives a DMA handle to identify the DMA resources allocated for the object. This handle is opaque to the device driver; the driver must save the handle and pass it in subsequent calls to DMA routines, but should not interpret it in any way.
Operations are defined on a DMA handle that provide the following services:
Manipulating DMA resources
Synchronizing DMA objects
Retrieving attributes of the allocated resources