We have seen that the VFS uses a canonical set of common functions (open, read, lseek, and so on) to control a device. The actual implementation of all these functions is delegated to the device driver. Since each device has a unique I/O controller, and thus unique commands and unique state information, most I/O devices have their own drivers.
We shall not attempt to describe any of the hundreds of existing device drivers but concentrate rather on how the kernel supports them. In doing so, we shall describe several I/O architecture features that must be taken into consideration by device driver programmers.
The kernel can support access to hardware devices in three possible ways:
No support at all
The application program interacts directly with the device's I/O ports by issuing suitable in and out assembly language instructions.
The kernel does not recognize the hardware device but only its I/O interface. User programs are able to treat the interface as a sequential device capable of reading and/or writing sequences of characters.
The kernel recognizes the hardware device and handles the I/O interface itself. In fact, there might not even be a device file for the device.
The most common example of the first approach, which does not rely on any kernel device driver, is how the X Window System handles the graphic display. The approach is quite efficient, although it restrains the X server from ...