Source string Read only

(itstool) path: sect2/para
169/1690
Context English State
SYSINIT relies on the ability of the linker to take static data declared at multiple locations throughout a program's source and group it together as a single contiguous chunk of data. This linker technique is called a <quote>linker set</quote>. SYSINIT uses two linker sets to maintain two data sets containing each consumer's call order, function, and a pointer to the data to pass to that function.
SYSINIT uses two priorities when ordering the functions for execution. The first priority is a subsystem ID giving an overall order for SYSINIT's dispatch of functions. Current predeclared ID's are in <filename>&lt;sys/kernel.h&gt;</filename> in the enum list <literal>sysinit_sub_id</literal>. The second priority used is an element order within the subsystem. Current predeclared subsystem element orders are in <filename>&lt;sys/kernel.h&gt;</filename> in the enum list <literal>sysinit_elem_order</literal>.
<primary>pseudo-devices</primary>
There are currently two uses for SYSINIT. Function dispatch at system startup and kernel module loads, and function dispatch at system shutdown and kernel module unload. Kernel subsystems often use system startup SYSINIT's to initialize data structures, for example the process scheduling subsystem uses a SYSINIT to initialize the run queue data structure. Device drivers should avoid using <literal>SYSINIT()</literal> directly. Instead drivers for real devices that are part of a bus structure should use <literal>DRIVER_MODULE()</literal> to provide a function that detects the device and, if it is present, initializes the device. It will do a few things specific to devices and then call <literal>SYSINIT()</literal> itself. For pseudo-devices, which are not part of a bus structure, use <literal>DEV_MODULE()</literal>.
Using SYSINIT
&lt;sys/kernel.h&gt;
SYSINIT(uniquifier, subsystem, order, func, ident)
SYSUNINIT(uniquifier, subsystem, order, func, ident)
Startup
The <literal>SYSINIT()</literal> macro creates the necessary SYSINIT data in SYSINIT's startup data set for SYSINIT to sort and dispatch a function at system startup and module load. <literal>SYSINIT()</literal> takes a uniquifier that SYSINIT uses to identify the particular function dispatch data, the subsystem order, the subsystem element order, the function to call, and the data to pass the function. All functions must take a constant pointer argument.
Example of a <literal>SYSINIT()</literal>
#include &lt;sys/kernel.h&gt;

void foo_null(void *unused)
{
foo_doo();
}
SYSINIT(foo, SI_SUB_FOO, SI_ORDER_FOO, foo_null, NULL);

struct foo foo_voodoo = {
FOO_VOODOO;
}

void foo_arg(void *vdata)
{
struct foo *foo = (struct foo *)vdata;
foo_data(foo);
}
SYSINIT(bar, SI_SUB_FOO, SI_ORDER_FOO, foo_arg, &amp;foo_voodoo);
Note that <literal>SI_SUB_FOO</literal> and <literal>SI_ORDER_FOO</literal> need to be in the <literal>sysinit_sub_id</literal> and <literal>sysinit_elem_order</literal> enum's as mentioned above. Either use existing ones or add your own to the enum's. You can also use math for fine-tuning the order a SYSINIT will run in. This example shows a SYSINIT that needs to be run just barely before the SYSINIT's that handle tuning kernel parameters.
Example of Adjusting <literal>SYSINIT()</literal> Order
static void
mptable_register(void *dummy __unused)
{

apic_register_enumerator(&amp;mptable_enumerator);
}

SYSINIT(mptable_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST,
mptable_register, NULL);
Shutdown
The <literal>SYSUNINIT()</literal> macro behaves similarly to the <literal>SYSINIT()</literal> macro except that it adds the SYSINIT data to SYSINIT's shutdown data set.
Example of a <literal>SYSUNINIT()</literal>
#include &lt;sys/kernel.h&gt;

void foo_cleanup(void *unused)
{
foo_kill();
}
SYSUNINIT(foobar, SI_SUB_FOO, SI_ORDER_FOO, foo_cleanup, NULL);

struct foo_stack foo_stack = {
FOO_STACK_VOODOO;
}

void foo_flush(void *vdata)
{
}
SYSUNINIT(barfoo, SI_SUB_FOO, SI_ORDER_FOO, foo_flush, &amp;foo_stack);
The TrustedBSD MAC Framework

<email>chris@FreeBSD.org</email>
<personname> <firstname>Chris</firstname> <surname>Costello</surname> </personname> <affiliation> <orgname>TrustedBSD Project</orgname> <_:address-1/> </affiliation>

<email>rwatson@FreeBSD.org</email>
<personname> <firstname>Robert</firstname> <surname>Watson</surname> </personname> <affiliation> <orgname>TrustedBSD Project</orgname> <_:address-1/> </affiliation>
MAC Documentation Copyright
This documentation was developed for the FreeBSD Project by Chris Costello at Safeport Network Services and Network Associates Laboratories, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (<quote>CBOSS</quote>), as part of the DARPA CHATS research program.
Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS ASSOCIATES TECHNOLOGY, INC "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL NETWORKS ASSOCIATES TECHNOLOGY, INC BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
FreeBSD includes experimental support for several mandatory access control policies, as well as a framework for kernel security extensibility, the TrustedBSD MAC Framework. The MAC Framework is a pluggable access control framework, permitting new security policies to be easily linked into the kernel, loaded at boot, or loaded dynamically at run-time. The framework provides a variety of features to make it easier to implement new security policies, including the ability to easily tag security labels (such as confidentiality information) onto system objects.
This chapter introduces the MAC policy framework and provides documentation for a sample MAC policy module.
Introduction

Loading…

No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/para
Flags
read-only
Source string location
book.translate.xml:4266
String age
a year ago
Source string age
a year ago
Translation file
books/arch-handbook.pot, string 556