CONFIG(9)
💖 NAME 💖
okay so CONFIG(9) is chillin' in the Kernel Developer's Manual, and this page is about config — the autoconfiguration framework “device definition” language. That's the name, bestie, and it's giving device-definition main character energy. 💅
✨ DESCRIPTION ✨
In NetBSD, the config(1) program reads and verifies a machine description file (documented in config(5)) that specifies the devices to include in the kernel. A table is produced by config(1) which is used by the kernel during autoconfiguration (see autoconf(9)) giving needed hints and details on matching hardware devices with device drivers. slay. 🌈
Each device in the machine description file has:
- A Name — the name is simply an alphanumeric string that ends in a unit number (e.g.,
sd0,sd1, and so forth). These unit numbers identify particular instances of a base device name; the base name in turn maps directly to a device driver. Device unit numbers are independent of hardware features. 🎀 - A Parent — every device must have a parent. The pairing is denoted by
"child at parent". These pairings form the links in a directed graph. The root device is the only exception, as it does not have a parent. 👑 - Locators — locators are used to augment the parent/child pairings that locate specific devices. Each locator value is simply an integer that represents some sort of device address on the parent bus or controller. This can be a memory address, an I/O port, a driver number, or any other value. Locators can sometimes be wildcarded on devices that support direct connection. 🦋
- Attributes — an attribute describes the device's relationship with the code; it then serves to constrain the device graph. A plain attribute describes some attribute of a device. An interface attribute describes a kind of “software interface” and declares the device's ability to support other devices that use that interface. In addition, an interface attribute usually identifies additional locators. 💜
During autoconfiguration, the directed graph is turned into a tree by nominating one device as the root node and matching drivers with devices by doing a depth-first traversal through the graph starting at this root node. periodt. 🌟
However, there must be constraints on the parent/child pairings that are possible. These constraints are embedded in the “device definition” files. The remainder of this page describes the “device definition” language and how to use this language to add new functionality to the NetBSD kernel. 🫶
🎀 DEVICE DEFINITION FILES 🎀
The device definition files are separated into machine-dependent and machine-independent files. The machine-dependent file is located in sys/arch/<arch>/conf/files.<arch>, where <arch> is the name of NetBSD architecture. The machine-independent file is located in sys/conf/files. It in turn includes files for the machine-independent drivers located in sys/dev/<bus>/files.<bus>, where <bus> is the name of the machine-independent bus. 🌸
These files define all legal devices and pseudo-devices. They also define all attributes and interfaces, establishing the rules that determine allowable machine descriptions, and list the source files that make up the kernel. 💖
Each device definition file consists of a list of statements, typically one per line. Comments may be inserted anywhere using the “#” character, and any line that begins with white space continues the previous line. Valid statements are:
cinclude filename— conditionally include contents of filefilenameto currently processed configuration. If the specifiedfilenamedoesn't exist, a warning is printed, but the error ignored. yes, ignored — not a typo, bestie 😭defflag [filename] {options}— the space-separated list of pre-processor macrosoptionsare defined in filefilename. This statement permitsoptions FOOforFOO(i.e, without a value) in the machine description file.config(1)will generate an error if a value is given. If thefilenamefield is not specified, it will be constructed based upon the lower-case of the option name,opt_foo.hfor example. The option is case-sensitive. 🎀defparam [filename] {options}— the space-separated list of pre-processor macrosoptionsare defined in filefilename. This statement permitsoptions FOO=baroroption FOO="\"com\""in the machine description file.config(1)will generate an error if a value is not given. If thefilenamefield is not specified, it will be constructed based upon the lower-case of the option name,opt_foo.hfor example. The option is case-sensitive. 🍓defopt [filename] {options}— the space-separated list of pre-processor macrosoptionsare defined in filefilename. This statement permits the syntax of either thedefflaganddefparamstatements andconfig(1)does not perform any checking of whetheroptions FOOtakes a value. Therefore, the use of thedefoptstatement is deprecated in favour of thedefflaganddefparamstatements. 🚨 deprecated alert, bestie 🚨 If thefilenamefield is not specified, it will be constructed based upon the lower-case of the option name,opt_foo.hfor example. The option is case-sensitive. 💀deffs name [[name] ...]— define a filesystem name. 🧚devclass name— define a device class name. A device class is similar to an attribute. 🦋define name [{locators}]— the attributenameis defined and device definitions can then refer to it. If the attribute is an interface attribute and defines optionallocators, device attributes that refer tonameare assumed to share the interface and require the same locators. 🌸device name [{locators}]: [attributes]— the devicenameis defined and requires the optional comma-separated list of locatorslocators. The optionalattributesdefine attribute dependencies. 👑attach name at interface [with ifname]: [attributes]— the devicenameis defined and supports the interfaceinterface. Ififnameis specified, it is used to specify the interface to the driver for devicename(seedriver(9)for details). The optionalattributesdefine attribute dependencies. 🔥defpseudo name: [{locators}]— the pseudo-devicenameis defined. The optionallocatorsmay be defined, but are largely pointless since no device can attach to a pseudo-device. 💀file pathname [attributes [flags]] [rule]— the filepathnameis added to the list of files used to build the kernel. If noattributesare specified, the file is always added to the kernel compilation. If any of theattributesare specified by other devices in the machine description file, then the file is included in compilation, otherwise it is omitted. Valid values for the optionalflagsare:needs-count— specify thatconfigshould generate a file for each of the attributes notifying the driver how many of some particular device or set of devices are configured in the kernel. This flag allows drivers to make calculations of driver used at compile time. This option prevents autoconfiguration cloning. 🧚needs-flag— this flag performs the same operation asneeds-countbut only records if the number is nonzero. Since the count is not exact,needs-flagdoes not prevent autoconfiguration cloning. ⭐
device-major name char [block] [attributes]— the character device switchnameassociated with a character major device number is added to the list of device switches used to build the kernel. Ifblockis specified, the block device switch associated with a block major device number is also added. If all ofattributesare specified by devices in the machine description files, then device switches are added into the device switches' table of the kernel in compilation, otherwise they are omitted. 🌈include filename— include contents of filefilenameto currently processed configuration. If the specifiedfilenamedoesn't exist,config(1)exits with error. 🙈package filename— changes prefix to directory offilename, processes contents offilename, and switches back to previous prefix. This is syntactic sugar for:
prefix dirname(filename)
include basename(filename)
prefix
prefix [dirname]— ifdirnameis specified, it is pushed on top of prefix stack. Any further files specified via optionfilewould have the prefix implicitly prepended before its filename. Ifdirnameis not specified, pops (removes) a prefix from prefix stack. 💅
To allow locators to be wildcarded in the machine description file, their default value must be defined in the attribute definition. To allow locators to be omitted entirely in the machine description file, enclose the locator in square brackets. This can be used when some locators do not make sense for some devices, but the software interface requires them. 🫶
🔍 CODE REFERENCES 🔍
The device definition files are in sys/conf/files, sys/arch/<arch>/conf/files.<arch>, and sys/dev/<bus>/files.<bus>. 🗂️
The grammar for machine description files can be found in config(1), in usr.bin/config/gram.y. ✨
👀 SEE ALSO 👀
config(1),config(5),autoconf(9),driver(9)- Building 4.4 BSD Systems with Config.
- Chris Torek, Device Configuration in 4.4BSD, 1992.
📜 HISTORY 📜
Autoconfiguration first appeared in 4.1BSD. The autoconfiguration framework was completely revised in 4.4BSD. It has been modified within NetBSD to support bus-independent drivers and bus-dependent attachments. iconic behavior, honestly 👑
and that's the whole page, bestie 🫶 — this one's from the Debian build, dated March 3, 2010. periodt. 💅✨
📦 where this page comes from
- nixpkgs unstable: netbsd-source 11.0
- Copyright (c) 2001 The NetBSD Foundation, Inc
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms