The translation is temporarily closed for contributions due to maintenance, please come back later.
Context English State
As <filename>boot0</filename> is loaded by the <acronym>BIOS</acronym> to address <literal>0x7C00</literal>, it copies itself to address <literal>0x600</literal> and then transfers control there (recall that it was linked to execute at address <literal>0x600</literal>). The source address, <literal>0x7c00</literal>, is copied to register <literal>%si</literal>. The destination address, <literal>0x600</literal>, to register <literal>%di</literal>. The number of bytes to copy, <literal>512</literal> (the program's size), is copied to register <literal>%cx</literal>. Next, the <literal>rep</literal> instruction repeats the instruction that follows, that is, <literal>movsb</literal>, the number of times dictated by the <literal>%cx</literal> register. The <literal>movsb</literal> instruction copies the byte pointed to by <literal>%si</literal> to the address pointed to by <literal>%di</literal>. This is repeated another 511 times. On each repetition, both the source and destination registers, <literal>%si</literal> and <literal>%di</literal>, are incremented by one. Thus, upon completion of the 512-byte copy, <literal>%di</literal> has the value <literal>0x600</literal>+<literal>512</literal>= <literal>0x800</literal>, and <literal>%si</literal> has the value <literal>0x7c00</literal>+<literal>512</literal>= <literal>0x7e00</literal>; we have thus completed the code <emphasis>relocation</emphasis>.
So <filename>boot1</filename> occupies exactly the first 512 bytes of <filename>boot</filename> and, because <filename>boot</filename> is written to the first sector of the FreeBSD slice, <filename>boot1</filename> fits exactly in this first sector. When <literal>nread</literal> reads the first 16 sectors of the FreeBSD slice, it effectively reads the entire <filename>boot</filename> file <_:footnote-1/>. We will see more details about how <filename>boot</filename> is formed from <filename>boot1</filename> and <filename>boot2</filename> in the next section.
<primary>virtual v86 mode</primary>
This code disables interrupts, sets up a working stack (starting at address <literal>0x1800</literal>) and clears the flags in the EFLAGS register. Note that the <literal>popfl</literal> instruction pops out a doubleword (4 bytes) from the stack and places it in the EFLAGS register. As the value actually popped is <literal>2</literal>, the EFLAGS register is effectively cleared (IA-32 requires that bit 2 of the EFLAGS register always be 1).
The next step is to initialize the <acronym>TSS</acronym> (Task-State Segment). The <acronym>TSS</acronym> is a hardware feature that helps the operating system or executive software implement multitasking functionality through process abstraction. The IA-32 architecture demands the creation and use of <emphasis>at least</emphasis> one <acronym>TSS</acronym> if multitasking facilities are used or different privilege levels are defined. Since the <filename>boot2</filename> client is executed in privilege level 3, but the <acronym>BTX</acronym> server does in privilege level 0, a <acronym>TSS</acronym> must be defined:
#include &lt;sys/kernel.h&gt;

void foo_null(void *unused)

struct foo foo_voodoo = {

void foo_arg(void *vdata)
struct foo *foo = (struct foo *)vdata;
SYSINIT(bar, SI_SUB_FOO, SI_ORDER_FOO, foo_arg, &amp;foo_voodoo);
#include &lt;sys/kernel.h&gt;

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

struct foo_stack foo_stack = {

void foo_flush(void *vdata)
SYSUNINIT(barfoo, SI_SUB_FOO, SI_ORDER_FOO, foo_flush, &amp;foo_stack);
Name of the policy whose label should be internalized
Text data to be internalized
Should be incremented when data can be successfully internalized.
Produce an internal label structure based on externalized label data in text format. Currently, all policies' <function>internalize</function> entry points are called when internalization is requested, so the implementation should compare the contents of <parameter>element_name</parameter> to its own name in order to be sure it should be internalizing the data in <parameter>element_data</parameter>. Just as in the <function>externalize</function> entry points, the entry point should return <returnvalue>0</returnvalue> if <parameter>element_name</parameter> does not match its own name, or when data can successfully be internalized, in which case <varname>*claimed</varname> should be incremented.
Management of Physical Memory—<literal>vm_page_t</literal>
The Unified Buffer Cache—<literal>vm_object_t</literal>
FreeBSD implements the idea of a generic <quote>VM object</quote>. VM objects can be associated with backing store of various types—unbacked, swap-backed, physical device-backed, or file-backed storage. Since the filesystem uses the same VM objects to manage in-core data relating to files, the result is a unified buffer cache.
Filesystem I/O—<literal>struct buf</literal>
Mapping Page Tables—<literal>vm_map_t, vm_entry_t</literal>
Following the pattern of several other multi-threaded <trademark class="registered">UNIX</trademark> kernels, FreeBSD deals with interrupt handlers by giving them their own thread context. Providing a context for interrupt handlers allows them to block on locks. To help avoid latency, however, interrupt threads run at real-time kernel priority. Thus, interrupt handlers should not execute for very long to avoid starving other kernel threads. In addition, since multiple handlers may share an interrupt thread, interrupt handlers should not sleep or use a sleepable lock to avoid starving another interrupt handler.
Most devices in a <trademark class="registered">UNIX</trademark>-like operating system are accessed through device-nodes, sometimes also called special files. These files are usually located under the directory <filename>/dev</filename> in the filesystem hierarchy.