Preparing for Installation

Before the driver is actually installed, it must be compiled into a binary, and a configuation file created, if necessary. The driver's module name must either match the name of the device nodes, or the system must be informed that this driver should manage other names.

Module Naming

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, a dev_info node for a device named wombat is handled by a driver module called wombat in a subdirectory called drv (resulting in drv/wombat) found in the module path.

If the driver should manage dev_info nodes with different names, the add_drv(1M) utility can create aliases. The -i flag specifies the names of other dev_info nodes that the driver handles.

Compiling and Linking the Driver

Compile each driver source file and link the resulting object files into a driver module. The example below shows a driver called xx that has two C-language source files and generates a driver module xx. This driver created in this example is intended for the 32-bit kernel:

% cc -D_KERNEL -c xx1.c% cc -D_KERNEL -c xx2.c% ld -r -o xx xx1.o xx2.o

The _KERNEL symbol must be defined while compiling kernel (driver) code. No other symbols (such as sun4m) should be defined, aside from driver private symbols. DEBUG can also be defined to enable any calls to assert(9F). There is no need to use the -I flag for the standard headers.

Drivers intended for the 64-bit SPARC kernel should specify the -xarch=v9 option. Use the following compile line:

% cc -D_KERNEL -xarch=v9 -c xx1.c

After the driver is stable, optimization flags can be used to build a production quality driver. For the Sun WorkShop Compilers C, the normal -O flag, or its equivalent -xO3, can be used. Note that -xO3 is the highest level of optimization device drivers should use (see cc(1)).

The following compile line was used to create 64-bit SPARC drivers provided with the Solaris 8 operating environment:

% cc -D_KERNEL -xcg92 -xarch=v9 -xcode=abs32 -xO3 -c xx1.c

Where -xcg92 refers to the code generator, and the use of -xcode=abs32 leads to more compact code.

Running ld -r is necessary even if there is only one object module.

Module Dependencies

If the driver module depends on symbols exported by another kernel module, the dependency can be specified by the -N option of ld. If the driver depends on a symbol exported by misc/foo, the example below should be used to create the driver binary. See also ld(1).

% ld -r -o xx xx1.o xx2.o -N misc/foo

Writing a Hardware Configuration File

If the device is non-self-identifying, the kernel requires a hardware configuration file for it. If the driver is called xx, the hardware configuration file for it should be called xx.conf. See driver.conf(4), pseudo(4), sbus(4), and scsi(4) for more information on hardware configuration files. On the Intel platform, device information is now supplied by the booting system. Hardware configuration files should no longer be needed, even for non-self-identifying devices.

Arbitrary properties can be defined in hardware configuration files by adding entries of the form property=value, where property is the property name, and value is its initial value. This allows devices to be configured by changing the property values.