![]() |
![]() |
| ||||||
Writing a Hardware Configuration FileIf 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 the driver.conf(4), pseudo(4), sbus(4), scsi(4), and update_drv(1M) man pages 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 enables devices to be configured by changing the property values. Installing, Updating, and Removing DriversBefore a driver can be used, the system must be informed that it exists. The add_drv(1M) utility must be used to correctly install the device driver. After the driver is installed, it can be loaded and unloaded from memory without using add_drv(1M) again. Copying the Driver to a Module DirectoryA device driver's module path (location) depends on the platform it runs on, the architecture it is compiled for, and whether it is needed at boot time. Platform-dependent device drivers reside in the following locations:
Platform-independent drivers reside in either of these directories:
To install a 32-bit driver, the driver and its configuration file must be copied to a drv directory in the module path. For example, to copy a driver to /usr/kernel/drv, type:
To install a 64-bit SPARC driver, copy the driver to a drv/sparcv9 directory in the module path. Copy the driver configuration file to the drv directory in the module path. For example, to copy a driver to /usr/kernel/drv, type:
Note - All driver configuration files (.conf files) must go in the drv directory in the module path. Even on 64-bit systems, the .conf file goes in the drv directory, not the drv/sparcv9 directory. Installing Drivers with add_drv()Run add_drv(1M) to install the driver in the system. If the driver installs successfully, add_drv(1M) will run devfsadm(1M) to create the logical names in /dev.
This is a simple case in which the device identifies itself as xx and the device special files will have default ownership and permissions (0600 root sys). add_drv(1M) also allows additional names for the device (aliases) to be specified. See add_drv(1M) to determine how to add aliases and set file permissions explicitly. Note - add_drv(1M) should not be run when installing a STREAMS module. See the STREAMS Programming Guide for details. If the driver creates minor nodes that do not represent disks, tapes, or ports (terminal devices), /etc/devlink.tab can be modified to cause devfsadm(1M) to create logical device names in /dev. Alternatively, logical names can be created by a program run at driver installation time. Updating Driver InformationUse the update_drv(1M) command to notify the system of any changes to an installed device driver. By default, the system re-reads the driver.conf(4) file and reloads the driver binary module. Removing the DriverTo remove a driver from the system, use rem_drv(1M), then delete the driver module and configuration file from the module path. The driver cannot be used again until it is reinstalled with add_drv(1M). Removing a SCSI HBA driver will require a reboot to take effect. Loading and Unloading DriversOpening a special file associated with the device driver causes the driver to be loaded. modload(1M) can also be used to load the driver into memory, but it does not call any routines in the module. Opening the device is the preferred method. Normally, the system automatically unloads device drivers when they are no longer in use. During development, it might be necessary to use modunload(1M) to unload the driver explicitly. In order for modunload(1M) to be successful, the device driver must be inactive; there must be no outstanding references to the device, such as through open(2) or mmap(2). modunload takes a runtime-dependentmodule_id as an argument. The module_id can be found by using grep to search the output of modinfo for the driver name in question and looking at the first column.
To unload all currently unloadable modules, specify module ID zero:
In addition to being inactive, the driver must have working detach(9E) and _fini(9E) routines for modunload(1M) to succeed. Driver PackagingThe normal delivery vehicle for software is to create a package with all the components of the software packaged together. A package provides a controlled mechanism for installation and removal of all the components of a software product. In addition to the files for using the product, the package includes control files for installing (and de-installing) the application. The postinstall and preremove installation scripts are two such control files. Package PostinstallAfter installing a package that includes a driver binary onto a system, the add_drv(1M) command must be run to complete the installation of the driver. Typically, add_drv is run a postinstall script as in the following example.
| ||||||
| ||||||