NAME
config.samples —
kernel configuration
file syntax examples
DESCRIPTION
Devices, drivers and
instances
For a given device, at most one driver will attach. In order for a driver to
attach, the kernel configuration file must include a compatible instance of
the driver for the location of the device. The following lines from the
GENERIC kernel configuration file of
NetBSD/i386 are examples of instances of drivers:
pchb* at pci? dev ? function ? # PCI-Host bridges
pcib* at pci? dev ? function ? # PCI-ISA bridges
ppb* at pci? dev ? function ? # PCI-PCI bridges
siop* at pci? dev ? function ? # Symbios 53c8xx SCSI
esiop* at pci? dev ? function ? # Symbios 53c875 SCSI and newer
ix0 at isa? port 0x300 irq 10 # EtherExpress/16
The first three instances allow three different drivers to attach to all the
matching devices found on any PCI bus. This is the most generic case.
The next two lines allow two distinct drivers to attach to any matching device
found on any PCI bus, but those two drivers are special because they both
support some of the same devices. Each of the driver has a matching function
that returns their score for the device that is being considered.
autoconf(9) decides at
run-time which driver will attach. Of course, it is deterministic so if the
user wants to change the driver that attaches to the device, the instance of
the other driver will have to be removed, e.g. by commenting it out.
The last line configures an instance of an ISA device. Unlike the PCI bus, the
ISA bus cannot discover the devices that are present on the bus. The driver
has to try accessing the device in order to discover it. That implies locators
must be specified to some extent: a driver would usually need the base address
of the device, some need the IRQ line that the device is configured to use,
though some others would just try a set of known values, at the risk of badly
interacting with other devices on the bus.
Hard-wiring kernel
configuration
This technique consists in specifying exactly the location of the devices on a
given system. In the general case it has very little use, because it does not
change the size of the kernel, and it will prevent it from finding devices in
case the hardware changes, even slightly.
Let's consider the following excerpt of
dmesg(8) output:
auich0 at pci0 dev 31 function 5: i82801DB/DBM (ICH4/ICH4M) AC-97 Audio
The
auich(4) driver (which controls
Intel's AC-97 audio chips) attached there because of the following instance of
GENERIC:
auich* at pci? dev ? function ?
Hard-wiring that instance means re-writing it to the following:
auich0 at pci0 dev 31 function 5
and that way,
auich0 will attach to that specific
location, or will not attach.
Removing options and
drivers
When two kernel configurations differ by a very small number of changes, it is
easier to manage them by having one include the other, and add or remove the
differences. Removing options and drivers is also useful in the situation of a
user who wants to follow the development of
NetBSD:
drivers and options get added to the configuration files found in the source
tree, such as
GENERIC, so one can include it and remove all
options and drivers that are not relevant to the considered system. Additions
to
GENERIC will then automatically be followed and used in
case they are relevant.
While negating an options (with
no options) is unambiguous, it
is not as clear for devices instances.
The
no instance definition statements of
config(1) syntax only apply on
the current state of the configuration file, not on the resulting kernel
binary.
autoconf(9) has no
knowledge of instance negation, thus it is currently impossible to express the
following in a kernel configuration file:
“I want support for
ath(4) attaching at
pci(4), but I do not want any
instance of
ath(4) attaching at
pci3.”
For a real-world use of
no device at
instance consider the following, taken from
NetBSD/i386:
include "arch/i386/conf/GENERIC"
acpi0 at mainbus?
com* at acpi?
[... more instances of legacy devices attaching at acpi? ...]
no device at isa0
One could actually live without the
isa0 instance, as all
the legacy devices are attached at
acpi0. But
unfortunately, dependencies on the
isa attribute are not
well registered all through the source tree, so an instance of the
isa(4) driver is required to
compile a kernel. So while:
is what is intended, the
isa(4)
instance itself must be kept, and that is precisely the difference made by:
Interface attributes
Interface attributes are a subtlety of
config(1) and
autoconf(9), which often
confuses users and utilities that parse
dmesg(8) output to manipulate
kernel configuration files. What they are is best shown by the following
example.
The
dmesg(8) output look like this:
auvia0 at pci0 dev 17 function 5: VIA Technologies VT8235 AC'97 Audio (rev 0x50)
audio0 at auvia0: full duplex, mmap, independent
while the kernel configuration look like this:
auvia* at pci? dev ? function ?
audio* at audiobus?
It is not obvious from the kernel configuration file that an
audio(4) device can attach at an
auvia(4) device.
audiobus is an
interface attribute,
exposed by
auvia.
Of course, it is possible to specify
in the kernel configuration file, but then one instance per audio controller
would be needed.
Interface attributes reflect the fact there
is a standard way to attach a device to its parent, no matter what the latter
is precisely. It also means lower maintainance of the kernel configuration
files because drivers for audio controllers are added more easily.
Most attachments are done through
interface attributes,
although only a few of them are specified that way in the configuration files
found in the tree. Another example of such an attribute is
ata:
viaide0 at pci0 dev 17 function 1
atabus0 at viaide0 channel 0
viaide* at pci? dev ? function ?
atabus* at ata?
SEE ALSO
config(1),
options(4),
config(5),
dmesg(8)