driver.conf(4)

NAME

driver.conf − driver configuration files

SYNOPSIS

driver.conf

DESCRIPTION

Driver configuration files pass information about device drivers and their configuration to the system. Most device drivers do not have to have configuration files. Drivers for devices that are self-identifying, such as the SBus devices on many systems, can usually obtain all the information they need from the FCode PROM on the SBus card using the DDI property interfaces. See ddi_prop_op(9F) for details.

The system associates a driver with its configuration file by name. For example, a driver in /usr/kernel/drv called wombat has the driver configuration file wombat.conf associated with it. By convention, the driver configuration file lives in the same directory as the driver.

Each entry in the driver configuration file corresponds to a prototype device information (devinfo) node in the kernel device tree. Each node has a name which is usually the name of the driver, and a parent name which is the name of the parent devinfo node it will be connected to. Any number of name-value pairs may be specified to create properties on the prototype devinfo node. These properties can be sized and retrieved using the DDI property interfaces (for example, ddi_getproplen(9F) and ddi_getprop(9F)). The prototype devinfo node specification must be terminated with a semicolon (;).

The syntax of a single entry in a driver configuration file takes one of two forms.

name="node name" parent="parent name" [property-name=value ...];

In this form, the parent name is a simple nexus driver name. Alternatively, the parent can be specified by the type of interface it presents to its children.

name="node name" class="class name" [property-name=value ...];

For example, the driver for the SCSI host adapter may have different names on different platforms, but the target drivers can use class scsi to insulate themselves from these differences.

Items are separated by any number of newlines, SPACE or TAB characters.

The configuration file may contain several entries to specify different device configurations and parent nodes. The system may call the driver for each possible prototype devinfo node, and it is generally the responsibility of the drivers probe(9E) routine to determine if the hardware described by the prototype devinfo node is really present.

Property names should obey the same naming convention as Open Boot PROM properties, in particular they should not contain at-sign (@), or slash (/) characters. Property values can be decimal integers or strings delimited by double quotes ("). Hexadecimal integers can be constructed by prefixing the digits with 0x.

A comma separated list of integers can be used to construct properties whose value is an integer array. The value of such properties can be retrieved inside the driver using ddi_getlongprop(9F) or one of the related property interfaces.

Comments are specified by placing a # character at the beginning of the comment string, the comment string extends for the rest of the line.

EXAMPLES

Here is a configuration file called ACME,simple.conf for a VMEbus frame buffer called ACME,simple.

#
# Copyright (c) 1992, by ACME Fictious Devices, Inc.
#
#ident"@(#)ACME,simple.conf 1.392/02/14"
name="ACME,simple" class="vme"
reg=0x7d,0x400000,0x110600;

This example creates a prototype devinfo node called ACME,simple under all parent nodes of class vme. It specifies a property called reg that consists of an array of three integers. The reg property is interpreted by the parent node, see vme(4) for further details.

Here is a configuration file called ACME,example.conf for a pseudo device driver called ACME,example.

#
# Copyright (c) 1992, ACME Fictious Devices, Inc.
#
#ident"@(#)ACME,example.conf1.292/02/14"
name="ACME,example" parent="pseudo" debug-level=3;

This example creates a devinfo node called ACME,example which will attach below the pseudo node in the kernel device tree. The pseudo node is the parent of all pseudo device drivers. A property called debug-level will be created on that devinfo node which will have the value 3. The example driver will be able to fetch the value of this property using ddi_getprop(9F).

WARNINGS

To avoid namespace collisions between multiple driver vendors, it is strongly recommended that the name property of the driver should begin with a vendor-unique string. A reasonably compact and unique choice is the vendor over-the-counter stock symbol.

SunOS 5.2 — Last change: 28 Sep 1992

Museum