A driver consists of a C source file and a hardware configuration file.
The C code for a driver is a collection of data and functions that define a kernel module. As noted in Structural Differences Between Kernel Modules and User Programs, a driver has no main() routine. Many of the subroutines of a driver are special functions called entry points. See Device Drivers for information about entry points.
The function man pages provide both the function declaration that you need in your driver and the list of header files you need to include. Make sure you consult the correct man page. For example, the following command displays the ioctl(2) man page. The ioctl(2) system call cannot be used in a device driver.
% man ioctl
Use one of the following commands to display the ioctl(9E) man page. The ioctl(9E) subroutine is a device driver entry point.
% man ioctl.9e % man -s 9e ioctl
By convention, the names of functions and data that are unique to this driver begin with a common prefix. The prefix is the name of this driver or an abbreviation of the name of this driver. Use the same prefix for all names that are specific to this driver. This practice makes debugging much easier. Instead of seeing an error related to an ambiguous attach() function, you see an error message about mydriver_attach() or newdriver_attach().
A 64-bit system can run both 32-bit user programs and 64-bit user programs. A 64-bit system runs 32-bit programs by converting all data needed between the two data models. A 64-bit kernel supports both 64-bit and 32-bit user data. Whenever a 64-bit driver copies data between kernel space and user space, the driver must use the ddi_model_convert_from(9F) function to determine whether the data must be converted between 32-bit and 64-bit models. For an example, see Reporting and Setting Device Size and Re-initializing the Device.
The Sun Studio IDE includes the following three source editors: GVIM, XEmacs, and the built-in Source Editor provided by NetBeans. The IDE provides online help for these tools. You can also run GVIM and XEmacs from the command line. See vim(1) and xemacs(1).
For more information, see the following resources:
For simple example source files, see Chapter 2, Template Driver Example and Chapter 3, Reading and Writing Data in Kernel Memory.
For production driver sources, go to http://www.opensolaris.org/ and click “Source Browser.”
For more driver source and documentation, go to the driver development OpenSolaris community at http://www.opensolaris.org/os/community/device_drivers/.
For advice and examples on a wide variety of driver topics, see the Driver Development FAQ (Frequently Asked Questions).
For more help, search the Driver Development Solaris forum at http://forum.java.sun.com/forum.jspa?forumID=866 or the Kernel forum at http://forum.java.sun.com/forum.jspa?forumID=865. See all the Solaris forums at http://forum.java.sun.com/index.jspa?tab=solaris.
A driver that is not self-identifying must have a configuration file named node_name.conf, where node_name is the prefix for the device. A self-identifying driver is a driver that can obtain all the property information it needs from the DDI property interfaces such as ddi_prop_get_int(9F) and ddi_prop_lookup(9F). The minimum information that a configuration file must contain is the name of the device node and the name or type of the device's parent.