All Acess2 device drivers communicate with user-level (and other parts of the greater kernel) via the VFS. They register themselves in a similar way to how filesystem drivers do, however instead of registering with the VFS core, they register with a special filesystem driver called the Device Filesystem (devfs). The DevFS provides the DevFS_AddDevice function that takes a tDevFS_Driver structure as an agument. This structure specifies the driver's name and its root VFS node. This node is used to provide the user access to the driver's functions via IOCtl calls and Reading or Writing to the driver file. Drivers are also able to expose a readonly buffer by using ProcDev, usually to provide state information or device capabilities for the the user.
The device driver interfaces are all based on the core specifcation in tpl_drv_common.h (Common Device Driver definitions). The following subsections define the various specific types of driver interfaces. These definitions only define the bare minimum of what the driver must implement, if the driver author so wants to, they can add IOCtl calls and/or files (where allowed by the type specifcation) to their device's VFS layout.
If a device type does not have a specifcation for it, the driver can identify itself as a miscelanious device by returning DRV_TYPE_MISC from DRV_IOCTL_TYPE. A misc device must at least implement the IOCtl calls defined in the Common Device Driver definitions, allowing it to be identified easily by the user and for interfacing programs to utilise the DRV_IOCTL_LOOKUP call.
Video drivers are based on a framebuffer model (unless in 3D mode, which is not yet fully standardised, so should be ignored). The driver will contain only one VFS node, that exposes the video framebuffer (this may not be the true framebuffer, to allow for double-buffering) to the user. See the full documentation in tpl_drv_video.h for the complete specifcation.
Storage devices present themselves as a linear collection of bytes. Reads and writes to the device need not be aligned to the stated block size, but it is suggested that users of a storage device file align their accesses to block boundaries. The functions DrvUtil_ReadBlock and DrvUtil_WriteBlock are provided to storage drivers to assist in handling non-alinged reads and writes.
1.6.3