1.\" $OpenBSD: autoconf.9,v 1.14 2014/07/13 09:37:22 mpi Exp $ 2.\" $NetBSD: autoconf.9,v 1.9 2002/02/13 08:18:35 ross Exp $ 3.\" 4.\" Copyright (c) 2001 The NetBSD Foundation, Inc. 5.\" All rights reserved. 6.\" 7.\" This code is derived from software contributed to The NetBSD Foundation 8.\" by Gregory McGarry. 9.\" 10.\" Redistribution and use in source and binary forms, with or without 11.\" modification, are permitted provided that the following conditions 12.\" are met: 13.\" 1. Redistributions of source code must retain the above copyright 14.\" notice, this list of conditions and the following disclaimer. 15.\" 2. Redistributions in binary form must reproduce the above copyright 16.\" notice, this list of conditions and the following disclaimer in the 17.\" documentation and/or other materials provided with the distribution. 18.\" 19.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS 20.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 21.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 22.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 23.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 24.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 25.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 26.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 27.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 28.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 29.\" POSSIBILITY OF SUCH DAMAGE. 30.\" 31.Dd $Mdocdate: July 13 2014 $ 32.Dt AUTOCONF 9 33.Os 34.Sh NAME 35.Nm autoconf 36.Nd autoconfiguration framework 37.Sh SYNOPSIS 38.In sys/param.h 39.In sys/device.h 40.Sh DESCRIPTION 41Autoconfiguration is the process of matching hardware devices with an 42appropriate device driver. 43In its most basic form, autoconfiguration consists of the recursive 44process of finding and attaching all devices on a bus, including other buses. 45.Pp 46The autoconfiguration framework supports 47.Em direct configuration 48where the bus driver can determine the devices present. 49.Pp 50The autoconfiguration framework also supports 51.Em indirect configuration 52where the drivers must probe the bus looking for the presence of a device. 53Direct configuration is preferred since it can find hardware regardless of 54the presence of proper drivers. 55.Pp 56The autoconfiguration process occurs at system bootstrap and is driven by a 57table generated from a 58.Do 59machine description 60.Dc 61file by 62.Xr config 8 . 63For a description of the 64.Xr config 8 65.Do 66device definition 67.Dc 68language, see 69.Xr files.conf 5 . 70.Pp 71Each device must have a name consisting of an alphanumeric string that 72ends with a unit number. 73The unit number identifies an instance of the driver. 74Device data structures are allocated dynamically during autoconfiguration, 75giving a unique address for each instance. 76.Sh INDIRECT CONFIGURATION 77.nr nS 1 78.Ft "void *" 79.Fn config_search "cfmatch_t func" "struct device *parent" "void *aux" 80.Ft "void *" 81.Fn config_rootsearch "cfmatch_t func" "char *rootname" "void *aux" 82.nr nS 0 83.Pp 84The 85.Fn config_search 86function performs indirect configuration of physical devices by iterating 87over all potential children, calling the given function 88.Fa func 89for each one. 90.Pp 91The 92.Fn config_rootsearch 93function finds the root device identified by the string 94.Fa rootname , 95in a manner similar to 96.Fn config_search , 97except that there is no parent device. 98If 99.Fa func 100is 101.Dv NULL , 102.Fn config_search 103applies each child's match function instead. 104The argument 105.Fa parent 106is the pointer to the parent's device structure. 107The given 108.Fa aux 109argument describes the device that has been found and is simply passed 110on through 111.Fa func 112to the child. 113.Fn config_search 114returns a pointer to the best-matched child or 115.Dv NULL 116otherwise. 117.Pp 118The role of 119.Fa func 120is to call 121the match function for each device and call 122.Fn config_attach 123for any positive matches. 124.Bd -literal 125typedef int (*cfmatch_t)(struct device *parent, void *child, void *aux); 126.Ed 127.Pp 128If 129.Fa func 130is 131.Dv NULL , 132then the parent should record the return value from 133.Fn config_search 134and call 135.Fn config_attach 136itself. 137.Pp 138Note that this function is designed so that it can be used to apply an 139arbitrary function to all potential children. 140In this case callers may choose to ignore the return value. 141.Sh DIRECT CONFIGURATION 142.nr nS 1 143.Ft "struct device *" 144.Fn config_found_sm "struct device *parent" "void *aux" "cfprint_t print" \ 145 "cfmatch_t submatch" 146.Ft "struct device *" 147.Fn config_found "struct device *parent" "void *aux" "cfprint_t print" 148.Ft "struct device *" 149.Fn config_rootfound "char *rootname" "void *aux" 150.nr nS 0 151.Pp 152The 153.Fn config_found_sm 154function performs direct configuration on a physical device. 155.Fn config_found_sm 156is called by the parent and in turn calls the 157.Fa submatch 158function to call the match function as determined by the configuration table. 159If 160.Fa submatch 161is 162.Dv NULL , 163the driver match functions are called directly. 164The argument 165.Fa parent 166is the pointer to the parent's device structure. 167The given 168.Fa aux 169argument describes the device that has been found. 170The 171.Em softc 172structure for the matched device will be allocated, and the appropriate 173driver attach function will be called. 174.Pp 175If the device is matched, the system prints the name of the child and 176parent devices, and then calls the 177.Fa print 178function to produce additional information if desired. 179If no driver takes a match, the same 180.Fa print 181function is called to complain. 182The print function is called with the 183.Fa aux 184argument and, if the matches failed, the full name (including unit 185number) of the parent device, otherwise 186.Dv NULL . 187.Bd -literal 188typedef int (*cfprint_t)(void *aux, const char *parentname); 189#define QUIET 0 /* print nothing */ 190#define UNCONF 1 /* print " not configured" */ 191#define UNSUPP 2 /* print " not supported" */ 192.Ed 193.Pp 194Two special strings, 195.Do 196not configured 197.Dc 198and 199.Do 200unsupported 201.Dc 202will be appended automatically to non-driver reports if the return 203value is 204.Dv UNCONF 205or 206.Dv UNSUPP 207respectively, otherwise the function should return the value 208.Dv QUIET . 209.Pp 210The 211.Fn config_found_sm 212function returns a pointer to the attached device's 213.Em softc 214structure if the device is attached, 215.Dv NULL 216otherwise. 217Most callers can ignore this value, since the system will already have 218printed a diagnostic. 219.Pp 220The 221.Fn config_found 222macro expands to 223.Fn config_found_sm "parent" "aux" "print" "submatch" 224with 225.Fa submatch 226set to 227.Dv NULL 228and is provided for compatibility with older drivers. 229.Pp 230The 231.Fn config_rootfound 232function performs the same operation on the root device identified 233by the 234.Fa rootname 235string. 236.Sh DEFERRED CONFIGURATION 237.nr nS 1 238.Ft "void" 239.Fn config_defer "struct device *dev" "void (*func)(struct device *)" 240.nr nS 0 241.Pp 242The 243.Fn config_defer 244function is called by the child to defer the remainder of its configuration 245until all its parent's devices have been attached. 246At this point, the function 247.Fa func 248is called with the argument 249.Fa dev . 250.Sh CODE REFERENCES 251The autoconfiguration framework itself is implemented within the file 252.Pa sys/kern/subr_autoconf.c . 253Data structures and function prototypes for the framework are located in 254.Pa sys/sys/device.h . 255.Sh SEE ALSO 256.Xr autoconf 4 , 257.Xr files.conf 5 , 258.Xr config 8 , 259.Xr config_attach 9 260.Sh HISTORY 261Autoconfiguration first appeared in 262.Bx 4.1 . 263The autoconfiguration framework was completely revised in 264.Bx 4.4 . 265