xref: /openbsd-src/share/man/man9/autoconf.9 (revision db3296cf5c1dd9058ceecc3a29fe4aaa0bd26000)
1.\"     $OpenBSD: autoconf.9,v 1.4 2003/06/06 20:56:32 jmc 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.\" 3. All advertising materials mentioning features or use of this software
19.\"    must display the following acknowledgement:
20.\"        This product includes software developed by the NetBSD
21.\"        Foundation, Inc. and its contributors.
22.\" 4. Neither the name of The NetBSD Foundation nor the names of its
23.\"    contributors may be used to endorse or promote products derived
24.\"    from this software without specific prior written permission.
25.\"
26.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
27.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
28.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
29.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
30.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
31.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
32.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
33.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
34.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
35.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
36.\" POSSIBILITY OF SUCH DAMAGE.
37.\"
38.Dd August 25, 2002
39.Dt AUTOCONF 9
40.Os
41.Sh NAME
42.Nm autoconf
43.Nd autoconfiguration framework
44.Sh SYNOPSIS
45.Fd #include \*[Lt]sys/param.h\*[Gt]
46.Fd #include \*[Lt]sys/device.h\*[Gt]
47.Sh DESCRIPTION
48Autoconfiguration is the process of matching hardware devices with an
49appropriate device driver.
50In its most basic form, autoconfiguration consists of the recursive
51process of finding and attaching all devices on a bus, including other busses.
52.Pp
53The autoconfiguration framework supports
54.Em direct configuration
55where the bus driver can determine the devices present.
56.Pp
57The autoconfiguration framework also supports
58.Em indirect configuration
59where the drivers must probe the bus looking for the presence of a device.
60Direct configuration is preferred since it can find hardware regardless of
61the presence of proper drivers.
62.Pp
63The autoconfiguration process occurs at system bootstrap and is driven by a
64table generated from a
65.Do
66machine description
67.Dc
68file by
69.Xr config 8 .
70For a description of the
71.Xr config 8
72.Do
73device definition
74.Dc
75language, see
76.Xr files.conf 5 .
77.Pp
78Each device must have a name consisting of an alphanumeric string that
79ends with a unit number.
80The unit number identifies an instance of the driver.
81Device data structures are allocated dynamically during autoconfiguration,
82giving a unique address for each instance.
83.Sh INITIALIZATION
84.nr nS 1
85.Ft "void"
86.Fn config_init "void"
87.nr nS 0
88.Pp
89The
90.Fn config_init
91function initializes autoconfiguration data structures.
92.Sh INDIRECT CONFIGURATION
93.nr nS 1
94.Ft "void *"
95.Fn config_search "cfmatch_t func" "struct device *parent" "void *aux"
96.Pp
97.Ft "void *"
98.Fn config_rootsearch "cfmatch_t func" "char *rootname" "void *aux"
99.nr nS 0
100.Pp
101The
102.Fn config_search
103function performs indirect configuration of physical devices by iterating
104over all potential children, calling the given function
105.Fa func
106for each one.
107.Pp
108The
109.Fn config_rootsearch
110function finds the root device identified by the string
111.Fa rootname ,
112in a manner similar to
113.Fn config_search ,
114except that there is no parent device.
115If
116.Fa func
117is NULL,
118.Pp
119.Fn config_search
120applies each child's match function instead.
121The argument
122.Fa parent
123is the pointer to the parent's device structure.
124The given
125.Fa aux
126argument describes the device that has been found and is simply passed
127on through
128.Fa func
129to the child.
130.Fn config_search
131returns a pointer to the best-matched child or NULL otherwise.
132.Pp
133The role of
134.Fa func
135is to call
136the match function for each device and call
137.Fn config_attach
138for any positive matches.
139.Bd -literal
140typedef int (*cfmatch_t)(struct device *parent, void *child, void *aux);
141.Ed
142.Pp
143If
144.Fa func
145is
146.Dv NULL ,
147then the parent should record the return value from
148.Fn config_search
149and call
150.Fn config_attach
151itself.
152.Pp
153Note that this function is designed so that it can be used to apply an
154arbitrary function to all potential children.
155In this case callers may choose to ignore the return value.
156.Sh DIRECT CONFIGURATION
157.nr nS 1
158.Ft "struct device *"
159.Fn config_found_sm "struct device *parent" "void *aux" "cfprint_t print" \
160                    "cfmatch_t submatch"
161.Pp
162.Ft "struct device *"
163.Fn config_found "struct device *parent" "void *aux" "cfprint_t print"
164.Pp
165.Ft "struct device *"
166.Fn config_rootfound "char *rootname" "void *aux"
167.nr nS 0
168.Pp
169The
170.Fn config_found_sm
171function performs direct configuration on a physical device.
172.Fn config_found_sm
173is called by the parent and in turn calls the
174.Fa submatch
175function to call the match function as determined by the configuration table.
176If
177.Fa submatch
178is NULL, the driver match functions are called directly.
179The argument
180.Fa parent
181is the pointer to the parent's device structure.
182The given
183.Fa aux
184argument describes the device that has been found.
185The
186.Em softc
187structure for the matched device will be allocated, and the appropriate
188driver attach function will be called.
189.Pp
190If the device is matched, the system prints the name of the child and
191parent devices, and then calls the
192.Fa print
193function to produce additional information if desired.
194If no driver takes a match, the same
195.Fa print
196function is called to complain.
197The print function is called with the
198.Fa aux
199argument and, if the matches failed, the full name (including unit
200number) of the parent device, otherwise NULL.
201.Pp
202.Bd -literal
203typedef int (*cfprint_t)(void *aux, const char *parentname);
204#define	QUIET	0		/* print nothing */
205#define	UNCONF	1		/* print " not configured" */
206#define	UNSUPP	2		/* print " not supported" */
207.Ed
208.Pp
209Two special strings,
210.Do
211not configured
212.Dc
213and
214.Do
215unsupported
216.Dc
217will be appended automatically to non-driver reports if the return
218value is
219.Dv UNCONF
220or
221.Dv UNSUPP
222respectively, otherwise the function should return the value
223.Dv QUIET .
224.Pp
225The
226.Fn config_found_sm
227function returns a pointer to the attached device's
228.Em softc
229structure if the device is attached, NULL otherwise.
230Most callers can ignore this value, since the system will already have
231printed a diagnostic.
232.Pp
233The
234.Fn config_found
235macro expands to
236.Fn config_found_sm "parent" "aux" "print" "submatch"
237with
238.Fa submatch
239set to
240.Dv NULL
241and is provided for compatibility with older drivers.
242.Pp
243The
244.Fn config_rootfound
245function performs the same operation on the root device identified
246by the
247.Fa rootname
248string.
249.Sh ATTACHING AND DETACHING DEVICES
250.nr nS 1
251.Ft "struct device *"
252.Fn config_attach "struct device *parent" "void *cf" "void *aux" \
253                  "cfprint_t print"
254.Pp
255.Ft "int"
256.Fn config_detach "struct device *dev" "int flags"
257.nr nS 0
258.Pp
259The
260.Fn config_attach
261function attaches a found device.
262Memory is allocated for the
263.Em softc
264structure and the driver's attach function is called according to the
265configuration table.
266If successful,
267.Fn config_attach
268returns the
269.Em softc .
270If unsuccessful, it returns
271.Dv NULL .
272.Pp
273The
274.Fn config_detach
275function is called by the parent to detach the child device.
276The second argument
277.Em flags
278contains detachment flags:
279.Pp
280.Bd -literal
281#define	DETACH_FORCE	0x01	/* Force detachment; hardware gone */
282#define	DETACH_QUIET	0x02	/* Don't print a notice */
283.Ed
284.Pp
285The
286.Fn config_detach
287function returns zero if successful and an error code otherwise.
288.Fn config_detach
289is always called from process context, allowing
290.Xr sleep 9
291to be called while the device detaches itself (to deal with processes
292which have a device open).
293.Sh DEVICE ACTIVATION/DEACTIVATION
294.nr nS 1
295.Ft "int"
296.Fn config_activate "struct device *dev"
297.Pp
298.Ft "int"
299.Fn config_deactivate "struct device *dev"
300.nr nS 0
301.Pp
302The
303.Fn config_activate
304function is called by the parent to activate the child device
305.Fa dev .
306It is called to activate resources and initialise other kernel
307subsystems (such as the network subsystem).
308.Fn config_activate
309is called from interrupt context after the device has been attached.
310.Pp
311The
312.Fn config_deactivate
313function is called by the parent to deactivate the child device
314.Fa dev .
315.Fn config_deactivate
316is called from interrupt context to immediately relinquish resources
317and notify dependent kernel subsystems that the device is about to be
318detached.
319At some later point,
320.Fn config_detach
321will be called to finalise the removal of the device.
322.Sh DEFERRED CONFIGURATION
323.nr nS 1
324.Ft "void"
325.Fn config_defer "struct device *dev" "void (*func)(struct device *)"
326.nr nS 0
327.Pp
328The
329.Fn config_defer
330function is called by the child to defer the remainder of its configuration
331until all its parent's devices have been attached.
332At this point, the function
333.Fa func
334is called with the argument
335.Fa dev .
336.Sh CODE REFERENCES
337The autoconfiguration framework itself is implemented within the file
338.Pa sys/kern/subr_autoconf.c .
339Data structures and function prototypes for the framework are located in
340.Pa sys/sys/device.h .
341.Sh SEE ALSO
342.Xr config 8
343.Sh HISTORY
344Autoconfiguration first appeared in
345.Bx 4.1 .
346The autoconfiguration framework was completely revised in
347.Bx 4.4 .
348The detach and activate/deactivate interfaces appeared in
349.Nx 1.5 .
350