Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Apropos / Subsearch:
optional field

driver.conf(4)                   File Formats                   driver.conf(4)

       driver.conf - driver configuration files


       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-identify-
       ing, 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_get_int(9F)    and
       ddi_prop_lookup(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  con-
       figuration file wombat.conf, also stored in /usr/kernel/drv, associated
       with it. On systems capable of support 64-bit drivers, the driver  con-
       figuration  file  should be placed in the directory in which the 32-bit
       driver is (or would be) located, even if only a 64-bit version is  pro-
       vided.  For  example, a 64-bit driver stored in /usr/kernel/drv/sparcv9
       stores its driver configuration file in /usr/kernel/drv.

       The value of the name property (see the name  field,  below)  needs  to
       match the binding name of the device. The binding name is the name cho-
       sen by the system to bind a driver to a device and is either  an  alias
       associated with the driver or the hardware node name of the device.

       The  syntax  of a single entry in a driver configuration file takes one
       of three forms:

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

       In this form, the parent name can be either a simple nexus driver  name
       to match all instances of that parent/node, or the parent name can be a
       specific full pathname, beginning with a slash (/) character, identify-
       ing a specific instance of a parent bus.

       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.

       Entries of either form above correspond to a device  information  (dev-
       info)  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 dev-
       info  node.  These  properties  can be retrieved using the DDI property
       interfaces (for example, ddi_prop_get_int(9F) and ddi_prop_lookup(9F)).
       The  prototype  devinfo  node  specification  must be terminated with a
       semicolon (;).

       The third form of an entry is simply a list of properties.

              [property-name=value ...];

       A property created in this way is treated as global to the  driver.  It
       can be overridden by a property with the same name on a particular dev-
       info node, either by creating one explicitly on the prototype  node  in
       the driver.conf file or by the driver.

       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  must  not violate the naming conventions for Open Boot
       PROM properties or for IEEE 1275 names. In particular,  property  names
       should  contain  only  printable characters, and should not contain at-
       sign (@), slash (/), backslash (\fR), colon  (:),  or  square  brackets
       ([]).  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_prop_lookup_int_array(9F).

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

       Example 1: Configuration File for a PCI Bus Frame Buffer

       The following is an example of a configuration  file  called  ACME,sim-
       ple.conf for a PCI bus frame buffer called ACME,simple.

       # Copyright (c) 1993, by ACME Fictitious Devices, Inc.
       #ident  "@(#)ACME,simple.conf   1.3     1999/09/09"

       name="ACME,simple" class="pci" unit-address="3,1"

       This  example creates a prototype devinfo node called ACME,simple under
       all parent nodes of class pci. The node has device and function numbers
       of  3  and 1, respectively; the property debug-mode is provided for all
       instances of the driver.

       Example 2: Configuration File for a Pseudo Device Driver

       The following is an example of a configuration file  called  ACME,exam-
       ple.conf for a pseudo device driver called ACME,example.

       # Copyright (c) 1993, ACME Fictitious Devices, Inc.
       #ident    "@(#)ACME,example.conf   1.2  93/09/09"
       name="ACME,example" parent="pseudo" instance=0

       name="ACME,example" parent="pseudo" instance=1;


       This  creates  two  devinfo nodes called ACME,example which will attach
       below the pseudo node in the kernel device tree. The instance  property
       is  only  interpreted  by  the  pseudo  node, see pseudo(4) for further
       details. A property called debug-level will be  created  on  the  first
       devinfo  node  which  will have the value 1. The example driver will be
       able to fetch the value of this property using ddi_prop_get_int(9F).

       Two global driver properties are created, whizzy-mode (which will  have
       the  string  value "on") and debug-level (which will have the value 3).
       If the driver looks up the property whizzy-mode on either node, it will
       retrieve  the  value  of the global whizzy-mode property ("on"). If the
       driver looks up the debug-level property on the  first  node,  it  will
       retrieve  the value of the debug-level property on that node (1). Look-
       ing up the same property on the second node will retrieve the value  of
       the global debug-level property (3).

       pci(4),  pseudo(4),  sbus(4),  scsi(4), probe(9E), ddi_getlongprop(9F),
       ddi_getprop(9F), ddi_getproplen(9F), ddi_prop_op(9F)

       Writing Device Drivers

       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.

       The  update_drv(1M)  command  should  be  used  to prompt the kernel to
       reread driver.conf files. Using  modunload(1M)  to  update  driver.conf
       continues  to  work  in release 9 of the Solaris operating environment,
       but the behavior will change in a future release.

SunOS 5.10                        29 Apr 2003                   driver.conf(4)