module(9) [debian man page]

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

NAME

     module -- structure describing a kernel module

DESCRIPTION

     Each module in the kernel is described by a module_t structure.  The structure contains the name of the device, a unique ID number, a pointer
     to an event handler function and to an argument, which is given to the event handler, as well as some kernel internal data.

     The DECLARE_MODULE(9) macro registers the module with the system.

     When the module is loaded, the event handler function is called with the what argument set to MOD_LOAD.

     On unload it is first called with what set to MOD_QUIESCE.  If the unload was not forced, a non-zero return will prevent the unload from hap-
     pening.

     If the unload continues what is set to MOD_UNLOAD.  If the module returns non-zero to this, the unload will not happen.

     The difference between MOD_QUIESCE and MOD_UNLOAD is that the module should fail MOD_QUIESCE if it is currently in use, whereas MOD_UNLOAD
     should only fail if it is impossible to unload the module, for instance because there are memory references to the module which cannot be
     revoked.

     When the system is shutting down, what contains the value of MOD_SHUTDOWN.

     The module should return EOPNOTSUPP for unsupported and unrecognized values of what.

EXAMPLES

     #include <sys/param.h>
     #include <sys/kernel.h>
     #include <sys/module.h>

     static int foo_handler(module_t mod, int /*modeventtype_t*/ what,
			    void *arg);

     static moduledata_t mod_data= {
	     "foo",
	     foo_handler,
	     0
     };

     MODULE_VERSION(foo, 1);
     MODULE_DEPEND(foo, bar, 1, 3, 4);

     DECLARE_MODULE(foo, mod_data, SI_SUB_EXEC, SI_ORDER_ANY);

SEE ALSO

     DECLARE_MODULE(9), DEV_MODULE(9), DRIVER_MODULE(9), MODULE_DEPEND(9), MODULE_VERSION(9), SYSCALL_MODULE(9)

     /usr/share/examples/kld

AUTHORS

     This manual page was written by Alexander Langer <alex@FreeBSD.org>.

BSD
								   July 19, 2007							       BSD

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