1.\" $NetBSD: config.9,v 1.6 2002/03/23 22:36:45 heinz Exp $ 2.\" 3.\" Copyright (c) 2001 The NetBSD Foundation, Inc. 4.\" All rights reserved. 5.\" 6.\" This code is derived from software contributed to The NetBSD Foundation 7.\" by Gregory McGarry. 8.\" 9.\" Redistribution and use in source and binary forms, with or without 10.\" modification, are permitted provided that the following conditions 11.\" are met: 12.\" 1. Redistributions of source code must retain the above copyright 13.\" notice, this list of conditions and the following disclaimer. 14.\" 2. Redistributions in binary form must reproduce the above copyright 15.\" notice, this list of conditions and the following disclaimer in the 16.\" documentation and/or other materials provided with the distribution. 17.\" 3. All advertising materials mentioning features or use of this software 18.\" must display the following acknowledgement: 19.\" This product includes software developed by the NetBSD 20.\" Foundation, Inc. and its contributors. 21.\" 4. Neither the name of The NetBSD Foundation nor the names of its 22.\" contributors may be used to endorse or promote products derived 23.\" from this software without specific prior written permission. 24.\" 25.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS 26.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 27.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 28.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 29.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 30.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 31.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 32.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 33.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 34.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 35.\" POSSIBILITY OF SUCH DAMAGE. 36.\" 37.Dd June 17, 2001 38.Dt CONFIG 9 39.Os 40.Sh NAME 41.Nm config 42.Nd the autoconfiguration framework 43.Do 44device definition 45.Dc 46language 47.Sh DESCRIPTION 48In 49.Nx , 50the 51.Xr config 8 52program reads and verifies a machine description file specifying the 53devices to include in the kernel. A table is produced by 54.Xr config 8 55which is used by the kernel during autoconfiguration (see 56.Xr autoconf 9 ) 57giving needed hints and details on matching hardware devices with 58device drivers. 59.Pp 60Each device in the machine description file has: 61.Bl -tag -width xxxxxx 62.It A Name 63The name is simply an alphanumeric string that ends in a unit number 64(eg. "sd0", "sd1", and so forth). These unit numbers identify 65particular instances of a base device name; the base name in turn maps 66directly to a device driver. Device unit numbers are independent of 67hardware features. 68.It A Parent 69Every device must have a parent. The pairing is denoted by "child at 70parent". These pairings form the links in a directed graph. The root 71device is the only exception, as it does not have a parent. 72.It Locators 73Locators are used to augment the parent/child pairings the locate 74specific devices. Each locator value is simply an integer that 75represents some sort of device address on the parent bus or 76controller. This can be a memory address, and I/O port, a driver 77number, or any other value. Locators can sometimes be wildcarded on 78devices that support direct connection. 79.It Attributes 80An attribute describes the device's relationship with the code; it 81then serves to constrain the device graph. A 82.Em plain attribute 83describes some attribute of a device. An 84.Em interface attribute 85describes a kind of 86.Do 87software interface 88.Dc 89and declares the devices's ability to support other devices that use 90that interface. In addition, an interface attribute usually identifies 91additional locators. 92.El 93.Pp 94During autoconfiguration, the directed graph is turned into a tree by 95nominating one device as the root node and matching drivers with 96devices by doing a depth-first traversal through the graph starting at 97this root node. 98.Pp 99However, there must be constraints on the parent/child pairings that 100are possible. These constraints are embedded in the 101.Do 102device definition 103.Dc 104files. The remainder of this page describes the 105.Do 106device definition 107.Dc 108language and how to use this language to add new functionality to the 109.Nx 110kernel. 111.Sh DEVICE DEFINITION FILES 112The device definition files are separated into machine-dependent and 113machine-independent files. The machine-dependent file is located in 114.Pa sys/arch/\*[Lt]arch\*[Gt]/conf/files.\*[Lt]arch\*[Gt] , 115where \*[Lt]arch\*[Gt] is the name of 116.Nx 117architecture. The machine-independent file is located in 118.Pa sys/conf/files . 119It in turn includes files for the machine-independent drivers located 120in 121.Pa sys/dev/\*[Lt]bus\*[Gt]/files.\*[Lt]bus\*[Gt] , 122where \*[Lt]bus\*[Gt] is the name of the machine-independent bus. 123.Pp 124These files define all legal devices and pseudo-devices. They also 125define all attributes and interfaces, establishing the rules that 126determine allowable machine descriptions, and list the source files 127that make up the kernel. 128.Pp 129Each device definition file consists of a list of statements, 130typically one per line. Comments may be inserted anywhere using the 131.Do 132# 133.Dc 134character, and any line that begins with white space continues the 135previous line. Valid statements are: 136.Bl -tag -width xxxxxx 137.It defflag [filename] {options} 138The space-separated list of pre-processor macros 139.Em options 140are defined in file 141.Em filename . 142This statement permits ``options FOO'' for FOO (i.e, without a value) 143in the machine description file. 144.Xr config 8 145will generate an error if a value is given. If the filename field is 146not specified, the options are defined on the commandline invocation 147of 148.Xr make 1 . 149The 150.Em option 151is case-sensitive. 152.It defparam [filename] {options} 153The space-separated list of pre-processor macros 154.Em options 155are defined in file 156.Em filename . 157This statement permits ``options FOO=bar'' or ``option FOO="\\"com\\""'' 158in the machine description file. 159.Xr config 8 160will generate an error if a value is not given. If the filename field 161is not specified, the options are defined on the commandline 162invocation of 163.Xr make 1 . 164The 165.Em option 166is case-sensitive. 167.It defopt [filename] {options} 168The space-separated list of pre-processor macros 169.Em options 170are defined in file 171.Em filename . 172This statement permits the syntax of either the defflag and defparam 173statements and 174.Xr config 8 175does not perform any checking of whether ``options FOO'' takes a 176value. Therefore, the use of the defopt statement is deprecated in 177favour of the defflag and defparam statements. If the filename field 178is not specified, the options are defined on the commandline 179invocation of 180.Xr make 1 . 181The 182.Em option 183is case-sensitive. 184.It deffs [filename] name 185Define a filesystem 186.Em name . 187.It devclass name 188Define a device class 189.Em name . 190A device class is similar to an attribute. 191.It define name [{locators}] 192The attribute 193.Em name 194is defined and device definitions can then refer to it. If the 195attribute is an interface attribute and defines optional 196.Em locators , 197device attributes that refer to 198.Em name 199are assumed to share the interface and require the same locators. 200.It device name [{locators}]: [attributes] 201The device 202.Em name 203is defined and requires the optional comma-separated list of locators 204.Em locators . 205The optional 206.Em attributes 207define attribute dependencies. 208.It attach name at interface [with ifname]: [attributes] 209The device 210.Em name 211is defined and supports the interface 212.Em interface . 213If 214.Em ifname 215is specified, it is used to specify the interface to the driver for 216device 217.Em name 218(see 219.Xr driver 9 220for details). 221The optional 222.Em attributes 223define attribute dependencies. 224.It defpseudo name: [{locators}] 225The pseudo-device 226.Em name 227is defined. The optional 228.Em locators 229may be defined, but are largely pointless since no device can attach 230to a pseudo-device. 231.It file pathname [attributes [flags]] [rule] 232The file 233.Em pathname 234is added to the list of files used to build the kernel. If no 235attributes are specified, the file is always added to the kernel 236compilation. If any of the attributes are specified by other devices 237in the machine descripton file, then the file is included in 238compilation, otherwise it is omitted. Valid values for the optional 239flags are: 240.Bl -tag -width xxxxxx 241.It needs-count 242Specify that config should generate a file for each of the attributes 243notifying the driver how many of some particular device or set of 244devices are configured in the kernel. This flag 245allows drivers to make calculations of driver used at compile time. 246This option prevents autoconfiguration cloning. 247.It needs-flag 248This flag performs the same operation as 249.Em needs-count 250but only records if the number is nonzero. Since the count is not 251exact, 252.Em needs-flag 253does not prevent autoconfiguration cloning. 254.El 255.It major major-list 256The devices listed in 257.Em major-list 258are associated with major device numbers, allowing them to be used for 259file system roots, swapping and crash dumps. Since major numbers are 260machine dependent, they should not appear in the machine-independent 261device definition files. 262.El 263.Pp 264To allow locators to be wildcarded in the machine description file, 265their default value must be defined in the attribute definition. To 266allow locators to be omitted entirely in the machine description file, 267enclose the locator in square brackets. This can be used when some 268locators do not make sense for some devices, but the software 269interface requires them. 270.Sh CODE REFERENCES 271This section describes places within the 272.Nx 273source tree where actual code implementing or utilising the 274autoconfiguration framework can be found. All pathnames are relative 275to 276.Pa /usr/src . 277.Pp 278The device definition files are in 279.Pa sys/conf/files , 280.Pa sys/arch/\*[Lt]arch\*[Gt]/conf/files.\*[Lt]arch\*[Gt] , 281and 282.Pa sys/dev/\*[Lt]bus\*[Gt]/files.\*[Lt]bus\*[Gt] . 283.Pp 284The grammar for machine description files can be found in 285.Xr config 8 , 286in 287.Pa usr.sbin/config/gram.y . 288.Sh SEE ALSO 289.Xr config 8 , 290.Xr autoconf 9 , 291.Xr driver 9 292.Rs 293.%T "Building 4.4 BSD Systems with Config" 294.Re 295.Rs 296.%A Chris Torek 297.%T "Device Configuration in 4.4BSD" 298.%D 1992 299.Re 300.Sh HISTORY 301Autoconfiguration first appeared in 302.Bx 4.1 . 303The autoconfiguration framework was completely revised in 304.Bx 4.4 . 305It has been modified within 306.Nx 307to support bus-independent drivers and bus-dependent attachments. 308