Part I Designing Device Drivers for the Solaris Platform
1. Overview of Solaris Device Drivers
2. Solaris Kernel and Device Tree
5. Managing Events and Queueing Tasks
7. Device Access: Programmed I/O
10. Mapping Device and Kernel Memory
14. Layered Driver Interface (LDI)
Part II Designing Specific Kinds of Device Drivers
15. Drivers for Character Devices
18. SCSI Host Bus Adapter Drivers
19. Drivers for Network Devices
Part III Building a Device Driver
21. Compiling, Loading, Packaging, and Testing Drivers
Preparing for Driver Installation
Compiling and Linking the Driver
Writing a Hardware Configuration File
Installing, Updating, and Removing Drivers
Copying the Driver to a Module Directory
Installing Drivers with add_drv
Stress, Performance, and Interoperability Testing
Installation and Packaging Testing
Testing Specific Types of Drivers
Asynchronous Communication Drivers
22. Debugging, Testing, and Tuning Device Drivers
23. Recommended Coding Practices
B. Summary of Solaris DDI/DKI Services
C. Making a Device Driver 64-Bit Ready
The code for a device driver is usually divided into the following files:
Header files (.h files)
Source files (.c files)
Optional configuration file (driver.conf file)
Header files provide the following definitions:
Data structures specific to the device, such as a structure representing the device registers
Data structures defined by the driver for maintaining state information
Defined constants, such as those representing the bits of the device registers
Macros, such as those defining the static mapping between the minor device number and the instance number
Some of the header file definitions, such as the state structure, might be needed only by the device driver. This information should go in private header files that are only included by the device driver itself.
Any information that an application might require, such as the I/O control commands, should be in public header files. These files are included by the driver and by any applications that need information about the device.
While there is no standard for naming private and public files, one convention is to name the private header file xximpl.h and the public header file xxio.h.
A C source file (a .c file) for a device driver has the following responsibilities:
Contains the data declarations and the code for the entry points of the driver
Contains the #include statements that are needed by the driver
Declares extern references
Declares local data
Sets up the cb_ops and dev_ops structures
Declares and initializes the module configuration section, that is, the modlinkage(9S) and modldrv(9S) structures
Makes any other necessary declarations
Defines the driver entry points
In general, the configuration file for a driver defines all of the properties that the driver needs. Entries in the driver configuration file specify possible device instances that the driver can probe for existence. Driver global properties can be set in the driver's configuration file. See the driver.conf(4) man page for more information.
Driver configuration files are required for devices that are not self-identifying.
Driver configuration files are optional for self-identifying devices (SID). For self-identifying devices, the configuration file can be used to add properties into SID nodes.
The following properties are examples of properties that are not set in the driver configuration file:
Drivers that use the SBus peripheral bus generally get property information from the SBus card. In cases where additional properties are needed, the driver configuration file can contain properties that are defined by sbus(4).
The properties of a PCI bus can generally be derived from the PCI configuration space. In cases where private driver properties are needed, the driver configuration file can contain properties that are defined by pci(4).
Drivers on the ISA bus can use additional properties that are defined by isa(4).