config.samples man page on NetBSD

Man page or keyword search:  
man Server   9087 pages
apropos Keyword Search (all sections)
Output format
NetBSD logo
[printable version]

CONFIG.SAMPLES(5)	    BSD File Formats Manual	     CONFIG.SAMPLES(5)

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 exam‐
     ples 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, thoug 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:

	   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

   Interface attributes
     Interface attributes are a subtility of config(1) and autoconf(9), which
     often confuses users and utilities that parse dmesg(8) output to manipu‐
     late kernel configuration files.  What they are is best shown by the fol‐
     lowing 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

	   audio* at auvia?
     in the kernel configuration file, but then one instance per audio con‐
     troler 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 configura‐
     tion files because drivers for audio controlers 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)

BSD				 June 4, 2006				   BSD
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server NetBSD

List of man pages available for NetBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net