xref: /openbsd/share/man/man9/autoconf.9 (revision 8529ddd3)
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