]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/blob - share/man/man9/DRIVER_MODULE.9
Remove $FreeBSD$: two-line nroff pattern
[FreeBSD/FreeBSD.git] / share / man / man9 / DRIVER_MODULE.9
1 .\" -*- nroff -*-
2 .\"
3 .\" Copyright (c) 2000 Alexander Langer
4 .\"
5 .\" All rights reserved.
6 .\"
7 .\" This program is free software.
8 .\"
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
11 .\" are met:
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\"    notice, this list of conditions and the following disclaimer.
14 .\" 2. Redistributions in binary form must reproduce the above copyright
15 .\"    notice, this list of conditions and the following disclaimer in the
16 .\"    documentation and/or other materials provided with the distribution.
17 .\"
18 .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR
19 .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
20 .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
21 .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
22 .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
23 .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
24 .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
25 .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
26 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
27 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
28 .\"
29 .Dd April 19, 2022
30 .Dt DRIVER_MODULE 9
31 .Os
32 .Sh NAME
33 .Nm DRIVER_MODULE ,
34 .Nm DRIVER_MODULE_ORDERED ,
35 .Nm EARLY_DRIVER_MODULE ,
36 .Nm EARLY_DRIVER_MODULE_ORDERED
37 .Nd kernel driver declaration macro
38 .Sh SYNOPSIS
39 .In sys/param.h
40 .In sys/kernel.h
41 .In sys/bus.h
42 .In sys/module.h
43 .Fn DRIVER_MODULE name busname "driver_t driver" "modeventhand_t evh" "void *arg"
44 .Fn DRIVER_MODULE_ORDERED name busname "driver_t driver" "modeventhand_t evh" "void *arg" "int order"
45 .Fn EARLY_DRIVER_MODULE name busname "driver_t driver" "modeventhand_t evh" "void *arg" "int pass"
46 .Fn EARLY_DRIVER_MODULE_ORDERED name busname "driver_t driver" "modeventhand_t evh" "void *arg" "enum sysinit_elem_order order" "int pass"
47 .Sh DESCRIPTION
48 The
49 .Fn DRIVER_MODULE
50 macro declares a kernel driver.
51 .Fn DRIVER_MODULE
52 expands to the real driver declaration, where the phrase
53 .Fa name
54 is used as the naming prefix for the driver and its functions.
55 Note that it is supplied as plain text, and not a
56 .Li char
57 or
58 .Li char * .
59 .Pp
60 .Fa busname
61 is the parent bus of the driver (PCI, ISA, PPBUS and others), e.g.\&
62 .Ql pci ,
63 .Ql isa ,
64 or
65 .Ql ppbus .
66 .Pp
67 The identifier used in
68 .Fn DRIVER_MODULE
69 can be different from the driver name.
70 Also, the same driver identifier can exist on different buses,
71 which is a pretty clean way of making front ends for different cards
72 using the same driver on the same or different buses.
73 For example, the following is allowed:
74 .Pp
75 .Fn DRIVER_MODULE foo isa foo_driver NULL NULL ;
76 .Pp
77 .Fn DRIVER_MODULE foo pci foo_driver NULL NULL ;
78 .Pp
79 .Fa driver
80 is the driver of type
81 .Li driver_t ,
82 which contains the information about the driver and is therefore one of the
83 two most important parts of the call to
84 .Fn DRIVER_MODULE .
85 .Pp
86 The
87 .Fa evh
88 argument is the event handler which is called when the driver (or module)
89 is loaded or unloaded (see
90 .Xr module 9 ) .
91 .Pp
92 The
93 .Fa arg
94 is unused at this time and should be a
95 .Dv NULL
96 pointer.
97 .Pp
98 The
99 .Fn DRIVER_MODULE_ORDERED
100 macro allows a driver to be registered in a specific order.
101 This can be useful if a single kernel module contains multiple drivers
102 that are inter-dependent.
103 The
104 .Fa order
105 argument should be one of the
106 .Xr SYSINIT 9
107 initialization ordering constants
108 .Pq Dv SI_ORDER_* .
109 The default order for a driver module is
110 .Dv SI_ORDER_MIDDLE .
111 Typically a module will specify an order of
112 .Dv SI_ORDER_ANY
113 for a single driver to ensure it is registered last.
114 .Pp
115 The
116 .Fn EARLY_DRIVER_MODULE
117 macro allows a driver to be registered for a specific pass level.
118 The boot time probe and attach process makes multiple passes over the
119 device tree.
120 Certain critical drivers that provide basic services needed by other
121 devices are attached during earlier passes.
122 Most drivers are attached in a final general pass.
123 A driver that attaches during an early pass must register for a specific
124 pass level
125 .Pq BUS_PASS_*
126 via the
127 .Fa pass
128 argument.
129 Once a driver is registered it is available to attach to devices for
130 all subsequent passes.
131 .Pp
132 The
133 .Fn EARLY_DRIVER_MODULE_ORDERED
134 macro allows a driver to be registered both in a specific order and
135 for a specific pass level.
136 .Sh SEE ALSO
137 .Xr device 9 ,
138 .Xr driver 9 ,
139 .Xr module 9 ,
140 .Xr MODULE_PNP_INFO 9 ,
141 .Xr SYSINIT 9
142 .Sh HISTORY
143 Prior to
144 .Fx 14.0 ,
145 these macros accepted an additional
146 .Vt devclass_t
147 argument after
148 .Fa driver .
149 .Sh AUTHORS
150 This manual page was written by
151 .An Alexander Langer Aq Mt alex@FreeBSD.org .