The following steps precede installation of a driver:
Compile the driver.
Create a configuration file if necessary.
Identify the driver module to the system through either of the following alternatives:
Match the driver's name to the name of the device node.
Use either add_drv(8) or update_drv(8) to inform the system of the module names.
The system maintains a one-to-one association between the name of the driver module and the name of the dev_info node. For example, consider a dev_info node for a device that is named mydevice. The device mydevice is handled by a driver module that is also named mydevice. The mydevice module resides in a subdirectory that is called drv, which is in the module path. The module is in drv/sparcv9/mydevice if you are using a 64-bit SPARC kernel. The module is in drv/amd64/mydevice if you are using a 64-bit x86 kernel.
If the driver is a STREAMS network driver, then the driver name must meet the following constraints:
Only alphanumeric characters (a-z, A-Z, 0-9), plus the underscore ('_'), are allowed.
Neither the first nor the last character of the name can be a digit.
The name cannot exceed 16 characters in length. Names in the range of 3-8 characters in length are preferable.
If the driver must manage dev_info nodes with different names, the add_drv(8) utility can create aliases. The -i flag specifies the names of other dev_info nodes that the driver handles. The update_drv command can also modify aliases for an installed device driver.
You need to compile each driver source file and link the resulting object files into a driver module. The Oracle Solaris OS is compatible with both the Oracle Developer Studio C compiler and the GNU C compiler from the Free Software Foundation, Inc. The examples in this section use the Oracle Developer Studio C compiler unless otherwise noted. For information about the Oracle Developer Studio C compiler, see the C, C++, Fortran Compiler and the Oracle Developer Studio 12.6 Documentation Library. For more information about compile and link options, see Oracle Developer Studio 12.6 Man Pages. The GNU C compiler is supplied in the /usr/bin directory. For information about the GNU C compiler, see http://gcc.gnu.org/.
|
The –xmodel option enables the compiler to modify the form of 64-bit objects for Oracle Solaris x86 platforms and should only be specified for the compilation of such objects. For more information see the description of the –xmodel option in the Oracle Developer Studio 12.6: C User's Guide.
Caution - If you are compiling for a 64-bit x86 architecture using Oracle Developer Studio compilers, you need to make sure your compilation does not produce MMX or SSE instructions. MMX and SSE instructions are not supported in the x86 kernel. Use of MMX or SSE instructions triggers a kernel panic and therefore should not be used. |
The following table lists the considerations and compiler options to generate code without MMX or SSE instructions for the x86 architecture.
|
After the driver is stable, you might want to add optimization flags to build a production quality driver. See the cc(1) man page in Oracle Developer Studio 12.6 Man Pages for specific information about optimizations in the Oracle Developer Studio compiler.
Global variables should be treated as volatile in device drivers. The volatile tag is discussed in greater detail in Declaring a Variable Volatile. Use of the flag depends on the platform. See the man pages.
The link-editor –z type=kmod option is used to link drivers, and other kernel modules. If the driver module depends on symbols that are exported by another kernel module, the dependency is specified with the –N option. For more information, see the ld(1) man page. For example, the following command creates a driver binary, xx2.o, that depends on a symbol exported by misc/mySymbol:
$ ld -o xx -z type=kmod -N misc/mySymbol xx1.o xx2.o
If a device is non-self-identifying, the kernel might require a hardware configuration file for that device. If the driver is called xx, the hardware configuration file for the driver should be called xx.conf.
On the x86 platform, device information is now supplied by the booting system. Hardware configuration files should no longer be needed, even for non-self-identifying devices.
See the driver.conf(5), pseudo(5), scsi_free_consistent_buf(9F), and update_drv(8) man pages for more information about hardware configuration files.
Arbitrary properties can be defined in hardware configuration files. Entries in the configuration file are in the form property=value, where property is the property name and value is its initial value. The configuration file approach enables devices to be configured by changing the property values.