1driver.conf(4) File Formats driver.conf(4)
2
6 driver.conf - driver configuration files
7
9 driver.conf
10
13 Driver configuration files provide values for device properties. The
14 values override values provided by the devices themselves. Most modern
15 devices provide enough property values to make a driver configuration
16 file unnecessary.
17 The system associates a driver with its configuration file by name. For
20 example, a driver in /usr/kernel/drv called wombat has the driver con‐
21 figuration file wombat.conf, also stored in /usr/kernel/drv, associated
22 with it. On systems capable of support 64-bit drivers, the driver con‐
23 figuration file should be placed in the directory in which the 32-bit
24 driver is (or would be) located, even if only a 64-bit version is pro‐
25 vided. For example, a 64-bit driver stored in /usr/kernel/drv/sparcv9
26 stores its driver configuration file in /usr/kernel/drv.
27 The value of the name property is the node name. In a driver.conf file,
30 where the generic node name and compatible property associated with a
31 self-identifying devices are typically not used, the node name must be
32 a binding name. The binding name is the name chosen by the system to
33 bind a driver to the device. The binding name is either an alias asso‐
34 ciated with the driver established by add_drv(1M) or the driver name
35 itself.
36 The syntax of a single entry in a driver configuration file takes one
39 of three forms:
40 name="node name" parent="parent name" [property-name=value ...];
42 In this form, the parent name can be either the binding name of the
46 parent nexus driver or a specific full pathname, beginning with a slash
47 (/) character, identifying a specific instance of a parent bus. If a
48 binding name is used then all parent nodes bound to that driver match.
49 A generic name (for example, pci) is not a valid binding name even
50 though it can appear in the full pathname of all intended parents.
51 Alternatively, the parent can be specified by the type of interface it
54 presents to its children.
55 name="node name" class="class name" [property-name=value ...];
57 For example, the driver for the SCSI host adapter can have different
61 names on different platforms, but the target drivers can use class scsi
62 to insulate themselves from these differences.
63 Entries of either form above correspond to a device information (dev‐
66 info) node in the kernel device tree. Each node has a name which is
67 usually the name of the driver, and a parent name which is the name of
68 the parent devinfo node to which it will be connected. Any number of
69 name-value pairs can be specified to create properties on the prototype
70 devinfo node. These properties can be retrieved using the DDI property
71 interfaces (for example, ddi_prop_get_int(9F) and ddi_prop_lookup(9F)).
72 The prototype devinfo node specification must be terminated with a
73 semicolon (;).
74 The third form of an entry is simply a list of properties.
77 [property-name=value ...];
79 A property created in this way is treated as global to the driver. It
84 can be overridden by a property with the same name on a particular dev‐
85 info node, either by creating one explicitly on the prototype node in
86 the driver.conf file or by the driver.
87 Items are separated by any number of newlines, SPACE or TAB characters.
90 The configuration file can contain several entries to specify different
93 device configurations and parent nodes. The system can call the driver
94 for each possible prototype devinfo node, and it is generally the
95 responsibility of the drivers probe(9E) routine to determine if the
96 hardware described by the prototype devinfo node is really present.
97 Property names must not violate the naming conventions for Open Boot
100 PROM properties or for IEEE 1275 names. In particular, property names
101 should contain only printable characters, and should not contain at-
102 sign (@), slash (/), backslash (\fR), colon (:), or square brackets
103 ([]). Property values can be decimal integers or strings delimited by
104 double quotes ("). Hexadecimal integers can be constructed by prefixing
105 the digits with 0x.
106 A comma separated list of integers can be used to construct properties
109 whose value is an integer array. The value of such properties can be
110 retrieved inside the driver using ddi_prop_lookup_int_array(9F).
111 Comments are specified by placing a # character at the beginning of the
114 comment string, the comment string extends for the rest of the line.
115
117 Example 1 Configuration File for a PCI Bus Frame Buffer
118 The following is an example of a configuration file called ACME,sim‐
121 ple.conf for a PCI bus frame buffer called ACME,simple.
122 #
125 # Copyright (c) 1993, by ACME Fictitious Devices, Inc.
126 #
127 #ident "@(#)ACME,simple.conf 1.3 1999/09/09"
128 name="ACME,simple" class="pci" unit-address="3,1"
130 debug-mode=12;
131 This example creates a prototype devinfo node called ACME,simple under
135 all parent nodes of class pci. The node has device and function numbers
136 of 3 and 1, respectively; the property debug-mode is provided for all
137 instances of the driver.
138 Example 2 Configuration File for a Pseudo Device Driver
141 The following is an example of a configuration file called ACME,exam‐
144 ple.conf for a pseudo device driver called ACME,example.
145 #
148 # Copyright (c) 1993, ACME Fictitious Devices, Inc.
149 #
150 #ident "@(#)ACME,example.conf 1.2 93/09/09"
151 name="ACME,example" parent="pseudo" instance=0
152 debug-level=1;
153 name="ACME,example" parent="pseudo" instance=1;
155 whizzy-mode="on";
157 debug-level=3;
158 This creates two devinfo nodes called ACME,example which attaches below
162 the pseudo node in the kernel device tree. The instance property is
163 only interpreted by the pseudo node, see pseudo(4) for further details.
164 A property called debug-level is created on the first devinfo node
165 which has the value 1. The example driver is able to fetch the value of
166 this property using ddi_prop_get_int(9F).
167 Two global driver properties are created, whizzy-mode (which has the
171 string value "on") and debug-level (which has the value 3). If the
172 driver looks up the property whizzy-mode on either node, it retrieves
173 the value of the global whizzy-mode property ("on"). If the driver
174 looks up the debug-level property on the first node, it retrieves the
175 value of the debug-level property on that node (1). Looking up the same
176 property on the second node retrieves the value of the global debug-
177 level [22mproperty (3).
178
181 add_drv(1M), pci(4), pseudo(4), sbus(4), scsi(4), probe(9E), ddi_get‐
182 longprop(9F), ddi_getprop(9F), ddi_getproplen(9F),
183 ddi_prop_get_int(9F), ddi_prop_lookup(9F), ddi_prop_op(9F)
184 Writing Device Drivers
187
189 To avoid namespace collisions between multiple driver vendors, it is
190 strongly recommended that the name property of the driver should begin
191 with a vendor-unique string. A reasonably compact and unique choice is
192 the vendor over-the-counter stock symbol.
193
195 The update_drv(1M) command should be used to prompt the kernel to
196 reread driver.conf files. Using modunload(1M) to update driver.conf
197 continues to work in release 9 of the Solaris operating environment,
198 but the behavior will change in a future release.
199SunOS 5.11 5 Jan 2007 driver.conf(4)