Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

early_driver_module_ordered(9) [freebsd man page]

DRIVER_MODULE(9)					   BSD 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 con- tains 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 sin- gle 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
device(9), driver(9), module(9), SYSINIT(9) AUTHORS
This manual page was written by Alexander Langer <alex@FreeBSD.org>. BSD
August 21, 2012 BSD

Check Out this Related Man Page

DRIVER(9)						   BSD Kernel Developer's Manual						 DRIVER(9)

NAME
driver -- structure describing a device driver SYNOPSIS
#include <sys/param.h> #include <sys/bus.h> static int foo_probe(device_t); static int foo_attach(device_t); static int foo_detach(device_t); static int foo_frob(device_t, int, int); static int foo_twiddle(device_t, char *); static device_method_t foo_methods[] = { /* Methods from the device interface */ DEVMETHOD(device_probe, foo_probe), DEVMETHOD(device_attach, foo_attach), DEVMETHOD(device_detach, foo_detach), /* Methods from the bogo interface */ DEVMETHOD(bogo_frob, foo_frob), DEVMETHOD(bogo_twiddle, foo_twiddle), /* Terminate method list */ { 0, 0 } }; static driver_t foo_driver { "foo", foo_methods, sizeof(struct foo_softc) }; static devclass_t foo_devclass; DRIVER_MODULE(foo, bogo, foo_driver, foo_devclass, 0, 0); DESCRIPTION
Each driver in the kernel is described by a driver_t structure. The structure contains the name of the device, a pointer to a list of meth- ods, an indication of the kind of device which the driver implements and the size of the private data which the driver needs to associate with a device instance. Each driver will implement one or more sets of methods (called interfaces). The example driver implements the stan- dard "driver" interface and the fictitious "bogo" interface. When a driver is registered with the system (by the DRIVER_MODULE macro, see DRIVER_MODULE(9)), it is added to the list of drivers contained in the devclass of its parent bus type. For instance all PCI drivers would be contained in the devclass named "pci" and all ISA drivers would be in the devclass named "isa". The reason the drivers are not held in the device object of the parent bus is to handle multiple instances of a given type of bus. The DRIVER_MODULE macro will also create the devclass with the name of the driver and can optionally call extra initialisation code in the driver by specifying an extra module event handler and argument as the last two arguments. SEE ALSO
devclass(9), device(9), DEVICE_ATTACH(9), DEVICE_DETACH(9), DEVICE_IDENTIFY(9), DEVICE_PROBE(9), DEVICE_SHUTDOWN(9), DRIVER_MODULE(9) AUTHORS
This manual page was written by Doug Rabson. BSD
June 16, 1998 BSD
Man Page