table of contents
| DRIVER_MODULE(9) | Kernel Developer's Manual | DRIVER_MODULE(9) |
NAME¶
DRIVER_MODULE,
DRIVER_MODULE_ORDERED,
EARLY_DRIVER_MODULE,
EARLY_DRIVER_MODULE_ORDERED —
kernel driver declaration macro
SYNOPSIS¶
#include
<sys/param.h>
#include <sys/kernel.h>
#include <sys/bus.h>
#include <sys/module.h>
DRIVER_MODULE(name,
busname,
driver_t driver,
devclass_t devclass,
modeventhand_t evh,
void *arg);
DRIVER_MODULE_ORDERED(name,
busname,
driver_t driver,
devclass_t devclass,
modeventhand_t evh,
void *arg,
int order);
EARLY_DRIVER_MODULE(name,
busname,
driver_t driver,
devclass_t devclass,
modeventhand_t evh,
void *arg,
enum sysinit_elem_order
order, int
pass);
EARLY_DRIVER_MODULE_ORDERED(name,
busname,
driver_t driver,
devclass_t devclass,
modeventhand_t evh,
void *arg,
enum sysinit_elem_order
order, int
pass);
DESCRIPTION¶
The
DRIVER_MODULE()
macro declares a kernel driver. DRIVER_MODULE()
expands to the real driver declaration, where the phrase
name is used as the naming prefix for the driver and
its functions. Note that it is supplied as plain text, and not a
char or char *.
busname is the parent bus of the driver
(PCI, ISA, PPBUS and others), e.g.
‘pci’,
‘isa’, or
‘ppbus’.
The identifier used in
DRIVER_MODULE()
can be different from the driver name. Also, the same driver identifier can
exist on different busses, which is a pretty clean way of making front ends
for different cards using the same driver on the same or different busses.
For example, the following is allowed:
DRIVER_MODULE(foo,
isa, foo_driver,
foo_devclass, NULL,
NULL);
DRIVER_MODULE(foo,
pci, foo_driver,
foo_devclass, NULL,
NULL);
driver is the driver of
type driver_t, which contains the information about
the driver and is therefore one of the two most important parts of the call
to
DRIVER_MODULE().
The devclass argument contains the kernel-internal information about the device, which will be used within the kernel driver module.
The evh argument is the event handler which is called when the driver (or module) is loaded or unloaded (see module(9)).
The arg is unused at this time and should be
a NULL pointer.
The
DRIVER_MODULE_ORDERED()
macro allows a driver to be registered in a specific order. This can be
useful if a single kernel module contains multiple drivers that are
inter-dependent. The order argument should be one of
the SYSINIT(9) initialization ordering constants
(SI_ORDER_*). The default order for a driver module
is SI_ORDER_MIDDLE. Typically a module will specify
an order of SI_ORDER_ANY for a single driver to
ensure it is registered last.
The
EARLY_DRIVER_MODULE()
macro allows a driver to be registered for a specific pass level. The boot
time probe and attach process makes multiple passes over the device tree.
Certain critical drivers that provide basic services needed by other devices
are attach during earlier passes. Most drivers are attached in a final
general pass. A driver that attaches during an early pass must register for
a specific pass level (BUS_PASS_*) via the pass
argument. Once a driver is registered it is available to attach to devices
for all subsequent passes.
The
EARLY_DRIVER_MODULE_ORDERED()
macro allows a driver to be registered both in a specific order and for a
specific pass level.
SEE ALSO¶
AUTHORS¶
This manual page was written by Alexander Langer <alex@FreeBSD.org>.
| August 21, 2012 | Debian |