Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

sysinit(9) [freebsd man page]

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

NAME
SYSINIT, SYSUNINIT -- a framework for dynamic kernel initialization SYNOPSIS
#include <sys/param.h> #include <sys/kernel.h> SYSINIT(uniquifier, enum sysinit_sub_id subsystem, enum sysinit_elem_order order, sysinit_cfunc_t func, const void *ident); SYSUNINIT(uniquifier, enum sysinit_sub_id subsystem, enum sysinit_elem_order order, sysinit_cfunc_t func, const void *ident); DESCRIPTION
SYSINIT is a mechanism for scheduling the execution of initialization and teardown routines. This is similar to init and fini routines with the addition of explicit ordering metadata. It allows runtime ordering of subsystem initialization in the kernel as well as kernel modules (KLDs). The SYSINIT() macro creates a struct sysinit and stores it in a startup linker set. The struct sysinit type as well as the subsystem identi- fier constants (SI_SUB_*) and initialization ordering constants (SI_ORDER_*) are defined in <sys/kernel.h>: struct sysinit { enum sysinit_sub_id subsystem; /* subsystem identifier*/ enum sysinit_elem_order order; /* init order within subsystem*/ sysinit_cfunc_t func; /* function */ const void *udata; /* multiplexer/argument */ }; The SYSINIT() macro takes a uniquifier argument to identify the particular function dispatch data, the subsystem type of startup interface, the subsystem element order of initialization within the subsystem, the func function to call, and the data specified in ident argument to pass the function. The SYSUNINIT() macro behaves similarly to the SYSINIT() macro except that it adds the data to a shutdown linker set. The startup linker set for the kernel is scanned during boot to build a sorted list of initialization routines. The initialization routines are then executed in the sorted order. The subsystem is used as the primary key and is sorted in ascending order. The order is used as the secondary key and is sorted in ascending order. The relative order of two routines that have the same subsystem and order is undefined. The startup linker sets for modules that are loaded together with the kernel by the boot loader are scanned during the SI_SUB_KLD subsystem initialization. These modules' initialization routines are sorted and merged into the kernel's list of startup routines and are executed during boot along with the kernel's initialization routines. Note that this has the effect that any initialization routines in a kernel mod- ule that are scheduled earlier than SI_SUB_KLD are not executed until after SI_SUB_KLD during boot. The startup linker set for a kernel module loaded at runtime via kldload(2) is scanned, sorted, and executed when the module is loaded. The shutdown linker set for a kernel module is scanned, sorted, and executed when a kernel module is unloaded. The teardown routines are sorted in the reverse order of the initialization routines. The teardown routines of the kernel and any loaded modules are not executed dur- ing shutdown. EXAMPLES
This example shows the SYSINIT which displays the copyright notice during boot: static void print_caddr_t(void *data) { printf("%s", (char *)data); } SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright); SEE ALSO
kld(4), DECLARE_MODULE(9), DEV_MODULE(9), DRIVER_MODULE(9), MTX_SYSINIT(9), SYSCALL_MODULE(9) HISTORY
The SYSINIT framework first appeared in FreeBSD 2.2. AUTHORS
The SYSINIT framework was written by Terrence Lambert <terry@FreeBSD.org>. This manual page was written by Hiten Pandya <hmp@FreeBSD.org>. BSD
December 1, 2010 BSD

Check Out this Related 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
Man Page