| CONFIG.SAMPLES(5) | File Formats Manual | CONFIG.SAMPLES(5) | 
config.samples —
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.
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.
While negating an options with
    no options is unambiguous, it is not as clear for
    devices instances.
The no
    instance-definition statements of
    config(5) 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:
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:
no isa*
is what is intended, the isa(4) instance itself must be kept, and that is precisely the difference made by:
no device at isa0
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
audio* at auvia?
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 maintenance 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?
| June 4, 2006 | NetBSD 10.0 |