.\" $NetBSD: config.5,v 1.38 2017/07/03 21:34:18 wiz Exp $ .\" .\" Copyright (c) 2006, 2007 The NetBSD Foundation. .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE .\" POSSIBILITY OF SUCH DAMAGE. .\" .Dd July 19, 2016 .Dt CONFIG 5 .Os .Sh NAME .Nm config .Nd kernel configuration file syntax .Sh DESCRIPTION The kernel configuration file specifies the way the kernel should be compiled by the rest of the toolchain. It is processed by .Xr config 1 to produce a number of files that will allow the user to compile a possibly customised kernel. One compilation can issue several kernel binaries, with different root and dump devices configurations, or with full debugging information. .Pp This manual page is intended to serve as a complete reference of all aspects of the syntax used in the many files processed by .Xr config 1 . The novice user will prefer looking at the examples given in .Xr config.samples 5 in order to understand better how the default configuration can be changed, and how all of its elements interact with each other. .Pp The kernel configuration file actually contains the description of all the options, drivers and source files involved in the kernel compilation, and the logic that binds them. The .Ic machine statement, usually found in the .Pa std.${MACHINE} file, hides this from the user by automatically including all the descriptive files spread all around the kernel source tree, the main one being .Pa conf/files . .Pp Thus, the kernel configuration file contains two parts: the description of the compilation options, and the selection of those options. However, it begins with a small preamble that controls a couple of options of .Xr config 1 , and a few statements belong to any of the two sections. .Pp The user controls the options selection part, which is located in a file commonly referenced as the .Em main configuration file or simply the .Em kernel configuration file . The developer is responsible for describing the options in the relevant files from the kernel source tree. .Pp Statements are separated by new-line characters. However, new-line characters can appear in the middle of a given statement, with the value of a space character. .Ss OBJECTS AND NAMES .Xr config 1 is a rather complicated piece of software that tries to comply with any configuration the user might think of. Quite a few different objects are manipulated through the kernel configuration file, therefore some definitions are needed. .Ss Options and attributes The basic objects driving the kernel compilation are .Em options , and are called .Ar attributes in some contexts. An .Ar attribute usually refers to a feature a given piece of hardware might have. However, the scope of an attribute is rather wide and can just be a place holder to group some source files together. .Pp There is a special class of attribute, named .Em interface attribute , which represents a hook that allows a device to attach to (i.e., be a child of) another device. An .Em interface attribute has a (possibly empty) list of .Ar locators to match the actual location of a device. For example, on a PCI bus, devices are located by a .Em device number that is fixed by the wiring of the motherboard. Additionally, each of those devices can appear through several interfaces named .Em functions . A single PCI device entity is a unique function number of a given device from the considered PCI bus. Therefore, the locators for a .Xr pci 4 device are .Ar dev (for device), and .Ar function . .Pp A .Ar locator can either be a single integer value, or an array of integer values. It can have a default value, in which case it can be wildcarded with a .Dq \&? in the options selection section of the configuration file. A single .Ar locator definition can take one of the following forms: .Bl -enum -offset indent -compact .It .Ar locator .It .Ar locator = .Ar value .It .Ar locator Ns Oo Ar length Oc .It .Ar locator Ns Oo Ar length Oc = Brq Ar value , ... .El The variants that specify a default value can be enclosed into square brackets, in which case the locator will not have to be specified later in the options selection section of the configuration file. .Pp In the options selection section, the locators are specified when declaring an instance as a space-separated list of .Dq Ao Ar locator Ac Ao Ar value Ac where value can be the .Dq \&? wildcard if the locator allows it. .Ss Devices, instances and attachments The main benefit of the kernel configuration file is to allow the user to avoid compiling some drivers, and wire down the configuration of some others. We have already seen that devices attach to each other through .Em interface attributes , but not everything can attach to anything. Furthermore, the user has the ability to define precise instances for the devices. An .Ar instance is simply the reality of a device when it is probed and attached by the kernel. .Pp Each driver has a name for its devices. It is called the base device name and is found as .Ar base in this documentation. An .Ar instance is the concatenation of a device name and a number. In the kernel configuration file, instances can sometimes be wildcarded (i.e., the number is replaced by a .Dq * or a .Dq \&? ) in order to match all the possible instances of a device. .Pp The usual .Dq * becomes a .Dq \&? when the instance name is used as an .Em attachment name . In the options selection part of the kernel configuration files, an .Em attachment is an .Em interface attribute concatenated with a number or the wildcard .Dq \&? . .Ss Pseudo-devices Some components of the kernel behave like a device although they don't have any actual reality in the hardware. For example, this is the case for special network devices, such as .Xr tun 4 and .Xr tap 4 . They are integrated in the kernel as pseudo-devices, and can have several instances and even children, just like normal devices. .Ss Dependencies The options description part of the kernel configuration file contains all the logic that ties the source files together, and it is done first through writing down dependencies between .Xr config 1 objects. .Pp In this documentation, the syntax for .Ar dependencies is a comma-separated list of .Ar options and .Ar attributes . .Pp For example, the use of an Ethernet network card requires the source files that handle the specificities of that protocol. Therefore, all Ethernet network card drivers depend on the .Ar ether attribute. .Ss Conditions Finally, source file selection is possible through the help of conditionals, referred to as .Ar condition later in this documentation. The syntax for those conditions uses well-known operators ( .Dq & , .Dq | and .Dq \&! ) to combine .Ar options and .Ar attributes . .Ss CONTEXT NEUTRAL STATEMENTS .Bl -ohang .It Ic version Ar yyyymmdd Indicates the syntax version used by the rest of the file, or until the next .Ic version statement. The argument is an ISO date. A given .Xr config 1 binary might only be compatible with a limited range of version numbers. .It Ic include Ar path Includes a file. The path is relative to the top of the kernel source tree, or the inner-most defined .Ic prefix . .It Ic cinclude Ar path Conditionally includes a file. Contrary to .Ic include , it will not produce an error if the file does not exist. The argument obeys the same rules as for .Ic include . .It Ic prefix Op Ar path If .Ar path is given, it pushes a new prefix for .Ic file , .Ic include and .Ic cinclude . .Ic prefix statements act like a stack, and an empty .Ar path argument has the latest prefix popped out. The .Ar path argument is either absolute or relative to the current defined prefix, which defaults to the top of the kernel source tree. .It Ic buildprefix Op Ar path If .Ar path is given, it pushes a new build prefix for .Ic file . .Ic buildprefix statements act like a stack, and an empty .Ar path argument has the latest prefix popped out. The .Ar path argument is relative to the current defined buildprefix, which defaults to the top of the kernel build directory. When prefix is either absolute or relative out of the kernel source tree (../), buildprefix must be defined. .It Ic ifdef Ar attribute .It Ic ifndef Ar attribute .It Ic elifdef Ar attribute .It Ic elifndef Ar attribute .It Ic else .It Ic endif Conditionally interprets portions of the current file. Those statements depend on whether or not the given .Ar attribute has been previously defined, through .Ic define or any other statement that implicitely defines attributes such as .Ic device . .El .Ss PREAMBLE In addition to .Ic include , cinclude , and .Ic prefix , the preamble may contain the following optional statements: .Bl -ohang .It Ic build Ar path Defines the build directory for the compilation of the kernel. It replaces the default of .Pa ../compile/ and is superseded by the .Fl b parameter of .Xr config 1 . .It Ic source Ar path Defines the directory in which the source of the kernel lives. It replaces the default of .Pa ../../../.. and is superseded by the .Fl s parameter of .Xr config 1 . .El .Ss OPTIONS DESCRIPTION The user will not usually have to use descriptive statements, as they are meant for the developer to tie a given piece of code to the rest of the kernel. However, third parties may provide sources to add to the kernel compilation, and the logic that binds them to the .Nx kernel will have to be added to the user-edited configuration file. .Bl -ohang .It Ic devclass Ar class Defines a special attribute, named .Em device class . A given device cannot belong to more than one device class. .Xr config 1 translates that property by the rule that a device cannot depend on more than one device class, and will properly fill the configuration information file it generates according to that value. .It Ic defflag Oo Ar file Oc Ar option Oo Ar option Oo Ar ... Oc Oc \ Op : Ar dependencies Defines a boolean option, that can either be selected or be un-selected by the user with the .Ic options statement. The optional .Ar file argument names a header file that will contain the C pre-processor definition for the option. If no file name is given, it will default to .Ar opt_