aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml661
-rw-r--r--en/handbook/contrib/chapter.sgml5796
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/Makefile55
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/book.sgml301
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml1023
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/chapters.ent48
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml392
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml2487
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml611
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml298
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml313
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/mac.ent122
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml7483
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml360
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/pci/chapter.sgml369
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml1983
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml957
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml687
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml161
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/usb/chapter.sgml623
-rw-r--r--en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml260
-rw-r--r--en_US.ISO8859-1/books/handbook/basics/disk-layout.kilbin1450 -> 0 bytes
-rw-r--r--en_US.ISO8859-1/books/handbook/basics/example-dir1.dot7
-rw-r--r--en_US.ISO8859-1/books/handbook/basics/example-dir2.dot8
-rw-r--r--en_US.ISO8859-1/books/handbook/basics/example-dir3.dot8
-rw-r--r--en_US.ISO8859-1/books/handbook/basics/example-dir4.dot9
-rw-r--r--en_US.ISO8859-1/books/handbook/basics/example-dir5.dot9
-rw-r--r--en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml60
-rw-r--r--en_US.ISO8859-1/books/porters-handbook/book.sgml10
-rw-r--r--ja_JP.eucJP/books/handbook/multimedia/Makefile16
-rw-r--r--ja_JP.eucJP/books/handbook/multimedia/chapter.sgml397
-rw-r--r--ja_JP.eucJP/man/man1/gtar.1597
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/aic.451
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/apm.4160
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/ar.4108
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/cs.4105
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/cx.4289
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/el.458
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/ep.4121
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/ex.484
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/fe.4284
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/ie.496
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/io.472
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/lnc.4124
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/mcd.4151
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/npx.479
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/pcf.465
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/perfmon.4225
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/pnp.4221
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/scd.465
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/spkr.4234
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/sr.4119
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/vx.4102
-rw-r--r--ja_JP.eucJP/man/man4/man4.i386/wd.4106
-rw-r--r--ja_JP.eucJP/man/man8/man8.i386/apm.8159
-rw-r--r--ja_JP.eucJP/man/man8/man8.i386/apmd.8294
-rw-r--r--share/sgml/freebsd.ent6
-rw-r--r--zh/FAQ/FAQ.sgml70
58 files changed, 61 insertions, 29498 deletions
diff --git a/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml b/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml
deleted file mode 100644
index 319c00579d..0000000000
--- a/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml
+++ /dev/null
@@ -1,661 +0,0 @@
-<!--
- The FreeBSD Documentation Project
- The FreeBSD German Documentation Project
-
- $FreeBSD$
- $FreeBSDde: de-docproj/books/handbook/sound/chapter.sgml,v 1.32 2003/03/08 18:27:35 mheinen Exp $
- basiert auf: 1.33
--->
-
-<chapter id="sound">
- <chapterinfo>
- <authorgroup>
- <author>
- <firstname>Moses</firstname>
- <surname>Moore</surname>
- <contrib>Von </contrib>
- </author>
- </authorgroup>
- <!-- 20 November 2000 -->
- <authorgroup>
- <author>
- <firstname>Benedikt</firstname>
- <surname>K&ouml;hler</surname>
- <contrib>&Uuml;bersetzt von </contrib>
- </author>
- <author>
- <firstname>Uwe</firstname>
- <surname>Pierau</surname>
- </author>
- </authorgroup>
- </chapterinfo>
-
- <title>Sound</title>
-
- <sect1 id="sound-synopsis">
- <title>Zusammenfassung</title>
-
- <para>FreeBSD unterst&uuml;tzt viele unterschiedliche Soundkarten,
- die Ihnen den Genuss von Highfidelity-Kl&auml;ngen auf Ihrem
- Computer erm&ouml;glichen. Dazu geh&ouml;rt unter anderem die
- M&ouml;glichkeit, Tonquellen in den Formaten MPEG Audio Layer 3
- (MP3), WAV, Ogg Vorbis und vielen weiteren Formaten aufzunehmen
- und wiederzugeben. Dar&uuml;ber hinaus enth&auml;lt die FreeBSD
- Ports-Sammlung Anwendungen, die Ihnen das Bearbeiten Ihrer
- aufgenommenen Tonspuren, das Hinzuf&uuml;gen von Klangeffekten
- und die Kontrolle der angeschlossenen MIDI-Ger&auml;te
- erlauben.</para>
-
- <para>Nach dem Lesen dieses Kapitels werden Sie wissen:</para>
- <itemizedlist>
- <listitem><para>Wie Sie Ihre Soundkarte
- bestimmen.</para></listitem>
- <listitem><para>Wie Sie Ihr System so einstellen, dass die
- Soundkarte richtig erkannt wird.</para></listitem>
- <listitem><para>Einige Methoden und Beispielanwendungen, mit
- denen Sie das korrekte Funktionieren Ihrer Soundkarte
- &uuml;berpr&uuml;fen k&ouml;nnen.</para></listitem>
- <listitem><para>Wie Sie Fehler in Ihren
- Soundkarten-Einstellungen finden.</para></listitem>
- <listitem><para>Wie Sie MP3s wiedergeben und
- erzeugen.</para></listitem>
- <listitem><para>Wie Sie CD-Tonspuren in Dateien
- rippen.</para></listitem>
- </itemizedlist>
-
- <para>Bevor Sie dieses Kapitel leben, sollten Sie:</para>
-
- <itemizedlist>
- <listitem><para>Wissen, wie Sie einen neuen Kernel
- konfigurieren und installieren (<xref
- linkend="kernelconfig">).</para></listitem>
- </itemizedlist>
- </sect1>
-
- <sect1 id="sound-devices">
- <title>Bestimmen des korrekten Ger&auml;ts</title>
-
- <indexterm><primary>PCI</primary></indexterm>
- <indexterm><primary>ISA</primary></indexterm>
- <indexterm><primary>Soundkarten</primary></indexterm>
- <para>Zun&auml;chst sollten Sie in Erfahrung bringen, welches
- Modell Ihrer Soundkarte Sie haben, welchen Chip sie benutzt und
- ob es sich um eine PCI- oder ISA-Karte handelt. FreeBSD
- unterst&uuml;tzt eine ganze Reihe sowohl von PCI- als auch von
- ISA-Karten. Wenn Ihre Soundkarte in der folgenden Liste nicht
- auftaucht, konsultieren Sie die &man.pcm.4; Manualpage. Diese
- Liste ist zwar nicht vollst&auml;ndig, deckt jedoch einige der
- verbreitetsten Karten ab.</para>
-
- <itemizedlist>
- <listitem>
- <para>Crystal 4237, 4236, 4232, 4231</para>
- </listitem>
-
- <listitem>
- <para>Yamaha OPL-SAx</para>
- </listitem>
-
- <listitem>
- <para>OPTi931</para>
- </listitem>
-
- <listitem>
- <para>Ensoniq AudioPCI 1370/1371</para>
- </listitem>
-
- <listitem>
- <para>ESS Solo-1/1E</para>
- </listitem>
-
- <listitem>
- <para>NeoMagic 256AV/ZX</para>
- </listitem>
-
- <listitem>
- <para>Sound Blaster Pro, 16, 32, AWE64, AWE128, Live</para>
- </listitem>
-
- <listitem>
- <para>Creative ViBRA16</para>
- </listitem>
-
- <listitem>
- <para>Advanced Asound 100, 110, and Logic ALS120</para>
- </listitem>
-
- <listitem>
- <para>ES 1868, 1869, 1879, 1888</para>
- </listitem>
-
- <listitem>
- <para>Gravis UltraSound</para>
- </listitem>
-
- <listitem>
- <para>Aureal Vortex 1 or 2</para>
- </listitem>
- </itemizedlist>
-
- <indexterm>
- <primary>Kernel</primary>
- <secondary>Konfiguration</secondary>
- </indexterm>
-
- <para>Um Ihre Soundkarte benutzen zu k&ouml;nnen, m&uuml;ssen Sie
- den richtigen Ger&auml;tetreiber laden. Daf&uuml;r gibt es mehrere
- M&ouml;glichkeiten: Am einfachsten ist es, mit &man.kldload.8; das
- entsprechende Kernel-Modul f&uuml;r Ihre Soundkarte zu laden. Sie
- k&ouml;nnen aber auch die Unterst&uuml;tzung Ihrer Soundkarte
- statisch in den Kernel hineinkompilieren. Der folgende Abschnitt
- erkl&auml;rt diese Methode. Weitere Informationen &uuml;ber das
- Kompilieren eines Kernels erhalten sie in dem Kapitel <link
- linkend="kernelconfig">Kernelkonfiguration</link>.</para>
-
- <sect2>
- <title>Creative, Advance und ESS Soundkarten</title>
-
- <para>F&uuml;r jede dieser Karten f&uuml;gen Sie die folgende Zeile
- zu Ihrer Kernelkonfiguration hinzu:</para>
-
- <programlisting>device pcm</programlisting>
-
- <para>ISA-Karten ben&ouml;tigen zus&auml;tzlich noch die
- Zeile:</para>
-
- <programlisting>device sbc</programlisting>
-
- <para>Nicht-PnP f&auml;hige ISA-Karten ben&ouml;tigen die Zeilen:</para>
-
- <programlisting>device pcm
-device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15</programlisting>
-
- <para>Dies sind die
- Voreinstellungen. Sie werden unter Umst&auml;nden den IRQ oder
- andere Einstellungen anpassen m&uuml;ssen. In der &man.sbc.4;
- Manualpage finden Sie weitere Informationen dazu.</para>
-
- <note>
- <para>Die Karte Sound Blaster Live wird unter FreeBSD&nbsp;4.0
- nicht unterst&uuml;tzt. Dazu ben&ouml;tigen Sie einen Patch,
- der in diesem Dokument nicht behandelt wird. Es ist deshalb
- empfehlenswert, dass Sie in diesem Fall Ihr System auf den
- neuesten -STABLE Stand aktualisieren, bevor Sie diese Karte
- benutzen k&ouml;nnen.</para>
- </note>
- </sect2>
-
- <sect2>
- <title>Gravis UltraSound Karten</title>
-
- <para>Eine PnP ISA-Karte ben&ouml;tigt die folgenden Zeilen in der
- Kernelkonfiguration:</para>
-
- <programlisting>device pcm
-device gusc</programlisting>
-
- <para>Wenn Sie eine nicht-PnP f&auml;hige ISA-Karte besitzen,
- f&uuml;gen Sie die folgenden Zeilen ein:</para>
-
- <programlisting>device pcm
-device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13</programlisting>
-
- <para>Es kann sein, dass Sie den
- IRQ oder andere Einstellungen Ihrer Karte anpassen
- m&uuml;ssen. Lesen Sie dazu die &man.gusc.4; Manualpage
- f&uuml;r weitere Informationen.</para>
- </sect2>
-
- <sect2>
- <title>Crystal Soundkarten</title>
-
- <para>In der Kernelkonfiguration geben Sie f&uuml;r Crystal Karten
- die beiden folgenden Zeilen an:</para>
-
- <programlisting>device pcm
-device csa</programlisting>
- </sect2>
-
- <sect2>
- <title>Allgemeine Unterst&uuml;tzung</title>
-
- <para>F&uuml;r PnP ISA- oder PCI-Karten f&uuml;gen Sie die folgende
- Zeile zu Ihrer Kernelkonfiguration hinzu:</para>
-
- <programlisting>device pcm</programlisting>
-
- <para>Wenn Sie eine nicht-PnP ISA-Karte besitzen, die keinen
- Bridge-Treiber hat, geben Sie zus&auml;tzlich die folgende Zeile
- an:</para>
-
- <programlisting>device pcm0 at isa? irq 10 drq 1 flags 0x0</programlisting>
-
- <para>&Auml;ndern Sie den IRQ oder
- andere Einstellungen so, dass sie Ihrer Soundkarte
- entsprechen.</para>
- </sect2>
-
- <sect2>
- <title>Onboard Sound</title>
-
- <para>Einige Systeme besitzen direkt auf dem Motherboard
- eingebaute Soundger&auml;te. Diese ben&ouml;tigen die folgende
- Angabe in Ihrer Kernelkonfiguration:</para>
-
- <programlisting>options PNPBIOS</programlisting>
- </sect2>
- </sect1>
-
- <sect1 id="sound-devicenodes">
- <title>Erstellen und Testen der Device Nodes</title>
-
- <indexterm><primary>Device Node</primary></indexterm>
- <indexterm><primary>Ger&auml;tedatei</primary></indexterm>
- <para>Nach einem Neustart loggen Sie sich ein und geben
- <command>dmesg | grep pcm</command> ein. Sie sollten etwas wie das
- folgende sehen:</para>
-
- <screen>&prompt.root; <userinput>dmesg | grep pcm</userinput>
-pcm0: &lt;SB16 DSP 4.11&gt; on sbc0</screen>
-
- <para>Die Ausgabe Ihres Systems kann anders aussehen. Erscheinen
- keine <devicename>pcm</devicename> Ger&auml;te, dann ist zuvor
- ein Fehler aufgetreten. Wenn das passiert, schauen Sie sich Ihre
- Kernelkonfiguration noch einmal an und vergewissern Sie sich,
- dass Sie den richtigen Treiber gew&auml;hlt haben. Weitere
- Hinweise zur Fehlersuche gibt <xref linkend="troubleshooting">.</para>
-
- <para>Ergab der vorige Befehl <devicename>pcm0</devicename> als
- Ausgabe, dann m&uuml;ssen Sie folgendes als <username>root</username>
- ausf&uuml;hren:</para>
-
- <screen>&prompt.root; <userinput>cd /dev</userinput>
-&prompt.root; <userinput>sh MAKEDEV snd0</userinput></screen>
-
- <para>Wenn auf den vorigen Befehl <devicename>pcm1</devicename>
- als Ausgabe erschienen ist, dann m&uuml;ssen Sie dieselben
- Befehle ausf&uuml;hren, nur dass Sie
- <devicename>snd0</devicename> durch
- <devicename>snd1</devicename> ersetzen.</para>
-
- <note>
- <para>Die obigen Kommandos legen <emphasis>kein</emphasis>
- <devicename>/dev/snd</devicename> Device an.</para>
- </note>
-
- <para>Der Befehl <command>MAKEDEV</command> erzeugt eine Gruppe
- von Device Nodes, darunter:</para>
-
- <informaltable frame="none">
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Device</entry>
- <entry>Beschreibung</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><devicename>/dev/audio</devicename></entry>
- <entry>SPARC-compatible audio device</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/dsp</devicename></entry>
- <entry>Digitized voice device</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/dspW</devicename></entry>
- <entry><devicename>/dev/dsp</devicename>-&auml;hnliches
- Device mit 16 bits pro Sample</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/midi</devicename></entry>
- <entry>Raw midi access device</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/mixer</devicename></entry>
- <entry>Control port mixer device</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/music</devicename></entry>
- <entry>Level 2 sequencer interface</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/sequencer</devicename></entry>
- <entry>Sequencer device</entry>
- </row>
-
- <row>
- <entry><devicename>/dev/pss</devicename></entry>
- <entry>Programmable device interface</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Wenn alles geklappt hat, haben Sie jetzt eine
- funktionierende Soundkarte. Nun k&ouml;nnen Sie eine Anwendung
- wie <filename role="package">audio/mpg123</filename> installieren,
- um Audiodateien anh&ouml;ren zu k&ouml;nnen.</para>
-
- <sect2 id="troubleshooting">
- <title>H&auml;ufige Probleme</title>
-
- <informaltable>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Fehler</entry>
- <entry>L&ouml;sung</entry>
- </row>
- </thead>
- <indexterm><primary>Device Node</primary></indexterm>
- <indexterm><primary>Ger&auml;tedatei</primary></indexterm>
-
- <tbody>
- <row>
- <entry><errorname>unsupported subdevice XX</errorname></entry>
- <entry><para>Ein oder mehrere Device Nodes wurden nicht
- korrekt angelegt. Wiederholen Sie die oben angegebenen
- Schritte.</para></entry>
- </row>
-
- <indexterm><primary>I/O port</primary></indexterm>
- <row>
- <entry><errorname>sb_dspwr(XX) timed out</errorname></entry>
- <entry><para>Der I/O Port ist nicht korrekt angegeben.</para></entry>
- </row>
-
- <indexterm><primary>IRQ</primary></indexterm>
- <row>
- <entry><errorname>bad irq XX</errorname></entry>
- <entry><para>Der IRQ ist falsch angegeben. Stellen Sie
- sicher, dass der angegebene IRQ mit dem Sound IRQ
- &uuml;bereinstimmt.</para></entry>
- </row>
-
- <row>
- <entry><errorname>xxx: gus pcm not attached, out of
- memory</errorname></entry>
- <entry><para>Es ist nicht genug Speicher verf&uuml;gbar,
- um das Ger&auml;t betreiben zu k&ouml;nnen.</para></entry>
- </row>
-
- <indexterm><primary>DSP</primary></indexterm>
- <row>
- <entry><errorname>xxx: can't open /dev/dsp!</errorname></entry>
- <entry><para>&Uuml;berpr&uuml;fen Sie mit <command>fstat |
- grep dsp</command> ob eine andere Anwendung das
- Ger&auml;t ge&ouml;ffnet hat. H&auml;ufige
- St&ouml;renfriede sind <application>esound</application>
- oder die Sound-Unterst&uuml;tzung von
- <application>KDE</application>.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </sect2>
- </sect1>
-
- <sect1 id="sound-mp3">
- <sect1info>
- <authorgroup>
- <author>
- <firstname>Chern</firstname>
- <surname>Lee</surname>
- <contrib>Ein Beitrag von </contrib>
- </author>
- </authorgroup>
- <!-- 11 Sept 2001 -->
- <authorgroup>
- <author>
- <firstname>Benedikt</firstname>
- <surname>K&ouml;hler</surname>
- <contrib>&Uuml;bersetzt von </contrib>
- </author>
- </authorgroup>
- </sect1info>
-
- <title>MP3 Audio</title>
-
- <para>MP3 (MPEG Layer 3 Audio) erm&ouml;glicht eine
- Klangwiedergabe in CD-&auml;hnlicher Qualit&auml;t, was Sie sich
- auf Ihrem FreeBSD Rechner nicht entgehen lassen sollten.</para>
-
- <sect2 id="mp3-players">
- <title>MP3-Player</title>
-
- <para><application>XMMS</application> (X Multimedia System) ist
- bei weitem der beliebteste XFree86 MP3-Player.
- <application>WinAmp</application>-Skins k&ouml;nnen auch mit
- <application>XMMS</application> genutzt werden, da die
- Benutzerschnittstelle fast identisch mit der von Nullsofts
- <application>WinAmp</application> ist. Daneben
- unterst&uuml;tzt <application>XMMS</application> auch eigene
- Plugins.</para>
-
- <para><application>XMMS</application> kann als
- <filename role="package">audio/xmms</filename> Port oder Package installiert
- werden.</para>
-
- <para>Die Benutzerschnittstelle von
- <application>XMMS</application> ist leicht zu erlernen und
- beinhaltet eine Playlist, einen graphischen Equalizer und
- vieles mehr. Diejenigen, die mit WinAmp vertraut sind, werden
- <application>XMMS</application> sehr leicht zu benutzen
- finden.</para>
-
- <para>Der Port <filename role="package">audio/mpg123</filename> ist
- ein alternativer, kommandozeilenorientierter MP3-Player.</para>
-
- <para><application>mpg123</application> kann ausgef&uuml;hrt
- werden, in dem man das zu benutzende Sound Device und die
- abzuspielende MP3-Datei in der Kommandozeile wie unten
- angibt:</para>
-
- <screen>&prompt.root; <userinput>mpg123 -a <replaceable>/dev/dsp1.0</replaceable> Foobar-GreatestHits.mp3</userinput>
-High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3.
-Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp.
-Uses code from various people. See 'README' for more!
-THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
-
-
-
-
-
-Playing MPEG stream from BT - Foobar-GreastHits.mp3 ...
-MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo
-</screen>
-
- <para><literal>/dev/dsp1.0</literal> sollten Sie dabei mit dem
- <devicename>dsp</devicename>-Device Ihres Systems ersetzen.</para>
- </sect2>
-
- <sect2 id="rip-cd">
- <title>CD-Audio Tracks rippen</title>
-
- <para>Bevor man eine ganze CD oder einen CD-Track in das
- MP3-Format umwandeln kann, m&uuml;ssen die Audiodaten von der
- CD auf die Festplatte gerippt werden. Dabei werden die CDDA
- (CD Digital Audio) Rohdaten in WAV-Dateien kopiert.</para>
-
- <para>Die Anwendung <command>cdda2wav</command> die in dem
- <filename role="package">sysutils/cdrtools</filename> Paket enthalten
- ist, kann zum Rippen der Audiodaten und anderen Informationen von CDs
- genutzt werden.</para>
-
- <para>Wenn die Audio CD in dem Laufwerk liegt, k&ouml;nnen Sie
- mit folgendem Befehl (als <username>root</username>) eine
- ganze CD in einzelne WAV-Dateien (eine Datei f&uuml;r jeden
- Track) rippen:</para>
-
- <screen>&prompt.root; <userinput>cdda2wav -D <replaceable>0,1,0</replaceable> -B</userinput></screen>
-
- <para>Der Schalter <option>-D
- <replaceable>0,1,0</replaceable></option> bezieht sich auf
- das SCSI Device <devicename>0,1,0</devicename>, dass sich aus
- dem Ergebnis des Befehls <command>cdrecord -scanbus</command>
- ergibt.</para>
-
- <para>Um einzelne Tracks zu rippen, benutzen Sie den
- <option>-t</option> Schalter wie folgt:</para>
-
- <screen>&prompt.root; <userinput>cdda2wav -D <replaceable>0,1,0</replaceable> -t 7</userinput></screen>
-
- <para>Dieses Beispiel rippt den siebten Track der Audio
- CD-ROM. Um mehrere Tracks zu rippen, zum Beispiel die Tracks
- eins bis sieben, k&ouml;nnen Sie wie folgt einen Bereich
- angeben:</para>
-
- <screen>&prompt.root; <userinput>cdda2wav -D <replaceable>0,1,0</replaceable> -t 1+7</userinput></screen>
-
- <para><application>cdda2wav</application> unterst&uuml;tzt auch ATAPI
- (IDE) CD-ROM Laufwerke. Wenn Sie ein IDE Laufwerk benutzen, geben
- Sie beim Aufruf von <command>cdda2wav</command> den
- Ger&auml;tenamen anstelle der SCSI Ger&auml;tenummern an. Um den
- siebten Track eines IDE Laufwerkes zu rippen, benutzen Sie das
- folgende Kommando:</para>
-
- <screen>&prompt.root; <userinput>cdda2wav -D <replaceable>/dev/acd0a</replaceable> -t 7</userinput></screen>
- </sect2>
-
- <sect2 id="mp3-encoding">
- <title>MP3-Dateien kodieren</title>
-
- <para>Gegenw&auml;rtig ist <application>Lame</application> der
- meistbenutzte MP3-Encoder. <application>Lame</application>
- finden Sie unter <filename role="package">audio/lame</filename> im
- Ports-Verzeichnis.</para>
-
- <para>Benutzen Sie die WAV-Dateien, die sie von CD gerippt
- haben, und wandeln sie mit dem folgenden Befehl die Datei
- <filename>audio01.wav</filename> in
- <filename>audio01.mp3</filename> um:</para>
-
- <screen>&prompt.root; <userinput>lame -h -b <replaceable>128</replaceable> \
---tt "<replaceable>Foo Liedtitel</replaceable>" \
---ta "<replaceable>FooBar K&uuml;nstler</replaceable>" \
---tl "<replaceable>FooBar Album</replaceable>" \
---ty "<replaceable>2001</replaceable>" \
---tc "<replaceable>Geripped und kodiert von Foo</replaceable>" \
---tg "<replaceable>Musikrichtung</replaceable>" \
-<replaceable>audio01.wav audio01.mp3</replaceable></userinput></screen>
-
- <para>128&nbsp;kbits ist die gew&ouml;hnliche MP3 Bitrate. Viele
- bevorzugen mit 160 oder 192&nbsp;kbits eine h&ouml;here Qualit&auml;t. Je
- h&ouml;her die Bitrate ist, desto mehr Speicherplatz
- ben&ouml;tigt die resultierende MP3-Datei, allerdings wird die
- Qualit&auml;t dadurch auch besser. Der Schalter
- <option>-h</option> verwendet den <quote>higher quality but a
- little slower</quote> (h&ouml;here Qualit&auml;t, aber etwas
- langsamer) Modus. Die Schalter, die mit
- <option>--t</option> beginnen, sind ID3-Tags, die in der Regel
- Informationen &uuml;ber das Lied enthalten und in die
- MP3-Datei eingebettet sind. Weitere Optionen k&ouml;nnen in
- der Manualpage von <application>Lame</application> nachgelesen
- werden.</para>
- </sect2>
-
- <sect2 id="mp3-decoding">
- <title>MP3-Dateien dekodieren</title>
-
- <para>Um aus MP3-Dateien eine Audio CD zu erstellen, m&uuml;ssen
- diese in ein nicht komprimiertes WAV-Format umgewandelt
- werden. Sowohl <application>XMMS</application> als auch
- <application>mpg123</application> unterst&uuml;tzen die Ausgabe
- der MP3-Dateien in unkomprimierte Dateiformate.</para>
-
- <para>Dekodieren mit <application>XMMS</application>:</para>
-
- <procedure>
- <step>
- <para>Starten Sie <application>XMMS</application>.</para>
- </step>
-
- <step>
- <para>Klicken Sie mit der rechten Maustaste, um das
- <application>XMMS</application>-Menu zu &ouml;ffnen.</para>
- </step>
-
- <step>
- <para>W&auml;hlen Sie <literal>Preference</literal> im
- Untermen&uuml; <literal>Options</literal>.</para>
- </step>
-
- <step>
- <para>&Auml;ndern Sie das Output-Plugin in <quote>Disk
- Writer Plugin</quote>.</para>
- </step>
-
- <step>
- <para>Dr&uuml;cken Sie <literal>Configure</literal>.</para>
- </step>
-
- <step>
- <para>Geben Sie ein Verzeichnis ein (oder w&auml;hlen Sie
- browse), in das Sie die unkomprimierte Datei schreiben
- wollen.</para>
- </step>
-
- <step>
- <para>Laden Sie die MP3-Datei wie gewohnt in
- <application>XMMS</application> mit einer Lautst&auml;rke
- von 100% und einem abgeschalteten EQ.</para>
- </step>
-
- <step>
- <para>Dr&uuml;cken Sie <literal>Play</literal> und es wird
- so aussehen, als spiele <application>XMMS</application>
- die MP3-Datei ab, aber keine Musik ist zu h&ouml;ren. Der
- Player &uuml;berspielt die MP3-Datei in eine Datei.</para>
- </step>
-
- <step>
- <para>Vergessen Sie nicht, das Output Plugin wieder in den
- Ausgangszustand zur&uuml;ckzusetzen um wieder MP3-Dateien
- anh&ouml;ren zu k&ouml;nnen.</para>
- </step>
- </procedure>
-
- <para>Mit <application>mpg123</application> nach stdout schreiben:</para>
-
- <procedure>
- <step>
- <para>Geben Sie mpg123 -s
- <replaceable>audio01.mp3</replaceable> &gt; audio01.pcm
- ein</para>
- </step>
- </procedure>
-
- <para><application>XMMS</application> schreibt die Datei in dem
- WAV-Formal w&auml;hrend <application>mpg123</application> die
- MP3-Datei in rohe PCM Audiodaten umwandelt. Beide Formate
- k&ouml;nnen von <application>cdrecord</application> oder
- <application>burncd</application> verwendet werden, um Audio
- CDs zu schreiben.</para>
-
- <para>Lesen Sie <xref linkend="creating-cds"> in diesem Handbuch,
- um mehr Informationen zur Benutzung von CD-Brennern mit FreeBSD zu
- erhalten.</para>
- </sect2>
- </sect1>
-</chapter>
-
-<!--
- Local Variables:
- mode: sgml
- sgml-declaration: "../chapter.decl"
- sgml-indent-data: t
- sgml-omittag: nil
- sgml-always-quote-attributes: t
- sgml-parent-document: ("../book.sgml" "part" "chapter")
- End:
--->
-
diff --git a/en/handbook/contrib/chapter.sgml b/en/handbook/contrib/chapter.sgml
deleted file mode 100644
index 9a41073467..0000000000
--- a/en/handbook/contrib/chapter.sgml
+++ /dev/null
@@ -1,5796 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $Id: chapter.sgml,v 1.92 2000-03-19 06:20:31 vanilla Exp $
--->
-
-<chapter id="contrib">
- <title>Contributing to FreeBSD</title>
-
- <para><emphasis>Contributed by &a.jkh;.</emphasis></para>
-
- <para>So you want to contribute something to FreeBSD? That is great! We can
- always use the help, and FreeBSD is one of those systems that
- <emphasis>relies</emphasis> on the contributions of its user base in order
- to survive. Your contributions are not only appreciated, they are vital
- to FreeBSD's continued growth!</para>
-
- <para>Contrary to what some people might also have you believe, you do not
- need to be a hot-shot programmer or a close personal friend of the FreeBSD
- core team in order to have your contributions accepted. The FreeBSD
- Project's development is done by a large and growing number of
- international contributors whose ages and areas of technical expertise
- vary greatly, and there is always more work to be done than there are
- people available to do it.</para>
-
- <para>Since the FreeBSD project is responsible for an entire operating
- system environment (and its installation) rather than just a kernel or a
- few scattered utilities, our <filename>TODO</filename> list also spans a
- very wide range of tasks, from documentation, beta testing and
- presentation to highly specialized types of kernel development. No matter
- what your skill level, there is almost certainly something you can do to
- help the project!</para>
-
- <para>Commercial entities engaged in FreeBSD-related enterprises are also
- encouraged to contact us. Need a special extension to make your product
- work? You will find us receptive to your requests, given that they are not
- too outlandish. Working on a value-added product? Please let us know! We
- may be able to work cooperatively on some aspect of it. The free software
- world is challenging a lot of existing assumptions about how software is
- developed, sold, and maintained throughout its life cycle, and we urge you
- to at least give it a second look.</para>
-
- <sect1>
- <title>What Is Needed</title>
-
- <para>The following list of tasks and sub-projects represents something of
- an amalgam of the various core team <filename>TODO</filename> lists and
- user requests we have collected over the last couple of months. Where
- possible, tasks have been ranked by degree of urgency. If you are
- interested in working on one of the tasks you see here, send mail to the
- coordinator listed by clicking on their names. If no coordinator has
- been appointed, maybe you would like to volunteer?</para>
-
- <sect2>
- <title>High priority tasks</title>
-
- <para>The following tasks are considered to be urgent, usually because
- they represent something that is badly broken or sorely needed:</para>
-
- <orderedlist>
- <listitem>
- <para>3-stage boot issues. Overall coordination: &a.hackers;</para>
-
- <itemizedlist>
- <listitem>
- <para>Do WinNT compatible drive tagging so that the 3rd stage
- can provide an accurate mapping of BIOS geometries for
- disks.</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>Filesystem problems. Overall coordination: &a.fs;</para>
-
- <itemizedlist>
- <listitem>
- <para>Fix the MSDOS file system.</para>
- </listitem>
-
- <listitem>
- <para>Clean up and document the nullfs filesystem code.
- Coordinator: &a.eivind;</para>
- </listitem>
-
- <listitem>
- <para>Fix the union file system. Coordinator: &a.dg;</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>Implement Int13 vm86 disk driver. Coordinator:
- &a.hackers;</para>
- </listitem>
-
- <listitem>
- <para>New bus architecture. Coordinator: &a.newbus;</para>
-
- <itemizedlist>
- <listitem>
- <para>Port existing ISA drivers to new architecture.</para>
- </listitem>
-
- <listitem>
- <para>Move all interrupt-management code to appropriate parts of
- the bus drivers.</para>
- </listitem>
-
- <listitem>
- <para>Port PCI subsystem to new architecture. Coordinator:
- &a.dfr;</para>
- </listitem>
-
- <listitem>
- <para>Figure out the right way to handle removable devices and
- then use that as a substrate on which PC-Card and CardBus
- support can be implemented.</para>
- </listitem>
-
- <listitem>
- <para>Resolve the probe/attach priority issue once and for
- all.</para>
- </listitem>
-
- <listitem>
- <para>Move any remaining buses over to the new
- architecture.</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>Kernel issues. Overall coordination: &a.hackers;</para>
- </listitem>
-
- <listitem>
- <para>Add more pro-active security infrastructure. Overall
- coordination: &a.security;</para>
-
- <itemizedlist>
- <listitem>
- <para>Build something like Tripwire(TM) into the kernel, with a
- remote and local part. There are a number of cryptographic
- issues to getting this right; contact the coordinator for
- details. Coordinator: &a.eivind;</para>
- </listitem>
-
- <listitem>
- <para>Make the entire kernel use <literal>suser()</literal>
- instead of comparing to 0. It is presently using about half
- of each. Coordinator: &a.eivind;</para>
- </listitem>
-
- <listitem>
- <para>Split securelevels into different parts, to allow an
- administrator to throw away those privileges he can throw
- away. Setting the overall securelevel needs to have the same
- effect as now, obviously. Coordinator: &a.eivind;</para>
- </listitem>
-
- <listitem>
- <para>Make it possible to upload a list of &ldquo;allowed
- program&rdquo; to BPF, and then block BPF from accepting other
- programs. This would allow BPF to be used e.g. for DHCP,
- without allowing an attacker to start snooping the local
- network.</para>
- </listitem>
-
- <listitem>
- <para>Update the security checker script. We should at least
- grab all the checks from the other BSD derivatives, and add
- checks that a system with securelevel increased also have
- reasonable flags on the relevant parts. Coordinator:
- &a.eivind;</para>
- </listitem>
-
- <listitem>
- <para>Add authorization infrastructure to the kernel, to allow
- different authorization policies. Part of this could be done
- by modifying <literal>suser()</literal>. Coordinator:
- &a.eivind;</para>
- </listitem>
-
- <listitem>
- <para>Add code to the NFS layer so that you cannot
- <literal>chdir("..")</literal> out of an NFS partition. E.g.,
- <filename>/usr</filename> is a UFS partition with
- <filename>/usr/src</filename> NFS exported. Now it is
- possible to use the NFS filehandle for
- <filename>/usr/src</filename> to get access to
- <filename>/usr</filename>.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </orderedlist>
- </sect2>
-
- <sect2>
- <title>Medium priority tasks</title>
-
- <para>The following tasks need to be done, but not with any particular
- urgency:</para>
-
- <orderedlist>
- <listitem>
- <para>Full KLD based driver support/Configuration Manager.</para>
-
- <itemizedlist>
- <listitem>
- <para>Write a configuration manager (in the 3rd stage boot?)
- that probes your hardware in a sane manner, keeps only the
- KLDs required for your hardware, etc.</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk;</para>
-
- <itemizedlist>
- <listitem>
- <para>Documentation!</para>
- </listitem>
-
- <listitem>
- <para>Reliable operation of the pcic driver (needs
- testing).</para>
- </listitem>
-
- <listitem>
- <para>Recognizer and handler for <filename>sio.c</filename>
- (mostly done).</para>
- </listitem>
-
- <listitem>
- <para>Recognizer and handler for <filename>ed.c</filename>
- (mostly done).</para>
- </listitem>
-
- <listitem>
- <para>Recognizer and handler for <filename>ep.c</filename>
- (mostly done).</para>
- </listitem>
-
- <listitem>
- <para>User-mode recognizer and handler (partially done).</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>Advanced Power Management. Coordinators: &a.msmith; and
- &a.phk;</para>
-
- <itemizedlist>
- <listitem>
- <para>APM sub-driver (mostly done).</para>
- </listitem>
-
- <listitem>
- <para>IDE/ATA disk sub-driver (partially done).</para>
- </listitem>
-
- <listitem>
- <para>syscons/pcvt sub-driver.</para>
- </listitem>
-
- <listitem>
- <para>Integration with the PCMCIA/PCCARD drivers
- (suspend/resume).</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </orderedlist>
- </sect2>
-
- <sect2>
- <title>Low priority tasks</title>
-
- <para>The following tasks are purely cosmetic or represent such an
- investment of work that it is not likely that anyone will get them
- done anytime soon:</para>
-
- <para>The first N items are from Terry Lambert
- <email>terry@lambert.org</email></para>
-
- <orderedlist>
- <listitem>
- <para>NetWare Server (protected mode ODI driver) loader and
- subservices to allow the use of ODI card drivers supplied with
- network cards. The same thing for NDIS drivers and NetWare SCSI
- drivers.</para>
- </listitem>
-
- <listitem>
- <para>An "upgrade system" option that works on Linux boxes instead
- of just previous rev FreeBSD boxes.</para>
- </listitem>
-
- <listitem>
- <para>Symmetric Multiprocessing with kernel preemption (requires
- kernel preemption).</para>
- </listitem>
-
- <listitem>
- <para>A concerted effort at support for portable computers. This is
- somewhat handled by changing PCMCIA bridging rules and power
- management event handling. But there are things like detecting
- internal vs. external display and picking a different screen
- resolution based on that fact, not spinning down the disk if the
- machine is in dock, and allowing dock-based cards to disappear
- without affecting the machines ability to boot (same issue for
- PCMCIA).</para>
- </listitem>
- </orderedlist>
- </sect2>
-
- <sect2>
- <title>Smaller tasks</title>
-
- <para>Most of the tasks listed in the previous sections require either a
- considerable investment of time or an in-depth knowledge of the
- FreeBSD kernel (or both). However, there are also many useful tasks
- which are suitable for &quot;weekend hackers&quot;, or people without
- programming skills.</para>
-
- <orderedlist>
- <listitem>
- <para>If you run FreeBSD-current and have a good Internet
- connection, there is a machine <hostid
- role="fqdn">current.FreeBSD.org</hostid> which builds a full
- release once a day &mdash; every now and again, try and install
- the latest release from it and report any failures in the
- process.</para>
- </listitem>
-
- <listitem>
- <para>Read the freebsd-bugs mailing list. There might be a
- problem you can comment constructively on or with patches you
- can test. Or you could even try to fix one of the problems
- yourself.</para>
- </listitem>
-
- <listitem>
- <para>Read through the FAQ and Handbook periodically. If anything
- is badly explained, out of date or even just completely wrong, let
- us know. Even better, send us a fix (SGML is not difficult to
- learn, but there is no objection to ASCII submissions).</para>
- </listitem>
-
- <listitem>
- <para>Help translate FreeBSD documentation into your native language
- (if not already available) &mdash; just send an email to &a.doc;
- asking if anyone is working on it. Note that you are not
- committing yourself to translating every single FreeBSD document
- by doing this &mdash; in fact, the documentation most in need of
- translation is the installation instructions.</para>
- </listitem>
-
- <listitem>
- <para>Read the freebsd-questions mailing list and &ng.misc
- occasionally (or even regularly). It can be very satisfying to
- share your expertise and help people solve their problems;
- sometimes you may even learn something new yourself! These forums
- can also be a source of ideas for things to work on.</para>
- </listitem>
-
- <listitem>
- <para>If you know of any bugfixes which have been successfully
- applied to -current but have not been merged into -stable after a
- decent interval (normally a couple of weeks), send the committer a
- polite reminder.</para>
- </listitem>
-
- <listitem>
- <para>Move contributed software to <filename>src/contrib</filename>
- in the source tree.</para>
- </listitem>
-
- <listitem>
- <para>Make sure code in <filename>src/contrib</filename> is up to
- date.</para>
- </listitem>
-
- <listitem>
- <para>Look for year 2000 bugs (and fix any you find!)</para>
- </listitem>
-
- <listitem>
- <para>Build the source tree (or just part of it) with extra warnings
- enabled and clean up the warnings.</para>
- </listitem>
-
- <listitem>
- <para>Fix warnings for ports which do deprecated things like using
- gets() or including malloc.h.</para>
- </listitem>
-
- <listitem>
- <para>If you have contributed any ports, send your patches back to
- the original author (this will make your life easier when they
- bring out the next version)</para>
- </listitem>
-
- <listitem>
- <para>Suggest further tasks for this list!</para>
- </listitem>
- </orderedlist>
- </sect2>
-
- <sect2>
- <title>Work through the PR database</title>
-
- <para>The <ulink
- url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi">FreeBSD PR
- list</ulink> shows all the current active problem reports and
- requests for enhancement that have been submitted by FreeBSD users.
- Look through the open PRs, and see if anything there takes your
- interest. Some of these might be very simple tasks, that just need an
- extra pair of eyes to look over them and confirm that the fix in the
- PR is a good one. Others might be much more complex.</para>
-
- <para>Start with the PRs that have not been assigned to anyone else, but
- if one them is assigned to someone else, but it looks like something
- you can handle, e-mail the person it is assigned to and ask if you can
- work on it&mdash;they might already have a patch ready to be tested,
- or further ideas that you can discuss with them.</para>
- </sect2>
- </sect1>
-
- <sect1>
- <title>How to Contribute</title>
-
- <para>Contributions to the system generally fall into one or more of the
- following 6 categories:</para>
-
- <sect2 id="contrib-general">
- <title>Bug reports and general commentary</title>
-
- <para>An idea or suggestion of <emphasis>general</emphasis> technical
- interest should be mailed to the &a.hackers;. Likewise, people with
- an interest in such things (and a tolerance for a
- <emphasis>high</emphasis> volume of mail!) may subscribe to the
- hackers mailing list by sending mail to &a.majordomo;. See <link
- linkend="eresources-mail">mailing lists</link> for more information
- about this and other mailing lists.</para>
-
- <para>If you find a bug or are submitting a specific change, please
- report it using the &man.send-pr.1; program or its <ulink
- URL="http://www.FreeBSD.org/send-pr.html">WEB-based
- equivalent</ulink>. Try to fill-in each field of the bug report.
- Unless they exceed 65KB, include any patches directly in the report.
- When including patches, <emphasis>do not</emphasis> use cut-and-paste
- because cut-and-paste turns tabs into spaces and makes them unusable.
- Consider compressing patches and using &man.uuencode.1; if they exceed
- 20KB. Upload very large submissions to <ulink
- url="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/">ftp.FreeBSD.org:/pub/FreeBSD/incoming/</ulink>.</para>
-
- <para>After filing a report, you should receive confirmation along with
- a tracking number. Keep this tracking number so that you can update
- us with details about the problem by sending mail to
- <email>bug-followup@FreeBSD.org</email>. Use the number as the
- message subject, e.g. <literal>"Re: kern/3377"</literal>. Additional
- information for any bug report should be submitted this way.</para>
-
- <para>If you do not receive confirmation in a timely fashion (3 days to
- a week, depending on your email connection) or are, for some reason,
- unable to use the &man.send-pr.1; command, then you may ask
- someone to file it for you by sending mail to the &a.bugs;.</para>
- </sect2>
-
- <sect2>
- <title>Changes to the documentation</title>
-
- <para>Changes to the documentation are overseen by the &a.doc;. Send
- submissions and changes (even small ones are welcome!) using
- <command>send-pr</command> as described in <link
- linkend="contrib-general">Bug Reports and General
- Commentary</link>.</para>
- </sect2>
-
- <sect2>
- <title>Changes to existing source code</title>
-
- <para>An addition or change to the existing source code is a somewhat
- trickier affair and depends a lot on how far out of date you are with
- the current state of the core FreeBSD development. There is a special
- on-going release of FreeBSD known as &ldquo;FreeBSD-current&rdquo;
- which is made available in a variety of ways for the convenience of
- developers working actively on the system. See <link
- linkend="current">Staying current with FreeBSD</link> for more
- information about getting and using FreeBSD-current.</para>
-
- <para>Working from older sources unfortunately means that your changes
- may sometimes be too obsolete or too divergent for easy re-integration
- into FreeBSD. Chances of this can be minimized somewhat by
- subscribing to the &a.announce; and the &a.current; lists, where
- discussions on the current state of the system take place.</para>
-
- <para>Assuming that you can manage to secure fairly up-to-date sources
- to base your changes on, the next step is to produce a set of diffs to
- send to the FreeBSD maintainers. This is done with the &man.diff.1;
- command, with the &ldquo;context diff&rdquo; form
- being preferred. For example:</para>
-
- <para>
- <screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen>
-
- or
-
- <screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen>
-
- would generate such a set of context diffs for the given source file
- or directory hierarchy. See the man page for &man.diff.1; for more
- details.</para>
-
- <para>Once you have a set of diffs (which you may test with the
- &man.patch.1; command), you should submit them for inclusion with
- FreeBSD. Use the &man.send-pr.1; program as described in <link
- linkend="contrib-general">Bug Reports and General Commentary</link>.
- <emphasis>Do not</emphasis> just send the diffs to the &a.hackers; or
- they will get lost! We greatly appreciate your submission (this is a
- volunteer project!); because we are busy, we may not be able to
- address it immediately, but it will remain in the pr database until we
- do.</para>
-
- <para>If you feel it appropriate (e.g. you have added, deleted, or
- renamed files), bundle your changes into a <command>tar</command> file
- and run the &man.uuencode.1; program on it. Shar archives are also
- welcome.</para>
-
- <para>If your change is of a potentially sensitive nature, e.g. you are
- unsure of copyright issues governing its further distribution or you
- are simply not ready to release it without a tighter review first,
- then you should send it to &a.core; directly rather than submitting it
- with &man.send-pr.1;. The core mailing list reaches a much smaller
- group of people who do much of the day-to-day work on FreeBSD. Note
- that this group is also <emphasis>very busy</emphasis> and so you
- should only send mail to them where it is truly necessary.</para>
-
- <para>Please refer to <command>man 9 intro</command> and <command>man 9
- style</command> for some information on coding style. We would
- appreciate it if you were at least aware of this information before
- submitting code.</para>
- </sect2>
-
- <sect2>
- <title>New code or major value-added packages</title>
-
- <para>In the rare case of a significant contribution of a large body
- work, or the addition of an important new feature to FreeBSD, it
- becomes almost always necessary to either send changes as uuencode'd
- tar files or upload them to our ftp site <ulink
- URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming">ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming</ulink>.</para>
-
- <para>When working with large amounts of code, the touchy subject of
- copyrights also invariably comes up. Acceptable copyrights for code
- included in FreeBSD are:</para>
-
- <orderedlist>
- <listitem>
- <para>The BSD copyright. This copyright is most preferred due to
- its &ldquo;no strings attached&rdquo; nature and general
- attractiveness to commercial enterprises. Far from discouraging
- such commercial use, the FreeBSD Project actively encourages such
- participation by commercial interests who might eventually be
- inclined to invest something of their own into FreeBSD.</para>
- </listitem>
-
- <listitem>
- <para>The GNU Public License, or &ldquo;GPL&rdquo;. This license is
- not quite as popular with us due to the amount of extra effort
- demanded of anyone using the code for commercial purposes, but
- given the sheer quantity of GPL'd code we currently require
- (compiler, assembler, text formatter, etc) it would be silly to
- refuse additional contributions under this license. Code under
- the GPL also goes into a different part of the tree, that being
- <filename>/sys/gnu</filename> or
- <filename>/usr/src/gnu</filename>, and is therefore easily
- identifiable to anyone for whom the GPL presents a problem.</para>
- </listitem>
- </orderedlist>
-
- <para>Contributions coming under any other type of copyright must be
- carefully reviewed before their inclusion into FreeBSD will be
- considered. Contributions for which particularly restrictive
- commercial copyrights apply are generally rejected, though the authors
- are always encouraged to make such changes available through their own
- channels.</para>
-
- <para>To place a &ldquo;BSD-style&rdquo; copyright on your work, include
- the following text at the very beginning of every source code file you
- wish to protect, replacing the text between the <literal>%%</literal>
- with the appropriate information.</para>
-
- <programlisting>
-Copyright (c) %%proper_years_here%%
- %%your_name_here%%, %%your_state%% %%your_zip%%.
- All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-1. Redistributions of source code must retain the above copyright
- notice, this list of conditions and the following disclaimer as
- the first lines of this file unmodified.
-2. Redistributions in binary form must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``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 %%your_name_here%% 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 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
- &#36;Id&#36;</programlisting>
-
- <para>For your convenience, a copy of this text can be found in
- <filename>/usr/share/examples/etc/bsd-style-copyright</filename>.</para>
- </sect2>
-
- <sect2>
- <title>Money, Hardware or Internet access</title>
-
- <para>We are always very happy to accept donations to further the cause
- of the FreeBSD Project and, in a volunteer effort like ours, a little
- can go a long way! Donations of hardware are also very important to
- expanding our list of supported peripherals since we generally lack
- the funds to buy such items ourselves.</para>
-
- <sect3>
- <title><anchor id="donations">Donating funds</title>
-
- <para>While the FreeBSD Project is not a 501(c)(3) (charitable)
- corporation and hence cannot offer special tax incentives for any
- donations made, any such donations will be gratefully accepted on
- behalf of the project by FreeBSD, Inc.</para>
-
- <para>FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg;
- with the goal of furthering the aims of the FreeBSD Project and
- giving it a minimal corporate presence. Any and all funds donated
- (as well as any profits that may eventually be realized by FreeBSD,
- Inc.) will be used exclusively to further the project's
- goals.</para>
-
- <para>Please make any checks payable to FreeBSD, Inc., sent in care of
- the following address:</para>
-
- <address>
- <otheraddr>FreeBSD, Inc.</otheraddr>
- <otheraddr>c/o Jordan Hubbard</otheraddr>
- <street>4041 Pike Lane, Suite F</street>
- <city>Concord</city>
- <state>CA</state>, <postcode>94520</postcode>
- </address>
-
- <para>(currently using the Walnut Creek CDROM address until a PO box
- can be opened)</para>
-
- <para>Wire transfers may also be sent directly to:</para>
-
- <address>
- <otheraddr>Bank Of America</otheraddr>
- <otheraddr>Concord Main Office</otheraddr>
- <pob>P.O. Box 37176</pob>
- <city>San Francisco</city>
- <state>CA</state>, <postcode>94137-5176</postcode>
-
- <otheraddr>Routing #: 121-000-358</otheraddr>
- <otheraddr>Account #: 01411-07441 (FreeBSD, Inc.)</otheraddr>
- </address>
-
- <para>Any correspondence related to donations should be sent to &a.jkh,
- either via email or to the FreeBSD, Inc. postal address given above.
- </para>
-
- <para>If you do not wish to be listed in our <link
- linkend="donors">donors</link> section, please specify this when
- making your donation. Thanks!</para>
- </sect3>
-
- <sect3>
- <title>Donating hardware</title>
-
- <para>Donations of hardware in any of the 3 following categories are
- also gladly accepted by the FreeBSD Project:</para>
-
- <itemizedlist>
- <listitem>
- <para>General purpose hardware such as disk drives, memory or
- complete systems should be sent to the FreeBSD, Inc. address
- listed in the <emphasis>donating funds</emphasis>
- section.</para>
- </listitem>
-
- <listitem>
- <para>Hardware for which ongoing compliance testing is desired.
- We are currently trying to put together a testing lab of all
- components that FreeBSD supports so that proper regression
- testing can be done with each new release. We are still lacking
- many important pieces (network cards, motherboards, etc) and if
- you would like to make such a donation, please contact &a.dg;
- for information on which items are still required.</para>
- </listitem>
-
- <listitem>
- <para>Hardware currently unsupported by FreeBSD for which you
- would like to see such support added. Please contact the
- &a.core; before sending such items as we will need to find a
- developer willing to take on the task before we can accept
- delivery of new hardware.</para>
- </listitem>
- </itemizedlist>
- </sect3>
-
- <sect3>
- <title>Donating Internet access</title>
-
- <para>We can always use new mirror sites for FTP, WWW or
- <command>cvsup</command>. If you would like to be such a mirror,
- please contact the FreeBSD project administrators
- <email>admin@FreeBSD.org</email> for more information.</para>
- </sect3>
- </sect2>
- </sect1>
-
- <sect1 id="donors">
- <title>Donors Gallery</title>
-
- <para>The FreeBSD Project is indebted to the following donors and would
- like to publically thank them here!</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>Contributors to the central server
- project:</emphasis></para>
-
- <para>The following individuals and businesses made it possible for
- the FreeBSD Project to build a new central server machine to
- eventually replace <hostid role="fqdn">freefall.FreeBSD.org</hostid>
- by donating the following items:</para>
-
- <itemizedlist>
- <listitem>
- <para>&a.mbarkah and his employer, <ulink URL="http://www.hemi.com">
- Hemisphere Online</ulink>, donated a <emphasis>Pentium Pro
- (P6) 200Mhz CPU</emphasis></para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.asacomputers.com">ASA
- Computers</ulink> donated a <emphasis>Tyan 1662
- motherboard</emphasis>.</para>
- </listitem>
-
- <listitem>
- <para>Joe McGuckin <email>joe@via.net</email> of <ulink
- URL="http://www.via.net">ViaNet Communications</ulink> donated
- a <emphasis>Kingston ethernet controller.</emphasis></para>
- </listitem>
-
- <listitem>
- <para>Jack O'Neill <email>jack@diamond.xtalwind.net</email>
- donated an <emphasis>NCR 53C875 SCSI controller
- card</emphasis>.</para>
- </listitem>
-
- <listitem>
- <para>Ulf Zimmermann <email>ulf@Alameda.net</email> of <ulink
- URL="http://www.Alameda.net">Alameda Networks</ulink> donated
- <emphasis>128MB of memory</emphasis>, a <emphasis>4 Gb disk
- drive and the case.</emphasis></para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para><emphasis>Direct funding:</emphasis></para>
-
- <para>The following individuals and businesses have generously
- contributed direct funding to the project:</para>
-
- <itemizedlist>
- <listitem>
- <para>Annelise Anderson
- <email>ANDRSN@HOOVER.STANFORD.EDU</email></para>
- </listitem>
-
- <listitem>
- <para>&a.dillon</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.epilogue.com/">Epilogue Technology
- Corporation</ulink></para>
- </listitem>
-
- <listitem>
- <para>&a.sef</para>
- </listitem>
-
- <listitem>
- <para>Don Scott Wilde</para>
- </listitem>
-
- <listitem>
- <para>Gianmarco Giovannelli
- <email>gmarco@masternet.it</email></para>
- </listitem>
-
- <listitem>
- <para>Josef C. Grosch <email>joeg@truenorth.org</email></para>
- </listitem>
-
- <listitem>
- <para>Robert T. Morris</para>
- </listitem>
-
- <listitem>
- <para>&a.chuckr</para>
- </listitem>
-
- <listitem>
- <para>Kenneth P. Stox <email>ken@stox.sa.enteract.com</email> of
- <ulink URL="http://www.imagescape.com">Imaginary Landscape,
- LLC.</ulink></para>
- </listitem>
-
- <listitem>
- <para>Dmitry S. Kohmanyuk <email>dk@dog.farm.org</email></para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.cdrom.co.jp/">Laser5</ulink> of Japan
- (a portion of the profits from sales of their various FreeBSD
- CD-ROMs.</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.mmjp.or.jp/fuki/">Fuki Shuppan
- Publishing Co.</ulink> donated a portion of their profits from
- <emphasis>Hajimete no FreeBSD</emphasis> (FreeBSD, Getting
- started) to the FreeBSD and XFree86 projects.</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.ascii.co.jp/">ASCII Corp.</ulink>
- donated a portion of their profits from several FreeBSD-related
- books to the FreeBSD project.</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.yokogawa.co.jp/">Yokogawa Electric
- Corp</ulink> has generously donated significant funding to the
- FreeBSD project.</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.buffnet.net/">BuffNET</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink url="http://www.pacificsolutions.com/">Pacific
- Solutions</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink url="http://www.siemens.de/">Siemens AG</ulink>
- via <ulink url="mailto:andre.albsmeier@mchp.siemens.de">Andre
- Albsmeier</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink url="mailto:ras@interaccess.com">Chris Silva</ulink>
- </para>
- </listitem>
-
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para><emphasis>Hardware contributors:</emphasis></para>
-
- <para>The following individuals and businesses have generously
- contributed hardware for testing and device driver
- development/support:</para>
-
- <itemizedlist>
- <listitem>
- <para>Walnut Creek CDROM for providing the Pentium P5-90 and
- 486/DX2-66 EISA/VL systems that are being used for our
- development work, to say nothing of the network access and other
- donations of hardware resources.</para>
- </listitem>
-
- <listitem>
- <para>TRW Financial Systems, Inc. provided 130 PCs, three 68 GB
- fileservers, twelve Ethernets, two routers and an ATM switch for
- debugging the diskless code.</para>
- </listitem>
-
- <listitem>
- <para>Dermot McDonnell donated the Toshiba XM3401B CDROM drive
- currently used in freefall.</para>
- </listitem>
-
- <listitem>
- <para>&a.chuck; contributed his floppy tape streamer for
- experimental work.</para>
- </listitem>
-
- <listitem>
- <para>Larry Altneu <email>larry@ALR.COM</email>, and &a.wilko;,
- provided Wangtek and Archive QIC-02 tape drives in order to
- improve the <devicename>wt</devicename> driver.</para>
- </listitem>
-
- <listitem>
- <para>Ernst Winter <email>ewinter@lobo.muc.de</email> contributed
- a 2.88 MB floppy drive to the project. This will hopefully
- increase the pressure for rewriting the floppy disk driver.
- <!-- smiley -->;-)</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.tekram.com">Tekram
- Technologies</ulink> sent one each of their DC-390, DC-390U
- and DC-390F FAST and ULTRA SCSI host adapter cards for
- regression testing of the NCR and AMD drivers with their cards.
- They are also to be applauded for making driver sources for free
- operating systems available from their FTP server <ulink
- URL="ftp://ftp.tekram.com/scsi/FreeBSD">ftp://ftp.tekram.com/scsi/FreeBSD</ulink>.</para>
- </listitem>
-
- <listitem>
- <para><email>Larry M. Augustin</email> contributed not only a
- Symbios Sym8751S SCSI card, but also a set of data books,
- including one about the forthcoming Sym53c895 chip with Ultra-2
- and LVD support, and the latest programming manual with
- information on how to safely use the advanced features of the
- latest Symbios SCSI chips. Thanks a lot!</para>
- </listitem>
-
- <listitem>
- <para>Christoph Kukulies <email>kuku@FreeBSD.org</email> donated
- an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver
- development.</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para><emphasis>Special contributors:</emphasis></para>
-
- <itemizedlist>
- <listitem>
- <para><ulink URL="http://www.cdrom.com">Walnut Creek CDROM</ulink>
- has donated almost more than we can say (see the <link
- linkend="history">history</link> document for more details).
- In particular, we would like to thank them for the original
- hardware used for <hostid
- role="fqdn">freefall.FreeBSD.org</hostid>, our primary
- development machine, and for <hostid
- role="fqdn">thud.FreeBSD.org</hostid>, a testing and build
- box. We are also indebted to them for funding various
- contributors over the years and providing us with unrestricted
- use of their T1 connection to the Internet.</para>
- </listitem>
-
- <listitem>
- <para>The <ulink URL="http://www.interface-business.de">interface
- business GmbH, Dresden</ulink> has been patiently supporting
- &a.joerg; who has often preferred FreeBSD work over paywork, and
- used to fall back to their (quite expensive) EUnet Internet
- connection whenever his private connection became too slow or
- flakey to work with it...</para>
- </listitem>
-
- <listitem>
- <para><ulink URL="http://www.bsdi.com">Berkeley Software Design,
- Inc.</ulink> has contributed their DOS emulator code to the
- remaining BSD world, which is used in the
- <emphasis>doscmd</emphasis> command.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </itemizedlist>
- </sect1>
-
- <sect1>
- <title>Core Team Alumni</title>
-
- <para>The following people were members of the FreeBSD core team during
- the periods indicated. We thank them for their past efforts in the
- service of the FreeBSD project.</para>
-
- <para><emphasis>In rough chronological order:</emphasis></para>
-
- <itemizedlist>
- <listitem>
- <para>&a.guido (1995 - 1999)</para>
- </listitem>
-
- <listitem>
- <para>&a.dyson (1993 - 1998)</para>
- </listitem>
-
- <listitem>
- <para>&a.nate (1992 - 1996)</para>
- </listitem>
-
- <listitem>
- <para>&a.rgrimes (1992 - 1995)</para>
- </listitem>
-
- <listitem>
- <para>Andreas Schulz (1992 - 1995)</para>
- </listitem>
-
- <listitem>
- <para>&a.csgr (1993 - 1995)</para>
- </listitem>
-
- <listitem>
- <para>&a.paul (1992 - 1995)</para>
- </listitem>
-
- <listitem>
- <para>&a.smace (1993 - 1994)</para>
- </listitem>
-
- <listitem>
- <para>Andrew Moore (1993 - 1994)</para>
- </listitem>
-
- <listitem>
- <para>Christoph Robitschko (1993 - 1994)</para>
- </listitem>
-
- <listitem>
- <para>J. T. Conklin (1992 - 1993)</para>
- </listitem>
- </itemizedlist>
- </sect1>
-
- <sect1>
- <title>Derived Software Contributors</title>
-
- <para>This software was originally derived from William F. Jolitz's 386BSD
- release 0.1, though almost none of the original 386BSD specific code
- remains. This software has been essentially re-implemented from the
- 4.4BSD-Lite release provided by the Computer Science Research Group
- (CSRG) at the University of California, Berkeley and associated academic
- contributors.</para>
-
- <para>There are also portions of NetBSD and OpenBSD that have been
- integrated into FreeBSD as well, and we would therefore like to thank
- all the contributors to NetBSD and OpenBSD for their work.</para>
- </sect1>
-
- <sect1 id="contrib-additional">
- <title>Additional FreeBSD Contributors</title>
-
- <para>(in alphabetical order by first name):</para>
-
- <itemizedlist>
- <listitem>
- <para>ABURAYA Ryushirou <email>rewsirow@ff.iij4u.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>AMAGAI Yoshiji <email>amagai@nue.org</email></para>
- </listitem>
-
- <listitem>
- <para>Aaron Bornstein <email>aaronb@j51.com</email></para>
- </listitem>
-
- <listitem>
- <para>Aaron Smith <email>aaron@mutex.org</email></para>
- </listitem>
-
- <listitem>
- <para>Achim Patzner <email>ap@noses.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ada T Lim <email>ada@bsd.org</email></para>
- </listitem>
-
- <listitem>
- <para>Adam Baran <email>badam@mw.mil.pl</email></para>
- </listitem>
-
- <listitem>
- <para>Adam Glass <email>glass@postgres.berkeley.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Adam McDougall <email>mcdouga9@egr.msu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Adrian Colley <email>aecolley@ois.ie</email></para>
- </listitem>
-
- <listitem>
- <para>Adrian Hall <email>adrian@ibmpcug.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Adrian Mariano <email>adrian@cam.cornell.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Adrian Steinmann <email>ast@marabu.ch</email></para>
- </listitem>
-
- <listitem>
- <para>Adam Strohl <email>troll@digitalspark.net</email></para>
- </listitem>
-
- <listitem>
- <para>Adrian T. Filipi-Martin
- <email>atf3r@agate.cs.virginia.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Ajit Thyagarajan <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Akio Morita
- <email>amorita@meadow.scphys.kyoto-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Akira SAWADA <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Akira Watanabe
- <email>akira@myaw.ei.meisei-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Akito Fujita <email>fujita@zoo.ncl.omron.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Alain Kalker
- <email>A.C.P.M.Kalker@student.utwente.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Alan Bawden <email>alan@curry.epilogue.com</email></para>
- </listitem>
-
- <listitem>
- <para>Alec Wolman <email>wolman@cs.washington.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Aled Morris <email>aledm@routers.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Alex <email>garbanzo@hooked.net</email></para>
- </listitem>
-
- <listitem>
- <para>Alex D. Chen
- <email>dhchen@Canvas.dorm7.nccu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Alex G. Bulushev <email>bag@demos.su</email></para>
- </listitem>
-
- <listitem>
- <para>Alex Le Heux <email>alexlh@funk.org</email></para>
- </listitem>
-
- <listitem>
- <para>Alex Perel <email>veers@disturbed.net</email></para>
- </listitem>
-
- <listitem>
- <para>Alexander B. Povolotsky <email>tarkhil@mgt.msk.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Alexander Leidinger
- <email>netchild@wurzelausix.CS.Uni-SB.DE</email></para>
- </listitem>
-
- <listitem>
- <para>Alexander Langer <email>alex@cichlids.com</email></para>
- </listitem>
-
- <listitem>
- <para>Alexandre Snarskii <email>snar@paranoia.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Alistair G. Crooks <email>agc@uts.amdahl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Allan Saddi <email>asaddi@philosophysw.com</email></para>
- </listitem>
-
- <listitem>
- <para>Allen Campbell <email>allenc@verinet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Amakawa Shuhei <email>amakawa@hoh.t.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Amancio Hasty <email>hasty@star-gate.com</email></para>
- </listitem>
-
- <listitem>
- <para>Amir Farah <email>amir@comtrol.com</email></para>
- </listitem>
-
- <listitem>
- <para>Amy Baron <email>amee@beer.org</email></para>
- </listitem>
-
- <listitem>
- <para>Anatoly A. Orehovsky <email>tolik@mpeks.tomsk.su</email></para>
- </listitem>
-
- <listitem>
- <para>Anatoly Vorobey <email>mellon@pobox.com</email></para>
- </listitem>
-
- <listitem>
- <para>Anders Nordby <email>nickerne@nome.no</email></para>
- </listitem>
-
- <listitem>
- <para>Anders Thulin <email>Anders.X.Thulin@telia.se</email></para>
- </listitem>
-
- <listitem>
- <para>Andras Olah <email>olah@cs.utwente.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Andre Albsmeier
- <email>Andre.Albsmeier@mchp.siemens.de</email></para>
- </listitem>
-
- <listitem>
- <para>Andre Oppermann <email>andre@pipeline.ch</email></para>
- </listitem>
-
- <listitem>
- <para>Andreas Haakh <email>ah@alman.robin.de</email></para>
- </listitem>
-
- <listitem>
- <para>Andreas Kohout <email>shanee@rabbit.augusta.de</email></para>
- </listitem>
-
- <listitem>
- <para>Andreas Lohr <email>andreas@marvin.RoBIN.de</email></para>
- </listitem>
-
- <listitem>
- <para>Andreas Schulz <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Andreas Wetzel <email>mickey@deadline.snafu.de</email></para>
- </listitem>
-
- <listitem>
- <para>Andreas Wrede <email>andreas@planix.com</email></para>
- </listitem>
-
- <listitem>
- <para>Andres Vega Garcia <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Atrens <email>atreand@statcan.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Boothman <email>andrew@cream.org</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Gillham <email>gillham@andrews.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Gordon <email>andrew.gordon@net-tel.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Herbert <email>andrew@werple.apana.org.au</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew J. Korty <email>ajk@purdue.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew L. Moore <email>alm@mclink.com</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew McRae <email>amcrae@cisco.com</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Stevenson <email>andrew@ugh.net.au</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Timonin <email>tim@pool1.convey.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew V. Stesin <email>stesin@elvisti.kiev.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Webster <email>awebster@dataradio.com</email></para>
- </listitem>
-
- <listitem>
- <para>Andrey Zakhvatov <email>andy@icc.surw.chel.su</email></para>
- </listitem>
-
- <listitem>
- <para>Andy Farkas <email>andyf@speednet.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Andy Valencia <email>ajv@csd.mot.com</email></para>
- </listitem>
-
- <listitem>
- <para>Andy Whitcroft <email>andy@sarc.city.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Angelo Turetta <email>ATuretta@stylo.it</email></para>
- </listitem>
-
- <listitem>
- <para>Anthony C. Chavez <email>magus@xmission.com</email></para>
- </listitem>
-
- <listitem>
- <para>Anthony Yee-Hang Chan <email>yeehang@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Anton Berezin <email>tobez@plab.ku.dk</email></para>
- </listitem>
-
- <listitem>
- <para>Antti Kaipila <email>anttik@iki.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Are Bryne <email>are.bryne@communique.no</email></para>
- </listitem>
-
- <listitem>
- <para>Ari Suutari <email>ari@suutari.iki.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Arjan de Vet <email>devet@IAEhv.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Arne Henrik Juul <email>arnej@Lise.Unit.NO</email></para>
- </listitem>
-
- <listitem>
- <para>Assar Westerlund <email>assar@sics.se</email></para>
- </listitem>
-
- <listitem>
- <para>Atsushi Furuta <email>furuta@sra.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Atsushi Murai <email>amurai@spec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Bakul Shah <email>bvs@bitblocks.com</email></para>
- </listitem>
-
- <listitem>
- <para>Barry Bierbauch <email>pivrnec@vszbr.cz</email></para>
- </listitem>
-
- <listitem>
- <para>Barry Lustig <email>barry@ictv.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ben Hutchinson <email>benhutch@xfiles.org.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Ben Jackson <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Ben Smithurst <email>ben@scientia.demon.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Ben Walter <email>bwalter@itachi.swcp.com</email></para>
- </listitem>
-
- <listitem>
- <para>Benjamin Lewis <email>bhlewis@gte.net</email></para>
- </listitem>
-
- <listitem>
- <para>Bernd Rosauer <email>br@schiele-ct.de</email></para>
- </listitem>
-
- <listitem>
- <para>Bill Kish <email>kish@osf.org</email></para>
- </listitem>
-
- <listitem>
- <para>Bill Trost <email>trost@cloud.rain.com</email></para>
- </listitem>
-
- <listitem>
- <para>Blaz Zupan <email>blaz@amis.net</email></para>
- </listitem>
-
- <listitem>
- <para>Bob Van Valzah <email>Bob@whitebarn.com</email></para>
- </listitem>
-
- <listitem>
- <para>Bob Willcox <email>bob@luke.pmr.com</email></para>
- </listitem>
-
- <listitem>
- <para>Boris Staeblow <email>balu@dva.in-berlin.de</email></para>
- </listitem>
-
- <listitem>
- <para>Boyd R. Faulkner <email>faulkner@asgard.bga.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brad Karp <email>karp@eecs.harvard.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Bradley Dunn <email>bradley@dunn.org</email></para>
- </listitem>
-
- <listitem>
- <para>Brandon Fosdick <email>bfoz@glue.umd.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Brandon Gillespie <email>brandon@roguetrader.com</email></para>
- </listitem>
-
- <listitem>
- <para>&a.wlloyd</para>
- </listitem>
-
- <listitem>
- <para>Bob Wilcox <email>bob@obiwan.uucp</email></para>
- </listitem>
-
- <listitem>
- <para>Boyd Faulkner <email>faulkner@mpd.tandem.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brent J. Nordquist <email>bjn@visi.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brett Lymn <email>blymn@mulga.awadi.com.AU</email></para>
- </listitem>
-
- <listitem>
- <para>Brett Taylor
- <email>brett@peloton.physics.montana.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Campbell <email>brianc@pobox.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Clapper <email>bmc@willscreek.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Cully <email>shmit@kublai.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Handy
- <email>handy@lambic.space.lockheed.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Litzinger <email>brian@MediaCity.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian McGovern <email>bmcgover@cisco.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Moore <email>ziff@houdini.eecs.umich.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Brian R. Haug <email>haug@conterra.com</email></para>
- </listitem>
-
- <listitem>
- <para>Brian Tao <email>taob@risc.org</email></para>
- </listitem>
-
- <listitem>
- <para>Brion Moss <email>brion@queeg.com</email></para>
- </listitem>
-
- <listitem>
- <para>Bruce A. Mah <email>bmah@ca.sandia.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Bruce Albrecht <email>bruce@zuhause.mn.org</email></para>
- </listitem>
-
- <listitem>
- <para>Bruce Gingery <email>bgingery@gtcs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Bruce J. Keeler <email>loodvrij@gridpoint.com</email></para>
- </listitem>
-
- <listitem>
- <para>Bruce Murphy <email>packrat@iinet.net.au</email></para>
- </listitem>
-
- <listitem>
- <para>Bruce Walter <email>walter@fortean.com</email></para>
- </listitem>
-
- <listitem>
- <para>Carey Jones <email>mcj@acquiesce.org</email></para>
- </listitem>
-
- <listitem>
- <para>Carl Fongheiser <email>cmf@netins.net</email></para>
- </listitem>
-
- <listitem>
- <para>Carl Mascott <email>cmascott@world.std.com</email></para>
- </listitem>
-
- <listitem>
- <para>Casper <email>casper@acc.am</email></para>
- </listitem>
-
- <listitem>
- <para>Castor Fu <email>castor@geocast.com</email></para>
- </listitem>
-
- <listitem>
- <para>Cejka Rudolf <email>cejkar@dcse.fee.vutbr.cz</email></para>
- </listitem>
-
- <listitem>
- <para>Chain Lee <email>chain@110.net</email></para>
- </listitem>
-
- <listitem>
- <para>Charles Hannum <email>mycroft@ai.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Charles Henrich <email>henrich@msu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Charles Mott <email>cmott@srv.net</email></para>
- </listitem>
-
- <listitem>
- <para>Charles Owens <email>owensc@enc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Chet Ramey <email>chet@odin.INS.CWRU.Edu</email></para>
- </listitem>
-
- <listitem>
- <para>Chia-liang Kao <email>clkao@CirX.ORG</email></para>
- </listitem>
-
- <listitem>
- <para>Chiharu Shibata <email>chi@bd.mbn.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Chip Norkus <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Choi Jun Ho <email>junker@jazz.snu.ac.kr</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Csanady <email>cc@tarsier.ca.sandia.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Dabrowski <email>chris@vader.org</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Dillon <email>cdillon@wolves.k12.mo.us</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Shenton
- <email>cshenton@angst.it.hq.nasa.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Stenton <email>jacs@gnome.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Timmons <email>skynyrd@opus.cts.cwu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Torek <email>torek@ee.lbl.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Christian Gusenbauer
- <email>cg@fimp01.fim.uni-linz.ac.at</email></para>
- </listitem>
-
- <listitem>
- <para>Christian Haury <email>Christian.Haury@sagem.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Christian Weisgerber
- <email>naddy@bigeye.rhein-neckar.de</email></para>
- </listitem>
-
- <listitem>
- <para>Christoph P. Kukulies <email>kuku@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Christoph Robitschko
- <email>chmr@edvz.tu-graz.ac.at</email></para>
- </listitem>
-
- <listitem>
- <para>Christoph Weber-Fahr
- <email>wefa@callcenter.systemhaus.net</email></para>
- </listitem>
-
- <listitem>
- <para>Christopher G. Demetriou
- <email>cgd@postgres.berkeley.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Christopher T. Johnson
- <email>cjohnson@neunacht.netgsi.com</email></para>
- </listitem>
-
- <listitem>
- <para>Chrisy Luke <email>chrisy@flix.net</email></para>
- </listitem>
-
- <listitem>
- <para>Chuck Hein <email>chein@cisco.com</email></para>
- </listitem>
-
- <listitem>
- <para>Clive Lin <email>clive@CiRX.ORG</email></para>
- </listitem>
-
- <listitem>
- <para>Colman Reilly <email>careilly@tcd.ie</email></para>
- </listitem>
-
- <listitem>
- <para>Conrad Sabatier <email>conrads@neosoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Coranth Gryphon <email>gryphon@healer.com</email></para>
- </listitem>
-
- <listitem>
- <para>Cornelis van der Laan
- <email>nils@guru.ims.uni-stuttgart.de</email></para>
- </listitem>
-
- <listitem>
- <para>Cove Schneider <email>cove@brazil.nbn.com</email></para>
- </listitem>
-
- <listitem>
- <para>Craig Leres <email>leres@ee.lbl.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Craig Loomis <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Craig Metz <email>cmetz@inner.net</email></para>
- </listitem>
-
- <listitem>
- <para>Craig Spannring <email>cts@internetcds.com</email></para>
- </listitem>
-
- <listitem>
- <para>Craig Struble <email>cstruble@vt.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Cristian Ferretti <email>cfs@riemann.mat.puc.cl</email></para>
- </listitem>
-
- <listitem>
- <para>Curt Mayer <email>curt@toad.com</email></para>
- </listitem>
-
- <listitem>
- <para>Cy Schubert <email>cschuber@uumail.gov.bc.ca</email></para>
- </listitem>
-
- <listitem>
- <para>DI. Christian Gusenbauer
- <email>cg@scotty.edvz.uni-linz.ac.at</email></para>
- </listitem>
-
- <listitem>
- <para>Dai Ishijima <email>ishijima@tri.pref.osaka.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Damian Hamill <email>damian@cablenet.net</email></para>
- </listitem>
-
- <listitem>
- <para>Dan Cross <email>tenser@spitfire.ecsel.psu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Dan Lukes <email>dan@obluda.cz</email></para>
- </listitem>
-
- <listitem>
- <para>Dan Nelson <email>dnelson@emsphone.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dan Walters <email>hannibal@cyberstation.net</email></para>
- </listitem>
-
- <listitem>
- <para>Daniel M. Eischen
- <email>deischen@iworks.InterWorks.org</email></para>
- </listitem>
-
- <listitem>
- <para>Daniel O'Connor <email>doconnor@gsoft.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Daniel Poirot <email>poirot@aio.jsc.nasa.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Daniel Rock <email>rock@cs.uni-sb.de</email></para>
- </listitem>
-
- <listitem>
- <para>Danny Egen <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Danny J. Zerkel <email>dzerkel@phofarm.com</email></para>
- </listitem>
-
- <listitem>
- <para>Darren Reed <email>avalon@coombs.anu.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Adkins <email>adkin003@tc.umn.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Andersen <email>angio@aros.net</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Blizzard <email>dblizzar@sprynet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Bodenstab <email>imdave@synet.net</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Burgess <email>burgess@hrd769.brooks.af.mil</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Chapeskie <email>dchapes@ddm.on.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Cornejo <email>dave@dogwood.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Edmondson <email>davided@sco.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Glowacki <email>dglo@ssec.wisc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Marquardt <email>marquard@austin.ibm.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Tweten <email>tweten@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>David A. Adkins <email>adkin003@tc.umn.edu</email></para>
- </listitem>
-
- <listitem>
- <para>David A. Bader <email>dbader@umiacs.umd.edu</email></para>
- </listitem>
-
- <listitem>
- <para>David Borman <email>dab@bsdi.com</email></para>
- </listitem>
-
- <listitem>
- <para>David Dawes <email>dawes@XFree86.org</email></para>
- </listitem>
-
- <listitem>
- <para>David Filo <email>filo@yahoo.com</email></para>
- </listitem>
-
- <listitem>
- <para>David Holland <email>dholland@eecs.harvard.edu</email></para>
- </listitem>
-
- <listitem>
- <para>David Holloway <email>daveh@gwythaint.tamis.com</email></para>
- </listitem>
-
- <listitem>
- <para>David Horwitt <email>dhorwitt@ucsd.edu</email></para>
- </listitem>
-
- <listitem>
- <para>David Hovemeyer <email>daveho@infocom.com</email></para>
- </listitem>
-
- <listitem>
- <para>David Jones <email>dej@qpoint.torfree.net</email></para>
- </listitem>
-
- <listitem>
- <para>David Kelly <email>dkelly@tomcat1.tbe.com</email></para>
- </listitem>
-
- <listitem>
- <para>David Kulp <email>dkulp@neomorphic.com</email></para>
- </listitem>
-
- <listitem>
- <para>David L. Nugent <email>davidn@blaze.net.au</email></para>
- </listitem>
-
- <listitem>
- <para>David Leonard <email>d@scry.dstc.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>David Malone <email>dwmalone@maths.tcd.ie</email></para>
- </listitem>
-
- <listitem>
- <para>David Muir Sharnoff <email>muir@idiom.com</email></para>
- </listitem>
-
- <listitem>
- <para>David S. Miller <email>davem@jenolan.rutgers.edu</email></para>
- </listitem>
-
- <listitem>
- <para>David Wolfskill <email>dhw@whistle.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dean Gaudet <email>dgaudet@arctic.org</email></para>
- </listitem>
-
- <listitem>
- <para>Dean Huxley <email>dean@fsa.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Denis Fortin <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Dennis Glatting
- <email>dennis.glatting@software-munitions.com</email></para>
- </listitem>
-
- <listitem>
- <para>Denton Gentry <email>denny1@home.com</email></para>
- </listitem>
-
- <listitem>
- <para>Derek Inksetter <email>derek@saidev.com</email></para>
- </listitem>
-
- <listitem>
- <para>Dima Sivachenko <email>dima@Chg.RU</email></para>
- </listitem>
-
- <listitem>
- <para>Dirk Keunecke <email>dk@panda.rhein-main.de</email></para>
- </listitem>
-
- <listitem>
- <para>Dirk Nehrling <email>nerle@pdv.de</email></para>
- </listitem>
-
- <listitem>
- <para>Dmitry Khrustalev <email>dima@xyzzy.machaon.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Dmitry Kohmanyuk <email>dk@farm.org</email></para>
- </listitem>
-
- <listitem>
- <para>Dom Mitchell <email>dom@myrddin.demon.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Dominik Brettnacher <email>domi@saargate.de</email></para>
- </listitem>
-
- <listitem>
- <para>Don Croyle <email>croyle@gelemna.ft-wayne.in.us</email></para>
- </listitem>
-
- <listitem>
- <para>&a.whiteside;</para>
- </listitem>
-
- <listitem>
- <para>Don Morrison <email>dmorrisn@u.washington.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Don Yuniskis <email>dgy@rtd.com</email></para>
- </listitem>
-
- <listitem>
- <para>Donald Maddox <email>dmaddox@conterra.com</email></para>
- </listitem>
-
- <listitem>
- <para>Doug Barton <email>studded@dal.net</email></para>
- </listitem>
-
- <listitem>
- <para>Douglas Ambrisko <email>ambrisko@whistle.com</email></para>
- </listitem>
-
- <listitem>
- <para>Douglas Carmichael <email>dcarmich@mcs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Douglas Crosher <email>dtc@scrooge.ee.swin.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Drew Derbyshire <email>ahd@kew.com</email></para>
- </listitem>
-
- <listitem>
- <para>Duncan Barclay <email>dmlb@ragnet.demon.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Dustin Sallings <email>dustin@spy.net</email></para>
- </listitem>
-
- <listitem>
- <para>Eckart "Isegrim" Hofmann
- <email>Isegrim@Wunder-Nett.org</email></para>
- </listitem>
-
- <listitem>
- <para>Ed Gold
- <email>vegold01@starbase.spd.louisville.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Ed Hudson <email>elh@p5.spnet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Edward Wang <email>edward@edcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Edwin Groothus <email>edwin@nwm.wan.philips.com</email></para>
- </listitem>
-
- <listitem>
- <para>Eiji-usagi-MATSUmoto <email>usagi@clave.gr.jp</email></para>
- </listitem>
-
- <listitem>
- <para>ELISA Font Project</para>
- </listitem>
-
- <listitem>
- <para>Elmar Bartel
- <email>bartel@informatik.tu-muenchen.de</email></para>
- </listitem>
-
- <listitem>
- <para>Eric A. Griff <email>eagriff@global2000.net</email></para>
- </listitem>
-
- <listitem>
- <para>Eric Blood <email>eblood@cs.unr.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Eric J. Haug <email>ejh@slustl.slu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Eric J. Schwertfeger <email>eric@cybernut.com</email></para>
- </listitem>
-
- <listitem>
- <para>Eric L. Hernes <email>erich@lodgenet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Eric P. Scott <email>eps@sirius.com</email></para>
- </listitem>
-
- <listitem>
- <para>Eric Sprinkle <email>eric@ennovatenetworks.com</email></para>
- </listitem>
-
- <listitem>
- <para>Erich Stefan Boleyn <email>erich@uruk.org</email></para>
- </listitem>
-
- <listitem>
- <para>Erik E. Rantapaa <email>rantapaa@math.umn.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Erik H. Moe <email>ehm@cris.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ernst Winter <email>ewinter@lobo.muc.de</email></para>
- </listitem>
-
- <listitem>
- <para>Espen Skoglund <email>espensk@stud.cs.uit.no></email></para>
- </listitem>
-
- <listitem>
- <para>Eugene M. Kim <email>astralblue@usa.net</email></para>
- </listitem>
-
- <listitem>
- <para>Eugene Radchenko <email>genie@qsar.chem.msu.su</email></para>
- </listitem>
-
- <listitem>
- <para>Evan Champion <email>evanc@synapse.net</email></para>
- </listitem>
-
- <listitem>
- <para>Faried Nawaz <email>fn@Hungry.COM</email></para>
- </listitem>
-
- <listitem>
- <para>Flemming Jacobsen <email>fj@tfs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Fong-Ching Liaw <email>fong@juniper.net</email></para>
- </listitem>
-
- <listitem>
- <para>Francis M J Hsieh <email>mjshieh@life.nthu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Bartels <email>knarf@camelot.de</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Chen Hsiung Chan
- <email>frankch@waru.life.nthu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Durda IV <email>uhclem@nemesis.lonestar.org</email></para>
- </listitem>
-
- <listitem>
- <para>Frank MacLachlan <email>fpm@n2.net</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Mayhar <email>frank@exit.com</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Nobis <email>fn@Radio-do.de</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Volf <email>volf@oasis.IAEhv.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Frank ten Wolde <email>franky@pinewood.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Frank van der Linden <email>frank@fwi.uva.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Fred Cawthorne <email>fcawth@jjarray.umn.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Fred Gilham <email>gilham@csl.sri.com</email></para>
- </listitem>
-
- <listitem>
- <para>Fred Templin <email>templin@erg.sri.com</email></para>
- </listitem>
-
- <listitem>
- <para>Frederick Earl Gray <email>fgray@rice.edu</email></para>
- </listitem>
-
- <listitem>
- <para>FUJIMOTO Kensaku
- <email>fujimoto@oscar.elec.waseda.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>FUJISHIMA Satsuki <email>k5@respo.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>FURUSAWA Kazuhisa
- <email>furusawa@com.cs.osakafu-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Gabor Kincses <email>gabor@acm.org</email></para>
- </listitem>
-
- <listitem>
- <para>Gabor Zahemszky <email>zgabor@CoDe.hu</email></para>
- </listitem>
-
- <listitem>
- <para>G. Adam Stanislav<email>adam@whizkidtech.net</email></para>
- </listitem>
-
- <listitem>
- <para>Garance A Drosehn <email>gad@eclipse.its.rpi.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Gareth McCaughan <email>gjm11@dpmms.cam.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Gary A. Browning <email>gab10@griffcd.amdahl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gary Howland <email>gary@hotlava.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gary J. <email>garyj@rks32.pcs.dec.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gary Kline <email>kline@thought.org</email></para>
- </listitem>
-
- <listitem>
- <para>Gaspar Chilingarov <email>nightmar@lemming.acc.am</email></para>
- </listitem>
-
- <listitem>
- <para>Gea-Suan Lin <email>gsl@tpts4.seed.net.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Geoff Rehmet <email>csgr@alpha.ru.ac.za</email></para>
- </listitem>
-
- <listitem>
- <para>Georg Wagner <email>georg.wagner@ubs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gerard Roudier <email>groudier@club-internet.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Gianmarco Giovannelli
- <email>gmarco@giovannelli.it</email></para>
- </listitem>
-
- <listitem>
- <para>Gil Kloepfer Jr. <email>gil@limbic.ssdl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gilad Rom <email>rom_glsa@ein-hashofet.co.il</email></para>
- </listitem>
-
- <listitem>
- <para>Ginga Kawaguti
- <email>ginga@amalthea.phys.s.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Giles Lean <email>giles@nemeton.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Glen Foster <email>gfoster@gfoster.com</email></para>
- </listitem>
-
- <listitem>
- <para>Glenn Johnson <email>gljohns@bellsouth.net</email></para>
- </listitem>
-
- <listitem>
- <para>Godmar Back <email>gback@facility.cs.utah.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Goran Hammarback <email>goran@astro.uu.se</email></para>
- </listitem>
-
- <listitem>
- <para>Gord Matzigkeit <email>gord@enci.ucalgary.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Gordon Greeff <email>gvg@uunet.co.za</email></para>
- </listitem>
-
- <listitem>
- <para>Graham Wheeler <email>gram@cdsec.com</email></para>
- </listitem>
-
- <listitem>
- <para>Greg A. Woods <email>woods@zeus.leitch.com</email></para>
- </listitem>
-
- <listitem>
- <para>Greg Ansley <email>gja@ansley.com</email></para>
- </listitem>
-
- <listitem>
- <para>Greg Troxel <email>gdt@ir.bbn.com</email></para>
- </listitem>
-
- <listitem>
- <para>Greg Ungerer <email>gerg@stallion.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Gregory Bond <email>gnb@itga.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Gregory D. Moncreaff
- <email>moncrg@bt340707.res.ray.com</email></para>
- </listitem>
-
- <listitem>
- <para>Guy Harris <email>guy@netapp.com</email></para>
- </listitem>
-
- <listitem>
- <para>Guy Helmer <email>ghelmer@cs.iastate.edu</email></para>
- </listitem>
-
- <listitem>
- <para>HAMADA Naoki <email>hamada@astec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>HONDA Yasuhiro
- <email>honda@kashio.info.mie-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>HOSOBUCHI Noriyuki <email>hoso@buchi.tama.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hannu Savolainen <email>hannu@voxware.pp.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Hans Huebner <email>hans@artcom.de</email></para>
- </listitem>
-
- <listitem>
- <para>Hans Petter Bieker <email>zerium@webindex.no</email></para>
- </listitem>
-
- <listitem>
- <para>Hans Zuidam <email>hans@brandinnovators.com</email></para>
- </listitem>
-
- <listitem>
- <para>Harlan Stenn <email>Harlan.Stenn@pfcs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Harold Barker <email>hbarker@dsms.com</email></para>
- </listitem>
-
- <listitem>
- <para>Havard Eidnes
- <email>Havard.Eidnes@runit.sintef.no</email></para>
- </listitem>
-
- <listitem>
- <para>Heikki Suonsivu <email>hsu@cs.hut.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Heiko W. Rupp <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Helmut F. Wirth <email>hfwirth@ping.at</email></para>
- </listitem>
-
- <listitem>
- <para>Henrik Vestergaard Draboel
- <email>hvd@terry.ping.dk</email></para>
- </listitem>
-
- <listitem>
- <para>Herb Peyerl <email>hpeyerl@NetBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Hideaki Ohmon <email>ohmon@tom.sfc.keio.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hidekazu Kuroki <email>hidekazu@cs.titech.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hideki Yamamoto <email>hyama@acm.org</email></para>
- </listitem>
-
- <listitem>
- <para>Hideyuki Suzuki
- <email>hideyuki@sat.t.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hirayama Issei <email>iss@mail.wbs.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hiroaki Sakai <email>sakai@miya.ee.kagu.sut.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hiroharu Tamaru <email>tamaru@ap.t.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hironori Ikura <email>hikura@kaisei.org</email></para>
- </listitem>
-
- <listitem>
- <para>Hiroshi Nishikawa <email>nis@pluto.dti.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Hiroya Tsubakimoto <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Holger Veit <email>Holger.Veit@gmd.de</email></para>
- </listitem>
-
- <listitem>
- <para>Holm Tiffe <email>holm@geophysik.tu-freiberg.de</email></para>
- </listitem>
-
- <listitem>
- <para>Horance Chou
- <email>horance@freedom.ie.cycu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Horihiro Kumagai <email>kuma@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>HOTARU-YA <email>hotaru@tail.net</email></para>
- </listitem>
-
- <listitem>
- <para>Hr.Ladavac <email>lada@ws2301.gud.siemens.co.at</email></para>
- </listitem>
-
- <listitem>
- <para>Hubert Feyrer <email>hubertf@NetBSD.ORG</email></para>
- </listitem>
-
- <listitem>
- <para>Hugh F. Mahon <email>hugh@nsmdserv.cnd.hp.com</email></para>
- </listitem>
-
- <listitem>
- <para>Hugh Mahon <email>h_mahon@fc.hp.com</email></para>
- </listitem>
-
- <listitem>
- <para>Hung-Chi Chu <email>hcchu@r350.ee.ntu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>IMAI Takeshi <email>take-i@ceres.dti.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>IMAMURA Tomoaki
- <email>tomoak-i@is.aist-nara.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Ian Dowse <email>iedowse@maths.tcd.ie</email></para>
- </listitem>
-
- <listitem>
- <para>Ian Holland <email>ianh@tortuga.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Ian Struble <email>ian@broken.net</email></para>
- </listitem>
-
- <listitem>
- <para>Ian Vaudrey <email>i.vaudrey@bigfoot.com</email></para>
- </listitem>
-
- <listitem>
- <para>Igor Khasilev <email>igor@jabber.paco.odessa.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Igor Roshchin <email>str@giganda.komkon.org</email></para>
- </listitem>
-
- <listitem>
- <para>Igor Sviridov <email>siac@ua.net</email></para>
- </listitem>
-
- <listitem>
- <para>Igor Vinokurov <email>igor@zynaps.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Ikuo Nakagawa <email>ikuo@isl.intec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Ilya V. Komarov <email>mur@lynx.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Issei Suzuki <email>issei@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Itsuro Saito <email>saito@miv.t.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>J. Bryant <email>jbryant@argus.flash.net</email></para>
- </listitem>
-
- <listitem>
- <para>J. David Lowe <email>lowe@saturn5.com</email></para>
- </listitem>
-
- <listitem>
- <para>J. Han <email>hjh@best.com</email></para>
- </listitem>
-
- <listitem>
- <para>J. Hawk <email>jhawk@MIT.EDU</email></para>
- </listitem>
-
- <listitem>
- <para>J.T. Conklin <email>jtc@cygnus.com</email></para>
- </listitem>
-
- <listitem>
- <para>J.T. Jang <email>keith@email.gcn.net.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Jack <email>jack@zeus.xtalwind.net</email></para>
- </listitem>
-
- <listitem>
- <para>Jacob Bohn Lorensen <email>jacob@jblhome.ping.mk</email></para>
- </listitem>
-
- <listitem>
- <para>Jagane D Sundar <email>jagane@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jake Burkholder <email>jake@checker.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jake Hamby <email>jehamby@lightside.com</email></para>
- </listitem>
-
- <listitem>
- <para>James Clark <email>jjc@jclark.com</email></para>
- </listitem>
-
- <listitem>
- <para>James D. Stewart <email>jds@c4systm.com</email></para>
- </listitem>
-
- <listitem>
- <para>James Jegers <email>jimj@miller.cs.uwm.edu</email></para>
- </listitem>
-
- <listitem>
- <para>James Raynard
- <email>fhackers@jraynard.demon.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>James T. Liu <email>jtliu@phlebas.rockefeller.edu</email></para>
- </listitem>
-
- <listitem>
- <para>James da Silva <email>jds@cs.umd.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jan Conard
- <email>charly@fachschaften.tu-muenchen.de</email></para>
- </listitem>
-
- <listitem>
- <para>Jan Koum <email>jkb@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Janick Taillandier
- <email>Janick.Taillandier@ratp.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Janusz Kokot <email>janek@gaja.ipan.lublin.pl</email></para>
- </listitem>
-
- <listitem>
- <para>Jarle Greipsland <email>jarle@idt.unit.no</email></para>
- </listitem>
-
- <listitem>
- <para>Jason Garman <email>init@risen.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jason Thorpe <email>thorpej@NetBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jason Wright <email>jason@OpenBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jason Young
- <email>doogie@forbidden-donut.anet-stl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Javier Martin Rueda <email>jmrueda@diatel.upm.es</email></para>
- </listitem>
-
- <listitem>
- <para>Jay Fenlason <email>hack@datacube.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jaye Mathisen <email>mrcpu@cdsnet.net</email></para>
- </listitem>
-
- <listitem>
- <para>Jeff Bartig <email>jeffb@doit.wisc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jeff Forys <email>jeff@forys.cranbury.nj.us</email></para>
- </listitem>
-
- <listitem>
- <para>Jeff Kletsky <email>Jeff@Wagsky.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jeffrey Evans <email>evans@scnc.k12.mi.us</email></para>
- </listitem>
-
- <listitem>
- <para>Jeffrey Wheat <email>jeff@cetlink.net</email></para>
- </listitem>
-
- <listitem>
- <para>Jens Schweikhardt <email>schweikh@noc.dfn.d</email></para>
- </listitem>
-
- <listitem>
- <para>Jeremy Allison <email>jallison@whistle.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jeremy Chatfield <email>jdc@xinside.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jeremy Lea <email>reg@shale.csir.co.za</email></para>
- </listitem>
-
- <listitem>
- <para>Jeremy Prior <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Jeroen Ruigrok/Asmodai <email>asmodai@wxs.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Jesse Rosenstock <email>jmr@ugcs.caltech.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jian-Da Li <email>jdli@csie.nctu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Babb <email>babb@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Binkley <email>jrb@cs.pdx.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Carroll <email>jim@carroll.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Flowers <email>jflowers@ezo.net</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Leppek <email>jleppek@harris.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Lowe <email>james@cs.uwm.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Mattson <email>jmattson@sonic.net</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Mercer <email>jim@komodo.reptiles.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Wilson <email>wilson@moria.cygnus.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jimbo Bahooli
- <email>griffin@blackhole.iceworld.org</email></para>
- </listitem>
-
- <listitem>
- <para>Jin Guojun <email>jin@george.lbl.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Joachim Kuebart <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Joao Carlos Mendes Luis <email>jonny@jonny.eng.br</email></para>
- </listitem>
-
- <listitem>
- <para>Jochen Pohl <email>jpo.drs@sni.de</email></para>
- </listitem>
-
- <listitem>
- <para>Joe "Marcus" Clarke <email>marcus@miami.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Joe Abley <email>jabley@clear.co.nz</email></para>
- </listitem>
-
- <listitem>
- <para>Joe Jih-Shian Lu <email>jslu@dns.ntu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Joe Orthoefer <email>j_orthoefer@tia.net</email></para>
- </listitem>
-
- <listitem>
- <para>Joe Traister <email>traister@mojozone.org</email></para>
- </listitem>
-
- <listitem>
- <para>Joel Faedi <email>Joel.Faedi@esial.u-nancy.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Joel Ray Holveck <email>joelh@gnu.org</email></para>
- </listitem>
-
- <listitem>
- <para>Joel Sutton <email>sutton@aardvark.apana.org.au</email></para>
- </listitem>
-
- <listitem>
- <para>Johan Granlund <email>johan@granlund.nu</email></para>
- </listitem>
-
- <listitem>
- <para>Johan Karlsson <email>k@numeri.campus.luth.se</email></para>
- </listitem>
-
- <listitem>
- <para>Johan Larsson <email>johan@moon.campus.luth.se</email></para>
- </listitem>
-
- <listitem>
- <para>Johann Tonsing <email>jtonsing@mikom.csir.co.za</email></para>
- </listitem>
-
- <listitem>
- <para>Johannes Helander <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Johannes Stille <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>John Baldwin <email>jobaldwi@vt.edu</email></para>
- </listitem>
-
- <listitem>
- <para>John Beckett <email>jbeckett@southern.edu</email></para>
- </listitem>
-
- <listitem>
- <para>John Beukema <email>jbeukema@hk.super.net</email></para>
- </listitem>
-
- <listitem>
- <para>John Brezak <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>John Capo <email>jc@irbs.com</email></para>
- </listitem>
-
- <listitem>
- <para>John F. Woods <email>jfw@jfwhome.funhouse.com</email></para>
- </listitem>
-
- <listitem>
- <para>John Goerzen
- <email>jgoerzen@alexanderwohl.complete.org</email></para>
- </listitem>
-
- <listitem>
- <para>John Hay <email>jhay@mikom.csir.co.za</email></para>
- </listitem>
-
- <listitem>
- <para>John Heidemann <email>johnh@isi.edu</email></para>
- </listitem>
-
- <listitem>
- <para>John Hood <email>cgull@owl.org</email></para>
- </listitem>
-
- <listitem>
- <para>John Kohl <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>John Lind <email>john@starfire.mn.org</email></para>
- </listitem>
-
- <listitem>
- <para>John Mackin <email>john@physiol.su.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>John P <email>johnp@lodgenet.com</email></para>
- </listitem>
-
- <listitem>
- <para>John Perry <email>perry@vishnu.alias.net</email></para>
- </listitem>
-
- <listitem>
- <para>John Preisler <email>john@vapornet.com</email></para>
- </listitem>
-
- <listitem>
- <para>John Rochester <email>jr@cs.mun.ca</email></para>
- </listitem>
-
- <listitem>
- <para>John Sadler <email>john_sadler@alum.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>John Saunders <email>john@pacer.nlc.net.au</email></para>
- </listitem>
-
- <listitem>
- <para>John W. DeBoskey <email>jwd@unx.sas.com</email></para>
- </listitem>
-
- <listitem>
- <para>John Wehle <email>john@feith.com</email></para>
- </listitem>
-
- <listitem>
- <para>John Woods <email>jfw@eddie.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jon Morgan <email>morgan@terminus.trailblazer.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jonathan H N Chin <email>jc254@newton.cam.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Jonathan Hanna
- <email>jh@pc-21490.bc.rogers.wave.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Jorge Goncalves <email>j@bug.fe.up.pt</email></para>
- </listitem>
-
- <listitem>
- <para>Jorge M. Goncalves <email>ee96199@tom.fe.up.pt</email></para>
- </listitem>
-
- <listitem>
- <para>Jos Backus <email>jbackus@plex.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Jose M. Alcaide <email>jose@we.lc.ehu.es</email></para>
- </listitem>
-
- <listitem>
- <para>Jose Marques <email>jose@nobody.org</email></para>
- </listitem>
-
- <listitem>
- <para>Josef Grosch
- <email>jgrosch@superior.mooseriver.com</email></para>
- </listitem>
-
- <listitem>
- <para>Josef Karthauser <email>joe@uk.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Joseph Stein <email>joes@wstein.com</email></para>
- </listitem>
-
- <listitem>
- <para>Josh Gilliam <email>josh@quick.net</email></para>
- </listitem>
-
- <listitem>
- <para>Josh Tiefenbach <email>josh@ican.net</email></para>
- </listitem>
-
- <listitem>
- <para>Juergen Lock <email>nox@jelal.hb.north.de</email></para>
- </listitem>
-
- <listitem>
- <para>Juha Inkari <email>inkari@cc.hut.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Jukka A. Ukkonen <email>jua@iki.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Julian Assange <email>proff@suburbia.net</email></para>
- </listitem>
-
- <listitem>
- <para>Julian Coleman <email>j.d.coleman@ncl.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>&a.jhs</para>
- </listitem>
-
- <listitem>
- <para>Julian Jenkins <email>kaveman@magna.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Junichi Satoh <email>junichi@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Junji SAKAI <email>sakai@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Junya WATANABE <email>junya-w@remus.dti.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>K.Higashino <email>a00303@cc.hc.keio.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>KUNISHIMA Takeo <email>kunishi@c.oka-pu.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kai Vorma <email>vode@snakemail.hut.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Kaleb S. Keithley <email>kaleb@ics.com</email></para>
- </listitem>
-
- <listitem>
- <para>Kaneda Hiloshi <email>vanitas@ma3.seikyou.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kapil Chowksey <email>kchowksey@hss.hns.com</email></para>
- </listitem>
-
- <listitem>
- <para>Karl Denninger <email>karl@mcs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Karl Dietz <email>Karl.Dietz@triplan.com</email></para>
- </listitem>
-
- <listitem>
- <para>Karl Lehenbauer <email>karl@NeoSoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Kato Takenori
- <email>kato@eclogite.eps.nagoya-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kawanobe Koh <email>kawanobe@st.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kazuhiko Kiriyama <email>kiri@kiri.toba-cmt.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kazuo Horikawa <email>horikawa@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Kees Jan Koster <email>kjk1@ukc.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Keith Bostic <email>bostic@bostic.com</email></para>
- </listitem>
-
- <listitem>
- <para>Keith E. Walker <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Keith Moore <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Keith Sklower <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Kelly Yancey <email>kbyanc@posi.net</email></para>
- </listitem>
-
- <listitem>
- <para>Ken Hornstein <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Ken Key <email>key@cs.utk.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Ken Mayer <email>kmayer@freegate.com</email></para>
- </listitem>
-
- <listitem>
- <para>Kenji Saito <email>marukun@mx2.nisiq.net</email></para>
- </listitem>
-
- <listitem>
- <para>Kenji Tomita <email>tommyk@da2.so-net.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kenneth Furge <email>kenneth.furge@us.endress.com</email></para>
- </listitem>
-
- <listitem>
- <para>Kenneth Monville <email>desmo@bandwidth.org</email></para>
- </listitem>
-
- <listitem>
- <para>Kenneth R. Westerback <email>krw@tcn.net</email></para>
- </listitem>
-
- <listitem>
- <para>Kenneth Stailey <email>kstailey@gnu.ai.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Kent Talarico <email>kent@shipwreck.tsoft.net</email></para>
- </listitem>
-
- <listitem>
- <para>Kent Vander Velden <email>graphix@iastate.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Kentaro Inagaki <email>JBD01226@niftyserve.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Bracey <email>kbracey@art.acorn.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Day <email>toasty@dragondata.com</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Lahey <email>kml@nas.nasa.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Lo<email>kevlo@hello.com.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Street <email>street@iname.com</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Van Maren <email>vanmaren@fast.cs.utah.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Kiroh HARADA <email>kiroh@kh.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Klaus Klein <email>kleink@layla.inka.de</email></para>
- </listitem>
-
- <listitem>
- <para>Klaus-J. Wolf <email>Yanestra@t-online.de</email></para>
- </listitem>
-
- <listitem>
- <para>Koichi Sato <email>copan@ppp.fastnet.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kostya Lukin <email>lukin@okbmei.msk.su</email></para>
- </listitem>
-
- <listitem>
- <para>Kouichi Hirabayashi <email>kh@mogami-wire.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Kurt D. Zeilenga <email>Kurt@Boolean.NET</email></para>
- </listitem>
-
- <listitem>
- <para>Kurt Olsen <email>kurto@tiny.mcs.usu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>L. Jonas Olsson
- <email>ljo@ljo-slip.DIALIN.CWRU.Edu</email></para>
- </listitem>
-
- <listitem>
- <para>Lars K&ouml;ller
- <email>Lars.Koeller@Uni-Bielefeld.DE</email></para>
- </listitem>
-
- <listitem>
- <para>Larry Altneu <email>larry@ALR.COM</email></para>
- </listitem>
-
- <listitem>
- <para>Laurence Lopez <email>lopez@mv.mv.com</email></para>
- </listitem>
-
- <listitem>
- <para>Lee Cremeans <email>lcremean@tidalwave.net</email></para>
- </listitem>
-
- <listitem>
- <para>Liang Tai-hwa
- <email>avatar@www.mmlab.cse.yzu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Lon Willett <email>lon%softt.uucp@math.utah.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Louis A. Mamakos <email>louie@TransSys.COM</email></para>
- </listitem>
-
- <listitem>
- <para>Louis Mamakos <email>loiue@TransSys.com</email></para>
- </listitem>
-
- <listitem>
- <para>Lucas James <email>Lucas.James@ldjpc.apana.org.au</email></para>
- </listitem>
-
- <listitem>
- <para>Lyndon Nerenberg <email>lyndon@orthanc.com</email></para>
- </listitem>
-
- <listitem>
- <para>M.C. Wong <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>MANTANI Nobutaka <email>nobutaka@nobutaka.com</email></para>
- </listitem>
-
- <listitem>
- <para>MIHIRA Sanpei Yoshiro <email>sanpei@sanpei.org</email></para>
- </listitem>
-
- <listitem>
- <para>MITA Yoshio <email>mita@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>MITSUNAGA Noriaki
- <email>mitchy@er.ams.eng.osaka-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>MOROHOSHI Akihiko <email>moro@race.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Magnus Enbom <email>dot@tinto.campus.luth.se</email></para>
- </listitem>
-
- <listitem>
- <para>Mahesh Neelakanta <email>mahesh@gcomm.com</email></para>
- </listitem>
-
- <listitem>
- <para>Makoto MATSUSHITA <email>matusita@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Makoto WATANABE
- <email>watanabe@zlab.phys.nagoya-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Malte Lance <email>malte.lance@gmx.net</email></para>
- </listitem>
-
- <listitem>
- <para>Manu Iyengar
- <email>iyengar@grunthos.pscwa.psca.com</email></para>
- </listitem>
-
- <listitem>
- <para>Marc Frajola <email>marc@dev.com</email></para>
- </listitem>
-
- <listitem>
- <para>Marc Ramirez <email>mrami@mramirez.sy.yale.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Marc Slemko <email>marcs@znep.com</email></para>
- </listitem>
-
- <listitem>
- <para>Marc van Kempen <email>wmbfmk@urc.tue.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Marc van Woerkom <email>van.woerkom@netcologne.de</email></para>
- </listitem>
-
- <listitem>
- <para>Marcel Moolenaar <email>marcel@scc.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Mario Sergio Fujikawa Ferreira
- <email>lioux@gns.com.br</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Andrews <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Cammidge <email>mark@gmtunx.ee.uct.ac.za</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Diekhans <email>markd@grizzly.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Huizer <email>xaa@stack.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Mark J. Taylor <email>mtaylor@cybernet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Krentel <email>krentel@rice.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Mayo <email>markm@vmunix.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Thompson <email>thompson@tgsoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Tinguely <email>tinguely@plains.nodak.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Treacy <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Valentine <email>mark@linus.demon.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Martin Birgmeier</para>
- </listitem>
-
- <listitem>
- <para>Martin Ibert <email>mib@ppe.bb-data.de</email></para>
- </listitem>
-
- <listitem>
- <para>Martin Kammerhofer <email>dada@sbox.tu-graz.ac.at</email></para>
- </listitem>
-
- <listitem>
- <para>Martin Renters <email>martin@tdc.on.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Martti Kuparinen
- <email>martti.kuparinen@ericsson.com</email></para>
- </listitem>
-
- <listitem>
- <para>Masachika ISHIZUKA
- <email>ishizuka@isis.min.ntt.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Mas.TAKEMURA <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Masafumi NAKANE <email>max@wide.ad.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Masahiro Sekiguchi
- <email>seki@sysrap.cs.fujitsu.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Masanobu Saitoh <email>msaitoh@spa.is.uec.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Masanori Kanaoka <email>kana@saijo.mke.mei.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Masanori Kiriake <email>seiken@ARGV.AC</email></para>
- </listitem>
-
- <listitem>
- <para>Masatoshi TAMURA
- <email>tamrin@shinzan.kuee.kyoto-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Mats Lofkvist <email>mal@algonet.se</email></para>
- </listitem>
-
- <listitem>
- <para>Matt Bartley <email>mbartley@lear35.cytex.com</email></para>
- </listitem>
-
- <listitem>
- <para>Matt Thomas <email>matt@3am-software.com</email></para>
- </listitem>
-
- <listitem>
- <para>Matt White <email>mwhite+@CMU.EDU</email></para>
- </listitem>
-
- <listitem>
- <para>Matthew C. Mead <email>mmead@Glock.COM</email></para>
- </listitem>
-
- <listitem>
- <para>Matthew Cashdollar <email>mattc@rfcnet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Matthew Flatt <email>mflatt@cs.rice.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Matthew Fuller <email>fullermd@futuresouth.com</email></para>
- </listitem>
-
- <listitem>
- <para>Matthew Stein <email>matt@bdd.net</email></para>
- </listitem>
-
- <listitem>
- <para>Matthias Pfaller <email>leo@dachau.marco.de</email></para>
- </listitem>
-
- <listitem>
- <para>Matthias Scheler <email>tron@netbsd.org</email></para>
- </listitem>
-
- <listitem>
- <para>Mattias Gronlund
- <email>Mattias.Gronlund@sa.erisoft.se</email></para>
- </listitem>
-
- <listitem>
- <para>Mattias Pantzare <email>pantzer@ludd.luth.se</email></para>
- </listitem>
-
- <listitem>
- <para>Maurice Castro
- <email>maurice@planet.serc.rmit.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Max Euston <email>meuston@jmrodgers.com</email></para>
- </listitem>
-
- <listitem>
- <para>Max Khon <email>fjoe@husky.iclub.nsu.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Maxim Bolotin <email>max@rsu.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Maxim V. Sobolev <email>sobomax@altavista.net</email></para>
- </listitem>
-
- <listitem>
- <para>Micha Class
- <email>michael_class@hpbbse.bbn.hp.com</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Butler <email>imb@scgt.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Butschky <email>butsch@computi.erols.com</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Clay <email>mclay@weareb.org</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Elbel <email>me@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Galassi <email>nerd@percival.rain.com</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Hancock <email>michaelh@cet.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Hohmuth <email>hohmuth@inf.tu-dresden.de</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Perlman <email>canuck@caam.rice.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Petry <email>petry@netwolf.NetMasters.com</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Reifenberger <email>root@totum.plaut.de</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Sardo <email>jaeger16@yahoo.com</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Searle <email>searle@longacre.demon.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Michal Listos <email>mcl@Amnesiac.123.org</email></para>
- </listitem>
-
- <listitem>
- <para>Michio Karl Jinbo
- <email>karl@marcer.nagaokaut.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Miguel Angel Sagreras
- <email>msagre@cactus.fi.uba.ar</email></para>
- </listitem>
-
- <listitem>
- <para>Mihoko Tanaka <email>m_tonaka@pa.yokogawa.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Mika Nystrom <email>mika@cs.caltech.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mikael Hybsch <email>micke@dynas.se</email></para>
- </listitem>
-
- <listitem>
- <para>Mikael Karpberg
- <email>karpen@ocean.campus.luth.se</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Del <email>repenting@hotmail.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Durian <email>durian@plutotech.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Durkin <email>mdurkin@tsoft.sf-bay.org</email></para>
- </listitem>
-
- <listitem>
- <para>Mike E. Matsnev <email>mike@azog.cs.msu.su</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Evans <email>mevans@candle.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Grupenhoff <email>kashmir@umiacs.umd.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Hibler <email>mike@marker.cs.utah.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Karels <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Mike McGaughey <email>mmcg@cs.monash.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Meyer <email>mwm@shiva.the-park.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Mitchell <email>mitchell@ref.tfs.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Murphy <email>mrm@alpharel.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Peck <email>mike@binghamton.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Spengler <email>mks@msc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Mikhail A. Sokolov <email>mishania@demos.su</email></para>
- </listitem>
-
- <listitem>
- <para>Mikhail Teterin <email>mi@aldan.ziplink.net</email></para>
- </listitem>
-
- <listitem>
- <para>Ming-I Hseh <email>PA@FreeBSD.ee.Ntu.edu.TW</email></para>
- </listitem>
-
- <listitem>
- <para>Mitsuru IWASAKI <email>iwasaki@pc.jaring.my</email></para>
- </listitem>
-
- <listitem>
- <para>Mitsuru Yoshida <email>mitsuru@riken.go.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Monte Mitzelfelt <email>monte@gonefishing.org</email></para>
- </listitem>
-
- <listitem>
- <para>Morgan Davis <email>root@io.cts.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mostyn Lewis <email>mostyn@mrl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Motomichi Matsuzaki <email>mzaki@e-mail.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Motoyuki Kasahara <email>m-kasahr@sra.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Motoyuki Konno <email>motoyuki@snipe.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Murray Stokely <email>murray@cdrom.com</email></para>
- </listitem>
-
- <listitem>
- <para>N.G.Smith <email>ngs@sesame.hensa.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>NAGAO Tadaaki <email>nagao@cs.titech.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>NAKAJI Hiroyuki
- <email>nakaji@tutrp.tut.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>NAKAMURA Kazushi <email>nkazushi@highway.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>NAKAMURA Motonori
- <email>motonori@econ.kyoto-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>NIIMI Satoshi <email>sa2c@and.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>NOKUBI Hirotaka <email>h-nokubi@yyy.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Nadav Eiron <email>nadav@barcode.co.il</email></para>
- </listitem>
-
- <listitem>
- <para>Nanbor Wang <email>nw1@cs.wustl.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Naofumi Honda
- <email>honda@Kururu.math.sci.hokudai.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Naoki Hamada <email>nao@tom-yam.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Narvi <email>narvi@haldjas.folklore.ee</email></para>
- </listitem>
-
- <listitem>
- <para>Nathan Ahlstrom <email>nrahlstr@winternet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Nathan Dorfman <email>nathan@rtfm.net</email></para>
- </listitem>
-
- <listitem>
- <para>Neal Fachan <email>kneel@ishiboo.com</email></para>
- </listitem>
-
- <listitem>
- <para>Neil Blakey-Milner <email>nbm@rucus.ru.ac.za</email></para>
- </listitem>
-
- <listitem>
- <para>Niall Smart <email>rotel@indigo.ie</email></para>
- </listitem>
-
- <listitem>
- <para>Nick Barnes <email>Nick.Barnes@pobox.com</email></para>
- </listitem>
-
- <listitem>
- <para>Nick Handel <email>nhandel@NeoSoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Nick Hilliard <email>nick@foobar.org</email></para>
- </listitem>
-
- <listitem>
- <para>&a.nsayer;</para>
- </listitem>
-
- <listitem>
- <para>Nick Williams <email>njw@cs.city.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Nickolay N. Dudorov <email>nnd@itfs.nsk.su</email></para>
- </listitem>
-
- <listitem>
- <para>Niklas Hallqvist <email>niklas@filippa.appli.se</email></para>
- </listitem>
-
- <listitem>
- <para>Nisha Talagala <email>nisha@cs.berkeley.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>ZW6T-KND@j.asahi-net.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>adrian@virginia.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>alex@elvisti.kiev.ua</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>anto@netscape.net</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>bobson@egg.ics.nitch.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>bovynf@awe.be</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>burg@is.ge.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>chris@gnome.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>colsen@usa.net</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>coredump@nervosa.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>dannyman@arh0300.urh.uiuc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>davids@SECNET.COM</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>derek@free.org</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>devet@adv.IAEhv.nl</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>djv@bedford.net</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>dvv@sprint.net</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>enami@ba2.so-net.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>flash@eru.tubank.msk.su</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>flash@hway.ru</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>fn@pain.csrv.uidaho.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>gclarkii@netport.neosoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>gordon@sheaky.lonestar.org</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>graaf@iae.nl</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>greg@greg.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>grossman@cygnus.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>gusw@fub46.zedat.fu-berlin.de</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>hfir@math.rochester.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>hnokubi@yyy.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>iaint@css.tuu.utas.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>invis@visi.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>ishisone@sra.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>iverson@lionheart.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>jpt@magic.net</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>junker@jazz.snu.ac.kr</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>k-sugyou@ccs.mt.nec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>kenji@reseau.toyonaka.osaka.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>kfurge@worldnet.att.net</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>lh@aus.org</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>lhecking@nmrc.ucc.ie</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>mrgreen@mame.mu.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>nakagawa@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>ohki@gssm.otsuka.tsukuba.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>owaki@st.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>pechter@shell.monmouth.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>pete@pelican.pelican.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>pritc003@maroon.tc.umn.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>risner@stdio.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>roman@rpd.univ.kiev.ua</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>root@ns2.redline.ru</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>root@uglabgw.ug.cs.sunysb.edu</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>stephen.ma@jtec.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>sumii@is.s.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>takas-su@is.aist-nara.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>tamone@eig.unige.ch</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>tjevans@raleigh.ibm.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>tony-o@iij.ad.jp amurai@spec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>torii@tcd.hitachi.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>uenami@imasy.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>uhlar@netlab.sk</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>vode@hut.fi</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>wlloyd@mpd.ca</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>wlr@furball.wellsfargo.com</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>wmbfmk@urc.tue.nl</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>yamagata@nwgpc.kek.jp</email></para>
- </listitem>
-
- <listitem>
- <para>No Name <email>ziggy@ryan.org</email></para>
- </listitem>
-
- <listitem>
- <para>Nobuhiro Yasutomi <email>nobu@psrc.isac.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Nobuyuki Koganemaru
- <email>kogane@koganemaru.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Norio Suzuki <email>nosuzuki@e-mail.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Noritaka Ishizumi <email>graphite@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Noriyuki Soda <email>soda@sra.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Oh Junseon <email>hollywar@mail.holywar.net</email></para>
- </listitem>
-
- <listitem>
- <para>Olaf Wagner <email>wagner@luthien.in-berlin.de</email></para>
- </listitem>
-
- <listitem>
- <para>Oleg Sharoiko <email>os@rsu.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Oleg V. Volkov <email>rover@lglobus.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Oliver Breuninger <email>ob@seicom.NET</email></para>
- </listitem>
-
- <listitem>
- <para>Oliver Friedrichs <email>oliver@secnet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Oliver Fromme
- <email>oliver.fromme@heim3.tu-clausthal.de</email></para>
- </listitem>
-
- <listitem>
- <para>Oliver Laumann
- <email>net@informatik.uni-bremen.de</email></para>
- </listitem>
-
- <listitem>
- <para>Oliver Oberdorf <email>oly@world.std.com</email></para>
- </listitem>
-
- <listitem>
- <para>Olof Johansson <email>offe@ludd.luth.se</email></para>
- </listitem>
-
- <listitem>
- <para>Osokin Sergey aka oZZ <email>ozz@FreeBSD.org.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Pace Willisson <email>pace@blitz.com</email></para>
- </listitem>
-
- <listitem>
- <para>Paco Rosich <email>rosich@modico.eleinf.uv.es</email></para>
- </listitem>
-
- <listitem>
- <para>Palle Girgensohn <email>girgen@partitur.se</email></para>
- </listitem>
-
- <listitem>
- <para>Parag Patel <email>parag@cgt.com</email></para>
- </listitem>
-
- <listitem>
- <para>Pascal Pederiva <email>pascal@zuo.dec.com</email></para>
- </listitem>
-
- <listitem>
- <para>Pasvorn Boonmark <email>boonmark@juniper.net</email></para>
- </listitem>
-
- <listitem>
- <para>Patrick Gardella <email>patrick@cre8tivegroup.com</email></para>
- </listitem>
-
- <listitem>
- <para>Patrick Hausen <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Antonov <email>apg@demos.su</email></para>
- </listitem>
-
- <listitem>
- <para>Paul F. Werkowski <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Fox <email>pgf@foxharp.boston.ma.us</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Koch <email>koch@thehub.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Kranenburg <email>pk@NetBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Mackerras <email>paulus@cs.anu.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Popelka <email>paulp@uts.amdahl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Paul S. LaFollette, Jr. <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Saab <email>paul@mu.org</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Sandys <email>myj@nyct.net</email></para>
- </listitem>
-
- <listitem>
- <para>Paul T. Root <email>proot@horton.iaces.com</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Vixie <email>paul@vix.com</email></para>
- </listitem>
-
- <listitem>
- <para>Paulo Menezes <email>paulo@isr.uc.pt</email></para>
- </listitem>
-
- <listitem>
- <para>Paulo Menezes <email>pm@dee.uc.pt</email></para>
- </listitem>
-
- <listitem>
- <para>Pedro A M Vazquez <email>vazquez@IQM.Unicamp.BR</email></para>
- </listitem>
-
- <listitem>
- <para>Pedro Giffuni <email>giffunip@asme.org</email></para>
- </listitem>
-
- <listitem>
- <para>Pete Bentley <email>pete@demon.net</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Childs <email>pjchilds@imforei.apana.org.au</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Cornelius <email>pc@inr.fzk.de</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Haight <email>peterh@prognet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Jeremy <email>perer.jeremy@alcatel.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Peter M. Chen <email>pmchen@eecs.umich.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Much <email>peter@citylink.dinoex.sub.org</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Olsson <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Philipp <email>pjp@bsd-daemon.net</email></para>
- </listitem>
-
- <listitem>
- <para>Peter Stubbs <email>PETERS@staidan.qld.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Phil Maker <email>pjm@cs.ntu.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Phil Sutherland
- <email>philsuth@mycroft.dialix.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Phil Taylor <email>phil@zipmail.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Philip Musumeci <email>philip@rmit.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Pierre Y. Dampure <email>pierre.dampure@k2c.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Pius Fischer <email>pius@ienet.com</email></para>
- </listitem>
-
- <listitem>
- <para>Pomegranate <email>daver@flag.blackened.net</email></para>
- </listitem>
-
- <listitem>
- <para>Powerdog Industries
- <email>kevin.ruddy@powerdog.com</email></para>
- </listitem>
-
- <listitem>
- <para>R. Kym Horsell</para>
- </listitem>
-
- <listitem>
- <para>Rajesh Vaidheeswarran <email>rv@fore.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ralf Friedl <email>friedl@informatik.uni-kl.de</email></para>
- </listitem>
-
- <listitem>
- <para>Randal S. Masutani <email>randal@comtest.com</email></para>
- </listitem>
-
- <listitem>
- <para>Randall Hopper <email>rhh@ct.picker.com</email></para>
- </listitem>
-
- <listitem>
- <para>Randall W. Dean <email>rwd@osf.org</email></para>
- </listitem>
-
- <listitem>
- <para>Randy Bush <email>rbush@bainbridge.verio.net</email></para>
- </listitem>
-
- <listitem>
- <para>Reinier Bezuidenhout
- <email>rbezuide@mikom.csir.co.za</email></para>
- </listitem>
-
- <listitem>
- <para>Remy Card <email>Remy.Card@masi.ibp.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Ricardas Cepas <email>rch@richard.eu.org</email></para>
- </listitem>
-
- <listitem>
- <para>Riccardo Veraldi <email>veraldi@cs.unibo.it</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Henderson <email>richard@atheist.tamu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Hwang <email>rhwang@bigpanda.com</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Kiss <email>richard@homemail.com</email></para>
- </listitem>
-
- <listitem>
- <para>Richard J Kuhns <email>rjk@watson.grauel.com</email></para>
- </listitem>
-
- <listitem>
- <para>Richard M. Neswold
- <email>rneswold@drmemory.fnal.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Seaman, Jr. <email>dick@tar.com</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Stallman <email>rms@gnu.ai.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Straka <email>straka@user1.inficad.com</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Tobin <email>richard@cogsci.ed.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Wackerbarth <email>rkw@Dataplex.NET</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Winkel <email>rich@math.missouri.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Richard Wiwatowski <email>rjwiwat@adelaide.on.net</email></para>
- </listitem>
-
- <listitem>
- <para>Rick Macklem <email>rick@snowhite.cis.uoguelph.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Rick Macklin <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Rob Austein <email>sra@epilogue.com</email></para>
- </listitem>
-
- <listitem>
- <para>Rob Mallory <email>rmallory@qualcomm.com</email></para>
- </listitem>
-
- <listitem>
- <para>Rob Snow <email>rsnow@txdirect.net</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Crowe <email>bob@speakez.com</email></para>
- </listitem>
-
- <listitem>
- <para>Robert D. Thrush <email>rd@phoenix.aii.com</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Eckardt
- <email>roberte@MEP.Ruhr-Uni-Bochum.de</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Sanders <email>rsanders@mindspring.com</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Sexton <email>robert@kudra.com</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Shady <email>rls@id.net</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Swindells <email>swindellsr@genrad.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Watson <email>robert@cyrus.watson.org</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Withrow <email>witr@rwwa.com</email></para>
- </listitem>
-
- <listitem>
- <para>Robert Yoder <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Robin Carey
- <email>robin@mailgate.dtc.rankxerox.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Roger Hardiman <email>roger@cs.strath.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Roland Jesse <email>jesse@cs.uni-magdeburg.de</email></para>
- </listitem>
-
- <listitem>
- <para>Ron Bickers <email>rbickers@intercenter.net</email></para>
- </listitem>
-
- <listitem>
- <para>Ron Lenk <email>rlenk@widget.xmission.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ronald Kuehn <email>kuehn@rz.tu-clausthal.de</email></para>
- </listitem>
-
- <listitem>
- <para>Rudolf Cejka <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Ruslan Belkin <email>rus@home2.UA.net</email></para>
- </listitem>
-
- <listitem>
- <para>Ruslan Ermilov <email>ru@ucb.crimea.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Ruslan Shevchenko <email>rssh@cam.grad.kiev.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Russell L. Carter <email>rcarter@pinyon.org</email></para>
- </listitem>
-
- <listitem>
- <para>Russell Vincent <email>rv@groa.uct.ac.za</email></para>
- </listitem>
-
- <listitem>
- <para>Ryan Younce <email>ryany@pobox.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ryuichiro IMURA <email>imura@cs.titech.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>SANETO Takanori <email>sanewo@strg.sony.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>SAWADA Mizuki <email>miz@qb3.so-net.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>SUGIMURA Takashi <email>sugimura@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>SURANYI Peter
- <email>suranyip@jks.is.tsukuba.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Sakai Hiroaki <email>sakai@miya.ee.kagu.sut.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Sakari Jalovaara <email>sja@tekla.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Sam Hartman <email>hartmans@mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Samuel Lam <email>skl@ScalableNetwork.com</email></para>
- </listitem>
-
- <listitem>
- <para>Samuele Zannoli <email>zannoli@cs.unibo.it</email></para>
- </listitem>
-
- <listitem>
- <para>Sander Vesik <email>sander@haldjas.folklore.ee</email></para>
- </listitem>
-
- <listitem>
- <para>Sandro Sigala <email>ssigala@globalnet.it</email></para>
- </listitem>
-
- <listitem>
- <para>Sascha Blank <email>blank@fox.uni-trier.de</email></para>
- </listitem>
-
- <listitem>
- <para>Sascha Wildner <email>swildner@channelz.GUN.de</email></para>
- </listitem>
-
- <listitem>
- <para>Satoh Junichi <email>junichi@astec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Scot Elliott <email>scot@poptart.org</email></para>
- </listitem>
-
- <listitem>
- <para>Scot W. Hetzel <email>hetzels@westbend.net</email></para>
- </listitem>
-
- <listitem>
- <para>Scott A. Kenney <email>saken@rmta.ml.org</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Blachowicz
- <email>scott.blachowicz@seaslug.org</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Burris <email>scott@pita.cns.ucla.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Hazen Mueller <email>scott@zorch.sf-bay.org</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Michel <email>scottm@cs.ucla.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Mitchel <email>scott@uk.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Reynolds <email>scott@clmqt.marquette.mi.us</email></para>
- </listitem>
-
- <listitem>
- <para>Sebastian Strollo <email>seb@erix.ericsson.se</email></para>
- </listitem>
-
- <listitem>
- <para>Serge A. Babkin <email>babkin@hq.icb.chel.su</email></para>
- </listitem>
-
- <listitem>
- <para>Serge V. Vakulenko <email>vak@zebub.msk.su</email></para>
- </listitem>
-
- <listitem>
- <para>Sergei Chechetkin
- <email>csl@whale.sunbay.crimea.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Sergei S. Laskavy <email>laskavy@pc759.cs.msu.su</email></para>
- </listitem>
-
- <listitem>
- <para>Sergey Gershtein <email>sg@mplik.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Sergey Kosyakov <email>ks@itp.ac.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Sergey Potapov <email>sp@alkor.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Sergey Shkonda <email>serg@bcs.zp.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Sergey V.Dorokhov <email>svd@kbtelecom.nalnet.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Sergio Lenzi <email>lenzi@bsi.com.br</email></para>
- </listitem>
-
- <listitem>
- <para>Shaun Courtney <email>shaun@emma.eng.uct.ac.za</email></para>
- </listitem>
-
- <listitem>
- <para>Shawn M. Carey <email>smcarey@mailbox.syr.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Shigio Yamaguchi <email>shigio@tamacom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Shinya Esu <email>esu@yk.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Shuichi Tanaka <email>stanaka@bb.mbn.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Shunsuke Akiyama <email>akiyama@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Simon <email>simon@masi.ibp.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Simon Burge <email>simonb@telstra.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Simon J Gerraty <email>sjg@melb.bull.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Simon Marlow <email>simonm@dcs.gla.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Simon Shapiro <email>shimon@simon-shapiro.org</email></para>
- </listitem>
-
- <listitem>
- <para>Sin'ichiro MIYATANI <email>siu@phaseone.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Slaven Rezic <email>eserte@cs.tu-berlin.de</email></para>
- </listitem>
-
- <listitem>
- <para>Soochon Radee <email>slr@mitre.org</email></para>
- </listitem>
-
- <listitem>
- <para>Soren Dayton <email>csdayton@midway.uchicago.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Soren Dossing <email>sauber@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Soren S. Jorvang <email>soren@dt.dk</email></para>
- </listitem>
-
- <listitem>
- <para>Stefan Bethke <email>stb@hanse.de</email></para>
- </listitem>
-
- <listitem>
- <para>Stefan Eggers <email>seggers@semyam.dinoco.de</email></para>
- </listitem>
-
- <listitem>
- <para>Stefan Moeding <email>s.moeding@ndh.net</email></para>
- </listitem>
-
- <listitem>
- <para>Stefan Petri <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Stefan `Sec` Zehl <email>sec@42.org</email></para>
- </listitem>
-
- <listitem>
- <para>Steinar Haug <email>sthaug@nethelp.no</email></para>
- </listitem>
-
- <listitem>
- <para>Stephane E. Potvin <email>sepotvin@videotron.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Stephane Legrand <email>stephane@lituus.fr</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen Clawson
- <email>sclawson@marker.cs.utah.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen F. Combs <email>combssf@salem.ge.com</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen Farrell <email>stephen@farrell.org</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen Hocking <email>sysseh@devetir.qld.gov.au</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen J. Roznowski <email>sjr@home.net</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen McKay <email>syssgm@devetir.qld.gov.au</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen Melvin <email>melvin@zytek.com</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Bauer <email>sbauer@rock.sdsmt.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Coltrin <email>spcoltri@io.com</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Deering <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Gerakines <email>steve2@genesis.tiac.net</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Gericke <email>steveg@comtrol.com</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Piette <email>steve@simon.chi.il.US</email></para>
- </listitem>
-
- <listitem>
- <para>Steve Schwarz <email>schwarz@alpharel.com</email></para>
- </listitem>
-
- <listitem>
- <para>Steven G. Kargl
- <email>kargl@troutmask.apl.washington.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Steven H. Samorodin <email>samorodi@NUXI.com</email></para>
- </listitem>
-
- <listitem>
- <para>Steven McCanne <email>mccanne@cs.berkeley.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Steven Plite <email>splite@purdue.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Steven Wallace <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Stuart Henderson
- <email>stuart@internationalschool.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Sue Blake <email>sue@welearn.com.au</email></para>
- </listitem>
-
- <listitem>
- <para>Sugimoto Sadahiro <email>ixtl@komaba.utmc.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Sugiura Shiro <email>ssugiura@duo.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Sujal Patel <email>smpatel@wam.umd.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Sune Stjerneby <email>stjerneby@usa.net</email></para>
- </listitem>
-
- <listitem>
- <para>Suzuki Yoshiaki
- <email>zensyo@ann.tama.kawasaki.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Tadashi Kumano <email>kumano@strl.nhk.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Taguchi Takeshi <email>taguchi@tohoku.iij.ad.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takahiro Yugawa <email>yugawa@orleans.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takanori Watanabe
- <email>takawata@shidahara1.planet.sci.kobe-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takashi Mega <email>mega@minz.org</email></para>
- </listitem>
-
- <listitem>
- <para>Takashi Uozu <email>j1594016@ed.kagu.sut.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takayuki Ariga <email>a00821@cc.hc.keio.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takeru NAIKI <email>naiki@bfd.es.hokudai.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takeshi Amaike <email>amaike@iri.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takeshi MUTOH <email>mutoh@info.nara-k.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takeshi Ohashi
- <email>ohashi@mickey.ai.kyutech.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takeshi WATANABE
- <email>watanabe@crayon.earth.s.kobe-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Takuya SHIOZAKI
- <email>tshiozak@makino.ise.chuo-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Tatoku Ogaito <email>tacha@tera.fukui-med.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Tatsumi HOSOKAWA <email>hosokawa@jp.FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Ted Buswell <email>tbuswell@mediaone.net</email></para>
- </listitem>
-
- <listitem>
- <para>Ted Faber <email>faber@isi.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Ted Lemon <email>mellon@isc.org</email></para>
- </listitem>
-
- <listitem>
- <para>Terry Lambert <email>terry@lambert.org</email></para>
- </listitem>
-
- <listitem>
- <para>Terry Lee <email>terry@uivlsi.csl.uiuc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Tetsuya Furukawa <email>tetsuya@secom-sis.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Theo de Raadt <email>deraadt@OpenBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas <email>thomas@mathematik.uni-Bremen.de</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas D. Dean <email>tomdean@ix.netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas David Rivers <email>rivers@dignus.com</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas G. McWilliams <email>tgm@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas Gellekum
- <email>thomas@ghpc8.ihf.rwth-aachen.de</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas Graichen
- <email>graichen@omega.physik.fu-berlin.de</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas K&ouml;nig
- <email>Thomas.Koenig@ciw.uni-karlsruhe.de</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas Ptacek <email>unknown</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas A. Stephens <email>tas@stephens.org</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas Stromberg <email>tstrombe@rtci.com</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas Valentino Crimi
- <email>tcrimi+@andrew.cmu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Thomas Wintergerst <email>thomas@lemur.nord.de</email></para>
- </listitem>
-
- <listitem>
- <para>&THORN;&oacute;r&eth;ur &Iacute;varsson
- <email>totii@est.is</email></para>
- </listitem>
-
- <listitem>
- <para>Tim Kientzle <email>kientzle@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Tim Singletary
- <email>tsingle@sunland.gsfc.nasa.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Tim Wilkinson <email>tim@sarc.city.ac.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Timo J. Rinne <email>tri@iki.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Todd Miller <email>millert@openbsd.org</email></para>
- </listitem>
-
- <listitem>
- <para>Tom <email>root@majestix.cmr.no</email></para>
- </listitem>
-
- <listitem>
- <para>Tom <email>tom@sdf.com</email></para>
- </listitem>
-
- <listitem>
- <para>Tom Gray - DCA <email>dcasba@rain.org</email></para>
- </listitem>
-
- <listitem>
- <para>Tom Jobbins <email>tom@tom.tj</email></para>
- </listitem>
-
- <listitem>
- <para>Tom Pusateri <email>pusateri@juniper.net</email></para>
- </listitem>
-
- <listitem>
- <para>Tom Rush <email>tarush@mindspring.com</email></para>
- </listitem>
-
- <listitem>
- <para>Tom Samplonius <email>tom@misery.sdf.com</email></para>
- </listitem>
-
- <listitem>
- <para>Tomohiko Kurahashi
- <email>kura@melchior.q.t.u-tokyo.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Tony Kimball <email>alk@Think.COM</email></para>
- </listitem>
-
- <listitem>
- <para>Tony Li <email>tli@jnx.com</email></para>
- </listitem>
-
- <listitem>
- <para>Tony Lynn <email>wing@cc.nsysu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Tony Maher <email>tonym@angis.org.au</email></para>
- </listitem>
-
- <listitem>
- <para>Torbjorn Granlund <email>tege@matematik.su.se</email></para>
- </listitem>
-
- <listitem>
- <para>Toshihiko ARAI <email>toshi@tenchi.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Toshihiko SHIMOKAWA <email>toshi@tea.forus.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Toshihiro Kanda <email>candy@kgc.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Toshiomi Moriki
- <email>Toshiomi.Moriki@ma1.seikyou.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Trefor S. <email>trefor@flevel.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Trevor Blackwell <email>tlb@viaweb.com</email></para>
- </listitem>
-
- <listitem>
- <para>URATA Shuichiro <email>s-urata@nmit.tmg.nec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Udo Schweigert <email>ust@cert.siemens.de</email></para>
- </listitem>
-
- <listitem>
- <para>Ugo Paternostro <email>paterno@dsi.unifi.it</email></para>
- </listitem>
-
- <listitem>
- <para>Ulf Kieber <email>kieber@sax.de</email></para>
- </listitem>
-
- <listitem>
- <para>Ulli Linzen <email>ulli@perceval.camelot.de</email></para>
- </listitem>
-
- <listitem>
- <para>Ustimenko Semen <email>semen@iclub.nsu.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Uwe Arndt <email>arndt@mailhost.uni-koblenz.de</email></para>
- </listitem>
-
- <listitem>
- <para>Vadim Chekan <email>vadim@gc.lviv.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Vadim Kolontsov <email>vadim@tversu.ac.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Vadim Mikhailov <email>mvp@braz.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Van Jacobson <email>van@ee.lbl.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Vasily V. Grechishnikov
- <email>bazilio@ns1.ied-vorstu.ac.ru</email></para>
- </listitem>
-
- <listitem>
- <para>Vasim Valejev <email>vasim@uddias.diaspro.com</email></para>
- </listitem>
-
- <listitem>
- <para>Vernon J. Schryver <email>vjs@mica.denver.sgi.com</email></para>
- </listitem>
-
- <listitem>
- <para>Vic Abell <email>abe@cc.purdue.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Ville Eerola <email>ve@sci.fi</email></para>
- </listitem>
-
- <listitem>
- <para>Vincent Poy <email>vince@venus.gaianet.net</email></para>
- </listitem>
-
- <listitem>
- <para>Vincenzo Capuano
- <email>VCAPUANO@vmprofs.esoc.esa.de</email></para>
- </listitem>
-
- <listitem>
- <para>Virgil Champlin <email>champlin@pa.dec.com</email></para>
- </listitem>
-
- <listitem>
- <para>Vladimir A. Jakovenko
- <email>vovik@ntu-kpi.kiev.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Vladimir Kushnir <email>kushn@mail.kar.net</email></para>
- </listitem>
-
- <listitem>
- <para>Vsevolod Lobko <email>seva@alex-ua.com</email></para>
- </listitem>
-
- <listitem>
- <para>W. Gerald Hicks <email>wghicks@bellsouth.net</email></para>
- </listitem>
-
- <listitem>
- <para>W. Richard Stevens <email>rstevens@noao.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Walt Howard <email>howard@ee.utah.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Warren Toomey <email>wkt@csadfa.cs.adfa.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Wayne Scott <email>wscott@ichips.intel.com</email></para>
- </listitem>
-
- <listitem>
- <para>Werner Griessl
- <email>werner@btp1da.phy.uni-bayreuth.de</email></para>
- </listitem>
-
- <listitem>
- <para>Wes Santee <email>wsantee@wsantee.oz.net</email></para>
- </listitem>
-
- <listitem>
- <para>Wietse Venema <email>wietse@wzv.win.tue.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Wilfredo Sanchez <email>wsanchez@apple.com</email></para>
- </listitem>
-
- <listitem>
- <para>Wiljo Heinen <email>wiljo@freeside.ki.open.de</email></para>
- </listitem>
-
- <listitem>
- <para>Wilko Bulte <email>wilko@yedi.iaf.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Will Andrews <email>andrews@technologist.com</email></para>
- </listitem>
-
- <listitem>
- <para>Willem Jan Withagen <email>wjw@surf.IAE.nl</email></para>
- </listitem>
-
- <listitem>
- <para>William Jolitz <email>withheld</email></para>
- </listitem>
-
- <listitem>
- <para>William Liao <email>william@tale.net</email></para>
- </listitem>
-
- <listitem>
- <para>Wojtek Pilorz
- <email>wpilorz@celebris.bdk.lublin.pl</email></para>
- </listitem>
-
- <listitem>
- <para>Wolfgang Helbig <email>helbig@ba-stuttgart.de</email></para>
- </listitem>
-
- <listitem>
- <para>Wolfgang Solfrank <email>ws@tools.de</email></para>
- </listitem>
-
- <listitem>
- <para>Wolfgang Stanglmeier <email>wolf@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Wu Ching-hong <email>woju@FreeBSD.ee.Ntu.edu.TW</email></para>
- </listitem>
-
- <listitem>
- <para>Yarema <email>yds@ingress.com</email></para>
- </listitem>
-
- <listitem>
- <para>Yaroslav Terletsky <email>ts@polynet.lviv.ua</email></para>
- </listitem>
-
- <listitem>
- <para>Yasuhito FUTATSUKI <email>futatuki@fureai.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yasuhiro Fukama <email>yasuf@big.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yen-Shuo Su <email>yssu@CCCA.NCTU.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Ying-Chieh Liao <email>ijliao@csie.NCTU.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>Yixin Jin <email>yjin@rain.cs.ucla.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Yoshiaki Uchikawa <email>yoshiaki@kt.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yoshihiko OHTA <email>yohta@bres.tsukuba.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yoshihisa NAKAGAWA
- <email>y-nakaga@ccs.mt.nec.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yoshikazu Goto <email>gotoh@ae.anritsu.co.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yoshimasa Ohnishi
- <email>ohnishi@isc.kyutech.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yoshishige Arai <email>ryo2@on.rim.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yuichi MATSUTAKA <email>matutaka@osa.att.ne.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yujiro MIYATA
- <email>miyata@bioele.nuee.nagoya-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yukihiro Nakai <email>nacai@iname.com</email></para>
- </listitem>
-
- <listitem>
- <para>Yusuke Nawano <email>azuki@azkey.org</email></para>
- </listitem>
-
- <listitem>
- <para>Yuu Yashiki <email>s974123@cc.matsuyama-u.ac.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Yuval Yarom <email>yval@cs.huji.ac.il</email></para>
- </listitem>
-
- <listitem>
- <para>Yves Fonk <email>yves@cpcoup5.tn.tudelft.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Yves Fonk <email>yves@dutncp8.tn.tudelft.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Zach Heilig <email>zach@gaffaneys.com</email></para>
- </listitem>
-
- <listitem>
- <para>Zahemszhky Gabor <email>zgabor@code.hu</email></para>
- </listitem>
-
- <listitem>
- <para>Zhong Ming-Xun <email>zmx@mail.CDPA.nsysu.edu.tw</email></para>
- </listitem>
-
- <listitem>
- <para>arci <email>vega@sophia.inria.fr</email></para>
- </listitem>
-
- <listitem>
- <para>der Mouse <email>mouse@Collatz.McRCIM.McGill.EDU</email></para>
- </listitem>
-
- <listitem>
- <para>frf <email>frf@xocolatl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Ege Rekk <email>aagero@aage.priv.no</email></para>
- </listitem>
- </itemizedlist>
- </sect1>
-
- <sect1>
- <title>386BSD Patch Kit Patch Contributors</title>
-
- <para>(in alphabetical order by first name):</para>
-
- <itemizedlist>
- <listitem>
- <para>Adam Glass <email>glass@postgres.berkeley.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Adrian Hall <email>adrian@ibmpcug.co.uk</email></para>
- </listitem>
-
- <listitem>
- <para>Andrey A. Chernov <email>ache@astral.msk.su</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Herbert <email>andrew@werple.apana.org.au</email></para>
- </listitem>
-
- <listitem>
- <para>Andrew Moore <email>alm@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Andy Valencia <email>ajv@csd.mot.com</email>
- <email>jtk@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Arne Henrik Juul <email>arnej@Lise.Unit.NO</email></para>
- </listitem>
-
- <listitem>
- <para>Bakul Shah <email>bvs@bitblocks.com</email></para>
- </listitem>
-
- <listitem>
- <para>Barry Lustig <email>barry@ictv.com</email></para>
- </listitem>
-
- <listitem>
- <para>Bob Wilcox <email>bob@obiwan.uucp</email></para>
- </listitem>
-
- <listitem>
- <para>Branko Lankester</para>
- </listitem>
-
- <listitem>
- <para>Brett Lymn <email>blymn@mulga.awadi.com.AU</email></para>
- </listitem>
-
- <listitem>
- <para>Charles Hannum <email>mycroft@ai.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Chris G. Demetriou
- <email>cgd@postgres.berkeley.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Chris Torek <email>torek@ee.lbl.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Christoph Robitschko
- <email>chmr@edvz.tu-graz.ac.at</email></para>
- </listitem>
-
- <listitem>
- <para>Daniel Poirot <email>poirot@aio.jsc.nasa.gov</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Burgess <email>burgess@hrd769.brooks.af.mil</email></para>
- </listitem>
-
- <listitem>
- <para>Dave Rivers <email>rivers@ponds.uucp</email></para>
- </listitem>
-
- <listitem>
- <para>David Dawes <email>dawes@physics.su.OZ.AU</email></para>
- </listitem>
-
- <listitem>
- <para>David Greenman <email>dg@Root.COM</email></para>
- </listitem>
-
- <listitem>
- <para>Eric J. Haug <email>ejh@slustl.slu.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Felix Gaehtgens
- <email>felix@escape.vsse.in-berlin.de</email></para>
- </listitem>
-
- <listitem>
- <para>Frank Maclachlan <email>fpm@crash.cts.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gary A. Browning <email>gab10@griffcd.amdahl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Gary Howland <email>gary@hotlava.com</email></para>
- </listitem>
-
- <listitem>
- <para>Geoff Rehmet <email>csgr@alpha.ru.ac.za</email></para>
- </listitem>
-
- <listitem>
- <para>Goran Hammarback <email>goran@astro.uu.se</email></para>
- </listitem>
-
- <listitem>
- <para>Guido van Rooij <email>guido@gvr.org</email></para>
- </listitem>
-
- <listitem>
- <para>Guy Harris <email>guy@auspex.com</email></para>
- </listitem>
-
- <listitem>
- <para>Havard Eidnes
- <email>Havard.Eidnes@runit.sintef.no</email></para>
- </listitem>
-
- <listitem>
- <para>Herb Peyerl <email>hpeyerl@novatel.cuc.ab.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Holger Veit <email>Holger.Veit@gmd.de</email></para>
- </listitem>
-
- <listitem>
- <para>Ishii Masahiro, R. Kym Horsell</para>
- </listitem>
-
- <listitem>
- <para>J.T. Conklin <email>jtc@cygnus.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jagane D Sundar <email>jagane@netcom.com</email></para>
- </listitem>
-
- <listitem>
- <para>James Clark <email>jjc@jclark.com</email></para>
- </listitem>
-
- <listitem>
- <para>James Jegers <email>jimj@miller.cs.uwm.edu</email></para>
- </listitem>
-
- <listitem>
- <para>James W. Dolter</para>
- </listitem>
-
- <listitem>
- <para>James da Silva <email>jds@cs.umd.edu</email> et al</para>
- </listitem>
-
- <listitem>
- <para>Jay Fenlason <email>hack@datacube.com</email></para>
- </listitem>
-
- <listitem>
- <para>Jim Wilson <email>wilson@moria.cygnus.com</email></para>
- </listitem>
-
- <listitem>
- <para>J&ouml;rg Lohse
- <email>lohse@tech7.informatik.uni-hamburg.de</email></para>
- </listitem>
-
- <listitem>
- <para>J&ouml;rg Wunsch
- <email>joerg_wunsch@uriah.heep.sax.de</email></para>
- </listitem>
-
- <listitem>
- <para>John Dyson</para>
- </listitem>
-
- <listitem>
- <para>John Woods <email>jfw@eddie.mit.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Jordan K. Hubbard <email>jkh@whisker.hubbard.ie</email></para>
- </listitem>
-
- <listitem>
- <para>Julian Elischer <email>julian@dialix.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Julian Stacey <email>jhs@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Karl Dietz <email>Karl.Dietz@triplan.com</email></para>
- </listitem>
-
- <listitem>
- <para>Karl Lehenbauer <email>karl@NeoSoft.com</email>
- <email>karl@one.neosoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Keith Bostic <email>bostic@toe.CS.Berkeley.EDU</email></para>
- </listitem>
-
- <listitem>
- <para>Ken Hughes</para>
- </listitem>
-
- <listitem>
- <para>Kent Talarico <email>kent@shipwreck.tsoft.net</email></para>
- </listitem>
-
- <listitem>
- <para>Kevin Lahey <email>kml%rokkaku.UUCP@mathcs.emory.edu</email>
- <email>kml@mosquito.cis.ufl.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Marc Frajola <email>marc@dev.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mark Tinguely <email>tinguely@plains.nodak.edu</email>
- <email>tinguely@hookie.cs.ndsu.NoDak.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Martin Renters <email>martin@tdc.on.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Clay <email>mclay@weareb.org</email></para>
- </listitem>
-
- <listitem>
- <para>Michael Galassi <email>nerd@percival.rain.com</email></para>
- </listitem>
-
- <listitem>
- <para>Mike Durkin <email>mdurkin@tsoft.sf-bay.org</email></para>
- </listitem>
-
- <listitem>
- <para>Naoki Hamada <email>nao@tom-yam.or.jp</email></para>
- </listitem>
-
- <listitem>
- <para>Nate Williams <email>nate@bsd.coe.montana.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Nick Handel <email>nhandel@NeoSoft.com</email>
- <email>nick@madhouse.neosoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Pace Willisson <email>pace@blitz.com</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Kranenburg <email>pk@cs.few.eur.nl</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Mackerras <email>paulus@cs.anu.edu.au</email></para>
- </listitem>
-
- <listitem>
- <para>Paul Popelka <email>paulp@uts.amdahl.com</email></para>
- </listitem>
-
- <listitem>
- <para>Peter da Silva <email>peter@NeoSoft.com</email></para>
- </listitem>
-
- <listitem>
- <para>Phil Sutherland
- <email>philsuth@mycroft.dialix.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Poul-Henning Kamp<email>phk@FreeBSD.org</email></para>
- </listitem>
-
- <listitem>
- <para>Ralf Friedl <email>friedl@informatik.uni-kl.de</email></para>
- </listitem>
-
- <listitem>
- <para>Rick Macklem <email>root@snowhite.cis.uoguelph.ca</email></para>
- </listitem>
-
- <listitem>
- <para>Robert D. Thrush <email>rd@phoenix.aii.com</email></para>
- </listitem>
-
- <listitem>
- <para>Rodney W. Grimes <email>rgrimes@cdrom.com</email></para>
- </listitem>
-
- <listitem>
- <para>Sascha Wildner <email>swildner@channelz.GUN.de</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Burris <email>scott@pita.cns.ucla.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Scott Reynolds <email>scott@clmqt.marquette.mi.us</email></para>
- </listitem>
-
- <listitem>
- <para>Sean Eric Fagan <email>sef@kithrup.com</email></para>
- </listitem>
-
- <listitem>
- <para>Simon J Gerraty <email>sjg@melb.bull.oz.au</email>
- <email>sjg@zen.void.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Stephen McKay <email>syssgm@devetir.qld.gov.au</email></para>
- </listitem>
-
- <listitem>
- <para>Terry Lambert <email>terry@icarus.weber.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Terry Lee <email>terry@uivlsi.csl.uiuc.edu</email></para>
- </listitem>
-
- <listitem>
- <para>Tor Egge <email>Tor.Egge@idi.ntnu.no</email></para>
- </listitem>
-
- <listitem>
- <para>Warren Toomey <email>wkt@csadfa.cs.adfa.oz.au</email></para>
- </listitem>
-
- <listitem>
- <para>Wiljo Heinen <email>wiljo@freeside.ki.open.de</email></para>
- </listitem>
-
- <listitem>
- <para>William Jolitz <email>withheld</email></para>
- </listitem>
-
- <listitem>
- <para>Wolfgang Solfrank <email>ws@tools.de</email></para>
- </listitem>
-
- <listitem>
- <para>Wolfgang Stanglmeier <email>wolf@dentaro.GUN.de</email></para>
- </listitem>
-
- <listitem>
- <para>Yuval Yarom <email>yval@cs.huji.ac.il</email></para>
- </listitem>
- </itemizedlist>
- </sect1>
-</chapter>
-
-<!--
- Local Variables:
- mode: sgml
- sgml-declaration: "../chapter.decl"
- sgml-indent-data: t
- sgml-omittag: nil
- sgml-always-quote-attributes: t
- sgml-parent-document: ("../handbook.sgml" "part" "chapter")
- End:
--->
-
diff --git a/en_US.ISO8859-1/books/arch-handbook/Makefile b/en_US.ISO8859-1/books/arch-handbook/Makefile
deleted file mode 100644
index f0390ebe65..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/Makefile
+++ /dev/null
@@ -1,55 +0,0 @@
-#
-# $FreeBSD$
-#
-# Build the FreeBSD Developers' Handbook.
-#
-
-MAINTAINER=murray@FreeBSD.org
-
-DOC?= book
-
-FORMATS?= html-split
-
-HAS_INDEX= true
-
-INSTALL_COMPRESSED?= gz
-INSTALL_ONLY_COMPRESSED?=
-
-# Images
-IMAGES= sockets/layers.eps sockets/sain.eps sockets/sainfill.eps sockets/sainlsb.eps sockets/sainmsb.eps sockets/sainserv.eps sockets/serv.eps sockets/serv2.eps sockets/slayers.eps
-
-#
-# SRCS lists the individual SGML files that make up the document. Changes
-# to any of these files will force a rebuild
-#
-
-# SGML content
-SRCS= book.sgml
-SRCS+= boot/chapter.sgml
-SRCS+= dma/chapter.sgml
-SRCS+= driverbasics/chapter.sgml
-SRCS+= introduction/chapter.sgml
-SRCS+= ipv6/chapter.sgml
-SRCS+= isa/chapter.sgml
-SRCS+= jail/chapter.sgml
-SRCS+= kerneldebug/chapter.sgml
-SRCS+= kobj/chapter.sgml
-SRCS+= l10n/chapter.sgml
-SRCS+= locking/chapter.sgml
-SRCS+= mac/chapter.sgml
-SRCS+= pci/chapter.sgml
-SRCS+= policies/chapter.sgml
-SRCS+= scsi/chapter.sgml
-SRCS+= secure/chapter.sgml
-SRCS+= sockets/chapter.sgml
-SRCS+= sound/chapter.sgml
-SRCS+= sysinit/chapter.sgml
-SRCS+= tools/chapter.sgml
-SRCS+= usb/chapter.sgml
-SRCS+= vm/chapter.sgml
-SRCS+= x86/chapter.sgml
-
-# Entities
-
-DOC_PREFIX?= ${.CURDIR}/../../..
-.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/en_US.ISO8859-1/books/arch-handbook/book.sgml b/en_US.ISO8859-1/books/arch-handbook/book.sgml
deleted file mode 100644
index e27a42d8a5..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/book.sgml
+++ /dev/null
@@ -1,301 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $FreeBSD$
--->
-
-<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
-<!ENTITY % bookinfo PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities//EN">
-%bookinfo;
-<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
-%man;
-<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN">
-%freebsd;
-<!ENTITY % chapters SYSTEM "chapters.ent"> %chapters;
-<!ENTITY % mac-entities SYSTEM "mac.ent"> %mac-entities;
-<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> %authors
-<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN"> %mailing-lists;
-<!ENTITY % chap.index "IGNORE">
-]>
-
-<book>
- <bookinfo>
- <title>FreeBSD Developers' Handbook</title>
-
- <corpauthor>The FreeBSD Documentation Project</corpauthor>
-
- <pubdate>August 2000</pubdate>
-
- <copyright>
- <year>2000</year>
- <year>2001</year>
- <year>2002</year>
- <year>2003</year>
- <holder>The FreeBSD Documentation Project</holder>
- </copyright>
-
- &bookinfo.legalnotice;
-
- <abstract>
- <para>Welcome to the Developers' Handbook. This manual is a
- <emphasis>work in progress</emphasis> and is the work of many
- individuals. Many sections do not yet exist and some of those
- that do exist need to be updated. If you are interested in
- helping with this project, send email to the &a.doc;.</para>
-
- <para>The latest version of this document is always available
- from the <ulink URL="../../../../index.html">FreeBSD World
- Wide Web server</ulink>. It may also be downloaded in a
- variety of formats and compression options from the <ulink
- url="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/">FreeBSD FTP
- server</ulink> or one of the numerous <ulink
- url="../handbook/mirrors-ftp.html">mirror
- sites</ulink>.</para>
- </abstract>
- </bookinfo>
-
- <part id="Basics">
- <title>Basics</title>
-
- &chap.introduction;
- &chap.tools;
- &chap.secure;
- &chap.l10n;
- &chap.policies;
-
- </part>
-
- <part id="ipc">
- <title>Interprocess Communication</title>
-
- <chapter id="signals">
- <title>* Signals</title>
-
- <para>Signals, pipes, semaphores, message queues, shared memory,
- ports, sockets, doors</para>
-
- </chapter>
-
- &chap.sockets;
- &chap.ipv6;
-
- </part>
-
- <part id="kernel">
- <title>Kernel</title>
-
- &chap.boot;
- &chap.locking;
- &chap.kobj;
- &chap.jail;
- &chap.sysinit;
- &chap.mac;
- &chap.vm;
- &chap.dma;
- &chap.kerneldebug;
-
- <chapter id="ufs">
- <title>* UFS</title>
-
- <para>UFS, FFS, Ext2FS, JFS, inodes, buffer cache, labeling,
- locking, metadata, soft-updates, LFS, portalfs, procfs,
- vnodes, memory sharing, memory objects, TLBs, caching</para>
-
- </chapter>
-
- <chapter id="afs">
- <title>* AFS</title>
-
- <para>AFS, NFS, SANs, etc.</para>
-
- </chapter>
-
- <chapter id="syscons">
- <title>* Syscons</title>
-
- <para>Syscons, tty, PCVT, serial console, screen savers,
- etc.</para>
-
- </chapter>
-
- <chapter id="compatibility">
- <title>* Compatibility Layers</title>
-
- <sect1 id="linux">
- <title>* Linux</title>
-
- <para>Linux, SVR4, etc.</para>
- </sect1>
-
- </chapter>
- </part>
-
- <part id="devicedrivers">
- <title>Device Drivers</title>
-
- &chap.driverbasics;
- &chap.isa;
- &chap.pci;
- &chap.scsi;
- &chap.usb;
- &chap.newbus;
-
- &chap.snd;
-
- </part>
-
- <part id="architectures">
- <title>Architectures</title>
-
- &chap.x86;
-
- <chapter id="alpha">
- <title>* Alpha</title>
-
- <para>Talk about the architectural specifics of
- FreeBSD/alpha.</para>
-
- <para>Explanation of alignment errors, how to fix, how to
- ignore.</para>
-
- <para>Example assembly language code for FreeBSD/alpha.</para>
- </chapter>
-
- <chapter id="ia64">
- <title>* IA-64</title>
-
- <para>Talk about the architectural specifics of
- FreeBSD/ia64.</para>
-
- </chapter>
- </part>
-
- <part id="appendices">
- <title>Appendices</title>
-
- <bibliography>
-
- <biblioentry id="COD" xreflabel="1">
- <authorgroup>
- <author>
- <firstname>Dave</firstname>
- <othername role="MI">A</othername>
- <surname>Patterson</surname>
- </author>
- <author>
- <firstname>John</firstname>
- <othername role="MI">L</othername>
- <surname>Hennessy</surname>
- </author>
- </authorgroup>
- <copyright><year>1998</year><holder>Morgan Kaufmann Publishers,
- Inc.</holder></copyright>
- <isbn>1-55860-428-6</isbn>
- <publisher>
- <publishername>Morgan Kaufmann Publishers, Inc.</publishername>
- </publisher>
- <title>Computer Organization and Design</title>
- <subtitle>The Hardware / Software Interface</subtitle>
- <pagenums>1-2</pagenums>
- </biblioentry>
-
- <biblioentry xreflabel="2">
- <authorgroup>
- <author>
- <firstname>W.</firstname>
- <othername role="Middle">Richard</othername>
- <surname>Stevens</surname>
- </author>
- </authorgroup>
- <copyright><year>1993</year><holder>Addison Wesley Longman,
- Inc.</holder></copyright>
- <isbn>0-201-56317-7</isbn>
- <publisher>
- <publishername>Addison Wesley Longman, Inc.</publishername>
- </publisher>
- <title>Advanced Programming in the Unix Environment</title>
- <pagenums>1-2</pagenums>
- </biblioentry>
-
- <biblioentry xreflabel="3">
- <authorgroup>
- <author>
- <firstname>Marshall</firstname>
- <othername role="Middle">Kirk</othername>
- <surname>McKusick</surname>
- </author>
- <author>
- <firstname>Keith</firstname>
- <surname>Bostic</surname>
- </author>
- <author>
- <firstname>Michael</firstname>
- <othername role="MI">J</othername>
- <surname>Karels</surname>
- </author>
- <author>
- <firstname>John</firstname>
- <othername role="MI">S</othername>
- <surname>Quarterman</surname>
- </author>
- </authorgroup>
- <copyright><year>1996</year><holder>Addison-Wesley Publishing Company,
- Inc.</holder></copyright>
- <isbn>0-201-54979-4</isbn>
- <publisher>
- <publishername>Addison-Wesley Publishing Company, Inc.</publishername>
- </publisher>
- <title>The Design and Implementation of the 4.4 BSD Operating System</title>
- <pagenums>1-2</pagenums>
- </biblioentry>
-
- <biblioentry id="Phrack" xreflabel="4">
- <authorgroup>
- <author>
- <firstname>Aleph</firstname>
- <surname>One</surname>
- </author>
- </authorgroup>
- <title>Phrack 49; "Smashing the Stack for Fun and Profit"</title>
- </biblioentry>
-
- <biblioentry id="StackGuard" xreflabel="5">
- <authorgroup>
- <author>
- <firstname>Chrispin</firstname>
- <surname>Cowan</surname>
- </author>
- <author>
- <firstname>Calton</firstname>
- <surname>Pu</surname>
- </author>
- <author>
- <firstname>Dave</firstname>
- <surname>Maier</surname>
- </author>
- </authorgroup>
- <title>StackGuard; Automatic Adaptive Detection and Prevention of
- Buffer-Overflow Attacks</title>
- </biblioentry>
-
- <biblioentry id="OpenBSD" xreflabel="6">
- <authorgroup>
- <author>
- <firstname>Todd</firstname>
- <surname>Miller</surname>
- </author>
- <author>
- <firstname>Theo</firstname>
- <surname>de Raadt</surname>
- </author>
- </authorgroup>
- <title>strlcpy and strlcat -- consistent, safe string copy and
- concatenation.</title>
- </biblioentry>
-
- </bibliography>
-
- <![ %chap.index; [ &chap.index; ]]>
- </part>
-
-</book>
diff --git a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml
deleted file mode 100644
index dba9d73a39..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml
+++ /dev/null
@@ -1,1023 +0,0 @@
-<!--
-The FreeBSD Documentation Project
-
-Copyright (c) 2002 Sergey Lyubka <devnull@uptsoft.com>
-All rights reserved
-$FreeBSD$
--->
-
-<chapter id="boot">
- <chapterinfo>
- <authorgroup>
- <author>
- <firstname>Sergey</firstname>
- <surname>Lyubka</surname>
- <contrib>Contributed by </contrib>
- </author> <!-- devnull@uptsoft.com 12 Jun 2002 -->
- </authorgroup>
- </chapterinfo>
- <title>Bootstrapping and kernel initialization</title>
-
- <sect1 id="boot-synopsis">
- <title>Synopsis</title>
-
- <para>This chapter is an overview of the boot and system
- initialization process, starting from the BIOS (firmware) POST,
- to the first user process creation. Since the initial steps of
- system startup are very architecture dependent, the IA-32
- architecture is used as an example.</para>
- </sect1>
-
- <sect1 id="boot-overview">
- <title>Overview</title>
-
- <para>A computer running FreeBSD can boot by several methods,
- although the most common method, booting from a harddisk where
- the OS is installed, will be discussed here. The boot process
- is divided into several steps:</para>
-
- <itemizedlist>
- <listitem><para>BIOS POST</para></listitem>
- <listitem><para><literal>boot0</literal> stage</para></listitem>
- <listitem><para><literal>boot2</literal> stage</para></listitem>
- <listitem><para>loader stage</para></listitem>
- <listitem><para>kernel initialization</para></listitem>
- </itemizedlist>
-
- <para>The <literal>boot0</literal> and <literal>boot2</literal>
- stages are also referred to as <emphasis>bootstrap stages 1 and
- 2</emphasis> in &man.boot.8; as the first steps in FreeBSD's
- 3-stage bootstrapping procedure. Various information is printed
- on the screen at each stage, so you may visually recognize them
- using the table that follows. Please note that the actual data
- may differ from machine to machine:</para>
-
- <informaltable>
- <tgroup cols="2">
- <tbody>
- <row>
- <entry><para>may vary</para></entry>
-
- <entry><para>BIOS (firmware) messages</para></entry>
- </row>
-
- <row>
- <entry><para>
-<screen>F1 FreeBSD
-F2 BSD
-F5 Disk 2</screen>
- </para></entry>
-
- <entry><para><literal>boot0</literal></para></entry>
- </row>
-
- <row>
- <entry><para>
-<screen>>>FreeBSD/i386 BOOT
-Default: 1:ad(1,a)/boot/loader
-boot:</screen>
- </para></entry>
-
- <entry><para><literal>boot2</literal><footnote><para>This
- prompt will appear if the user presses a key just after
- selecting an OS to boot at the <literal>boot0</literal>
- stage.</para></footnote></para></entry>
- </row>
-
- <row>
- <entry><para>
-<screen>BTX loader 1.0 BTX version is 1.01
-BIOS drive A: is disk0
-BIOS drive C: is disk1
-BIOS 639kB/64512kB available memory
-FreeBSD/i386 bootstrap loader, Revision 0.8
-Console internal video/keyboard
-(jkh@bento.freebsd.org, Mon Nov 20 11:41:23 GMT 2000)
-/kernel text=0x1234 data=0x2345 syms=[0x4+0x3456]
-Hit [Enter] to boot immediately, or any other key for command prompt
-Booting [kernel] in 9 seconds..._</screen>
- </para></entry>
-
- <entry><para>loader</para></entry>
- </row>
-
- <row>
- <entry><para>
- <screen>Copyright (c) 1992-2002 The FreeBSD Project.
-Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
- The Regents of the University of California. All rights reserved.
-FreeBSD 4.6-RC #0: Sat May 4 22:49:02 GMT 2002
- devnull@kukas:/usr/obj/usr/src/sys/DEVNULL
-Timecounter "i8254" frequency 1193182 Hz</screen></para></entry>
-
- <entry><para>kernel</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </sect1>
-
- <sect1 id="boot-bios">
- <title>BIOS POST</title>
-
- <para>When the PC powers on, the processor's registers are set
- to some predefined values. One of the registers is the
- <emphasis>instruction pointer</emphasis> register, and its value
- after a power on is well defined: it is a 32-bit value of
- 0xfffffff0. The instruction pointer register points to code to
- be executed by the processor. One of the registers is the
- <literal>cr1</literal> 32-bit control register, and its value
- just after the reboot is 0. One of the cr1's bits, the bit PE
- (Protected Enabled) indicates whether the processor is running
- in protected or real mode. Since at boot time this bit is
- cleared, the processor boots in real mode. Real mode means,
- among other things, that linear and physical addresses are
- identical.</para>
-
- <para>The value of 0xfffffff0 is slightly less then 4Gb, so unless
- the machine has 4Gb physical memory, it cannot point to a valid
- memory address. The computer's hardware translates this address
- so that it points to a BIOS memory block.</para>
-
- <para>BIOS stands for <emphasis>Basic Input Output
- System</emphasis>, and it is a chip on the motherboard that has
- a relatively small amount of read-only memory (ROM). This
- memory contains various low-level routines that are specific to
- the hardware supplied with the motherboard. So, the processor
- will first jump to the address 0xfffffff0, which really resides
- in the BIOS's memory. Usually this address contains a jump
- instruction to the BIOS's POST routines.</para>
-
- <para>POST stands for <emphasis>Power On Self Test</emphasis>.
- This is a set of routines including the memory check, system bus
- check and other low-level stuff so that the CPU can initialize
- the computer properly. The important step on this stage is
- determining the boot device. All modern BIOS's allow the boot
- device to be set manually, so you can boot from a floppy,
- CD-ROM, harddisk etc.</para>
-
- <para>The very last thing in the POST is the <literal>INT
- 0x19</literal> instruction. That instruction reads 512 bytes
- from the first sector of boot device into the memory at address
- 0x7c00. The term <emphasis>first sector</emphasis> originates
- from harddrive architecture, where the magnetic plate is divided
- to a number of cylindrical tracks. Tracks are numbered, and
- every track is divided by a number (usually 64) sectors. Track
- number 0 is the outermost on the magnetic plate, and sector 1,
- the first sector (tracks, or, cylinders, are numbered starting
- from 0, but sectors - starting from 1), has a special meaning.
- It is also called Master Boot Record, or MBR. The remaining
- sectors on the first track are never used <footnote><para>Some
- utilities such as &man.disklabel.8; may store the information in
- this area, mostly in the second
- sector.</para></footnote>.</para>
- </sect1>
-
- <sect1 id="boot-boot0">
- <title><literal>boot0</literal> stage</title>
-
- <para>Take a look at the file <filename>/boot/boot0</filename>.
- This is a small 512-byte file, and it is exactly what FreeBSD's
- installation procedure wrote to your harddisk's MBR if you chose
- the <quote>bootmanager</quote> option at installation time.</para>
-
- <para>As mentioned previously, the <literal>INT 0x19</literal>
- instruction loads an MBR, i.e. the <filename>boot0</filename>
- content, into the memory at address 0x7c00. Taking a look at
- the file <filename>sys/boot/i386/boot0/boot0.s</filename> can
- give a guess at what is happening there - this is the boot
- manager, which is an awesome piece of code written by Robert
- Nordier.</para>
-
- <para>The MBR, or, <filename>boot0</filename>, has a special
- structure starting from offset 0x1be, called the
- <emphasis>partition table</emphasis>. It has 4 records of 16
- bytes each, called <emphasis>partition records</emphasis>, which
- represent how the harddisk(s) are partitioned, or, in FreeBSD's
- terminology, sliced. One byte of those 16 says whether a
- partition (slice) is bootable or not. Exactly one record must
- have that flag set, otherwise <filename>boot0</filename>'s code
- will refuse to proceed.</para>
-
- <para>A partition record has the following fields:</para>
-
- <itemizedlist>
- <listitem>
- <para>the 1-byte filesystem type</para>
- </listitem>
-
- <listitem>
- <para>the 1-byte bootable flag</para>
- </listitem>
-
- <listitem>
- <para>the 6 byte descriptor in CHS format</para>
- </listitem>
-
- <listitem>
- <para>the 8 byte descriptor in LBA format</para>
- </listitem>
- </itemizedlist>
-
- <para>A partition record descriptor has the information about
- where exactly the partition resides on the drive. Both
- descriptors, LBA and CHS, describe the same information, but in
- different ways: LBA (Logical Block Addressing) has the starting
- sector for the partition and the partition's length, while CHS
- (Cylinder Head Sector) has coordinates for the first and last
- sectors of the partition.</para>
-
- <para>The boot manager scans the partition table and prints the
- menu on the screen so the user can select what disk and what
- slice to boot. By pressing an appropriate key,
- <filename>boot0</filename> performs the following
- actions:</para>
-
- <itemizedlist>
- <listitem>
- <para>modifies the bootable flag for the selected partition to
- make it bootable, and clears the previous</para>
- </listitem>
-
- <listitem>
- <para>saves itself to disk to remember what partition (slice)
- has been selected so to use it as the default on the next
- boot</para>
- </listitem>
-
- <listitem>
- <para>loads the first sector of the selected partition (slice)
- into memory and jumps there</para>
- </listitem>
- </itemizedlist>
-
- <para>What kind of data should reside on the very first sector of
- a bootable partition (slice), in our case, a FreeBSD slice? As
- you may have already guessed, it is
- <filename>boot2</filename>.</para>
- </sect1>
-
- <sect1 id="boot-boot2">
- <title><literal>boot2</literal> stage</title>
-
- <para>You might wonder, why <literal>boot2</literal> comes after
- <literal>boot0</literal>, and not boot1. Actually, there is a
- 512-byte file called <filename>boot1</filename> in the directory
- <filename>/boot</filename> as well. It is used for booting from
- a floppy. When booting from a floppy,
- <filename>boot1</filename> plays the same role as
- <filename>boot0</filename> for a harddisk: it locates
- <filename>boot2</filename> and runs it.</para>
-
- <para>You may have realized that a file
- <filename>/boot/mbr</filename> exists as well. It is a
- simplified version of <filename>boot0</filename>. The code in
- <filename>mbr</filename> does not provide a menu for the user,
- it just blindly boots the partition marked active.</para>
-
- <para>The code implementing <filename>boot2</filename> resides in
- <filename>sys/boot/i386/boot2/</filename>, and the executable
- itself is in <filename>/boot</filename>. The files
- <filename>boot0</filename> and <filename>boot2</filename> that
- are in <filename>/boot</filename> are not used by the bootstrap,
- but by utilities such as <application>boot0cfg</application>.
- The actual position for <filename>boot0</filename> is in the
- MBR. For <filename>boot2</filename> it is the beginning of a
- bootable FreeBSD slice. These locations are not under the
- filesystem's control, so they are invisible to commands like
- <application>ls</application>.</para>
-
- <para>The main task for <literal>boot2</literal> is to load the
- file <filename>/boot/loader</filename>, which is the third stage
- in the bootstrapping procedure. The code in
- <literal>boot2</literal> cannot use any services like
- <function>open()</function> and <function>read()</function>,
- since the kernel is not yet loaded. It must scan the harddisk,
- knowing about the filesystem structure, find the file
- <filename>/boot/loader</filename>, read it into memory using a
- BIOS service, and then pass the execution to the loader's entry
- point.</para>
-
- <para>Besides that, <literal>boot2</literal> prompts for user
- input so the loader can be booted from different disk, unit,
- slice and partition.</para>
-
- <para>The <literal>boot2</literal> binary is created in special
- way:</para>
-
- <programlisting><filename>sys/boot/i386/boot2/Makefile</filename>
-boot2: boot2.ldr boot2.bin ${BTX}/btx/btx
- btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \
- -o boot2.ld -P 1 boot2.bin</programlisting>
-
- <para>This Makefile snippet shows that &man.btxld.8; is used to
- link the binary. BTX, which stands for BooT eXtender, is a
- piece of code that provides a protected mode environment for the
- program, called the client, that it is linked with. So
- <literal>boot2</literal> is a BTX client, i.e. it uses the
- service provided by BTX.</para>
-
- <para>The <application>btxld</application> utility is the linker.
- It links two binaries together. The difference between
- &man.btxld.8; and &man.ld.1; is that
- <application>ld</application> usually links object files into a
- shared object or executable, while
- <application>btxld</application> links an object file with the
- BTX, producing the binary file suitable to be put on the
- beginning of the partition for the system boot.</para>
-
- <para><literal>boot0</literal> passes the execution to BTX's entry
- point. BTX then switches the processor to protected mode, and
- prepares a simple environment before calling the client. This
- includes:</para>
-
- <itemizedlist>
- <listitem><para>virtual v86 mode. That means, the BTX is a v86
- monitor. Real mode instructions like posh, popf, cli, sti, if
- called by the client, will work.</para></listitem>
-
- <listitem><para>Interrupt Descriptor Table (IDT) is set up so
- all hardware interrupts are routed to the default BIOS's
- handlers, and interrupt 0x30 is set up to be the syscall
- gate.</para></listitem>
-
- <listitem><para>Two system calls: <function>exec</function> and
- <function>exit</function>, are defined:</para>
-
- <programlisting><filename>sys/boot/i386/btx/lib/btxsys.s:</filename>
- .set INT_SYS,0x30 # Interrupt number
-#
-# System call: exit
-#
-__exit: xorl %eax,%eax # BTX system
- int $INT_SYS # call 0x0
-#
-# System call: exec
-#
-__exec: movl $0x1,%eax # BTX system
- int $INT_SYS # call 0x1</programlisting></listitem>
- </itemizedlist>
-
- <para>BTX creates a Global Descriptor Table (GDT):</para>
-
- <programlisting><filename>sys/boot/i386/btx/btx/btx.s:</filename>
-gdt: .word 0x0,0x0,0x0,0x0 # Null entry
- .word 0xffff,0x0,0x9a00,0xcf # SEL_SCODE
- .word 0xffff,0x0,0x9200,0xcf # SEL_SDATA
- .word 0xffff,0x0,0x9a00,0x0 # SEL_RCODE
- .word 0xffff,0x0,0x9200,0x0 # SEL_RDATA
- .word 0xffff,MEM_USR,0xfa00,0xcf# SEL_UCODE
- .word 0xffff,MEM_USR,0xf200,0xcf# SEL_UDATA
- .word _TSSLM,MEM_TSS,0x8900,0x0 # SEL_TSS</programlisting>
-
- <para>The client's code and data start from address MEM_USR
- (0xa000), and a selector (SEL_UCODE) points to the client's code
- segment. The SEL_UCODE descriptor has Descriptor Privilege
- Level (DPL) 3, which is the lowest privilege level. But the
- <literal>INT 0x30</literal> instruction handler resides in a
- segment pointed to by the SEL_SCODE (supervisor code) selector,
- as shown from the code that creates an IDT:</para>
-
- <programlisting> mov $SEL_SCODE,%dh # Segment selector
-init.2: shr %bx # Handle this int?
- jnc init.3 # No
- mov %ax,(%di) # Set handler offset
- mov %dh,0x2(%di) # and selector
- mov %dl,0x5(%di) # Set P:DPL:type
- add $0x4,%ax # Next handler</programlisting>
-
- <para>So, when the client calls <function>__exec()</function>, the
- code will be executed with the highest privileges. This allows
- the kernel to change the protected mode data structures, such as
- page tables, GDT, IDT, etc later, if needed.</para>
-
- <para><literal>boot2</literal> defines an important structure,
- <literal>struct bootinfo</literal>. This structure is
- initialized by <literal>boot2</literal> and passed to the
- loader, and then further to the kernel. Some nodes of this
- structures are set by <literal>boot2</literal>, the rest by the
- loader. This structure, among other information, contains the
- kernel filename, BIOS harddisk geometry, BIOS drive number for
- boot device, physical memory available, <literal>envp</literal>
- pointer etc. The definition for it is:</para>
-
- <programlisting><filename>/usr/include/machine/bootinfo.h</filename>
-struct bootinfo {
- u_int32_t bi_version;
- u_int32_t bi_kernelname; /* represents a char * */
- u_int32_t bi_nfs_diskless; /* struct nfs_diskless * */
- /* End of fields that are always present. */
-#define bi_endcommon bi_n_bios_used
- u_int32_t bi_n_bios_used;
- u_int32_t bi_bios_geom[N_BIOS_GEOM];
- u_int32_t bi_size;
- u_int8_t bi_memsizes_valid;
- u_int8_t bi_bios_dev; /* bootdev BIOS unit number */
- u_int8_t bi_pad[2];
- u_int32_t bi_basemem;
- u_int32_t bi_extmem;
- u_int32_t bi_symtab; /* struct symtab * */
- u_int32_t bi_esymtab; /* struct symtab * */
- /* Items below only from advanced bootloader */
- u_int32_t bi_kernend; /* end of kernel space */
- u_int32_t bi_envp; /* environment */
- u_int32_t bi_modulep; /* preloaded modules */
-};</programlisting>
-
- <para><literal>boot2</literal> enters into an infinite loop waiting
- for user input, then calls <function>load()</function>. If the
- user does not press anything, the loop brakes by a timeout, so
- <function>load()</function> will load the default file
- (<filename>/boot/loader</filename>). Functions <function>ino_t
- lookup(char *filename)</function> and <function>int xfsread(ino_t
- inode, void *buf, size_t nbyte)</function> are used to read the
- content of a file into memory. <filename>/boot/loader</filename>
- is an ELF binary, but where the ELF header is prepended with
- a.out's <literal>struct exec</literal> structure.
- <function>load()</function> scans the loader's ELF header, loading
- the content of <filename>/boot/loader</filename> into memory, and
- passing the execution to the loader's entry:</para>
-
- <programlisting><filename>sys/boot/i386/boot2/boot2.c:</filename>
- __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK),
- MAKEBOOTDEV(dev_maj[dsk.type], 0, dsk.slice, dsk.unit, dsk.part),
- 0, 0, 0, VTOP(&amp;bootinfo));</programlisting>
- </sect1>
-
- <sect1 id="boot-loader">
- <title><application>loader</application> stage</title>
-
- <para><application>loader</application> is a BTX client as well.
- I will not describe it here in detail, there is a comprehensive
- manpage written by Mike Smith, &man.loader.8;. The underlying
- mechanisms and BTX were discussed above.</para>
-
- <para>The main task for the loader is to boot the kernel. When
- the kernel is loaded into memory, it is being called by the
- loader:</para>
-
- <programlisting><filename>sys/boot/common/boot.c:</filename>
- /* Call the exec handler from the loader matching the kernel */
- module_formats[km->m_loader]->l_exec(km);</programlisting>
- </sect1>
-
- <sect1 id="boot-kernel">
- <title>Kernel initialization</title>
-
- <para>To where exactly is the execution passed by the loader,
- i.e. what is the kernel's actual entry point. Let us take a
- look at the command that links the kernel:</para>
-
- <programlisting><filename>sys/conf/Makefile.i386:</filename>
-ld -elf -Bdynamic -T /usr/src/sys/conf/ldscript.i386 -export-dynamic \
--dynamic-linker /red/herring -o kernel -X locore.o \
-&lt;lots of kernel .o files&gt;</programlisting>
-
- <para>A few interesting things can be seen in this line. First,
- the kernel is an ELF dynamically linked binary, but the dynamic
- linker for kernel is <filename>/red/herring</filename>, which is
- definitely a bogus file. Second, taking a look at the file
- <filename>sys/conf/ldscript.i386</filename> gives an idea about
- what <application>ld</application> options are used when
- compiling a kernel. Reading through the first few lines, the
- string</para>
-
- <programlisting><filename>sys/conf/ldscript.i386:</filename>
-ENTRY(btext)</programlisting>
-
- <para>says that a kernel's entry point is the symbol `btext'.
- This symbol is defined in <filename>locore.s</filename>:</para>
-
- <programlisting><filename>sys/i386/i386/locore.s:</filename>
- .text
-/**********************************************************************
- *
- * This is where the bootblocks start us, set the ball rolling...
- *
- */
-NON_GPROF_ENTRY(btext)</programlisting>
-
- <para>First what is done is the register EFLAGS is set to a
- predefined value of 0x00000002, and then all the segment
- registers are initialized:</para>
-
- <programlisting><filename>sys/i386/i386/locore.s</filename>
-/* Don't trust what the BIOS gives for eflags. */
- pushl $PSL_KERNEL
- popfl
-
-/*
- * Don't trust what the BIOS gives for %fs and %gs. Trust the bootstrap
- * to set %cs, %ds, %es and %ss.
- */
- mov %ds, %ax
- mov %ax, %fs
- mov %ax, %gs</programlisting>
-
- <para>btext calls the routines
- <function>recover_bootinfo()</function>,
- <function>identify_cpu()</function>,
- <function>create_pagetables()</function>, which are also defined
- in <filename>locore.s</filename>. Here is a description of what
- they do:</para>
-
- <informaltable>
- <tgroup cols=2 align=left>
- <tbody>
- <row>
- <entry><function>recover_bootinfo</function></entry>
-
- <entry>This routine parses the parameters to the kernel
- passed from the bootstrap. The kernel may have been
- booted in 3 ways: by the loader, described above, by the
- old disk boot blocks, and by the old diskless boot
- procedure. This function determines the booting method,
- and stores the <literal>struct bootinfo</literal>
- structure into the kernel memory.</entry>
- </row>
-
- <row>
- <entry><function>identify_cpu</function></entry>
-
- <entry>This functions tries to find out what CPU it is
- running on, storing the value found in a variable
- <varname>_cpu</varname>.</entry>
- </row>
-
- <row>
- <entry><function>create_pagetables</function></entry>
-
- <entry>This function allocates and fills out a Page Table
- Directory at the top of the kernel memory area.</entry>
- </row>
- </tgroup>
- </informaltable>
-
- <para>The next steps are enabling VME, if the CPU supports
- it:</para>
-
- <programlisting> testl $CPUID_VME, R(_cpu_feature)
- jz 1f
- movl %cr4, %eax
- orl $CR4_VME, %eax
- movl %eax, %cr4</programlisting>
-
- <para>Then, enabling paging:</para>
- <programlisting>/* Now enable paging */
- movl R(_IdlePTD), %eax
- movl %eax,%cr3 /* load ptd addr into mmu */
- movl %cr0,%eax /* get control word */
- orl $CR0_PE|CR0_PG,%eax /* enable paging */
- movl %eax,%cr0 /* and let's page NOW! */</programlisting>
-
- <para>The next three lines of code are because the paging was set,
- so the jump is needed to continue the execution in virtualized
- address space:</para>
-
- <programlisting> pushl $begin /* jump to high virtualized address */
- ret
-
-/* now running relocated at KERNBASE where the system is linked to run */
-begin:</programlisting>
-
- <para>The function <function>init386()</function> is called, with
- a pointer to the first free physical page, after that
- <function>mi_startup()</function>. <function>init386</function>
- is an architecture dependent initialization function, and
- <function>mi_startup()</function> is an architecture independent
- one (the 'mi_' prefix stands for Machine Independent). The
- kernel never returns from <function>mi_startup()</function>, and
- by calling it, the kernel finishes booting:</para>
-
- <programlisting><filename>sys/i386/i386/locore.s:</filename>
- movl physfree, %esi
- pushl %esi /* value of first for init386(first) */
- call _init386 /* wire 386 chip for unix operation */
- call _mi_startup /* autoconfiguration, mountroot etc */
- hlt /* never returns to here */</programlisting>
-
- <sect2>
- <title><function>init386()</function></title>
-
- <para><function>init386()</function> is defined in
- <filename>sys/i386/i386/machdep.c</filename> and performs
- low-level initialization, specific to the i386 chip. The
- switch to protected mode was performed by the loader. The
- loader has created the very first task, in which the kernel
- continues to operate. Before running straight away to the
- code, I will enumerate the tasks the processor must complete
- to initialize protected mode execution:</para>
-
- <itemizedlist>
- <listitem>
- <para>Initialize the kernel tunable parameters, passed from
- the bootstrapping program.</para>
- </listitem>
-
- <listitem>
- <para>Prepare the GDT.</para>
- </listitem>
-
- <listitem>
- <para>Prepare the IDT.</para>
- </listitem>
-
- <listitem>
- <para>Initialize the system console.</para>
- </listitem>
-
- <listitem>
- <para>Initialize the DDB, if it is compiled into
- kernel.</para>
- </listitem>
-
- <listitem>
- <para>Initialize the TSS.</para>
- </listitem>
-
- <listitem>
- <para>Prepare the LDT.</para>
- </listitem>
-
- <listitem>
- <para>Setup proc0's pcb.</para>
- </listitem>
- </itemizedlist>
-
- <para>What <function>init386()</function> first does is
- initialize the tunable parameters passed from bootstrap. This
- is done by setting the environment pointer (envp) and calling
- <function>init_param1()</function>. The envp pointer has been
- passed from loader in the <literal>bootinfo</literal>
- structure:</para>
-
- <programlisting><filename>sys/i386/i386/machdep.c:</filename>
- kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
-
- /* Init basic tunables, hz etc */
- init_param1();</programlisting>
-
- <para><function>init_param1()</function> is defined in
- <filename>sys/kern/subr_param.c</filename>. That file has a
- number of sysctls, and two functions,
- <function>init_param1()</function> and
- <function>init_param2()</function>, that are called from
- <function>init386()</function>:</para>
-
- <programlisting><filename>sys/kern/subr_param.c</filename>
- hz = HZ;
- TUNABLE_INT_FETCH("kern.hz", &amp;hz);</programlisting>
-
- <para>TUNABLE_&lt;typename&gt;_FETCH is used to fetch the value
- from the environment:</para>
-
- <programlisting><filename>/usr/src/sys/sys/kernel.h</filename>
-#define TUNABLE_INT_FETCH(path, var) getenv_int((path), (var))
-</programlisting>
-
- <para>Sysctl <literal>kern.hz</literal> is the system clock tick. Along with
- this, the following sysctls are set by
- <function>init_param1()</function>: <literal>kern.maxswzone,
- kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.dflssiz,
- kern.maxssiz, kern.sgrowsiz</literal>.</para>
-
- <para>Then <function>init386()</function> prepares the Global
- Descriptors Table (GDT). Every task on an x86 is running in
- its own virtual address space, and this space is addressed by
- a segment:offset pair. Say, for instance, the current
- instruction to be executed by the processor lies at CS:EIP,
- then the linear virtual address for that instruction would be
- <quote>the virtual address of code segment CS</quote> + EIP. For
- convenience, segments begin at virtual address 0 and end at a
- 4Gb boundary. Therefore, the instruction's linear virtual
- address for this example would just be the value of EIP.
- Segment registers such as CS, DS etc are the selectors,
- i.e. indexes, into GDT (to be more precise, an index is not a
- selector itself, but the INDEX field of a selector).
- FreeBSD's GDT holds descriptors for 15 selectors per
- CPU:</para>
-
- <programlisting><filename>sys/i386/i386/machdep.c:</filename>
-union descriptor gdt[NGDT * MAXCPU]; /* global descriptor table */
-
-<filename>sys/i386/include/segments.h:</filename>
-/*
- * Entries in the Global Descriptor Table (GDT)
- */
-#define GNULL_SEL 0 /* Null Descriptor */
-#define GCODE_SEL 1 /* Kernel Code Descriptor */
-#define GDATA_SEL 2 /* Kernel Data Descriptor */
-#define GPRIV_SEL 3 /* SMP Per-Processor Private Data */
-#define GPROC0_SEL 4 /* Task state process slot zero and up */
-#define GLDT_SEL 5 /* LDT - eventually one per process */
-#define GUSERLDT_SEL 6 /* User LDT */
-#define GTGATE_SEL 7 /* Process task switch gate */
-#define GBIOSLOWMEM_SEL 8 /* BIOS low memory access (must be entry 8) */
-#define GPANIC_SEL 9 /* Task state to consider panic from */
-#define GBIOSCODE32_SEL 10 /* BIOS interface (32bit Code) */
-#define GBIOSCODE16_SEL 11 /* BIOS interface (16bit Code) */
-#define GBIOSDATA_SEL 12 /* BIOS interface (Data) */
-#define GBIOSUTIL_SEL 13 /* BIOS interface (Utility) */
-#define GBIOSARGS_SEL 14 /* BIOS interface (Arguments) */</programlisting>
-
- <para>Note that those #defines are not selectors themselves, but
- just a field INDEX of a selector, so they are exactly the
- indices of the GDT. for example, an actual selector for the
- kernel code (GCODE_SEL) has the value 0x08.</para>
-
- <para>The next step is to initialize the Interrupt Descriptor
- Table (IDT). This table is to be referenced by the processor
- when a software or hardware interrupt occurs. For example, to
- make a system call, user application issues the <literal>INT
- 0x80</literal> instruction. This is a software interrupt, so
- the processor's hardware looks up a record with index 0x80 in
- the IDT. This record points to the routine that handles this
- interrupt, in this particular case, this will be the kernel's
- syscall gate. The IDT may have a maximum of 256 (0x100)
- records. The kernel allocates NIDT records for the IDT, where
- NIDT is the maximum (256):</para>
-
- <programlisting><filename>sys/i386/i386/machdep.c:</filename>
-static struct gate_descriptor idt0[NIDT];
-struct gate_descriptor *idt = &amp;idt0[0]; /* interrupt descriptor table */
-</programlisting>
-
- <para>For each interrupt, an appropriate handler is set. The
- syscall gate for <literal>INT 0x80</literal> is set as
- well:</para>
-
- <programlisting><filename>sys/i386/i386/machdep.c:</filename>
- setidt(0x80, &amp;IDTVEC(int0x80_syscall),
- SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL));</programlisting>
-
- <para>So when a userland application issues the <literal>INT
- 0x80</literal> instruction, control will transfer to the
- function <function>_Xint0x80_syscall</function>, which is in
- the kernel code segment and will be executed with supervisor
- privileges.</para>
-
- <para>Console and DDB are then initialized:</para>
-
- <programlisting><filename>sys/i386/i386/machdep.c:</filename>
- cninit();
-/* skipped */
-#ifdef DDB
- kdb_init();
- if (boothowto & RB_KDB)
- Debugger("Boot flags requested debugger");
-#endif</programlisting>
-
- <para>The Task State Segment is another x86 protected mode
- structure, the TSS is used by the hardware to store task
- information when a task switch occurs.</para>
-
- <para>The Local Descriptors Table is used to reference userland
- code and data. Several selectors are defined to point to the
- LDT, they are the system call gates and the user code and data
- selectors:</para>
-
- <programlisting><filename>/usr/include/machine/segments.h</filename>
-#define LSYS5CALLS_SEL 0 /* forced by intel BCS */
-#define LSYS5SIGR_SEL 1
-#define L43BSDCALLS_SEL 2 /* notyet */
-#define LUCODE_SEL 3
-#define LSOL26CALLS_SEL 4 /* Solaris >= 2.6 system call gate */
-#define LUDATA_SEL 5
-/* separate stack, es,fs,gs sels ? */
-/* #define LPOSIXCALLS_SEL 5*/ /* notyet */
-#define LBSDICALLS_SEL 16 /* BSDI system call gate */
-#define NLDT (LBSDICALLS_SEL + 1)
-</programlisting>
-
- <para>Next, proc0's Process Control Block (<literal>struct
- pcb</literal>) structure is initialized. proc0 is a
- <literal>struct proc</literal> structure that describes a kernel
- process. It is always present while the kernel is running,
- therefore it is declared as global:</para>
-
- <programlisting><filename>sys/kern/kern_init.c:</filename>
- struct proc proc0;</programlisting>
-
- <para>The structure <literal>struct pcb</literal> is a part of a
- proc structure. It is defined in
- <filename>/usr/include/machine/pcb.h</filename> and has a
- process's information specific to the i386 architecture, such as
- registers values.</para>
- </sect2>
-
- <sect2>
- <title><function>mi_startup()</function></title>
-
- <para>This function performs a bubble sort of all the system
- initialization objects and then calls the entry of each object
- one by one:</para>
-
- <programlisting><filename>sys/kern/init_main.c:</filename>
- for (sipp = sysinit; *sipp; sipp++) {
-
- /* ... skipped ... */
-
- /* Call function */
- (*((*sipp)->func))((*sipp)->udata);
- /* ... skipped ... */
- }</programlisting>
-
- <para>Although the sysinit framework is described in the
- Developers' Handbook, I will discuss the internals of it.</para>
-
- <para>Every system initialization object (sysinit object) is
- created by calling a SYSINIT() macro. Let us take as example an
- <literal>announce</literal> sysinit object. This object prints
- the copyright message:</para>
-
- <programlisting><filename>sys/kern/init_main.c:</filename>
-static void
-print_caddr_t(void *data __unused)
-{
- printf("%s", (char *)data);
-}
-SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright)</programlisting>
-
- <para>The subsystem ID for this object is SI_SUB_COPYRIGHT
- (0x0800001), which comes right after the SI_SUB_CONSOLE
- (0x0800000). So, the copyright message will be printed out
- first, just after the console initialization.</para>
-
- <para>Let us take a look at what exactly the macro
- <literal>SYSINIT()</literal> does. It expands to a
- <literal>C_SYSINIT()</literal> macro. The
- <literal>C_SYSINIT()</literal> macro then expands to a static
- <literal>struct sysinit</literal> structure declaration with
- another <literal>DATA_SET</literal> macro call:</para>
- <programlisting><filename>/usr/include/sys/kernel.h:</filename>
- #define C_SYSINIT(uniquifier, subsystem, order, func, ident) \
- static struct sysinit uniquifier ## _sys_init = { \ subsystem, \
- order, \ func, \ ident \ }; \ DATA_SET(sysinit_set,uniquifier ##
- _sys_init);
-
-#define SYSINIT(uniquifier, subsystem, order, func, ident) \
- C_SYSINIT(uniquifier, subsystem, order, \
- (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)ident)</programlisting>
-
- <para>The <literal>DATA_SET()</literal> macro expands to a
- <literal>MAKE_SET()</literal>, and that macro is the point where
- the all sysinit magic is hidden:</para>
-
- <programlisting><filename>/usr/include/linker_set.h</filename>
-#define MAKE_SET(set, sym) \
- static void const * const __set_##set##_sym_##sym = &amp;sym; \
- __asm(".section .set." #set ",\"aw\""); \
- __asm(".long " #sym); \
- __asm(".previous")
-#endif
-#define TEXT_SET(set, sym) MAKE_SET(set, sym)
-#define DATA_SET(set, sym) MAKE_SET(set, sym)</programlisting>
-
- <para>In our case, the following declaration will occur:</para>
-
- <programlisting>static struct sysinit announce_sys_init = {
- SI_SUB_COPYRIGHT,
- SI_ORDER_FIRST,
- (sysinit_cfunc_t)(sysinit_nfunc_t) print_caddr_t,
- (void *) copyright
-};
-
-static void const *const __set_sysinit_set_sym_announce_sys_init =
- &amp;announce_sys_init;
-__asm(".section .set.sysinit_set" ",\"aw\"");
-__asm(".long " "announce_sys_init");
-__asm(".previous");</programlisting>
-
- <para>The first <literal>__asm</literal> instruction will create
- an ELF section within the kernel's executable. This will happen
- at kernel link time. The section will have the name
- <literal>.set.sysinit_set</literal>. The content of this section is one 32-bit
- value, the address of announce_sys_init structure, and that is
- what the second <literal>__asm</literal> is. The third
- <literal>__asm</literal> instruction marks the end of a section.
- If a directive with the same section name occured before, the
- content, i.e. the 32-bit value, will be appended to the existing
- section, so forming an array of 32-bit pointers.</para>
-
- <para>Running <application>objdump</application> on a kernel
- binary, you may notice the presence of such small
- sections:</para>
-
- <screen>&prompt.user; <userinput>objdump -h /kernel</userinput>
- 7 .set.cons_set 00000014 c03164c0 c03164c0 002154c0 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 8 .set.kbddriver_set 00000010 c03164d4 c03164d4 002154d4 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 9 .set.scrndr_set 00000024 c03164e4 c03164e4 002154e4 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 10 .set.scterm_set 0000000c c0316508 c0316508 00215508 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 11 .set.sysctl_set 0000097c c0316514 c0316514 00215514 2**2
- CONTENTS, ALLOC, LOAD, DATA
- 12 .set.sysinit_set 00000664 c0316e90 c0316e90 00215e90 2**2
- CONTENTS, ALLOC, LOAD, DATA</screen>
-
- <para>This screen dump shows that the size of .set.sysinit_set
- section is 0x664 bytes, so <literal>0x664/sizeof(void
- *)</literal> sysinit objects are compiled into the kernel. The
- other sections such as <literal>.set.sysctl_set</literal>
- represent other linker sets.</para>
-
- <para>By defining a variable of type <literal>struct
- linker_set</literal> the content of
- <literal>.set.sysinit_set</literal> section will be <quote>collected</quote>
- into that variable:</para>
- <programlisting><filename>sys/kern/init_main.c:</filename>
- extern struct linker_set sysinit_set; /* XXX */</programlisting>
-
- <para>The <literal>struct linker_set</literal> is defined as
- follows:</para>
-
- <programlisting><filename>/usr/include/linker_set.h:</filename>
- struct linker_set {
- int ls_length;
- void *ls_items[1]; /* really ls_length of them, trailing NULL */
-};</programlisting>
-
- <para>The first node will be equal to the number of a sysinit
- objects, and the second node will be a NULL-terminated array of
- pointers to them.</para>
-
- <para>Returning to the <function>mi_startup()</function>
- discussion, it is must be clear now, how the sysinit objects are
- being organized. The <function>mi_startup()</function> function
- sorts them and calls each. The very last object is the system
- scheduler:</para>
-
- <programlisting><filename>/usr/include/sys/kernel.h:</filename>
-enum sysinit_sub_id {
- SI_SUB_DUMMY = 0x0000000, /* not executed; for linker*/
- SI_SUB_DONE = 0x0000001, /* processed*/
- SI_SUB_CONSOLE = 0x0800000, /* console*/
- SI_SUB_COPYRIGHT = 0x0800001, /* first use of console*/
-...
- SI_SUB_RUN_SCHEDULER = 0xfffffff /* scheduler: no return*/
-};</programlisting>
-
- <para>The system scheduler sysinit object is defined in the file
- <filename>sys/vm/vm_glue.c</filename>, and the entry point for
- that object is <function>scheduler()</function>. That function
- is actually an infinite loop, and it represents a process with
- PID 0, the swapper process. The proc0 structure, mentioned
- before, is used to describe it.</para>
-
- <para>The first user process, called <emphasis>init</emphasis>, is
- created by the sysinit object <literal>init</literal>:</para>
-
- <programlisting><filename>sys/kern/init_main.c:</filename>
-static void
-create_init(const void *udata __unused)
-{
- int error;
- int s;
-
- s = splhigh();
- error = fork1(&amp;proc0, RFFDG | RFPROC, &amp;initproc);
- if (error)
- panic("cannot fork init: %d\n", error);
- initproc->p_flag |= P_INMEM | P_SYSTEM;
- cpu_set_fork_handler(initproc, start_init, NULL);
- remrunqueue(initproc);
- splx(s);
-}
-SYSINIT(init,SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL)</programlisting>
-
- <para>The <function>create_init()</function> allocates a new process
- by calling <function>fork1()</function>, but does not mark it
- runnable. When this new process is scheduled for execution by the
- scheduler, the <function>start_init()</function> will be called.
- That function is defined in <filename>init_main.c</filename>. It
- tries to load and exec the <filename>init</filename> binary,
- probing <filename>/sbin/init</filename> first, then
- <filename>/sbin/oinit</filename>,
- <filename>/sbin/init.bak</filename>, and finally
- <filename>/stand/sysinstall</filename>:</para>
-
- <programlisting><filename>sys/kern/init_main.c:</filename>
-static char init_path[MAXPATHLEN] =
-#ifdef INIT_PATH
- __XSTRING(INIT_PATH);
-#else
- "/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall";
-#endif</programlisting>
-
- </sect2>
-</sect1>
-
-</chapter>
-
-<!--
- Local Variables:
- mode: sgml
- sgml-declaration: "../chapter.decl"
- sgml-indent-data: t
- sgml-omittag: nil
- sgml-always-quote-attributes: t
- sgml-parent-document: ("../book.sgml" "part" "chapter")
- End:
--->
diff --git a/en_US.ISO8859-1/books/arch-handbook/chapters.ent b/en_US.ISO8859-1/books/arch-handbook/chapters.ent
deleted file mode 100644
index 38db6f5f93..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/chapters.ent
+++ /dev/null
@@ -1,48 +0,0 @@
-<!--
- Creates entities for each chapter in the FreeBSD Developer's
- Handbook. Each entity is named chap.foo, where foo is the value
- of the id attribute on that chapter, and corresponds to the name of
- the directory in which that chapter's .sgml file is stored.
-
- Chapters should be listed in the order in which they are referenced.
-
- $FreeBSD$
--->
-
-<!-- Part one -->
-<!ENTITY chap.introduction SYSTEM "introduction/chapter.sgml">
-<!ENTITY chap.tools SYSTEM "tools/chapter.sgml">
-<!ENTITY chap.secure SYSTEM "secure/chapter.sgml">
-<!ENTITY chap.l10n SYSTEM "l10n/chapter.sgml">
-<!ENTITY chap.policies SYSTEM "policies/chapter.sgml">
-
-<!-- Part two - IPC -->
-<!ENTITY chap.sockets SYSTEM "sockets/chapter.sgml">
-<!ENTITY chap.ipv6 SYSTEM "ipv6/chapter.sgml">
-
-<!-- Part three - Kernel -->
-<!ENTITY chap.boot SYSTEM "boot/chapter.sgml">
-<!ENTITY chap.kobj SYSTEM "kobj/chapter.sgml">
-<!ENTITY chap.sysinit SYSTEM "sysinit/chapter.sgml">
-<!ENTITY chap.locking SYSTEM "locking/chapter.sgml">
-<!ENTITY chap.vm SYSTEM "vm/chapter.sgml">
-<!ENTITY chap.dma SYSTEM "dma/chapter.sgml">
-<!ENTITY chap.kerneldebug SYSTEM "kerneldebug/chapter.sgml">
-<!ENTITY chap.jail SYSTEM "jail/chapter.sgml">
-<!ENTITY chap.mac SYSTEM "mac/chapter.sgml">
-
-<!-- Part four - Device Drivers -->
-<!ENTITY chap.driverbasics SYSTEM "driverbasics/chapter.sgml">
-<!ENTITY chap.isa SYSTEM "isa/chapter.sgml">
-<!ENTITY chap.pci SYSTEM "pci/chapter.sgml">
-<!ENTITY chap.scsi SYSTEM "scsi/chapter.sgml">
-<!ENTITY chap.usb SYSTEM "usb/chapter.sgml">
-<!ENTITY chap.newbus SYSTEM "newbus/chapter.sgml">
-<!ENTITY chap.snd SYSTEM "sound/chapter.sgml">
-
-<!-- Part five - Architectures -->
-<!ENTITY chap.x86 SYSTEM "x86/chapter.sgml">
-
-<!-- Part six - Appendices -->
-<!ENTITY chap.bibliography SYSTEM "bibliography/chapter.sgml">
-<!ENTITY chap.index SYSTEM "index.sgml">
diff --git a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml
deleted file mode 100644
index 61a425b8bd..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml
+++ /dev/null
@@ -1,392 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $FreeBSD$
--->
-
-<chapter id="driverbasics">
- <title>Writing FreeBSD Device Drivers</title>
-
- <para>This chapter was written by &a.murray; with selections from a
- variety of sources including the intro(4) manual page by
- &a.joerg;.</para>
-
- <sect1 id="driverbasics-intro">
- <title>Introduction</title>
- <para>This chapter provides a brief introduction to writing device
- drivers for FreeBSD. A device in this context is a term used
- mostly for hardware-related stuff that belongs to the system,
- like disks, printers, or a graphics display with its keyboard.
- A device driver is the software component of the operating
- system that controls a specific device. There are also
- so-called pseudo-devices where a device driver emulates the
- behavior of a device in software without any particular
- underlying hardware. Device drivers can be compiled into the
- system statically or loaded on demand through the dynamic kernel
- linker facility `kld'.</para>
-
- <para>Most devices in a Unix-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.
- In releases of FreeBSD older than 5.0-RELEASE, where
- &man.devfs.5; support is not integrated into FreeBSD,
- each device node must be
- created statically and independent of the existence of the
- associated device driver. Most device nodes on the system are
- created by running <command>MAKEDEV</command>.</para>
-
- <para>Device drivers can roughly be broken down into two
- categories; character and network device drivers.</para>
-
- </sect1>
-
- <sect1 id="driverbasics-kld">
- <title>Dynamic Kernel Linker Facility - KLD</title>
-
- <para>The kld interface allows system administrators to
- dynamically add and remove functionality from a running system.
- This allows device driver writers to load their new changes into
- a running kernel without constantly rebooting to test
- changes.</para>
-
- <para>The kld interface is used through the following
- privileged commands:
-
- <itemizedlist>
- <listitem><simpara><command>kldload</command> - loads a new kernel
- module</simpara></listitem>
- <listitem><simpara><command>kldunload</command> - unloads a kernel
- module</simpara></listitem>
- <listitem><simpara><command>kldstat</command> - lists the currently loaded
- modules</simpara></listitem>
- </itemizedlist>
- </para>
-
- <para>Skeleton Layout of a kernel module</para>
-
-<programlisting>/*
- * KLD Skeleton
- * Inspired by Andrew Reiter's Daemonnews article
- */
-
-#include &lt;sys/types.h&gt;
-#include &lt;sys/module.h&gt;
-#include &lt;sys/systm.h&gt; /* uprintf */
-#include &lt;sys/errno.h&gt;
-#include &lt;sys/param.h&gt; /* defines used in kernel.h */
-#include &lt;sys/kernel.h&gt; /* types used in module initialization */
-
-/*
- * Load handler that deals with the loading and unloading of a KLD.
- */
-
-static int
-skel_loader(struct module *m, int what, void *arg)
-{
- int err = 0;
-
- switch (what) {
- case MOD_LOAD: /* kldload */
- uprintf("Skeleton KLD loaded.\n");
- break;
- case MOD_UNLOAD:
- uprintf("Skeleton KLD unloaded.\n");
- break;
- default:
- err = EINVAL;
- break;
- }
- return(err);
-}
-
-/* Declare this module to the rest of the kernel */
-
-static moduledata_t skel_mod = {
- "skel",
- skel_loader,
- NULL
-};
-
-DECLARE_MODULE(skeleton, skel_mod, SI_SUB_KLD, SI_ORDER_ANY);</programlisting>
-
-
- <sect2>
- <title>Makefile</title>
-
- <para>FreeBSD provides a makefile include that you can use to
- quickly compile your kernel addition.</para>
-
- <programlisting>SRCS=skeleton.c
-KMOD=skeleton
-
-.include &lt;bsd.kmod.mk&gt;</programlisting>
-
- <para>Simply running <command>make</command> with this makefile
- will create a file <filename>skeleton.ko</filename> that can
- be loaded into your system by typing:
-<screen>&prompt.root; <userinput>kldload -v ./skeleton.ko</userinput></screen>
- </para>
- </sect2>
- </sect1>
-
- <sect1 id="driverbasics-access">
- <title>Accessing a device driver</title>
-
- <para>Unix provides a common set of system calls for user
- applications to use. The upper layers of the kernel dispatch
- these calls to the corresponding device driver when a user
- accesses a device node. The <command>/dev/MAKEDEV</command>
- script makes most of the device nodes for your system but if you
- are doing your own driver development it may be necessary to
- create your own device nodes with <command>mknod</command>.
- </para>
-
- <sect2>
- <title>Creating static device nodes</title>
-
- <para>The <command>mknod</command> command requires four
- arguments to create a device node. You must specify the name
- of the device node, the type of device, the major number of
- the device, and the minor number of the device.</para>
- </sect2>
-
- <sect2>
- <title>Dynamic device nodes</title>
-
- <para>The device filesystem, or devfs, provides access to the
- kernel's device namespace in the global filesystem namespace.
- This eliminates the problems of potentially having a device
- driver without a static device node, or a device node without
- an installed device driver. Devfs is still a work in
- progress, but it is already working quite nicely.</para>
- </sect2>
-
- </sect1>
-
- <sect1 id="driverbasics-char">
- <title>Character Devices</title>
-
- <para>A character device driver is one that transfers data
- directly to and from a user process. This is the most common
- type of device driver and there are plenty of simple examples in
- the source tree.</para>
-
- <para>This simple example pseudo-device remembers whatever values
- you write to it and can then supply them back to you when you
- read from it.</para>
-
- <programlisting>/*
- * Simple `echo' pseudo-device KLD
- *
- * Murray Stokely
- */
-
-#define MIN(a,b) (((a) < (b)) ? (a) : (b))
-
-#include &lt;sys/types.h&gt;
-#include &lt;sys/module.h&gt;
-#include &lt;sys/systm.h&gt; /* uprintf */
-#include &lt;sys/errno.h&gt;
-#include &lt;sys/param.h&gt; /* defines used in kernel.h */
-#include &lt;sys/kernel.h&gt; /* types used in module initialization */
-#include &lt;sys/conf.h&gt; /* cdevsw struct */
-#include &lt;sys/uio.h&gt; /* uio struct */
-#include &lt;sys/malloc.h&gt;
-
-#define BUFFERSIZE 256
-
-/* Function prototypes */
-d_open_t echo_open;
-d_close_t echo_close;
-d_read_t echo_read;
-d_write_t echo_write;
-
-/* Character device entry points */
-static struct cdevsw echo_cdevsw = {
- echo_open,
- echo_close,
- echo_read,
- echo_write,
- noioctl,
- nopoll,
- nommap,
- nostrategy,
- "echo",
- 33, /* reserved for lkms - /usr/src/sys/conf/majors */
- nodump,
- nopsize,
- D_TTY,
- -1
-};
-
-typedef struct s_echo {
- char msg[BUFFERSIZE];
- int len;
-} t_echo;
-
-/* vars */
-static dev_t sdev;
-static int len;
-static int count;
-static t_echo *echomsg;
-
-MALLOC_DECLARE(M_ECHOBUF);
-MALLOC_DEFINE(M_ECHOBUF, "echobuffer", "buffer for echo module");
-
-/*
- * This function acts is called by the kld[un]load(2) system calls to
- * determine what actions to take when a module is loaded or unloaded.
- */
-
-static int
-echo_loader(struct module *m, int what, void *arg)
-{
- int err = 0;
-
- switch (what) {
- case MOD_LOAD: /* kldload */
- sdev = make_dev(<literal>&</literal>echo_cdevsw,
- 0,
- UID_ROOT,
- GID_WHEEL,
- 0600,
- "echo");
- /* kmalloc memory for use by this driver */
- /* malloc(256,M_ECHOBUF,M_WAITOK); */
- MALLOC(echomsg, t_echo *, sizeof(t_echo), M_ECHOBUF, M_WAITOK);
- printf("Echo device loaded.\n");
- break;
- case MOD_UNLOAD:
- destroy_dev(sdev);
- FREE(echomsg,M_ECHOBUF);
- printf("Echo device unloaded.\n");
- break;
- default:
- err = EINVAL;
- break;
- }
- return(err);
-}
-
-int
-echo_open(dev_t dev, int oflags, int devtype, struct proc *p)
-{
- int err = 0;
-
- uprintf("Opened device \"echo\" successfully.\n");
- return(err);
-}
-
-int
-echo_close(dev_t dev, int fflag, int devtype, struct proc *p)
-{
- uprintf("Closing device \"echo.\"\n");
- return(0);
-}
-
-/*
- * The read function just takes the buf that was saved via
- * echo_write() and returns it to userland for accessing.
- * uio(9)
- */
-
-int
-echo_read(dev_t dev, struct uio *uio, int ioflag)
-{
- int err = 0;
- int amt;
-
- /* How big is this read operation? Either as big as the user wants,
- or as big as the remaining data */
- amt = MIN(uio->uio_resid, (echomsg->len - uio->uio_offset > 0) ? echomsg->len - uio->uio_offset : 0);
- if ((err = uiomove(echomsg->msg + uio->uio_offset,amt,uio)) != 0) {
- uprintf("uiomove failed!\n");
- }
-
- return err;
-}
-
-/*
- * echo_write takes in a character string and saves it
- * to buf for later accessing.
- */
-
-int
-echo_write(dev_t dev, struct uio *uio, int ioflag)
-{
- int err = 0;
-
- /* Copy the string in from user memory to kernel memory */
- err = copyin(uio->uio_iov->iov_base, echomsg->msg, MIN(uio->uio_iov->iov_len,BUFFERSIZE));
-
- /* Now we need to null terminate */
- *(echomsg->msg + MIN(uio->uio_iov->iov_len,BUFFERSIZE)) = 0;
- /* Record the length */
- echomsg->len = MIN(uio->uio_iov->iov_len,BUFFERSIZE);
-
- if (err != 0) {
- uprintf("Write failed: bad address!\n");
- }
-
- count++;
- return(err);
-}
-
-DEV_MODULE(echo,echo_loader,NULL);</programlisting>
-
- <para>To install this driver you will first need to make a node on
- your filesystem with a command such as:</para>
-
- <screen>&prompt.root; <userinput>mknod /dev/echo c 33 0</userinput></screen>
-
- <para>With this driver loaded you should now be able to type
- something like:</para>
-
- <screen>&prompt.root; <userinput>echo -n "Test Data" &gt; /dev/echo</userinput>
-&prompt.root; <userinput>cat /dev/echo</userinput>
-Test Data</screen>
-
- <para>Real hardware devices in the next chapter..</para>
-
- <para>Additional Resources
- <itemizedlist>
- <listitem><simpara><ulink
- url="http://www.daemonnews.org/200010/blueprints.html">Dynamic
- Kernel Linker (KLD) Facility Programming Tutorial</ulink> -
- <ulink url="http://www.daemonnews.org/">Daemonnews</ulink> October 2000</simpara></listitem>
- <listitem><simpara><ulink
- url="http://www.daemonnews.org/200007/newbus-intro.html">How
- to Write Kernel Drivers with NEWBUS</ulink> - <ulink
- url="http://www.daemonnews.org/">Daemonnews</ulink> July
- 2000</simpara></listitem>
- </itemizedlist>
- </para>
- </sect1>
-
- <sect1 id="driverbasics-net">
- <title>Network Drivers</title>
-
- <para>Drivers for network devices do not use device nodes in order
- to be accessed. Their selection is based on other decisions
- made inside the kernel and instead of calling open(), use of a
- network device is generally introduced by using the system call
- socket(2).</para>
-
- <para>man ifnet(), loopback device, Bill Paul's drivers,
- etc..</para>
-
- </sect1>
-
-</chapter>
-
-<!--
- Local Variables:
- mode: sgml
- sgml-declaration: "../chapter.decl"
- sgml-indent-data: t
- sgml-omittag: nil
- sgml-always-quote-attributes: t
- sgml-parent-document: ("../book.sgml" "part" "chapter")
- End:
--->
diff --git a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml
deleted file mode 100644
index 55469129ff..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml
+++ /dev/null
@@ -1,2487 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $FreeBSD$
--->
-
-<chapter id="isa-driver">
- <title>ISA device drivers</title>
-
- <para>
- <emphasis>
- This chapter was written by &a.babkin; Modifications for the
- handbook made by &a.murray;, &a.wylie;, and &a.logo;.
- </emphasis>
- </para>
-
- <sect1 id="isa-driver-synopsis">
- <title>Synopsis</title>
-
- <para>This chapter introduces the issues relevant to writing a
- driver for an ISA device. The pseudo-code presented here is
- rather detailed and reminiscent of the real code but is still
- only pseudo-code. It avoids the details irrelevant to the
- subject of the discussion. The real-life examples can be found
- in the source code of real drivers. In particular the drivers
- <literal>ep</literal> and <literal>aha</literal> are good sources of information.</para>
- </sect1>
-
- <sect1 id="isa-driver-basics">
- <title>Basic information</title>
-
- <para>A typical ISA driver would need the following include
- files:</para>
-
-<programlisting>#include &lt;sys/module.h&gt;
-#include &lt;sys/bus.h&gt;
-#include &lt;machine/bus.h&gt;
-#include &lt;machine/resource.h&gt;
-#include &lt;sys/rman.h&gt;
-
-#include &lt;isa/isavar.h&gt;
-#include &lt;isa/pnpvar.h&gt;</programlisting>
-
- <para>They describe the things specific to the ISA and generic
- bus subsystem.</para>
-
- <para>The bus subsystem is implemented in an object-oriented
- fashion, its main structures are accessed by associated method
- functions.</para>
-
- <para>The list of bus methods implemented by an ISA driver is like
- one for any other bus. For a hypothetical driver named <quote>xxx</quote>
- they would be:</para>
-
- <itemizedlist>
- <listitem>
- <para><function>static void xxx_isa_identify (driver_t *,
- device_t);</function> Normally used for bus drivers, not
- device drivers. But for ISA devices this method may have
- special use: if the device provides some device-specific
- (non-PnP) way to auto-detect devices this routine may
- implement it.</para>
- </listitem>
-
- <listitem>
- <para><function>static int xxx_isa_probe (device_t
- dev);</function> Probe for a device at a known (or PnP)
- location. This routine can also accommodate device-specific
- auto-detection of parameters for partially configured
- devices.</para>
- </listitem>
-
- <listitem>
- <para><function>static int xxx_isa_attach (device_t
- dev);</function> Attach and initialize device.</para>
- </listitem>
-
- <listitem>
- <para><function>static int xxx_isa_detach (device_t
- dev);</function> Detach device before unloading the driver
- module.</para>
- </listitem>
-
- <listitem>
- <para><function>static int xxx_isa_shutdown (device_t
- dev);</function> Execute shutdown of the device before
- system shutdown.</para>
- </listitem>
-
- <listitem>
- <para><function>static int xxx_isa_suspend (device_t
- dev);</function> Suspend the device before the system goes
- to the power-save state. May also abort transition to the
- power-save state.</para>
- </listitem>
-
- <listitem>
- <para><function>static int xxx_isa_resume (device_t
- dev);</function> Resume the device activity after return
- from power-save state.</para>
- </listitem>
-
- </itemizedlist>
-
- <para><function>xxx_isa_probe()</function> and
- <function>xxx_isa_attach()</function> are mandatory, the rest of
- the routines are optional, depending on the device's
- needs.</para>
-
- <para>The driver is linked to the system with the following set of
- descriptions.</para>
-
-<programlisting> /* table of supported bus methods */
- static device_method_t xxx_isa_methods[] = {
- /* list all the bus method functions supported by the driver */
- /* omit the unsupported methods */
- DEVMETHOD(device_identify, xxx_isa_identify),
- DEVMETHOD(device_probe, xxx_isa_probe),
- DEVMETHOD(device_attach, xxx_isa_attach),
- DEVMETHOD(device_detach, xxx_isa_detach),
- DEVMETHOD(device_shutdown, xxx_isa_shutdown),
- DEVMETHOD(device_suspend, xxx_isa_suspend),
- DEVMETHOD(device_resume, xxx_isa_resume),
-
- { 0, 0 }
- };
-
- static driver_t xxx_isa_driver = {
- "xxx",
- xxx_isa_methods,
- sizeof(struct xxx_softc),
- };
-
-
- static devclass_t xxx_devclass;
-
- DRIVER_MODULE(xxx, isa, xxx_isa_driver, xxx_devclass,
- load_function, load_argument);</programlisting>
-
- <para>Here struct <structname>xxx_softc</structname> is a
- device-specific structure that contains private driver data
- and descriptors for the driver's resources. The bus code
- automatically allocates one softc descriptor per device as
- needed.</para>
-
- <para>If the driver is implemented as a loadable module then
- <function>load_function()</function> is called to do
- driver-specific initialization or clean-up when the driver is
- loaded or unloaded and load_argument is passed as one of its
- arguments. If the driver does not support dynamic loading (in
- other words it must always be linked into the kernel) then these
- values should be set to 0 and the last definition would look
- like:</para>
-
- <programlisting> DRIVER_MODULE(xxx, isa, xxx_isa_driver,
- xxx_devclass, 0, 0);</programlisting>
-
- <para>If the driver is for a device which supports PnP then a
- table of supported PnP IDs must be defined. The table
- consists of a list of PnP IDs supported by this driver and
- human-readable descriptions of the hardware types and models
- having these IDs. It looks like:</para>
-
-<programlisting> static struct isa_pnp_id xxx_pnp_ids[] = {
- /* a line for each supported PnP ID */
- { 0x12345678, "Our device model 1234A" },
- { 0x12345679, "Our device model 1234B" },
- { 0, NULL }, /* end of table */
- };</programlisting>
-
- <para>If the driver does not support PnP devices it still needs
- an empty PnP ID table, like:</para>
-
-<programlisting> static struct isa_pnp_id xxx_pnp_ids[] = {
- { 0, NULL }, /* end of table */
- };</programlisting>
-
- </sect1>
-
- <sect1 id="isa-driver-device-t">
- <title>Device_t pointer</title>
-
- <para><structname>Device_t</structname> is the pointer type for
- the device structure. Here we consider only the methods
- interesting from the device driver writer's standpoint. The
- methods to manipulate values in the device structure
- are:</para>
-
- <itemizedlist>
-
- <listitem><para><function>device_t
- device_get_parent(dev)</function> Get the parent bus of a
- device.</para></listitem>
-
- <listitem><para><function>driver_t
- device_get_driver(dev)</function> Get pointer to its driver
- structure.</para></listitem>
-
- <listitem><para><function>char
- *device_get_name(dev)</function> Get the driver name, such
- as <literal>"xxx"</literal> for our example.</para></listitem>
-
- <listitem><para><function>int device_get_unit(dev)</function>
- Get the unit number (units are numbered from 0 for the
- devices associated with each driver).</para></listitem>
-
- <listitem><para><function>char
- *device_get_nameunit(dev)</function> Get the device name
- including the unit number, such as <quote>xxx0</quote>, <quote>xxx1</quote> and so
- on.</para></listitem>
-
- <listitem><para><function>char
- *device_get_desc(dev)</function> Get the device
- description. Normally it describes the exact model of device
- in human-readable form.</para></listitem>
-
- <listitem><para><function>device_set_desc(dev,
- desc)</function> Set the description. This makes the device
- description point to the string desc which may not be
- deallocated or changed after that.</para></listitem>
-
- <listitem><para><function>device_set_desc_copy(dev,
- desc)</function> Set the description. The description is
- copied into an internal dynamically allocated buffer, so the
- string desc may be changed afterwards without adverse
- effects.</para></listitem>
-
- <listitem><para><function>void
- *device_get_softc(dev)</function> Get pointer to the device
- descriptor (struct <structname>xxx_softc</structname>)
- associated with this device.</para></listitem>
-
- <listitem><para><function>u_int32_t
- device_get_flags(dev)</function> Get the flags specified for
- the device in the configuration file.</para></listitem>
-
- </itemizedlist>
-
- <para>A convenience function <function>device_printf(dev, fmt,
- ...)</function> may be used to print the messages from the
- device driver. It automatically prepends the unitname and
- colon to the message.</para>
-
- <para>The device_t methods are implemented in the file
- <filename>kern/bus_subr.c</filename>.</para>
-
- </sect1>
-
- <sect1 id="isa-driver-config">
- <title>Configuration file and the order of identifying and probing
- during auto-configuration</title>
-
- <para>The ISA devices are described in the kernel configuration file
- like:</para>
-
- <programlisting>device xxx0 at isa? port 0x300 irq 10 drq 5
- iomem 0xd0000 flags 0x1 sensitive</programlisting>
-
- <para>The values of port, IRQ and so on are converted to the
- resource values associated with the device. They are optional,
- depending on the device's needs and abilities for
- auto-configuration. For example, some devices do not need DRQ
- at all and some allow the driver to read the IRQ setting from
- the device configuration ports. If a machine has multiple ISA
- buses the exact bus may be specified in the configuration
- line, like <literal>isa0</literal> or <literal>isa1</literal>, otherwise the device would be
- searched for on all the ISA buses.</para>
-
- <para><literal>sensitive</literal> is a resource requesting that this device must
- be probed before all non-sensitive devices. It is supported
- but does not seem to be used in any current driver.</para>
-
- <para>For legacy ISA devices in many cases the drivers are still
- able to detect the configuration parameters. But each device
- to be configured in the system must have a config line. If two
- devices of some type are installed in the system but there is
- only one configuration line for the corresponding driver, ie:
- <programlisting>device xxx0 at isa?</programlisting> then only
- one device will be configured.</para>
-
- <para>But for the devices supporting automatic identification by
- the means of Plug-n-Play or some proprietary protocol one
- configuration line is enough to configure all the devices in
- the system, like the one above or just simply:</para>
-
- <programlisting>device xxx at isa?</programlisting>
-
- <para>If a driver supports both auto-identified and legacy
- devices and both kinds are installed at once in one machine
- then it is enough to describe in the config file the legacy
- devices only. The auto-identified devices will be added
- automatically.</para>
-
- <para>When an ISA bus is auto-configured the events happen as
- follows:</para>
-
- <para>All the drivers' identify routines (including the PnP
- identify routine which identifies all the PnP devices) are
- called in random order. As they identify the devices they add
- them to the list on the ISA bus. Normally the drivers'
- identify routines associate their drivers with the new
- devices. The PnP identify routine does not know about the
- other drivers yet so it does not associate any with the new
- devices it adds.</para>
-
- <para>The PnP devices are put to sleep using the PnP protocol to
- prevent them from being probed as legacy devices.</para>
-
- <para>The probe routines of non-PnP devices marked as
- <literal>sensitive</literal> are called. If probe for a device went
- successfully, the attach routine is called for it.</para>
-
- <para>The probe and attach routines of all non-PNP devices are
- called likewise.</para>
-
- <para>The PnP devices are brought back from the sleep state and
- assigned the resources they request: I/O and memory address
- ranges, IRQs and DRQs, all of them not conflicting with the
- attached legacy devices.</para>
-
- <para>Then for each PnP device the probe routines of all the
- present ISA drivers are called. The first one that claims the
- device gets attached. It is possible that multiple drivers
- would claim the device with different priority; in this case, the
- highest-priority driver wins. The probe routines must call
- <function>ISA_PNP_PROBE()</function> to compare the actual PnP
- ID with the list of the IDs supported by the driver and if the
- ID is not in the table return failure. That means that
- absolutely every driver, even the ones not supporting any PnP
- devices must call <function>ISA_PNP_PROBE()</function>, at
- least with an empty PnP ID table to return failure on unknown
- PnP devices.</para>
-
- <para>The probe routine returns a positive value (the error
- code) on error, zero or negative value on success.</para>
-
- <para>The negative return values are used when a PnP device
- supports multiple interfaces. For example, an older
- compatibility interface and a newer advanced interface which
- are supported by different drivers. Then both drivers would
- detect the device. The driver which returns a higher value in
- the probe routine takes precedence (in other words, the driver
- returning 0 has highest precedence, returning -1 is next,
- returning -2 is after it and so on). In result the devices
- which support only the old interface will be handled by the
- old driver (which should return -1 from the probe routine)
- while the devices supporting the new interface as well will be
- handled by the new driver (which should return 0 from the
- probe routine). If multiple drivers return the same value then
- the one called first wins. So if a driver returns value 0 it
- may be sure that it won the priority arbitration.</para>
-
- <para>The device-specific identify routines can also assign not
- a driver but a class of drivers to the device. Then all the
- drivers in the class are probed for this device, like the case
- with PnP. This feature is not implemented in any existing
- driver and is not considered further in this document.</para>
-
- <para>Because the PnP devices are disabled when probing the
- legacy devices they will not be attached twice (once as legacy
- and once as PnP). But in case of device-dependent identify
- routines it is the responsibility of the driver to make sure
- that the same device will not be attached by the driver twice:
- once as legacy user-configured and once as
- auto-identified.</para>
-
- <para>Another practical consequence for the auto-identified
- devices (both PnP and device-specific) is that the flags can
- not be passed to them from the kernel configuration file. So
- they must either not use the flags at all or use the flags
- from the device unit 0 for all the auto-identified devices or
- use the sysctl interface instead of flags.</para>
-
- <para>Other unusual configurations may be accommodated by
- accessing the configuration resources directly with functions
- of families <function>resource_query_*()</function> and
- <function>resource_*_value()</function>. Their implementations
- are located in <filename>kern/subr_bus.c</filename>. The old IDE disk driver
- <filename>i386/isa/wd.c</filename> contains examples of such use. But the standard
- means of configuration must always be preferred. Leave parsing
- the configuration resources to the bus configuration
- code.</para>
-
- </sect1>
-
- <sect1 id="isa-driver-resources">
- <title>Resources</title>
-
- <para>The information that a user enters into the kernel
- configuration file is processed and passed to the kernel as
- configuration resources. This information is parsed by the bus
- configuration code and transformed into a value of structure
- device_t and the bus resources associated with it. The drivers
- may access the configuration resources directly using
- functions resource_* for more complex cases of
- configuration. However, generally this is neither needed nor recommended,
- so this issue is not discussed further here.</para>
-
- <para>The bus resources are associated with each device. They
- are identified by type and number within the type. For the ISA
- bus the following types are defined:</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>SYS_RES_IRQ</emphasis> - interrupt
- number</para>
- </listitem>
-
- <listitem>
- <para><emphasis>SYS_RES_DRQ</emphasis> - ISA DMA channel
- number</para>
- </listitem>
-
- <listitem>
- <para><emphasis>SYS_RES_MEMORY</emphasis> - range of
- device memory mapped into the system memory space
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis>SYS_RES_IOPORT</emphasis> - range of
- device I/O registers</para>
- </listitem>
- </itemizedlist>
-
- <para>The enumeration within types starts from 0, so if a device
- has two memory regions it would have resources of type
- SYS_RES_MEMORY numbered 0 and 1. The resource type has
- nothing to do with the C language type, all the resource
- values have the C language type <literal>unsigned long</literal> and must be
- cast as necessary. The resource numbers do not have to be
- contiguous, although for ISA they normally would be. The
- permitted resource numbers for ISA devices are:</para>
-
- <programlisting> IRQ: 0-1
- DRQ: 0-1
- MEMORY: 0-3
- IOPORT: 0-7</programlisting>
-
- <para>All the resources are represented as ranges, with a start
- value and count. For IRQ and DRQ resources the count would
- normally be equal to 1. The values for memory refer to the
- physical addresses.</para>
-
- <para>Three types of activities can be performed on
- resources:</para>
-
- <itemizedlist>
- <listitem><para>set/get</para></listitem>
- <listitem><para>allocate/release</para></listitem>
- <listitem><para>activate/deactivate</para></listitem>
- </itemizedlist>
-
- <para>Setting sets the range used by the resource. Allocation
- reserves the requested range that no other driver would be
- able to reserve it (and checking that no other driver reserved
- this range already). Activation makes the resource accessible
- to the driver by doing whatever is necessary for that (for
- example, for memory it would be mapping into the kernel
- virtual address space).</para>
-
- <para>The functions to manipulate resources are:</para>
-
- <itemizedlist>
- <listitem>
- <para><function>int bus_set_resource(device_t dev, int type,
- int rid, u_long start, u_long count)</function></para>
-
- <para>Set a range for a resource. Returns 0 if successful,
- error code otherwise. Normally, this function will
- return an error only if one of <literal>type</literal>,
- <literal>rid</literal>, <literal>start</literal> or
- <literal>count</literal> has a value that falls out of the
- permitted range.</para>
-
- <itemizedlist>
- <listitem>
- <para> dev - driver's device</para>
- </listitem>
- <listitem>
- <para> type - type of resource, SYS_RES_* </para>
- </listitem>
- <listitem>
- <para> rid - resource number (ID) within type </para>
- </listitem>
- <listitem>
- <para> start, count - resource range </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para><function>int bus_get_resource(device_t dev, int type,
- int rid, u_long *startp, u_long *countp)</function></para>
-
- <para>Get the range of resource. Returns 0 if successful,
- error code if the resource is not defined yet.</para>
- </listitem>
-
- <listitem>
- <para><function>u_long bus_get_resource_start(device_t dev,
- int type, int rid) u_long bus_get_resource_count (device_t
- dev, int type, int rid)</function></para>
-
- <para>Convenience functions to get only the start or
- count. Return 0 in case of error, so if the resource start
- has 0 among the legitimate values it would be impossible
- to tell if the value is 0 or an error occurred. Luckily,
- no ISA resources for add-on drivers may have a start value
- equal to 0.</para>
- </listitem>
-
- <listitem>
- <para><function>void bus_delete_resource(device_t dev, int
- type, int rid)</function></para>
- <para> Delete a resource, make it undefined.</para>
- </listitem>
-
- <listitem>
- <para><function>struct resource *
- bus_alloc_resource(device_t dev, int type, int *rid,
- u_long start, u_long end, u_long count, u_int
- flags)</function></para>
-
- <para>Allocate a resource as a range of count values not
- allocated by anyone else, somewhere between start and
- end. Alas, alignment is not supported. If the resource
- was not set yet it is automatically created. The special
- values of start 0 and end ~0 (all ones) means that the
- fixed values previously set by
- <function>bus_set_resource()</function> must be used
- instead: start and count as themselves and
- end=(start+count), in this case if the resource was not
- defined before then an error is returned. Although rid is
- passed by reference it is not set anywhere by the resource
- allocation code of the ISA bus. (The other buses may use a
- different approach and modify it).</para>
- </listitem>
- </itemizedlist>
-
- <para>Flags are a bitmap, the flags interesting for the caller
- are:</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>RF_ACTIVE</emphasis> - causes the resource
- to be automatically activated after allocation.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>RF_SHAREABLE</emphasis> - resource may be
- shared at the same time by multiple drivers.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>RF_TIMESHARE</emphasis> - resource may be
- time-shared by multiple drivers, i.e. allocated at the
- same time by many but activated only by one at any given
- moment of time.</para>
- </listitem>
-<!-- XXXDONT KNOW IT THESE SHOULD BE TWO SEPARATE LISTS OR NOT -->
- <listitem>
- <para>Returns 0 on error. The allocated values may be
- obtained from the returned handle using methods
- <function>rhand_*()</function>.</para>
- </listitem>
- <listitem>
- <para><function>int bus_release_resource(device_t dev, int
- type, int rid, struct resource *r)</function></para>
- </listitem>
-
- <listitem>
- <para>Release the resource, r is the handle returned by
- <function>bus_alloc_resource()</function>. Returns 0 on
- success, error code otherwise.</para>
- </listitem>
-
- <listitem>
- <para><function>int bus_activate_resource(device_t dev, int
- type, int rid, struct resource *r)</function>
- <function>int bus_deactivate_resource(device_t dev, int
- type, int rid, struct resource *r)</function></para>
- </listitem>
-
- <listitem>
- <para>Activate or deactivate resource. Return 0 on success,
- error code otherwise. If the resource is time-shared and
- currently activated by another driver then EBUSY is
- returned.</para>
- </listitem>
-
- <listitem>
- <para><function>int bus_setup_intr(device_t dev, struct
- resource *r, int flags, driver_intr_t *handler, void *arg,
- void **cookiep)</function> <function>int
- bus_teardown_intr(device_t dev, struct resource *r, void
- *cookie)</function></para>
- </listitem>
-
- <listitem>
- <para>Associate or de-associate the interrupt handler with a
- device. Return 0 on success, error code otherwise.</para>
- </listitem>
-
- <listitem>
- <para>r - the activated resource handler describing the
- IRQ</para>
- <para>flags - the interrupt priority level, one of:</para>
-
- <itemizedlist>
- <listitem>
- <para><function>INTR_TYPE_TTY</function> - terminals and
- other likewise character-type devices. To mask them
- use <function>spltty()</function>.</para>
- </listitem>
- <listitem>
- <para><function>(INTR_TYPE_TTY |
- INTR_TYPE_FAST)</function> - terminal type devices
- with small input buffer, critical to the data loss on
- input (such as the old-fashioned serial ports). To
- mask them use <function>spltty()</function>.</para>
- </listitem>
- <listitem>
- <para><function>INTR_TYPE_BIO</function> - block-type
- devices, except those on the CAM controllers. To mask
- them use <function>splbio()</function>.</para>
- </listitem>
- <listitem>
- <para><function>INTR_TYPE_CAM</function> - CAM (Common
- Access Method) bus controllers. To mask them use
- <function>splcam()</function>.</para>
- </listitem>
- <listitem>
- <para><function>INTR_TYPE_NET</function> - network
- interface controllers. To mask them use
- <function>splimp()</function>.</para>
- </listitem>
- <listitem>
- <para><function>INTR_TYPE_MISC</function> -
- miscellaneous devices. There is no other way to mask
- them than by <function>splhigh()</function> which
- masks all interrupts.</para>
- </listitem>
- </itemizedlist>
- </listitem>
- </itemizedlist>
-
- <para>When an interrupt handler executes all the other
- interrupts matching its priority level will be masked. The
- only exception is the MISC level for which no other interrupts
- are masked and which is not masked by any other
- interrupt.</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>handler</emphasis> - pointer to the handler
- function, the type driver_intr_t is defined as <function>void
- driver_intr_t(void *)</function></para>
- </listitem>
- <listitem>
- <para><emphasis>arg</emphasis> - the argument passed to the
- handler to identify this particular device. It is cast
- from void* to any real type by the handler. The old
- convention for the ISA interrupt handlers was to use the
- unit number as argument, the new (recommended) convention
- is using a pointer to the device softc structure.</para>
- </listitem>
- <listitem>
- <para><emphasis>cookie[p]</emphasis> - the value received
- from <function>setup()</function> is used to identify the
- handler when passed to
- <function>teardown()</function></para>
- </listitem>
- </itemizedlist>
-
- <para>A number of methods are defined to operate on the resource
- handlers (struct resource *). Those of interest to the device
- driver writers are:</para>
-
- <itemizedlist>
- <listitem>
- <para><function>u_long rman_get_start(r) u_long
- rman_get_end(r)</function> Get the start and end of
- allocated resource range.</para>
- </listitem>
- <listitem>
- <para><function>void *rman_get_virtual(r)</function> Get
- the virtual address of activated memory resource.</para>
- </listitem>
- </itemizedlist>
-
- </sect1>
-
- <sect1 id="isa-driver-busmem">
- <title>Bus memory mapping</title>
-
- <para>In many cases data is exchanged between the driver and the
- device through the memory. Two variants are possible:</para>
-
- <para>(a) memory is located on the device card</para>
- <para>(b) memory is the main memory of the computer</para>
-
- <para>In case (a) the driver always copies the data back and
- forth between the on-card memory and the main memory as
- necessary. To map the on-card memory into the kernel virtual
- address space the physical address and length of the on-card
- memory must be defined as a SYS_RES_MEMORY resource. That
- resource can then be allocated and activated, and its virtual
- address obtained using
- <function>rman_get_virtual()</function>. The older drivers
- used the function <function>pmap_mapdev()</function> for this
- purpose, which should not be used directly any more. Now it is
- one of the internal steps of resource activation.</para>
-
- <para>Most of the ISA cards will have their memory configured
- for physical location somewhere in range 640KB-1MB. Some of
- the ISA cards require larger memory ranges which should be
- placed somewhere under 16MB (because of the 24-bit address
- limitation on the ISA bus). In that case if the machine has
- more memory than the start address of the device memory (in
- other words, they overlap) a memory hole must be configured at
- the address range used by devices. Many BIOSes allow
- configuration of a memory hole of 1MB starting at 14MB or
- 15MB. FreeBSD can handle the memory holes properly if the BIOS
- reports them properly (this feature may be broken on old BIOSes).</para>
-
- <para>In case (b) just the address of the data is sent to
- the device, and the device uses DMA to actually access the
- data in the main memory. Two limitations are present: First,
- ISA cards can only access memory below 16MB. Second, the
- contiguous pages in virtual address space may not be
- contiguous in physical address space, so the device may have
- to do scatter/gather operations. The bus subsystem provides
- ready solutions for some of these problems, the rest has to be
- done by the drivers themselves.</para>
-
- <para>Two structures are used for DMA memory allocation,
- bus_dma_tag_t and bus_dmamap_t. Tag describes the properties
- required for the DMA memory. Map represents a memory block
- allocated according to these properties. Multiple maps may be
- associated with the same tag.</para>
-
- <para>Tags are organized into a tree-like hierarchy with
- inheritance of the properties. A child tag inherits all the
- requirements of its parent tag, and may make them more strict
- but never more loose.</para>
-
- <para>Normally one top-level tag (with no parent) is created for
- each device unit. If multiple memory areas with different
- requirements are needed for each device then a tag for each of
- them may be created as a child of the parent tag.</para>
-
- <para>The tags can be used to create a map in two ways.</para>
-
- <para>First, a chunk of contiguous memory conformant with the
- tag requirements may be allocated (and later may be
- freed). This is normally used to allocate relatively
- long-living areas of memory for communication with the
- device. Loading of such memory into a map is trivial: it is
- always considered as one chunk in the appropriate physical
- memory range.</para>
-
- <para>Second, an arbitrary area of virtual memory may be loaded
- into a map. Each page of this memory will be checked for
- conformance to the map requirement. If it conforms then it is
- left at its original location. If it is not then a fresh
- conformant <quote>bounce page</quote> is allocated and used as intermediate
- storage. When writing the data from the non-conformant
- original pages they will be copied to their bounce pages first
- and then transferred from the bounce pages to the device. When
- reading the data would go from the device to the bounce pages
- and then copied to their non-conformant original pages. The
- process of copying between the original and bounce pages is
- called synchronization. This is normally used on a per-transfer
- basis: buffer for each transfer would be loaded, transfer done
- and buffer unloaded.</para>
-
- <para>The functions working on the DMA memory are:</para>
-
- <itemizedlist>
- <listitem>
- <para><function>int bus_dma_tag_create(bus_dma_tag_t parent,
- bus_size_t alignment, bus_size_t boundary, bus_addr_t
- lowaddr, bus_addr_t highaddr, bus_dma_filter_t *filter, void
- *filterarg, bus_size_t maxsize, int nsegments, bus_size_t
- maxsegsz, int flags, bus_dma_tag_t *dmat)</function></para>
-
- <para>Create a new tag. Returns 0 on success, the error code
- otherwise.</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>parent</emphasis> - parent tag, or NULL to
- create a top-level tag.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>alignment</emphasis> -
- required physical alignment of the memory area to be
- allocated for this tag. Use value 1 for <quote>no specific
- alignment</quote>. Applies only to the future
- <function>bus_dmamem_alloc()</function> but not
- <function>bus_dmamap_create()</function> calls.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>boundary</emphasis> - physical address
- boundary that must not be crossed when allocating the
- memory. Use value 0 for <quote>no boundary</quote>. Applies only to
- the future <function>bus_dmamem_alloc()</function> but
- not <function>bus_dmamap_create()</function> calls.
- Must be power of 2. If the memory is planned to be used
- in non-cascaded DMA mode (i.e. the DMA addresses will be
- supplied not by the device itself but by the ISA DMA
- controller) then the boundary must be no larger than
- 64KB (64*1024) due to the limitations of the DMA
- hardware.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>lowaddr, highaddr</emphasis> - the names
- are slightly misleading; these values are used to limit
- the permitted range of physical addresses used to
- allocate the memory. The exact meaning varies depending
- on the planned future use:</para>
-
- <itemizedlist>
- <listitem>
- <para>For <function>bus_dmamem_alloc()</function> all
- the addresses from 0 to lowaddr-1 are considered
- permitted, the higher ones are forbidden.</para>
- </listitem>
-
- <listitem>
- <para>For <function>bus_dmamap_create()</function> all
- the addresses outside the inclusive range [lowaddr;
- highaddr] are considered accessible. The addresses
- of pages inside the range are passed to the filter
- function which decides if they are accessible. If no
- filter function is supplied then all the range is
- considered unaccessible.</para>
- </listitem>
-
- <listitem>
- <para>For the ISA devices the normal values (with no
- filter function) are:</para>
- <para>lowaddr = BUS_SPACE_MAXADDR_24BIT</para>
- <para>highaddr = BUS_SPACE_MAXADDR</para>
- </listitem>
- </itemizedlist>
-
- </listitem>
-
- <listitem>
- <para><emphasis>filter, filterarg</emphasis> - the filter
- function and its argument. If NULL is passed for filter
- then the whole range [lowaddr, highaddr] is considered
- unaccessible when doing
- <function>bus_dmamap_create()</function>. Otherwise the
- physical address of each attempted page in range
- [lowaddr; highaddr] is passed to the filter function
- which decides if it is accessible. The prototype of the
- filter function is: <function>int filterfunc(void *arg,
- bus_addr_t paddr)</function>. It must return 0 if the
- page is accessible, non-zero otherwise.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>maxsize</emphasis> - the maximal size of
- memory (in bytes) that may be allocated through this
- tag. In case it is difficult to estimate or could be
- arbitrarily big, the value for ISA devices would be
- BUS_SPACE_MAXSIZE_24BIT.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>nsegments</emphasis> - maximal number of
- scatter-gather segments supported by the device. If
- unrestricted then the value BUS_SPACE_UNRESTRICTED
- should be used. This value is recommended for the parent
- tags, the actual restrictions would then be specified
- for the descendant tags. Tags with nsegments equal to
- BUS_SPACE_UNRESTRICTED may not be used to actually load
- maps, they may be used only as parent tags. The
- practical limit for nsegments seems to be about 250-300,
- higher values will cause kernel stack overflow (the hardware
- can not normally support that many
- scatter-gather buffers anyway).</para>
- </listitem>
-
- <listitem>
- <para><emphasis>maxsegsz</emphasis> - maximal size of a
- scatter-gather segment supported by the device. The
- maximal value for ISA device would be
- BUS_SPACE_MAXSIZE_24BIT.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>flags</emphasis> - a bitmap of flags. The
- only interesting flags are:</para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>BUS_DMA_ALLOCNOW</emphasis> - requests
- to allocate all the potentially needed bounce pages
- when creating the tag.</para>
- </listitem>
-
- <listitem>
- <para><emphasis>BUS_DMA_ISA</emphasis> - mysterious
- flag used only on Alpha machines. It is not defined
- for the i386 machines. Probably it should be used
- by all the ISA drivers for Alpha machines but it
- looks like there are no such drivers yet.</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para><emphasis>dmat</emphasis> - pointer to the storage
- for the new tag to be returned.</para>
- </listitem>
-
- </itemizedlist>
-
- </listitem>
-
- <listitem> <!-- Second entry in list alpha -->
- <para><function>int bus_dma_tag_destroy(bus_dma_tag_t
- dmat)</function></para>
-
- <para>Destroy a tag. Returns 0 on success, the error code
- otherwise.</para>
-
- <para>dmat - the tag to be destroyed.</para>
-
- </listitem>
-
- <listitem> <!-- Third entry in list alpha -->
- <para><function>int bus_dmamem_alloc(bus_dma_tag_t dmat,
- void** vaddr, int flags, bus_dmamap_t
- *mapp)</function></para>
-
- <para>Allocate an area of contiguous memory described by the
- tag. The size of memory to be allocated is tag's maxsize.
- Returns 0 on success, the error code otherwise. The result
- still has to be loaded by
- <function>bus_dmamap_load()</function> before being used to get
- the physical address of the memory.</para>
-
-<!-- XXX What it is Wylie, I got to here -->
-
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>dmat</emphasis> - the tag
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>vaddr</emphasis> - pointer to the storage
- for the kernel virtual address of the allocated area
- to be returned.
- </para>
- </listitem>
- <listitem>
- <para>
- flags - a bitmap of flags. The only interesting flag is:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>BUS_DMA_NOWAIT</emphasis> - if the
- memory is not immediately available return the
- error. If this flag is not set then the routine
- is allowed to sleep until the memory
- becomes available.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para>
- <emphasis>mapp</emphasis> - pointer to the storage
- for the new map to be returned.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem> <!-- Fourth entry in list alpha -->
- <para>
- <function>void bus_dmamem_free(bus_dma_tag_t dmat, void
- *vaddr, bus_dmamap_t map)</function>
- </para>
- <para>
- Free the memory allocated by
- <function>bus_dmamem_alloc()</function>. At present,
- freeing of the memory allocated with ISA restrictions is
- not implemented. Because of this the recommended model
- of use is to keep and re-use the allocated areas for as
- long as possible. Do not lightly free some area and then
- shortly allocate it again. That does not mean that
- <function>bus_dmamem_free()</function> should not be
- used at all: hopefully it will be properly implemented
- soon.
- </para>
-
- <itemizedlist>
- <listitem>
- <para><emphasis>dmat</emphasis> - the tag
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>vaddr</emphasis> - the kernel virtual
- address of the memory
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>map</emphasis> - the map of the memory (as
- returned from
- <function>bus_dmamem_alloc()</function>)
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem> <!-- The fifth entry in list alpha -->
- <para>
- <function>int bus_dmamap_create(bus_dma_tag_t dmat, int
- flags, bus_dmamap_t *mapp)</function>
- </para>
- <para>
- Create a map for the tag, to be used in
- <function>bus_dmamap_load()</function> later. Returns 0
- on success, the error code otherwise.
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>dmat</emphasis> - the tag
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>flags</emphasis> - theoretically, a bit map
- of flags. But no flags are defined yet, so at present
- it will be always 0.
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>mapp</emphasis> - pointer to the storage
- for the new map to be returned
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem> <!-- Sixth entry in the alpha list -->
- <para>
- <function>int bus_dmamap_destroy(bus_dma_tag_t dmat,
- bus_dmamap_t map)</function>
- </para>
- <para>
- Destroy a map. Returns 0 on success, the error code otherwise.
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- dmat - the tag to which the map is associated
- </para>
- </listitem>
- <listitem>
- <para>
- map - the map to be destroyed
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem> <!-- Seventh entry in list alpha -->
- <para>
- <function>int bus_dmamap_load(bus_dma_tag_t dmat,
- bus_dmamap_t map, void *buf, bus_size_t buflen,
- bus_dmamap_callback_t *callback, void *callback_arg, int
- flags)</function>
- </para>
- <para>
- Load a buffer into the map (the map must be previously
- created by <function>bus_dmamap_create()</function> or
- <function>bus_dmamem_alloc()</function>). All the pages
- of the buffer are checked for conformance to the tag
- requirements and for those not conformant the bounce
- pages are allocated. An array of physical segment
- descriptors is built and passed to the callback
- routine. This callback routine is then expected to
- handle it in some way. The number of bounce buffers in
- the system is limited, so if the bounce buffers are
- needed but not immediately available the request will be
- queued and the callback will be called when the bounce
- buffers will become available. Returns 0 if the callback
- was executed immediately or EINPROGRESS if the request
- was queued for future execution. In the latter case the
- synchronization with queued callback routine is the
- responsibility of the driver.
- </para>
- <!--<blockquote>-->
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>dmat</emphasis> - the tag
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>map</emphasis> - the map
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>buf</emphasis> - kernel virtual address of
- the buffer
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>buflen</emphasis> - length of the buffer
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>callback</emphasis>,<function>
- callback_arg</function> - the callback function and
- its argument
- </para>
- </listitem>
- </itemizedlist>
- <!--</blockquote>-->
- <para>
- The prototype of callback function is:
- </para>
- <para>
- <function>void callback(void *arg, bus_dma_segment_t
- *seg, int nseg, int error)</function>
- </para>
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>arg</emphasis> - the same as callback_arg
- passed to <function>bus_dmamap_load()</function>
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>seg</emphasis> - array of the segment
- descriptors
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>nseg</emphasis> - number of descriptors in
- array
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>error</emphasis> - indication of the
- segment number overflow: if it is set to EFBIG then
- the buffer did not fit into the maximal number of
- segments permitted by the tag. In this case only the
- permitted number of descriptors will be in the
- array. Handling of this situation is up to the
- driver: depending on the desired semantics it can
- either consider this an error or split the buffer in
- two and handle the second part separately
- </para>
- </listitem>
- </itemizedlist>
- <!-- </blockquote> -->
- <para>
- Each entry in the segments array contains the fields:
- </para>
-
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>ds_addr</emphasis> - physical bus address
- of the segment
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>ds_len</emphasis> - length of the segment
- </para>
- </listitem>
- </itemizedlist>
- <!-- </blockquote>-->
- </listitem>
-
- <listitem> <!-- Eighth entry in alpha list -->
- <para>
- <function>void bus_dmamap_unload(bus_dma_tag_t dmat,
- bus_dmamap_t map)</function>
- </para>
- <para>unload the map.
- </para>
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>dmat</emphasis> - tag
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>map</emphasis> - loaded map
- </para>
- </listitem>
- </itemizedlist>
- <!-- </blockquote> -->
- </listitem>
-
- <listitem> <!-- Ninth entry list alpha -->
- <para>
- <function>void bus_dmamap_sync (bus_dma_tag_t dmat,
- bus_dmamap_t map, bus_dmasync_op_t op)</function>
- </para>
- <para>
- Synchronise a loaded buffer with its bounce pages before
- and after physical transfer to or from device. This is
- the function that does all the necessary copying of data
- between the original buffer and its mapped version. The
- buffers must be synchronized both before and after doing
- the transfer.
- </para>
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>dmat</emphasis> - tag
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>map</emphasis> - loaded map
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>op</emphasis> - type of synchronization
- operation to perform:
- </para>
- </listitem>
- </itemizedlist>
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- <function>BUS_DMASYNC_PREREAD</function> - before
- reading from device into buffer
- </para>
- </listitem>
- <listitem>
- <para>
- <function>BUS_DMASYNC_POSTREAD</function> - after
- reading from device into buffer
- </para>
- </listitem>
- <listitem>
- <para>
- <function>BUS_DMASYNC_PREWRITE</function> - before
- writing the buffer to device
- </para>
- </listitem>
- <listitem>
- <para>
- <function>BUS_DMASYNC_POSTWRITE</function> - after
- writing the buffer to device
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
- </itemizedlist> <!-- End of list alpha -->
-<!-- </blockquote>
-</blockquote> -->
-
- <para>
- As of now PREREAD and POSTWRITE are null operations but that
- may change in the future, so they must not be ignored in the
- driver. Synchronization is not needed for the memory
- obtained from <function>bus_dmamem_alloc()</function>.
- </para>
- <para>
- Before calling the callback function from
- <function>bus_dmamap_load()</function> the segment array is
- stored in the stack. And it gets pre-allocated for the
- maximal number of segments allowed by the tag. Because of
- this the practical limit for the number of segments on i386
- architecture is about 250-300 (the kernel stack is 4KB minus
- the size of the user structure, size of a segment array
- entry is 8 bytes, and some space must be left). Because the
- array is allocated based on the maximal number this value
- must not be set higher than really needed. Fortunately, for
- most of hardware the maximal supported number of segments is
- much lower. But if the driver wants to handle buffers with a
- very large number of scatter-gather segments it should do
- that in portions: load part of the buffer, transfer it to
- the device, load next part of the buffer, and so on.
- </para>
- <para>
- Another practical consequence is that the number of segments
- may limit the size of the buffer. If all the pages in the
- buffer happen to be physically non-contiguous then the
- maximal supported buffer size for that fragmented case would
- be (nsegments * page_size). For example, if a maximal number
- of 10 segments is supported then on i386 maximal guaranteed
- supported buffer size would be 40K. If a higher size is
- desired then special tricks should be used in the driver.
- </para>
- <para>
- If the hardware does not support scatter-gather at all or
- the driver wants to support some buffer size even if it is
- heavily fragmented then the solution is to allocate a
- contiguous buffer in the driver and use it as intermediate
- storage if the original buffer does not fit.
- </para>
- <para>
- Below are the typical call sequences when using a map depend
- on the use of the map. The characters -> are used to show
- the flow of time.
- </para>
- <para>
- For a buffer which stays practically fixed during all the
- time between attachment and detachment of a device:</para>
- <para>
- bus_dmamem_alloc -> bus_dmamap_load -> ...use buffer... ->
- -> bus_dmamap_unload -> bus_dmamem_free
- </para>
-
- <para>For a buffer that changes frequently and is passed from
- outside the driver:
-
- <!-- XXX is this correct? -->
- <programlisting> bus_dmamap_create ->
- -> bus_dmamap_load -> bus_dmamap_sync(PRE...) -> do transfer ->
- -> bus_dmamap_sync(POST...) -> bus_dmamap_unload ->
- ...
- -> bus_dmamap_load -> bus_dmamap_sync(PRE...) -> do transfer ->
- -> bus_dmamap_sync(POST...) -> bus_dmamap_unload ->
- -> bus_dmamap_destroy </programlisting>
-
- </para>
- <para>
- When loading a map created by
- <function>bus_dmamem_alloc()</function> the passed address
- and size of the buffer must be the same as used in
- <function>bus_dmamem_alloc()</function>. In this case it is
- guaranteed that the whole buffer will be mapped as one
- segment (so the callback may be based on this assumption)
- and the request will be executed immediately (EINPROGRESS
- will never be returned). All the callback needs to do in
- this case is to save the physical address.
- </para>
- <para>
- A typical example would be:
- </para>
-
- <programlisting> static void
- alloc_callback(void *arg, bus_dma_segment_t *seg, int nseg, int error)
- {
- *(bus_addr_t *)arg = seg[0].ds_addr;
- }
-
- ...
- int error;
- struct somedata {
- ....
- };
- struct somedata *vsomedata; /* virtual address */
- bus_addr_t psomedata; /* physical bus-relative address */
- bus_dma_tag_t tag_somedata;
- bus_dmamap_t map_somedata;
- ...
-
- error=bus_dma_tag_create(parent_tag, alignment,
- boundary, lowaddr, highaddr, /*filter*/ NULL, /*filterarg*/ NULL,
- /*maxsize*/ sizeof(struct somedata), /*nsegments*/ 1,
- /*maxsegsz*/ sizeof(struct somedata), /*flags*/ 0,
- &#38;tag_somedata);
- if(error)
- return error;
-
- error = bus_dmamem_alloc(tag_somedata, &#38;vsomedata, /* flags*/ 0,
- &#38;map_somedata);
- if(error)
- return error;
-
- bus_dmamap_load(tag_somedata, map_somedata, (void *)vsomedata,
- sizeof (struct somedata), alloc_callback,
- (void *) &#38;psomedata, /*flags*/0); </programlisting>
-
- <para>
- Looks a bit long and complicated but that is the way to do
- it. The practical consequence is: if multiple memory areas
- are allocated always together it would be a really good idea
- to combine them all into one structure and allocate as one
- (if the alignment and boundary limitations permit).
- </para>
- <para>
- When loading an arbitrary buffer into the map created by
- <function>bus_dmamap_create()</function> special measures
- must be taken to synchronize with the callback in case it
- would be delayed. The code would look like:
- </para>
-
- <programlisting> {
- int s;
- int error;
-
- s = splsoftvm();
- error = bus_dmamap_load(
- dmat,
- dmamap,
- buffer_ptr,
- buffer_len,
- callback,
- /*callback_arg*/ buffer_descriptor,
- /*flags*/0);
- if (error == EINPROGRESS) {
- /*
- * Do whatever is needed to ensure synchronization
- * with callback. Callback is guaranteed not to be started
- * until we do splx() or tsleep().
- */
- }
- splx(s);
- } </programlisting>
-
- <para>
- Two possible approaches for the processing of requests are:
- </para>
- <para>
- 1. If requests are completed by marking them explicitly as
- done (such as the CAM requests) then it would be simpler to
- put all the further processing into the callback driver
- which would mark the request when it is done. Then not much
- extra synchronization is needed. For the flow control
- reasons it may be a good idea to freeze the request queue
- until this request gets completed.
- </para>
- <para>
- 2. If requests are completed when the function returns (such
- as classic read or write requests on character devices) then
- a synchronization flag should be set in the buffer
- descriptor and <function>tsleep()</function> called. Later
- when the callback gets called it will do its processing and
- check this synchronization flag. If it is set then the
- callback should issue a wakeup. In this approach the
- callback function could either do all the needed processing
- (just like the previous case) or simply save the segments
- array in the buffer descriptor. Then after callback
- completes the calling function could use this saved segments
- array and do all the processing.
-
- </para>
- </sect1>
-<!--_________________________________________________________________________-->
-<!--~~~~~~~~~~~~~~~~~~~~END OF SECTION~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
-
- <sect1 id="isa-driver-dma">
- <title>DMA</title>
- <!-- Section Marked up by Wylie -->
- <para>
- The Direct Memory Access (DMA) is implemented in the ISA bus
- through the DMA controller (actually, two of them but that is
- an irrelevant detail). To make the early ISA devices simple
- and cheap the logic of the bus control and address
- generation was concentrated in the DMA controller.
- Fortunately, FreeBSD provides a set of functions that mostly
- hide the annoying details of the DMA controller from the
- device drivers.
- </para>
-
- <para>
- The simplest case is for the fairly intelligent
- devices. Like the bus master devices on PCI they can
- generate the bus cycles and memory addresses all by
- themselves. The only thing they really need from the DMA
- controller is bus arbitration. So for this purpose they
- pretend to be cascaded slave DMA controllers. And the only
- thing needed from the system DMA controller is to enable the
- cascaded mode on a DMA channel by calling the following
- function when attaching the driver:
- </para>
-
- <para>
- <function>void isa_dmacascade(int channel_number)</function>
- </para>
-
- <para>
- All the further activity is done by programming the
- device. When detaching the driver no DMA-related functions
- need to be called.
- </para>
-
- <para>
- For the simpler devices things get more complicated. The
- functions used are:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- <function>int isa_dma_acquire(int chanel_number)</function>
- </para>
- <para>
- Reserve a DMA channel. Returns 0 on success or EBUSY
- if the channel was already reserved by this or a
- different driver. Most of the ISA devices are not able
- to share DMA channels anyway, so normally this
- function is called when attaching a device. This
- reservation was made redundant by the modern interface
- of bus resources but still must be used in addition to
- the latter. If not used then later, other DMA routines
- will panic.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>int isa_dma_release(int chanel_number)</function>
- </para>
- <para>
- Release a previously reserved DMA channel. No
- transfers must be in progress when the channel is
- released (in addition the device must not try to
- initiate transfer after the channel is released).
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>void isa_dmainit(int chan, u_int
- bouncebufsize)</function>
- </para>
- <para>
- Allocate a bounce buffer for use with the specified
- channel. The requested size of the buffer can not exceed
- 64KB. This bounce buffer will be automatically used
- later if a transfer buffer happens to be not
- physically contiguous or outside of the memory
- accessible by the ISA bus or crossing the 64KB
- boundary. If the transfers will be always done from
- buffers which conform to these conditions (such as
- those allocated by
- <function>bus_dmamem_alloc()</function> with proper
- limitations) then <function>isa_dmainit()</function>
- does not have to be called. But it is quite convenient
- to transfer arbitrary data using the DMA controller.
- The bounce buffer will automatically care of the
- scatter-gather issues.
- </para>
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>chan</emphasis> - channel number
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>bouncebufsize</emphasis> - size of the
- bounce buffer in bytes
- </para>
- </listitem>
- </itemizedlist>
-<!-- </blockquote> -->
-<!--</para> -->
- </listitem>
-
- <listitem>
- <para>
- <function>void isa_dmastart(int flags, caddr_t addr, u_int
- nbytes, int chan)</function>
- </para>
- <para>
- Prepare to start a DMA transfer. This function must be
- called to set up the DMA controller before actually
- starting transfer on the device. It checks that the
- buffer is contiguous and falls into the ISA memory
- range, if not then the bounce buffer is automatically
- used. If bounce buffer is required but not set up by
- <function>isa_dmainit()</function> or too small for
- the requested transfer size then the system will
- panic. In case of a write request with bounce buffer
- the data will be automatically copied to the bounce
- buffer.
- </para>
- </listitem>
- <listitem>
- <para>flags - a bitmask determining the type of operation to
- be done. The direction bits B_READ and B_WRITE are mutually
- exclusive.
- </para>
- <!-- <blockquote> -->
- <itemizedlist>
- <listitem>
- <para>
- B_READ - read from the ISA bus into memory
- </para>
- </listitem>
- <listitem>
- <para>
- B_WRITE - write from the memory to the ISA bus
- </para>
- </listitem>
- <listitem>
- <para>
- B_RAW - if set then the DMA controller will remember
- the buffer and after the end of transfer will
- automatically re-initialize itself to repeat transfer
- of the same buffer again (of course, the driver may
- change the data in the buffer before initiating
- another transfer in the device). If not set then the
- parameters will work only for one transfer, and
- <function>isa_dmastart()</function> will have to be
- called again before initiating the next
- transfer. Using B_RAW makes sense only if the bounce
- buffer is not used.
- </para>
- </listitem>
- </itemizedlist>
-<!-- </blockquote> -->
- </listitem>
- <listitem>
- <para>
- addr - virtual address of the buffer
- </para>
- </listitem>
- <listitem>
- <para>
- nbytes - length of the buffer. Must be less or equal to
- 64KB. Length of 0 is not allowed: the DMA controller will
- understand it as 64KB while the kernel code will
- understand it as 0 and that would cause unpredictable
- effects. For channels number 4 and higher the length must
- be even because these channels transfer 2 bytes at a
- time. In case of an odd length the last byte will not be
- transferred.
- </para>
- </listitem>
- <listitem>
- <para>
- chan - channel number
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>void isa_dmadone(int flags, caddr_t addr, int
- nbytes, int chan)</function>
- </para>
- <para>
- Synchronize the memory after device reports that transfer
- is done. If that was a read operation with a bounce buffer
- then the data will be copied from the bounce buffer to the
- original buffer. Arguments are the same as for
- <function>isa_dmastart()</function>. Flag B_RAW is
- permitted but it does not affect
- <function>isa_dmadone()</function> in any way.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>int isa_dmastatus(int channel_number)</function>
- </para>
- <para>
- Returns the number of bytes left in the current transfer
- to be transferred. In case the flag B_READ was set in
- <function>isa_dmastart()</function> the number returned
- will never be equal to zero. At the end of transfer it
- will be automatically reset back to the length of
- buffer. The normal use is to check the number of bytes
- left after the device signals that the transfer is
- completed. If the number of bytes is not 0 then something
- probably went wrong with that transfer.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>int isa_dmastop(int channel_number)</function>
- </para>
- <para>
- Aborts the current transfer and returns the number of
- bytes left untransferred.
- </para>
- </listitem>
- </itemizedlist>
- </sect1>
-
- <sect1 id="isa-driver-probe">
- <title>xxx_isa_probe</title>
- <!-- Section marked up by Wylie -->
-
- <para>
- This function probes if a device is present. If the driver
- supports auto-detection of some part of device configuration
- (such as interrupt vector or memory address) this
- auto-detection must be done in this routine.
- </para>
-
- <para>
- As for any other bus, if the device cannot be detected or
- is detected but failed the self-test or some other problem
- happened then it returns a positive value of error. The
- value ENXIO must be returned if the device is not
- present. Other error values may mean other conditions. Zero
- or negative values mean success. Most of the drivers return
- zero as success.
- </para>
-
- <para>
- The negative return values are used when a PnP device
- supports multiple interfaces. For example, an older
- compatibility interface and a newer advanced interface which
- are supported by different drivers. Then both drivers would
- detect the device. The driver which returns a higher value
- in the probe routine takes precedence (in other words, the
- driver returning 0 has highest precedence, one returning -1
- is next, one returning -2 is after it and so on). In result
- the devices which support only the old interface will be
- handled by the old driver (which should return -1 from the
- probe routine) while the devices supporting the new
- interface as well will be handled by the new driver (which
- should return 0 from the probe routine).
- </para>
-
- <para>
- The device descriptor struct xxx_softc is allocated by the
- system before calling the probe routine. If the probe
- routine returns an error the descriptor will be
- automatically deallocated by the system. So if a probing
- error occurs the driver must make sure that all the
- resources it used during probe are deallocated and that
- nothing keeps the descriptor from being safely
- deallocated. If the probe completes successfully the
- descriptor will be preserved by the system and later passed
- to the routine <function>xxx_isa_attach()</function>. If a
- driver returns a negative value it can not be sure that it
- will have the highest priority and its attach routine will
- be called. So in this case it also must release all the
- resources before returning and if necessary allocate them
- again in the attach routine. When
- <function>xxx_isa_probe()</function> returns 0 releasing the
- resources before returning is also a good idea and a
- well-behaved driver should do so. But in cases where there is
- some problem with releasing the resources the driver is
- allowed to keep resources between returning 0 from the probe
- routine and execution of the attach routine.
- </para>
-
- <para>
- A typical probe routine starts with getting the device
- descriptor and unit:
- </para>
-
- <programlisting> struct xxx_softc *sc = device_get_softc(dev);
- int unit = device_get_unit(dev);
- int pnperror;
- int error = 0;
-
- sc->dev = dev; /* link it back */
- sc->unit = unit; </programlisting>
-
- <para>
- Then check for the PnP devices. The check is carried out by
- a table containing the list of PnP IDs supported by this
- driver and human-readable descriptions of the device models
- corresponding to these IDs.
- </para>
-
- <programlisting>
- pnperror=ISA_PNP_PROBE(device_get_parent(dev), dev,
- xxx_pnp_ids); if(pnperror == ENXIO) return ENXIO;
- </programlisting>
-
- <para>
- The logic of ISA_PNP_PROBE is the following: If this card
- (device unit) was not detected as PnP then ENOENT will be
- returned. If it was detected as PnP but its detected ID does
- not match any of the IDs in the table then ENXIO is
- returned. Finally, if it has PnP support and it matches on
- of the IDs in the table, 0 is returned and the appropriate
- description from the table is set by
- <function>device_set_desc()</function>.
- </para>
-
- <para>
- If a driver supports only PnP devices then the condition
- would look like:
- </para>
-
- <programlisting> if(pnperror != 0)
- return pnperror; </programlisting>
-
- <para>
- No special treatment is required for the drivers which do not
- support PnP because they pass an empty PnP ID table and will
- always get ENXIO if called on a PnP card.
- </para>
-
- <para>
- The probe routine normally needs at least some minimal set
- of resources, such as I/O port number to find the card and
- probe it. Depending on the hardware the driver may be able
- to discover the other necessary resources automatically. The
- PnP devices have all the resources pre-set by the PnP
- subsystem, so the driver does not need to discover them by
- itself.
- </para>
-
- <para>
- Typically the minimal information required to get access to
- the device is the I/O port number. Then some devices allow
- to get the rest of information from the device configuration
- registers (though not all devices do that). So first we try
- to get the port start value:
- </para>
-
- <programlisting> sc->port0 = bus_get_resource_start(dev,
- SYS_RES_IOPORT, 0 /*rid*/); if(sc->port0 == 0) return ENXIO;
- </programlisting>
-
- <para>
- The base port address is saved in the structure softc for
- future use. If it will be used very often then calling the
- resource function each time would be prohibitively slow. If
- we do not get a port we just return an error. Some device
- drivers can instead be clever and try to probe all the
- possible ports, like this:
- </para>
-
- <programlisting>
- /* table of all possible base I/O port addresses for this device */
- static struct xxx_allports {
- u_short port; /* port address */
- short used; /* flag: if this port is already used by some unit */
- } xxx_allports = {
- { 0x300, 0 },
- { 0x320, 0 },
- { 0x340, 0 },
- { 0, 0 } /* end of table */
- };
-
- ...
- int port, i;
- ...
-
- port = bus_get_resource_start(dev, SYS_RES_IOPORT, 0 /*rid*/);
- if(port !=0 ) {
- for(i=0; xxx_allports[i].port!=0; i++) {
- if(xxx_allports[i].used || xxx_allports[i].port != port)
- continue;
-
- /* found it */
- xxx_allports[i].used = 1;
- /* do probe on a known port */
- return xxx_really_probe(dev, port);
- }
- return ENXIO; /* port is unknown or already used */
- }
-
- /* we get here only if we need to guess the port */
- for(i=0; xxx_allports[i].port!=0; i++) {
- if(xxx_allports[i].used)
- continue;
-
- /* mark as used - even if we find nothing at this port
- * at least we won't probe it in future
- */
- xxx_allports[i].used = 1;
-
- error = xxx_really_probe(dev, xxx_allports[i].port);
- if(error == 0) /* found a device at that port */
- return 0;
- }
- /* probed all possible addresses, none worked */
- return ENXIO;</programlisting>
-
- <para>
- Of course, normally the driver's
- <function>identify()</function> routine should be used for
- such things. But there may be one valid reason why it may be
- better to be done in <function>probe()</function>: if this
- probe would drive some other sensitive device crazy. The
- probe routines are ordered with consideration of the
- <literal>sensitive</literal> flag: the sensitive devices get probed first and
- the rest of the devices later. But the
- <function>identify()</function> routines are called before
- any probes, so they show no respect to the sensitive devices
- and may upset them.
- </para>
-
- <para>
- Now, after we got the starting port we need to set the port
- count (except for PnP devices) because the kernel does not
- have this information in the configuration file.
- </para>
-
- <programlisting>
- if(pnperror /* only for non-PnP devices */
- &#38;&#38; bus_set_resource(dev, SYS_RES_IOPORT, 0, sc->port0,
- XXX_PORT_COUNT)&lt;0)
- return ENXIO;</programlisting>
-
- <para>
- Finally allocate and activate a piece of port address space
- (special values of start and end mean <quote>use those we set by
- <function>bus_set_resource()</function></quote>):
- </para>
-
- <programlisting>
- sc->port0_rid = 0;
- sc->port0_r = bus_alloc_resource(dev, SYS_RES_IOPORT,
- &#38;sc->port0_rid,
- /*start*/ 0, /*end*/ ~0, /*count*/ 0, RF_ACTIVE);
-
- if(sc->port0_r == NULL)
- return ENXIO;</programlisting>
-
- <para>
- Now having access to the port-mapped registers we can poke
- the device in some way and check if it reacts like it is
- expected to. If it does not then there is probably some
- other device or no device at all at this address.
- </para>
-
- <para>
- Normally drivers do not set up the interrupt handlers until
- the attach routine. Instead they do probes in the polling
- mode using the <function>DELAY()</function> function for
- timeout. The probe routine must never hang forever, all the
- waits for the device must be done with timeouts. If the
- device does not respond within the time it is probably broken
- or misconfigured and the driver must return error. When
- determining the timeout interval give the device some extra
- time to be on the safe side: although
- <function>DELAY()</function> is supposed to delay for the
- same amount of time on any machine it has some margin of
- error, depending on the exact CPU.
- </para>
-
- <para>
- If the probe routine really wants to check that the
- interrupts really work it may configure and probe the
- interrupts too. But that is not recommended.
- </para>
-
- <programlisting>
- /* implemented in some very device-specific way */
- if(error = xxx_probe_ports(sc))
- goto bad; /* will deallocate the resources before returning */
- </programlisting>
-
- <para>
- The function <function>xxx_probe_ports()</function> may also
- set the device description depending on the exact model of
- device it discovers. But if there is only one supported
- device model this can be as well done in a hardcoded way.
- Of course, for the PnP devices the PnP support sets the
- description from the table automatically.
- </para>
-
-
- <programlisting> if(pnperror)
- device_set_desc(dev, "Our device model 1234");
- </programlisting>
-
- <para>
- Then the probe routine should either discover the ranges of
- all the resources by reading the device configuration
- registers or make sure that they were set explicitly by the
- user. We will consider it with an example of on-board
- memory. The probe routine should be as non-intrusive as
- possible, so allocation and check of functionality of the
- rest of resources (besides the ports) would be better left
- to the attach routine.
- </para>
-
- <para>
- The memory address may be specified in the kernel
- configuration file or on some devices it may be
- pre-configured in non-volatile configuration registers. If
- both sources are available and different, which one should
- be used? Probably if the user bothered to set the address
- explicitly in the kernel configuration file they know what
- they are doing and this one should take precedence. An
- example of implementation could be:
- </para>
- <programlisting>
- /* try to find out the config address first */
- sc->mem0_p = bus_get_resource_start(dev, SYS_RES_MEMORY, 0 /*rid*/);
- if(sc->mem0_p == 0) { /* nope, not specified by user */
- sc->mem0_p = xxx_read_mem0_from_device_config(sc);
-
-
- if(sc->mem0_p == 0)
- /* can't get it from device config registers either */
- goto bad;
- } else {
- if(xxx_set_mem0_address_on_device(sc) &lt; 0)
- goto bad; /* device does not support that address */
- }
-
- /* just like the port, set the memory size,
- * for some devices the memory size would not be constant
- * but should be read from the device configuration registers instead
- * to accommodate different models of devices. Another option would
- * be to let the user set the memory size as "msize" configuration
- * resource which will be automatically handled by the ISA bus.
- */
- if(pnperror) { /* only for non-PnP devices */
- sc->mem0_size = bus_get_resource_count(dev, SYS_RES_MEMORY, 0 /*rid*/);
- if(sc->mem0_size == 0) /* not specified by user */
- sc->mem0_size = xxx_read_mem0_size_from_device_config(sc);
-
- if(sc->mem0_size == 0) {
- /* suppose this is a very old model of device without
- * auto-configuration features and the user gave no preference,
- * so assume the minimalistic case
- * (of course, the real value will vary with the driver)
- */
- sc->mem0_size = 8*1024;
- }
-
- if(xxx_set_mem0_size_on_device(sc) &lt; 0)
- goto bad; /* device does not support that size */
-
- if(bus_set_resource(dev, SYS_RES_MEMORY, /*rid*/0,
- sc->mem0_p, sc->mem0_size)&lt;0)
- goto bad;
- } else {
- sc->mem0_size = bus_get_resource_count(dev, SYS_RES_MEMORY, 0 /*rid*/);
- } </programlisting>
-
- <para>
- Resources for IRQ and DRQ are easy to check by analogy.
- </para>
-
- <para>
- If all went well then release all the resources and return success.
- </para>
-
- <programlisting> xxx_free_resources(sc);
- return 0;</programlisting>
-
- <para>
- Finally, handle the troublesome situations. All the
- resources should be deallocated before returning. We make
- use of the fact that before the structure softc is passed to
- us it gets zeroed out, so we can find out if some resource
- was allocated: then its descriptor is non-zero.
- </para>
-
- <programlisting> bad:
-
- xxx_free_resources(sc);
- if(error)
- return error;
- else /* exact error is unknown */
- return ENXIO;</programlisting>
-
- <para>
- That would be all for the probe routine. Freeing of
- resources is done from multiple places, so it is moved to a
- function which may look like:
- </para>
-
-<programlisting>static void
- xxx_free_resources(sc)
- struct xxx_softc *sc;
- {
- /* check every resource and free if not zero */
-
- /* interrupt handler */
- if(sc->intr_r) {
- bus_teardown_intr(sc->dev, sc->intr_r, sc->intr_cookie);
- bus_release_resource(sc->dev, SYS_RES_IRQ, sc->intr_rid,
- sc->intr_r);
- sc->intr_r = 0;
- }
-
- /* all kinds of memory maps we could have allocated */
- if(sc->data_p) {
- bus_dmamap_unload(sc->data_tag, sc->data_map);
- sc->data_p = 0;
- }
- if(sc->data) { /* sc->data_map may be legitimately equal to 0 */
- /* the map will also be freed */
- bus_dmamem_free(sc->data_tag, sc->data, sc->data_map);
- sc->data = 0;
- }
- if(sc->data_tag) {
- bus_dma_tag_destroy(sc->data_tag);
- sc->data_tag = 0;
- }
-
- ... free other maps and tags if we have them ...
-
- if(sc->parent_tag) {
- bus_dma_tag_destroy(sc->parent_tag);
- sc->parent_tag = 0;
- }
-
- /* release all the bus resources */
- if(sc->mem0_r) {
- bus_release_resource(sc->dev, SYS_RES_MEMORY, sc->mem0_rid,
- sc->mem0_r);
- sc->mem0_r = 0;
- }
- ...
- if(sc->port0_r) {
- bus_release_resource(sc->dev, SYS_RES_IOPORT, sc->port0_rid,
- sc->port0_r);
- sc->port0_r = 0;
- }
- }</programlisting>
-
- </sect1>
-
- <sect1 id="isa-driver-attach">
- <title>xxx_isa_attach</title>
- <!-- Section Marked up by Wylie -->
-
- <para>The attach routine actually connects the driver to the
- system if the probe routine returned success and the system
- had chosen to attach that driver. If the probe routine
- returned 0 then the attach routine may expect to receive the
- device structure softc intact, as it was set by the probe
- routine. Also if the probe routine returns 0 it may expect
- that the attach routine for this device shall be called at
- some point in the future. If the probe routine returns a
- negative value then the driver may make none of these
- assumptions.
- </para>
-
- <para>The attach routine returns 0 if it completed successfully or
- error code otherwise.
- </para>
-
- <para>The attach routine starts just like the probe routine,
- with getting some frequently used data into more accessible
- variables.
- </para>
-
- <programlisting> struct xxx_softc *sc = device_get_softc(dev);
- int unit = device_get_unit(dev);
- int error = 0;</programlisting>
-
- <para>Then allocate and activate all the necessary
- resources. Because normally the port range will be released
- before returning from probe, it has to be allocated
- again. We expect that the probe routine had properly set all
- the resource ranges, as well as saved them in the structure
- softc. If the probe routine had left some resource allocated
- then it does not need to be allocated again (which would be
- considered an error).
- </para>
-
- <programlisting> sc->port0_rid = 0;
- sc->port0_r = bus_alloc_resource(dev, SYS_RES_IOPORT, &#38;sc->port0_rid,
- /*start*/ 0, /*end*/ ~0, /*count*/ 0, RF_ACTIVE);
-
- if(sc->port0_r == NULL)
- return ENXIO;
-
- /* on-board memory */
- sc->mem0_rid = 0;
- sc->mem0_r = bus_alloc_resource(dev, SYS_RES_MEMORY, &#38;sc->mem0_rid,
- /*start*/ 0, /*end*/ ~0, /*count*/ 0, RF_ACTIVE);
-
- if(sc->mem0_r == NULL)
- goto bad;
-
- /* get its virtual address */
- sc->mem0_v = rman_get_virtual(sc->mem0_r);</programlisting>
-
- <para>The DMA request channel (DRQ) is allocated likewise. To
- initialize it use functions of the
- <function>isa_dma*()</function> family. For example:
- </para>
-
- <para><function>isa_dmacascade(sc->drq0);</function></para>
-
- <para>The interrupt request line (IRQ) is a bit
- special. Besides allocation the driver's interrupt handler
- should be associated with it. Historically in the old ISA
- drivers the argument passed by the system to the interrupt
- handler was the device unit number. But in modern drivers
- the convention suggests passing the pointer to structure
- softc. The important reason is that when the structures
- softc are allocated dynamically then getting the unit number
- from softc is easy while getting softc from the unit number is
- difficult. Also this convention makes the drivers for
- different buses look more uniform and allows them to share
- the code: each bus gets its own probe, attach, detach and
- other bus-specific routines while the bulk of the driver
- code may be shared among them.
- </para>
-
- <programlisting>
- sc->intr_rid = 0;
- sc->intr_r = bus_alloc_resource(dev, SYS_RES_MEMORY, &#38;sc->intr_rid,
- /*start*/ 0, /*end*/ ~0, /*count*/ 0, RF_ACTIVE);
-
- if(sc->intr_r == NULL)
- goto bad;
-
- /*
- * XXX_INTR_TYPE is supposed to be defined depending on the type of
- * the driver, for example as INTR_TYPE_CAM for a CAM driver
- */
- error = bus_setup_intr(dev, sc->intr_r, XXX_INTR_TYPE,
- (driver_intr_t *) xxx_intr, (void *) sc, &#38;sc->intr_cookie);
- if(error)
- goto bad;
-
- </programlisting>
-
-
- <para>If the device needs to make DMA to the main memory then
- this memory should be allocated like described before:
- </para>
-
- <programlisting> error=bus_dma_tag_create(NULL, /*alignment*/ 4,
- /*boundary*/ 0, /*lowaddr*/ BUS_SPACE_MAXADDR_24BIT,
- /*highaddr*/ BUS_SPACE_MAXADDR, /*filter*/ NULL, /*filterarg*/ NULL,
- /*maxsize*/ BUS_SPACE_MAXSIZE_24BIT,
- /*nsegments*/ BUS_SPACE_UNRESTRICTED,
- /*maxsegsz*/ BUS_SPACE_MAXSIZE_24BIT, /*flags*/ 0,
- &#38;sc->parent_tag);
- if(error)
- goto bad;
-
- /* many things get inherited from the parent tag
- * sc->data is supposed to point to the structure with the shared data,
- * for example for a ring buffer it could be:
- * struct {
- * u_short rd_pos;
- * u_short wr_pos;
- * char bf[XXX_RING_BUFFER_SIZE]
- * } *data;
- */
- error=bus_dma_tag_create(sc->parent_tag, 1,
- 0, BUS_SPACE_MAXADDR, 0, /*filter*/ NULL, /*filterarg*/ NULL,
- /*maxsize*/ sizeof(* sc->data), /*nsegments*/ 1,
- /*maxsegsz*/ sizeof(* sc->data), /*flags*/ 0,
- &#38;sc->data_tag);
- if(error)
- goto bad;
-
- error = bus_dmamem_alloc(sc->data_tag, &#38;sc->data, /* flags*/ 0,
- &#38;sc->data_map);
- if(error)
- goto bad;
-
- /* xxx_alloc_callback() just saves the physical address at
- * the pointer passed as its argument, in this case &#38;sc->data_p.
- * See details in the section on bus memory mapping.
- * It can be implemented like:
- *
- * static void
- * xxx_alloc_callback(void *arg, bus_dma_segment_t *seg,
- * int nseg, int error)
- * {
- * *(bus_addr_t *)arg = seg[0].ds_addr;
- * }
- */
- bus_dmamap_load(sc->data_tag, sc->data_map, (void *)sc->data,
- sizeof (* sc->data), xxx_alloc_callback, (void *) &#38;sc->data_p,
- /*flags*/0);</programlisting>
-
-
- <para>After all the necessary resources are allocated the
- device should be initialized. The initialization may include
- testing that all the expected features are functional.</para>
-
- <programlisting> if(xxx_initialize(sc) &lt; 0)
- goto bad; </programlisting>
-
-
- <para>The bus subsystem will automatically print on the
- console the device description set by probe. But if the
- driver wants to print some extra information about the
- device it may do so, for example:</para>
-
- <programlisting>
- device_printf(dev, "has on-card FIFO buffer of %d bytes\n", sc->fifosize);
- </programlisting>
-
- <para>If the initialization routine experiences any problems
- then printing messages about them before returning error is
- also recommended.</para>
-
- <para>The final step of the attach routine is attaching the
- device to its functional subsystem in the kernel. The exact
- way to do it depends on the type of the driver: a character
- device, a block device, a network device, a CAM SCSI bus
- device and so on.</para>
-
- <para>If all went well then return success.</para>
-
- <programlisting> error = xxx_attach_subsystem(sc);
- if(error)
- goto bad;
-
- return 0; </programlisting>
-
- <para>Finally, handle the troublesome situations. All the
- resources should be deallocated before returning an
- error. We make use of the fact that before the structure
- softc is passed to us it gets zeroed out, so we can find out
- if some resource was allocated: then its descriptor is
- non-zero.</para>
-
- <programlisting> bad:
-
- xxx_free_resources(sc);
- if(error)
- return error;
- else /* exact error is unknown */
- return ENXIO;</programlisting>
-
- <para>That would be all for the attach routine.</para>
-
- </sect1>
-
-
- <sect1 id="isa-driver-detach">
- <title>xxx_isa_detach</title>
-
- <para>
- If this function is present in the driver and the driver is
- compiled as a loadable module then the driver gets the
- ability to be unloaded. This is an important feature if the
- hardware supports hot plug. But the ISA bus does not support
- hot plug, so this feature is not particularly important for
- the ISA devices. The ability to unload a driver may be
- useful when debugging it, but in many cases installation of
- the new version of the driver would be required only after
- the old version somehow wedges the system and a reboot will be
- needed anyway, so the efforts spent on writing the detach
- routine may not be worth it. Another argument that
- unloading would allow upgrading the drivers on a production
- machine seems to be mostly theoretical. Installing a new
- version of a driver is a dangerous operation which should
- never be performed on a production machine (and which is not
- permitted when the system is running in secure mode). Still,
- the detach routine may be provided for the sake of
- completeness.
- </para>
-
- <para>
- The detach routine returns 0 if the driver was successfully
- detached or the error code otherwise.
- </para>
-
- <para>
- The logic of detach is a mirror of the attach. The first
- thing to do is to detach the driver from its kernel
- subsystem. If the device is currently open then the driver
- has two choices: refuse to be detached or forcibly close and
- proceed with detach. The choice used depends on the ability
- of the particular kernel subsystem to do a forced close and
- on the preferences of the driver's author. Generally the
- forced close seems to be the preferred alternative.
- <programlisting> struct xxx_softc *sc = device_get_softc(dev);
- int error;
-
- error = xxx_detach_subsystem(sc);
- if(error)
- return error;</programlisting>
- </para>
- <para>
- Next the driver may want to reset the hardware to some
- consistent state. That includes stopping any ongoing
- transfers, disabling the DMA channels and interrupts to
- avoid memory corruption by the device. For most of the
- drivers this is exactly what the shutdown routine does, so
- if it is included in the driver we can just call it.
- </para>
- <para><function>xxx_isa_shutdown(dev);</function></para>
-
- <para>
- And finally release all the resources and return success.
- <programlisting> xxx_free_resources(sc);
- return 0;</programlisting>
-
- </para>
- </sect1>
-
- <sect1 id="isa-driver-shutdown">
- <title>xxx_isa_shutdown</title>
-
- <para>
- This routine is called when the system is about to be shut
- down. It is expected to bring the hardware to some
- consistent state. For most of the ISA devices no special
- action is required, so the function is not really necessary
- because the device will be re-initialized on reboot
- anyway. But some devices have to be shut down with a special
- procedure, to make sure that they will be properly detected
- after soft reboot (this is especially true for many devices
- with proprietary identification protocols). In any case
- disabling DMA and interrupts in the device registers and
- stopping any ongoing transfers is a good idea. The exact
- action depends on the hardware, so we do not consider it here
- in any detail.
- </para>
- </sect1>
-
- <sect1 id="isa-driver-intr">
- <title>xxx_intr</title>
-
- <para>
- The interrupt handler is called when an interrupt is
- received which may be from this particular device. The ISA
- bus does not support interrupt sharing (except in some special
- cases) so in practice if the interrupt handler is called
- then the interrupt almost for sure came from its
- device. Still, the interrupt handler must poll the device
- registers and make sure that the interrupt was generated by
- its device. If not it should just return.
- </para>
-
- <para>
- The old convention for the ISA drivers was getting the
- device unit number as an argument. This is obsolete, and the
- new drivers receive whatever argument was specified for them
- in the attach routine when calling
- <function>bus_setup_intr()</function>. By the new convention
- it should be the pointer to the structure softc. So the
- interrupt handler commonly starts as:
- </para>
-
- <programlisting>
- static void
- xxx_intr(struct xxx_softc *sc)
- {
-
- </programlisting>
-
- <para>
- It runs at the interrupt priority level specified by the
- interrupt type parameter of
- <function>bus_setup_intr()</function>. That means that all
- the other interrupts of the same type as well as all the
- software interrupts are disabled.
- </para>
-
- <para>
- To avoid races it is commonly written as a loop:
- </para>
-
- <programlisting>
- while(xxx_interrupt_pending(sc)) {
- xxx_process_interrupt(sc);
- xxx_acknowledge_interrupt(sc);
- } </programlisting>
-
- <para>
- The interrupt handler has to acknowledge interrupt to the
- device only but not to the interrupt controller, the system
- takes care of the latter.
- </para>
-
- </sect1>
-</chapter>
diff --git a/en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml
deleted file mode 100644
index 53af59a441..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml
+++ /dev/null
@@ -1,611 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $FreeBSD$
--->
-
-<chapter id="jail">
- <chapterinfo>
- <author><firstname>Evan Sarmiento</firstname>
- <affiliation><address><email>evms@cs.bu.edu</email></address>
- </affiliation>
- </author>
- <copyright>
- <year>2001</year>
- <holder role="mailto:evms@cs.bu.edu">Evan Sarmiento</holder>
- </copyright>
- </chapterinfo>
- <title>The Jail Subsystem</title>
-
- <para>On most UNIX systems, root has omnipotent power. This promotes
- insecurity. If an attacker were to gain root on a system, he would
- have every function at his fingertips. In FreeBSD there are
- sysctls which dilute the power of root, in order to minimize the
- damage caused by an attacker. Specifically, one of these functions
- is called secure levels. Similarly, another function which is
- present from FreeBSD 4.0 and onward, is a utility called
- &man.jail.8;. <application>Jail</application> chroots an
- environment and sets certain restrictions on processes which are
- forked from within. For example, a jailed process cannot affect
- processes outside of the jail, utilize certain system calls, or
- inflict any damage on the main computer.</para>
-
- <para><application>Jail</application> is becoming the new security
- model. People are running potentially vulnerable servers such as
- Apache, BIND, and sendmail within jails, so that if an attacker
- gains root within the <application>Jail</application>, it is only
- an annoyance, and not a devastation. This article focuses on the
- internals (source code) of <application>Jail</application> and
- <application>Jail</application> NG. It will also suggest
- improvements upon the jail code base which are already being
- worked on. If you are looking for a how-to on setting up a
- <application>Jail</application>, I suggest you look at my other
- article in Sys Admin Magazine, May 2001, entitled "Securing
- FreeBSD using <application>Jail</application>."</para>
-
- <sect1 id="jail-arch">
- <title>Architecture</title>
-
- <para>
- <application>Jail</application> consists of two realms: the
- user-space program, jail, and the code implemented within the
- kernel: the <literal>jail()</literal> system call and associated
- restrictions. I will be discussing the user-space program and
- then how jail is implemented within the kernel.</para>
-
- <sect2>
- <title>Userland code</title>
-
- <para>The source for the user-land jail is located in
- <filename>/usr/src/usr.sbin/jail</filename>, consisting of
- one file, <filename>jail.c</filename>. The program takes these
- arguments: the path of the jail, hostname, ip address, and the
- command to be executed.</para>
-
- <sect3>
- <title>Data Structures</title>
-
- <para>In <filename>jail.c</filename>, the first thing I would
- note is the declaration of an important structure
- <literal>struct jail j</literal>; which was included from
- <filename>/usr/include/sys/jail.h</filename>.
-
- <para>The definition of the jail structure is:</para>
-
-<programlisting><filename>/usr/include/sys/jail.h</filename>:
-
-struct jail {
- u_int32_t version;
- char *path;
- char *hostname;
- u_int32_t ip_number;
-};</programlisting>
-
- <para>As you can see, there is an entry for each of the
- arguments passed to the jail program, and indeed, they are
- set during it's execution.</para>
-
- <programlisting><filename>/usr/src/usr.sbin/jail.c</filename>
-j.version = 0;
-j.path = argv[1];
-j.hostname = argv[2];</programlisting>
-
- </sect3>
-
- <sect3>
- <title>Networking</title>
-
- <para>One of the arguments passed to the Jail program is an IP
- address with which the jail can be accessed over the
- network. Jail translates the ip address given into network
- byte order and then stores it in j (the jail structure).</para>
-
- <programlisting><filename>/usr/src/usr.sbin/jail/jail.c</filename>:
-struct in.addr in;
-...
-i = inet.aton(argv[3], <![CDATA[&in]]>);
-...
-j.ip_number = ntohl(in.s.addr);</programlisting>
-
- <para>The
- <citerefentry><refentrytitle>inet_aton</refentrytitle><manvolnum>3</manvolnum></citerefentry>
- function "interprets the specified character string as an
- Internet address, placing the address into the structure
- provided." The ip number node in the jail structure is set
- only when the ip address placed onto the in structure by
- inet aton is translated into network byte order by
- <function>ntohl()</function>.</para>
-
- </sect3>
-
- <sect3>
- <title>Jailing The Process</title>
-
- <para>Finally, the userland program jails the process, and
- executes the command specified. Jail now becomes an
- imprisoned process itself and forks a child process which
- then executes the command given using &man.execv.3;
-
- <programlisting><filename>/usr/src/sys/usr.sbin/jail/jail.c</filename>
-i = jail(<![CDATA[&j]]>);
-...
-i = execv(argv[4], argv + 4);</programlisting>
-
- <para>As you can see, the jail function is being called, and
- its argument is the jail structure which has been filled
- with the arguments given to the program. Finally, the
- program you specify is executed. I will now discuss how Jail
- is implemented within the kernel.</para>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Kernel Space</title>
-
- <para>We will now be looking at the file
- <filename>/usr/src/sys/kern/kern_jail.c</filename>. This is
- the file where the jail system call, appropriate sysctls, and
- networking functions are defined.</para>
-
- <sect3>
- <title>sysctls</title>
-
- <para>In <filename>kern_jail.c</filename>, the following
- sysctls are defined:</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c:</filename>
-
-int jail_set_hostname_allowed = 1;
-SYSCTL_INT(_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW,
- <![CDATA[&jail]]>_set_hostname_allowed, 0,
- "Processes in jail can set their hostnames");
-
-int jail_socket_unixiproute_only = 1;
-SYSCTL_INT(_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW,
- <![CDATA[&jail]]>_socket_unixiproute_only, 0,
- "Processes in jail are limited to creating UNIX/IPv4/route sockets only
-");
-
-int jail_sysvipc_allowed = 0;
-SYSCTL_INT(_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
- <![CDATA[&jail]]>_sysvipc_allowed, 0,
- "Processes in jail can use System V IPC primitives");</programlisting>
-
- <para>Each of these sysctls can be accessed by the user
- through the sysctl program. Throughout the kernel, these
- specific sysctls are recognized by their name. For example,
- the name of the first sysctl is
- <literal>jail.set.hostname.allowed</literal>.</para>
- </sect3>
-
- <sect3>
- <title>&man.jail.2; system call</title>
-
- <para>Like all system calls, the &man.jail.2; system call takes
- two arguments, <literal>struct proc *p</literal> and
- <literal>struct jail_args
- *uap</literal>. <literal>p</literal> is a pointer to a proc
- structure which describes the calling process. In this
- context, uap is a pointer to a structure which specifies the
- arguments given to &man.jail.2; from the userland program
- <filename>jail.c</filename>. When I described the userland
- program before, you saw that the &man.jail.2; system call was
- given a jail structure as its own argument.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c:</filename>
-int
-jail(p, uap)
- struct proc *p;
- struct jail_args /* {
- syscallarg(struct jail *) jail;
- } */ *uap;</programlisting>
-
- <para>Therefore, <literal>uap->jail</literal> would access the
- jail structure which was passed to the system call. Next,
- the system call copies the jail structure into kernel space
- using the <literal>copyin()</literal>
- function. <literal>copyin()</literal> takes three arguments:
- the data which is to be copied into kernel space,
- <literal>uap->jail</literal>, where to store it,
- <literal>j</literal> and the size of the storage. The jail
- structure <literal>uap->jail</literal> is copied into kernel
- space and stored in another jail structure,
- <literal>j</literal>.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c: </filename>
-error = copyin(uap->jail, <![CDATA[&j]]>, sizeof j);</programlisting>
-
- <para>There is another important structure defined in
- jail.h. It is the prison structure
- (<literal>pr</literal>). The prison structure is used
- exclusively within kernel space. The &man.jail.2; system call
- copies everything from the jail structure onto the prison
- structure. Here is the definition of the prison structure.</para>
-
- <programlisting><filename>/usr/include/sys/jail.h</filename>:
-struct prison {
- int pr_ref;
- char pr_host[MAXHOSTNAMELEN];
- u_int32_t pr_ip;
- void *pr_linux;
-};</programlisting>
-
- <para>The jail() system call then allocates memory for a
- pointer to a prison structure and copies data between the two
- structures.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c</filename>:
- MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_WAITOK);
- bzero((caddr_t)pr, sizeof *pr);
- error = copyinstr(j.hostname, <![CDATA[&pr->pr_host]]>, sizeof pr->pr_host, 0);
- if (error)
- goto bail;</programlisting>
-
- <para>Finally, the jail system call chroots the path
- specified. The chroot function is given two arguments. The
- first is p, which represents the calling process, the second
- is a pointer to the structure chroot args. The structure
- chroot args contains the path which is to be chrooted. As
- you can see, the path specified in the jail structure is
- copied to the chroot args structure and used.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c</filename>:
-ca.path = j.path;
-error = chroot(p, <![CDATA[&ca]]>);</programlisting>
-
- <para>These next three lines in the source are very important,
- as they specify how the kernel recognizes a process as
- jailed. Each process on a Unix system is described by its
- own proc structure. You can see the whole proc structure in
- <filename>/usr/include/sys/proc.h</filename>. For example,
- the p argument in any system call is actually a pointer to
- that process' proc structure, as stated before. The proc
- structure contains nodes which can describe the owner's
- identity (<literal>p_cred</literal>), the process resource
- limits (<literal>p_limit</literal>), and so on. In the
- definition of the process structure, there is a pointer to a
- prison structure. (<literal>p_prison</literal>).</para>
-
- <programlisting><filename>/usr/include/sys/proc.h: </filename>
-struct proc {
-...
-struct prison *p_prison;
-...
-};</programlisting>
-
- <para>In <filename>kern_jail.c</filename>, the function then
- copies the pr structure, which is filled with all the
- information from the original jail structure, over to the
- <literal>p->p_prison</literal> structure. It then does a
- bitwise OR of <literal>p->p_flag</literal> with the constant
- <literal>P_JAILED</literal>, meaning that the calling
- process is now recognized as jailed. The parent process of
- each process, forked within the jail, is the program jail
- itself, as it calls the &man.jail.2; system call. When the
- program is executed through execve, it inherits the
- properties of its parents proc structure, therefore it has
- the <literal>p->p_flag</literal> set, and the
- <literal>p->p_prison</literal> structure is filled.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c</filename>
-p->p.prison = pr;
-p->p.flag |= P.JAILED;</programlisting>
-
- <para>When a process is forked from a parent process, the
- &man.fork.2; system call deals differently with imprisoned
- processes. In the fork system call, there are two pointers
- to a <literal>proc</literal> structure <literal>p1</literal>
- and <literal>p2</literal>. <literal>p1</literal> points to
- the parent's <literal>proc</literal> structure and p2 points
- to the child's unfilled <literal>proc</literal>
- structure. After copying all relevant data between the
- structures, &man.fork.2; checks if the structure
- <literal>p->p_prison</literal> is filled on
- <literal>p2</literal>. If it is, it increments the
- <literal>pr.ref</literal> by one, and sets the
- <literal>p_flag</literal> to one on the child process.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_fork.c</filename>:
-if (p2->p_prison) {
- p2->p_prison->pr_ref++;
- p2->p_flag |= P_JAILED;
-}</programlisting>
-
- </sect3>
- </sect2>
- </sect1>
-
- <sect1 id="jail-restrictions">
- <title>Restrictions</title>
-
- <para>Throughout the kernel there are access restrictions relating
- to jailed processes. Usually, these restrictions only check if
- the process is jailed, and if so, returns an error. For
- example:</para>
-
- <programlisting>if (p->p_prison)
- return EPERM;</programlisting>
-
- <sect2>
- <title>SysV IPC</title>
-
- <para>System V IPC is based on messages. Processes can send each
- other these messages which tell them how to act. The functions
- which deal with messages are: <literal>msgsys</literal>,
- <literal>msgctl</literal>, <literal>msgget</literal>,
- <literal>msgsend</literal> and <literal>msgrcv</literal>.
- Earlier, I mentioned that there were certain sysctls you could
- turn on or off in order to affect the behavior of Jail. One of
- these sysctls was <literal>jail_sysvipc_allowed</literal>. On
- most systems, this sysctl is set to 0. If it were set to 1, it
- would defeat the whole purpose of having a jail; privleged
- users from within the jail would be able to affect processes
- outside of the environment. The difference between a message
- and a signal is that the message only consists of the signal
- number.</para>
-
- <para><filename>/usr/src/sys/kern/sysv_msg.c</filename>:</para>
-
- <itemizedlist>
- <listitem> <para>&man.msgget.3;: msgget returns (and possibly
- creates) a message descriptor that designates a message queue
- for use in other system calls.</para></listitem>
-
- <listitem> <para>&man.msgctl.3;: Using this function, a process
- can query the status of a message
- descriptor.</para></listitem>
-
- <listitem> <para>&man.msgsnd.3;: msgsnd sends a message to a
- process.</para></listitem>
-
- <listitem> <para>&man.msgrcv.3;: a process receives messages using
- this function</para></listitem>
-
- </itemizedlist>
-
- <para>In each of these system calls, there is this
- conditional:</para>
-
- <programlisting><filename>/usr/src/sys/kern/sysv msg.c</filename>:
-if (!jail.sysvipc.allowed && p->p_prison != NULL)
- return (ENOSYS);</programlisting>
-
- <para>Semaphore system calls allow processes to synchronize
- execution by doing a set of operations atomically on a set of
- semaphores. Basically semaphores provide another way for
- processes lock resources. However, process waiting on a
- semaphore, that is being used, will sleep until the resources
- are relinquished. The following semaphore system calls are
- blocked inside a jail: <literal>semsys</literal>,
- <literal>semget</literal>, <literal>semctl</literal> and
- <literal>semop</literal>.</para>
-
- <para><filename>/usr/src/sys/kern/sysv_sem.c</filename>:</para>
-
- <itemizedlist>
- <listitem>
- <para>&man.semctl.2;<literal>(id, num, cmd, arg)</literal>:
- Semctl does the specified cmd on the semaphore queue
- indicated by id.</para></listitem>
-
- <listitem>
- <para>&man.semget.2;<literal>(key, nsems, flag)</literal>:
- Semget creates an array of semaphores, corresponding to
- key.</para>
-
- <para><literal>Key and flag take on the same meaning as they
- do in msgget.</literal></para></listitem>
-
- <listitem><para>&man.semop.2;<literal>(id, ops, num)</literal>:
- Semop does the set of semaphore operations in the array of
- structures ops, to the set of semaphores identified by
- id.</para></listitem>
- </itemizedlist>
-
- <para>System V IPC allows for processes to share
- memory. Processes can communicate directly with each other by
- sharing parts of their virtual address space and then reading
- and writing data stored in the shared memory. These system
- calls are blocked within a jailed environment: <literal>shmdt,
- shmat, oshmctl, shmctl, shmget</literal>, and
- <literal>shmsys</literal>.</para>
-
- <para><filename>/usr/src/sys/kern/sysv shm.c</filename>:</para>
-
- <itemizedlist>
- <listitem><para>&man.shmctl.2;<literal>(id, cmd, buf)</literal>:
- shmctl does various control operations on the shared memory
- region identified by id.</para></listitem>
-
- <listitem><para>&man.shmget.2;<literal>(key, size,
- flag)</literal>: shmget accesses or creates a shared memory
- region of size bytes.</para></listitem>
-
- <listitem><para>&man.shmat.2;<literal>(id, addr, flag)</literal>:
- shmat attaches a shared memory region identified by id to the
- address space of a process.</para></listitem>
-
- <listitem><para>&man.shmdt.2;<literal>(addr)</literal>: shmdt
- detaches the shared memory region previously attached at
- addr.</para></listitem>
-
- </itemizedlist>
- </sect2>
-
- <sect2>
- <title>Sockets</title>
-
- <para>Jail treats the &man.socket.2; system call and related
- lower-level socket functions in a special manner. In order to
- determine whether a certain socket is allowed to be created,
- it first checks to see if the sysctl
- <literal>jail.socket.unixiproute.only</literal> is set. If
- set, sockets are only allowed to be created if the family
- specified is either <literal>PF_LOCAL</literal>,
- <literal>PF_INET</literal> or
- <literal>PF_ROUTE</literal>. Otherwise, it returns an
- error.</para>
-
- <programlisting><filename>/usr/src/sys/kern/uipc_socket.c</filename>:
-int socreate(dom, aso, type, proto, p)
-...
-register struct protosw *prp;
-...
-{
- if (p->p_prison && jail_socket_unixiproute_only &&
- prp->pr_domain->dom_family != PR_LOCAL && prp->pr_domain->dom_family != PF_INET
- && prp->pr_domain->dom_family != PF_ROUTE)
- return (EPROTONOSUPPORT);
-...
-}</programlisting>
-
- </sect2>
-
- <sect2>
- <title>Berkeley Packet Filter</title>
-
- <para>The Berkeley Packet Filter provides a raw interface to
- data link layers in a protocol independent fashion. The
- function <literal>bpfopen()</literal> opens an Ethernet
- device. There is a conditional which disallows any jailed
- processes from accessing this function.</para>
-
- <programlisting><filename>/usr/src/sys/net/bpf.c</filename>:
-static int bpfopen(dev, flags, fmt, p)
-...
-{
- if (p->p_prison)
- return (EPERM);
-...
-}</programlisting>
-
- </sect2>
-
- <sect2>
- <title>Protocols</title>
-
- <para>There are certain protocols which are very common, such as
- TCP, UDP, IP and ICMP. IP and ICMP are on the same level: the
- network layer 2. There are certain precautions which are
- taken in order to prevent a jailed process from binding a
- protocol to a certain port only if the <literal>nam</literal>
- parameter is set. nam is a pointer to a sockaddr structure,
- which describes the address on which to bind the service. A
- more exact definition is that sockaddr "may be used as a
- template for reffering to the identifying tag and length of
- each address"[2]. In the function in
- <literal>pcbbind</literal>, <literal>sin</literal> is a
- pointer to a sockaddr.in structure, which contains the port,
- address, length and domain family of the socket which is to be
- bound. Basically, this disallows any processes from jail to be
- able to specify the domain family.</para>
-
- <programlisting><filename>/usr/src/sys/kern/netinet/in_pcb.c</filename>:
-int in.pcbbind(int, nam, p)
-...
- struct sockaddr *nam;
- struct proc *p;
-{
- ...
- struct sockaddr.in *sin;
- ...
- if (nam) {
- sin = (struct sockaddr.in *)nam;
- ...
- if (sin->sin_addr.s_addr != INADDR_ANY)
- if (prison.ip(p, 0, <![CDATA[&sin]]>->sin.addr.s_addr))
- return (EINVAL);
- ....
- }
-...
-}</programlisting>
-
- <para>You might be wondering what function
- <literal>prison_ip()</literal> does. prison.ip is given three
- arguments, the current process (represented by
- <literal>p</literal>), any flags, and an ip address. It
- returns 1 if the ip address belongs to a jail or 0 if it does
- not. As you can see from the code, if it is indeed an ip
- address belonging to a jail, the protcol is not allowed to
- bind to a certain port.</para>
-
- <programlisting><filename>/usr/src/sys/kern/kern_jail.c:</filename>
-int prison_ip(struct proc *p, int flag, u_int32_t *ip) {
- u_int32_t tmp;
-
- if (!p->p_prison)
- return (0);
- if (flag)
- tmp = *ip;
- else tmp = ntohl (*ip);
-
- if (tmp == INADDR_ANY) {
- if (flag)
- *ip = p->p_prison->pr_ip;
- else *ip = htonl(p->p_prison->pr_ip);
- return (0);
- }
-
- if (p->p_prison->pr_ip != tmp)
- return (1);
- return (0);
-}</programlisting>
-
- <para>Jailed users are not allowed to bind services to an ip
- which does not belong to the jail. The restriction is also
- written within the function <literal>in_pcbbind</literal>:</para>
-
- <programlisting><filename>/usr/src/sys/net inet/in_pcb.c</filename>
- if (nam) {
- ...
- lport = sin->sin.port;
- ... if (lport) {
- ...
- if (p && p->p_prison)
- prison = 1;
- if (prison &&
- prison_ip(p, 0, <![CDATA[&sin]]>->sin_addr.s_addr))
- return (EADDRNOTAVAIL);</programlisting>
-
- </sect2>
-
- <sect2>
- <title>Filesystem</title>
-
- <para>Even root users within the jail are not allowed to set any
- file flags, such as immutable, append, and no unlink flags, if
- the securelevel is greater than 0.</para>
-
- <programlisting>/usr/src/sys/ufs/ufs/ufs_vnops.c:
-int ufs.setattr(ap)
- ...
-{
- if ((cred->cr.uid == 0) && (p->prison == NULL)) {
- if ((ip->i_flags
- & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) &&
- securelevel > 0)
- return (EPERM);
-}</programlisting>
-
- </sect2>
-
- </sect1>
-
- <sect1 id="jail-jailng">
- <title>Jail NG</title>
-
- <para>Jail NG is a "from-scratch re-implementation of Jail" by
- Robert Watson, a FreeBSD committer. Some of the new features
- include the ability to add processes to a jail, an improved
- management tool, and per-jail sysctls. For example, you could
- have <literal>sysvipc_permitted</literal> set on one jail while
- another jail may be allowed to use System V IPC. You can
- download the kernel patches and utilities for Jail NG from his
- website at:
- <ulink
- url="http://www.watson.org/~robert/jailng/"></ulink>.</para>
-
- </sect1>
-
-</chapter>
-
diff --git a/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml
deleted file mode 100644
index b2ef1f689b..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml
+++ /dev/null
@@ -1,298 +0,0 @@
-<!--
- The FreeBSD Documentation Project
-
- $FreeBSD$
--->
-
-<chapter id="kernel-objects">
- <title>Kernel Objects</title>
-
- <para>Kernel Objects, or <firstterm>Kobj</firstterm> provides an
- object-oriented C programming system for the kernel. As such the
- data being operated on carries the description of how to operate
- on it. This allows operations to be added and removed from an
- interface at run time and without breaking binary
- compatibility.</para>
-
- <sect1 id="kernel-objects-term">
- <title>Terminology</title>
-
- <variablelist>
- <varlistentry>
- <term>Object</term>
- <listitem><para>A set of data - data structure - data
- allocation.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Method</term>
- <listitem>
- <para>An operation - function.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Class</term>
- <listitem>
- <para>One or more methods.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Interface</term>
- <listitem>
- <para>A standard set of one or more methods.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect1>
-
- <sect1 id="kernel-objects-operation">
- <title>Kobj Operation</title>
-
- <para>Kobj works by generating descriptions of methods. Each
- description holds a unique id as well as a default function. The
- description's address is used to uniquely identify the method
- within a class' method table.</para>
-
- <para>A class is built by creating a method table associating one
- or more functions with method descriptions. Before use the class
- is compiled. The compilation allocates a cache and associates it
- with the class. A unique id is assigned to each method
- description within the method table of the class if not already
- done so by another referencing class compilation. For every
- method to be used a function is generated by script to qualify
- arguments and automatically reference the method description for
- a lookup. The generated function looks up the method by using
- the unique id associated with the method description as a hash
- into the cache associated with the object's class. If the method
- is not cached the generated function proceeds to use the class'
- table to find the method. If the method is found then the
- associated function within the class is used; otherwise, the
- default function associated with the method description is
- used.</para>
-
- <para>These indirections can be visualized as the
- following:</para>
-
- <programlisting>object->cache<->class</programlisting>
-
- </sect1>
-
- <sect1 id="kernel-objects-using">
- <title>Using Kobj</title>
-
- <sect2>
- <title>Structures</title>
-
- <programlisting>struct kobj_method</programlisting>
- </sect2>
-
- <sect2>
- <title>Functions</title>
-
- <programlisting>void kobj_class_compile(kobj_class_t cls);
-void kobj_class_compile_static(kobj_class_t cls, kobj_ops_t ops);
-void kobj_class_free(kobj_class_t cls);
-kobj_t kobj_create(kobj_class_t cls, struct malloc_type *mtype, int mflags);
-void kobj_init(kobj_t obj, kobj_class_t cls);
-void kobj_delete(kobj_t obj, struct malloc_type *mtype);</programlisting>
- </sect2>
-
- <sect2>
- <title>Macros</title>
-
- <programlisting>KOBJ_CLASS_FIELDS
-KOBJ_FIELDS
-DEFINE_CLASS(name, methods, size)
-KOBJMETHOD(NAME, FUNC)</programlisting>
- </sect2>
-
- <sect2>
- <title>Headers</title>
-
- <programlisting>&lt;sys/param.h>
-&lt;sys/kobj.h></programlisting>
- </sect2>
-
- <sect2>
- <title>Creating an interface template</title>
-
- <para>The first step in using Kobj is to create an
- Interface. Creating the interface involves creating a template
- that the script
- <filename>src/sys/kern/makeobjops.pl</filename> can use to
- generate the header and code for the method declarations and
- method lookup functions.</para>
-
- <para>Within this template the following keywords are used:
- <literal>#include</literal>, <literal>INTERFACE</literal>,
- <literal>CODE</literal>, <literal>METHOD</literal>,
- <literal>STATICMETHOD</literal>, and
- <literal>DEFAULT</literal>.</para>
-
- <para>The <literal>#include</literal> statement and what follows
- it is copied verbatim to the head of the generated code
- file.</para>
-
- <para>For example:</para>
-
- <programlisting>#include &lt;sys/foo.h></programlisting>
-
- <para>The <literal>INTERFACE</literal> keyword is used to define
- the interface name. This name is concatenated with each method
- name as [interface name]_[method name]. Its syntax is
- INTERFACE [interface name];.</para>
-
- <para>For example:</para>
-
- <programlisting>INTERFACE foo;</programlisting>
-
- <para>The <literal>CODE</literal> keyword copies its arguments
- verbatim into the code file. Its syntax is
- <literal>CODE { [whatever] };</literal></para>
-
- <para>For example:</para>
-
- <programlisting>CODE {
- struct foo * foo_alloc_null(struct bar *)
- {
- return NULL;
-}
-};</programlisting>
-
- <para>The <literal>METHOD</literal> keyword describes a method. Its syntax is
- <literal>METHOD [return type] [method name] { [object [,
- arguments]] };</literal></para>
-
- <para>For example:</para>
-
- <programlisting>METHOD int bar {
- struct object *;
- struct foo *;
- struct bar;
-};</programlisting>
-
- <para>The <literal>DEFAULT</literal> keyword may follow the
- <literal>METHOD</literal> keyword. It extends the
- <literal>METHOD</literal> key word to include the default
- function for method. The extended syntax is
- <literal>METHOD [return type] [method name] {
- [object; [other arguments]] }DEFAULT [default
- function];</literal></para>
-
- <para>For example:</para>
-
- <programlisting>METHOD int bar {
- struct object *;
- struct foo *;
- int bar;
-} DEFAULT foo_hack;</programlisting>
-
- <para>The <literal>STATICMETHOD</literal> keyword is used like
- the <literal>METHOD</literal> keyword except the kobj data is not
- at the head of the object structure so casting to kobj_t would
- be incorrect. Instead <literal>STATICMETHOD</literal> relies on the Kobj data being
- referenced as 'ops'. This is also useful for calling
- methods directly out of a class's method table.</para>
-
- <para>Other complete examples:</para>
-
- <programlisting>src/sys/kern/bus_if.m
-src/sys/kern/device_if.m</programlisting>
-
- </sect2>
-
- <sect2>
- <title>Creating a Class</title>
-
- <para>The second step in using Kobj is to create a class. A
- class consists of a name, a table of methods, and the size of
- objects if Kobj's object handling facilities are used. To
- create the class use the macro
- <function>DEFINE_CLASS()</function>. To create the method
- table create an array of kobj_method_t terminated by a NULL
- entry. Each non-NULL entry may be created using the macro
- <function>KOBJMETHOD()</function>.</para>
-
- <para>For example:</para>
-
- <programlisting>DEFINE_CLASS(fooclass, foomethods, sizeof(struct foodata));
-
-kobj_method_t foomethods[] = {
- KOBJMETHOD(bar_doo, foo_doo),
- KOBJMETHOD(bar_foo, foo_foo),
- { NULL, NULL}
-};</programlisting>
-
- <para>The class must be <quote>compiled</quote>. Depending on
- the state of the system at the time that the class is to be
- initialized a statically allocated cache, <quote>ops
- table</quote> have to be used. This can be accomplished by
- declaring a <structname>struct kobj_ops</structname> and using
- <function>kobj_class_compile_static();</function> otherwise,
- <function>kobj_class_compile()</function> should be used.</para>
- </sect2>
-
- <sect2>
- <title>Creating an Object</title>
-
- <para>The third step in using Kobj involves how to define the
- object. Kobj object creation routines assume that Kobj data is
- at the head of an object. If this in not appropriate you will
- have to allocate the object yourself and then use
- <function>kobj_init()</function> on the Kobj portion of it;
- otherwise, you may use <function>kobj_create()</function> to
- allocate and initialize the Kobj portion of the object
- automatically. <function>kobj_init()</function> may also be
- used to change the class that an object uses.</para>
-
- <para>To integrate Kobj into the object you should use the macro
- KOBJ_FIELDS.</para>
-
- <para>For example</para>
-
- <programlisting>struct foo_data {
- KOBJ_FIELDS;
- foo_foo;
- foo_bar;
-};</programlisting>
- </sect2>
-
- <sect2>
- <title>Calling Methods</title>
-
- <para>The last step in using Kobj is to simply use the generated
- functions to use the desired method within the object's
- class. This is as simple as using the interface name and the
- method name with a few modifications. The interface name
- should be concatenated with the method name using a '_'
- between them, all in upper case.</para>
-
- <para>For example, if the interface name was foo and the method
- was bar then the call would be:</para>
-
- <programlisting>[return value = ] FOO_BAR(object [, other parameters]);</programlisting>
-
- </sect2>
-
- <sect2>
- <title>Cleaning Up</title>
-
- <para>When an object allocated through
- <function>kobj_create()</function> is no longer needed
- <function>kobj_delete()</function> may be called on it, and
- when a class is no longer being used
- <function>kobj_class_free()</function> may be called on it.</para>
- </sect2>
- </sect1>
-</chapter>
-
-<!--
- Local Variables:
- mode: sgml
- sgml-declaration: "../chapter.decl"
- sgml-indent-data: t
- sgml-omittag: nil
- sgml-always-quote-attributes: t
- sgml-parent-document: ("../book.sgml" "part" "chapter")
- End:
--->
diff --git a/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml
deleted file mode 100644
index ed32ed61b5..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml
+++ /dev/null
@@ -1,313 +0,0 @@
-<!--
- The FreeBSD Documentation Project
- The FreeBSD SMP Next Generation Project
-
- $FreeBSD$
--->
-
-<chapter id="locking">
- <title>Locking Notes</title>
-
- <para><emphasis>This chapter is maintained by the FreeBSD SMP Next
- Generation Project. Please direct any comments or suggestions
- to its &a.smp;.</emphasis></para>
-
-
- <para>This document outlines the locking used in the FreeBSD kernel
- to permit effective multi-processing within the kernel. Locking
- can be achieved via several means. Data structures can be
- protected by mutexes or &man.lockmgr.9; locks. A few variables
- are protected simply by always using atomic operations to access
- them.</para>
-
- <sect1 id="locking-mutexes">
- <title>Mutexes</title>
-
- <para>A mutex is simply a lock used to guarantee mutual exclusion.
- Specifically, a mutex may only be owned by one entity at a time.
- If another entity wishes to obtain a mutex that is already
- owned, it must wait until the mutex is released. In the FreeBSD
- kernel, mutexes are owned by processes.</para>
-
- <para>Mutexes may be recursively acquired, but they are intended
- to be held for a short period of time. Specifically, one may
- not sleep while holding a mutex. If you need to hold a lock
- across a sleep, use a &man.lockmgr.9; lock.</para>
-
- <para>Each mutex has several properties of interest:</para>
-
- <variablelist>
- <varlistentry>
- <term>Variable Name</term>
- <listitem>
- <para>The name of the <type>struct mtx</type> variable in
- the kernel source.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Logical Name</term>
- <listitem>
- <para>The name of the mutex assigned to it by
- <function>mtx_init</function>. This name is displayed in
- KTR trace messages and witness errors and warnings and is
- used to distinguish mutexes in the witness code.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Type</term>
- <listitem>
- <para>The type of the mutex in terms of the
- <constant>MTX_*</constant> flags. The meaning for each
- flag is related to its meaning as documented in
- &man.mutex.9;.</para>
-
- <variablelist>
- <varlistentry>
- <term><constant>MTX_DEF</constant></term>
- <listitem>
- <para>A sleep mutex</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><constant>MTX_SPIN</constant></term>
- <listitem>
- <para>A spin mutex</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><constant>MTX_RECURSE</constant></term>
- <listitem>
- <para>This mutex is allowed to recurse.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Protectees</term>
- <listitem>
- <para>A list of data structures or data structure members
- that this entry protects. For data structure members, the
- name will be in the form of
- <structname/structure name/.<structfield/member name/.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Dependent Functions</term>
- <listitem>
- <para>Functions that can only be called if this mutex is
- held.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <table frame="all" colsep="1" rowsep="1" pgwide="1">
- <title>Mutex List</title>
-
- <tgroup cols="5">
- <thead>
- <row>
- <entry>Variable Name</entry>
- <entry>Logical Name</entry>
- <entry>Type</entry>
- <entry>Protectees</entry>
- <entry>Dependent Functions</entry>
- </row>
- </thead>
-
- <!-- The scheduler lock -->
- <tbody>
- <row>
- <entry>sched_lock</entry>
- <entry><quote>sched lock</quote></entry>
- <entry>
- <constant>MTX_SPIN</constant> |
- <constant>MTX_RECURSE</constant>
- </entry>
- <entry>
- <varname>_gmonparam</varname>,
- <varname>cnt.v_swtch</varname>,
- <varname>cp_time</varname>,
- <varname>curpriority</varname>,
- <structname/mtx/.<structfield/mtx_blocked/,
- <structname/mtx/.<structfield/mtx_contested/,
- <structname/proc/.<structfield/p_procq/,
- <structname/proc/.<structfield/p_slpq/,
- <structname/proc/.<structfield/p_sflag/
- <structname/proc/.<structfield/p_stat/,
- <structname/proc/.<structfield/p_estcpu/,
- <structname/proc/.<structfield/p_cpticks/
- <structname/proc/.<structfield/p_pctcpu/,
- <structname/proc/.<structfield/p_wchan/,
- <structname/proc/.<structfield/p_wmesg/,
- <structname/proc/.<structfield/p_swtime/,
- <structname/proc/.<structfield/p_slptime/,
- <structname/proc/.<structfield/p_runtime/,
- <structname/proc/.<structfield/p_uu/,
- <structname/proc/.<structfield/p_su/,
- <structname/proc/.<structfield/p_iu/,
- <structname/proc/.<structfield/p_uticks/,
- <structname/proc/.<structfield/p_sticks/,
- <structname/proc/.<structfield/p_iticks/,
- <structname/proc/.<structfield/p_oncpu/,
- <structname/proc/.<structfield/p_lastcpu/,
- <structname/proc/.<structfield/p_rqindex/,
- <structname/proc/.<structfield/p_heldmtx/,
- <structname/proc/.<structfield/p_blocked/,
- <structname/proc/.<structfield/p_mtxname/,
- <structname/proc/.<structfield/p_contested/,
- <structname/proc/.<structfield/p_priority/,
- <structname/proc/.<structfield/p_usrpri/,
- <structname/proc/.<structfield/p_nativepri/,
- <structname/proc/.<structfield/p_nice/,
- <structname/proc/.<structfield/p_rtprio/,
- <varname>pscnt</varname>,
- <varname>slpque</varname>,
- <varname>itqueuebits</varname>,
- <varname>itqueues</varname>,
- <varname>rtqueuebits</varname>,
- <varname>rtqueues</varname>,
- <varname>queuebits</varname>,
- <varname>queues</varname>,
- <varname>idqueuebits</varname>,
- <varname>idqueues</varname>,
- <varname>switchtime</varname>,
- <varname>switchticks</varname>
- </entry>
- <entry>
- <function>setrunqueue</function>,
- <function>remrunqueue</function>,
- <function>mi_switch</function>,
- <function>chooseproc</function>,
- <function>schedclock</function>,
- <function>resetpriority</function>,
- <function>updatepri</function>,
- <function>maybe_resched</function>,
- <function>cpu_switch</function>,
- <function>cpu_throw</function>,
- <function>need_resched</function>,
- <function>resched_wanted</function>,
- <function>clear_resched</function>,
- <function>aston</function>,
- <function>astoff</function>,
- <function>astpending</function>,
- <function>calcru</function>,
- <function>proc_compare</function>
- </entry>
- </row>
-
- <!-- The vm86 pcb lock -->
- <row>
- <entry>vm86pcb_lock</entry>
- <entry><quote>vm86pcb lock</quote></entry>
- <entry>
- <constant>MTX_DEF</constant>
- </entry>
- <entry>
- <varname>vm86pcb</varname>
- </entry>
- <entry>
- <function>vm86_bioscall</function>
- </entry>
- </row>
-
- <!-- Giant -->
- <row>
- <entry>Giant</entry>
- <entry><quote>Giant</quote></entry>
- <entry>
- <constant>MTX_DEF</constant> |
- <constant>MTX_RECURSE</constant>
- </entry>
- <entry>nearly everything</entry>
- <entry>lots</entry>
- </row>
-
- <!-- The callout lock -->
- <row>
- <entry>callout_lock</entry>
- <entry><quote>callout lock</quote></entry>
- <entry>
- <constant>MTX_SPIN</constant> |
- <constant>MTX_RECURSE</constant>
- </entry>
- <entry>
- <varname>callfree</varname>,
- <varname>callwheel</varname>,
- <varname>nextsoftcheck</varname>,
- <structname/proc/.<structfield/p_itcallout/,
- <structname/proc/.<structfield/p_slpcallout/,
- <varname>softticks</varname>,
- <varname>ticks</varname>
- </entry>
- <entry>
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </sect1>
-
- <sect1 id="locking-sx">
- <title>Shared Exclusive Locks</title>
-
- <para>These locks provide basic reader-writer type functionality
- and may be held by a sleeping process. Currently they are
- backed by &man.lockmgr.9;.</para>
-
- <table>
- <title>Shared Exclusive Lock List</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Variable Name</entry>
- <entry>Protectees</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><varname>allproc_lock</varname></entry>
- <entry>
- <varname>allproc</varname>
- <varname>zombproc</varname>
- <varname>pidhashtbl</varname>
- <structname/proc/.<structfield/p_list/
- <structname/proc/.<structfield/p_hash/
- <varname>nextpid</varname>
- </entry>
- <entry><varname>proctree_lock</varname></entry>
- <entry>
- <structname/proc/.<structfield/p_children/
- <structname/proc/.<structfield/p_sibling/
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </sect1>
-
- <sect1 id="locking-atomic">
- <title>Atomically Protected Variables</title>
-
- <para>An atomically protected variable is a special variable that
- is not protected by an explicit lock. Instead, all data
- accesses to the variables use special atomic operations as
- described in &man.atomic.9;. Very few variables are treated
- this way, although other synchronization primitives such as
- mutexes are implemented with atomically protected
- variables.</para>
-
- <itemizedlist>
- <listitem>
- <para><structname/mtx/.<structfield/mtx_lock/</para>
- </listitem>
- </itemizedlist>
- </sect1>
-</chapter>
diff --git a/en_US.ISO8859-1/books/arch-handbook/mac.ent b/en_US.ISO8859-1/books/arch-handbook/mac.ent
deleted file mode 100644
index 6ead9b19ca..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/mac.ent
+++ /dev/null
@@ -1,122 +0,0 @@
-<!-- $FreeBSD$ -->
-
-<!ENTITY mac.mpo "mpo">
-<!ENTITY mac.thead '
- <colspec colname="first" colwidth="0">
- <colspec colwidth="0">
- <colspec colname="last" colwidth="0">
-
- <thead>
- <row>
- <entry>Parameter</entry>
- <entry>Description</entry>
- <entry>Locking</entry>
- </row>
- </thead>
-'>
-
-<!ENTITY mac.externalize.paramdefs '
- <paramdef>struct label *<parameter>label</parameter></paramdef>
- <paramdef>char *<parameter>element_name</parameter></paramdef>
- <paramdef>char *<parameter>element_data</parameter></paramdef>
- <paramdef>size_t <parameter>size</parameter></paramdef>
- <paramdef>size_t <parameter>*len</parameter></paramdef>
- <paramdef>int <parameter>*claimed</parameter></paramdef>
-'>
-
-<!ENTITY mac.externalize.tbody '
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label to be externalized</entry>
- </row>
-
- <row>
- <entry><parameter>element_name</parameter>
- <entry>Name of the policy whose label should be externalized</entry>
- </row>
-
- <row>
- <entry><parameter>element_data</parameter>
- <entry>Buffer; to be filled in with text representation of label</entry>
- </row>
-
- <row>
- <entry><parameter>size</parameter></entry>
- <entry>Size of <parameter>element_data</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>len</parameter></entry>
- <entry>To be filled in with the length of the string representing the
- label data.</entry>
- </row>
-
- <row>
- <entry><parameter>claimed</parameter></entry>
- <entry>Should be incremented when <parameter>element_data</parameter>
- can be filled in.</entry>
- </row>
- </tbody>
-'>
-
-<!ENTITY mac.externalize.para "
- <para>Produce an externalized label based on the label structure passed.
- An externalized label consists of a text representation of the label
- contents that can be used with userland applications and read by the
- user. Currently, all policies' <function>externalize</function> entry
- points will be called, so the implementation should check the contents
- of <parameter>element_name</parameter> before attempting to fill in
- <parameter>element_data</parameter>. If
- <parameter>element_name</parameter> does not match the name of your
- policy, simply return <returnvalue>0</returnvalue>. Only return nonzero
- if an error occurs while externalizing the label data. Once the policy
- fills in <parameter>element_data</parameter>, <varname>*claimed</varname>
- should be incremented.</para>
-">
-
-<!ENTITY mac.internalize.paramdefs '
- <paramdef>struct label *<parameter>label</parameter></paramdef>
- <paramdef>char *<parameter>element_name</parameter></paramdef>
- <paramdef>char *<parameter>element_data</parameter></paramdef>
- <paramdef>int *<parameter>claimed</parameter></paramdef>
-'>
-
-<!ENTITY mac.internalize.tbody '
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label to be filled in</entry>
- </row>
-
- <row>
- <entry><parameter>element_name</parameter></entry>
- <entry>Name of the policy whose label should be internalized</entry>
- </row>
-
- <row>
- <entry><parameter>element_data</parameter></entry>
- <entry>Text data to be internalized</entry>
- </row>
-
- <row>
- <entry><parameter>claimed</parameter></entry>
- <entry>Should be incremented when data can be successfully
- internalized.</entry>
- </row>
- </tbody>
-'>
-
-<!ENTITY mac.internalize.para "
- <para>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.</para>
-">
diff --git a/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml
deleted file mode 100644
index caee9e28a4..0000000000
--- a/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml
+++ /dev/null
@@ -1,7483 +0,0 @@
-<!--
- Copyright (c) 2002, 2003 Networks Associates Technology, Inc.
- All rights reserved.
-
- This software was developed for the FreeBSD Project by
- Chris Costello at Safeport Network Services and Network Associates Labs,
- the Security Research Division of Network Associates, Inc. under
- DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the
- DARPA CHATS research program.
-
- Redistribution and use in source and binary forms, with or without
- modification, are permitted provided that the following conditions
- are met:
- 1. Redistributions of source code must retain the above copyright
- notice, this list of conditions and the following disclaimer.
- 2. Redistributions in binary form must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
- THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``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 THE AUTHORS OR CONTRIBUTORS 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 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- SUCH DAMAGE.
-
- $FreeBSD$
--->
-
-<chapter id="mac">
- <chapterinfo>
- <authorgroup>
- <author>
- <firstname>Chris</firstname>
- <surname>Costello</surname>
-
- <affiliation>
- <orgname>TrustedBSD Project</orgname>
- <address><email>chris@FreeBSD.org</email></address>
- </affiliation>
- </author>
-
- <author>
- <firstname>Robert</firstname>
- <surname>Watson</surname>
-
- <affiliation>
- <orgname>TrustedBSD Project</orgname>
- <address><email>rwatson@FreeBSD.org</email></address>
- </affiliation>
- </author>
- </authorgroup>
- </chapterinfo>
-
- <title>The TrustedBSD MAC Framework</title>
-
- <sect1 id="mac-copyright">
- <title>MAC Documentation Copyright</title>
-
- <para>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.</para>
-
- <para>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:</para>
-
- <orderedlist>
- <listitem>
- <para>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.</para>
- </listitem>
-
- <listitem>
- <para>Redistributions in compiled form (transformed to other
- DTDs, converted to PDF, PostScript, RTF and other formats)
- must reproduce the above copyright notice, this list of
- conditions and the following disclaimer in the documentation
- and/or other materials provided with the
- distribution.</para>
- </listitem>
- </orderedlist>
-
- <important>
- <para>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.</para>
- </important>
- </sect1>
-
- <sect1 id="mac-synopsis">
- <title>Synopsis</title>
-
- <para>MAC, or Mandatory Access Control, is a feature introduced by
- the TrustedBSD Project to supplement the existing standard DAC
- (Discretionary Access Control) policies of BSD Unix systems.</para>
-
- <para>This chapter introduces the MAC policy framework and
- provides documentation for a sample MAC policy module.</para>
- </sect1>
-
-
- <sect1 id="mac-introduction">
- <title>Introduction</title>
-
- <para>The TrustedBSD MAC framework provides a mechanism to allow
- the compile-time or run-time extension of the kernel access
- control model. New system policies may be implemented as
- kernel modules and linked to the kernel; if multiple policy
- modules are present, their results will be composed. While the
- framework is intended to support a variety of access control
- models, its design was derived from the requirements of a set
- of specific access control models required for the TrustedBSD
- and CBOSS Projects. This includes support for fixed and
- floating label Biba integrity policies, the MLS
- confidentiality policy, the Type Enforcement rule-based access
- control policy, and the ability to support layering of the NSA
- FLASK framework above the TrustedBSD MAC framework. This
- document describes the rough architecture of the framework,
- with the understanding that this is a work-in-progress and may
- change subtantially as requirements evolve.</para>
- </sect1>
-
- <sect1 id="mac-kernel-arch">
- <title>Kernel Architecture</title>
-
- <para>The TrustedBSD MAC framework provides the opportunity for
- policy modules to be augment system access control decisions.
- Policies are permitted the opportunity to restrict the set of
- rights available for processes at a variety of relevant points
- in the kernel. In addition, they are provided the opportunity
- to tag processes and various kernel objects with labels storing
- access control information. Policy modules may register
- interest in a subset of the total available events or objects,
- and are not required to implement events or objects that are not
- relevant to the policy. Multiple modules may be loaded at once,
- and the results of the modules are composed as necessary to
- build an over-all system policy. Policy modules may be
- implemented such that they can be loaded on-demand at run-time,
- or such that they may only be loaded early in the boot process.
- This permits policies requiring pervasive labeling of all
- objects to prevent improper use.</para>
- </sect1>
-
- <sect1 id="mac-userland-arch">
- <title>Userland Architecture</title>
-
- <para>...</para>
- </sect1>
-
- <sect1 id="mac-entry-point">
- <title>Entry Point Framework</title>
-
- <para>Four classes of entry points are offered to policies
- registered with the framework: entry points associated with
- the registration and management of policies, entry points
- denoting initialization, creation, destruction, and other life
- cycle events for kernel objects, events assocated with access
- control decisions that the policy module may influence, and
- calls associated with the management of labels on objects. In
- addition, a <function>mac_syscall()</function> entry point is
- provided so that policies may extend the kernel interface
- without registering new system calls.</para>
-
- <para>Policy module writers should be aware of the kernel
- locking strategy, as well as what object locks are available
- during which entry points. Writers should attempt to avoid
- deadlock scenarios by avoiding grabbing non-leaf locks inside
- of entry points, and also follow the locking protocol for
- object access and modification. In particular, writers should
- be aware that while necessary locks to access objects and
- their labels are generally held, sufficient locks to modify an
- object or its label may not be present for all entry points.
- Locking information for arguments is documented in the MAC
- framework entry point document.</para>
-
- <para>Policy entry points will pass a reference to the object
- label along with the object itself. This permits labeled
- policies to be unaware of the internals of the object yet
- still make decisions based on the label. The exception to this
- is the process credential, which is assumed to be understood
- by policies as a first class security object in the kernel.
- Policies that do not implement labels on kernel objects will
- be passed NULL pointers for label arguments to entry
- points.</para>
-
- <sect2 id="mac-mpo-general">
- <title>General-Purpose Module Entry Points</title>
-
- <para>Modules may be declared using the
- <function>MAC_POLICY_SET()</function> macro, which names the
- policy, provides a reference to the MAC entry point vector,
- provides load-time flags determining how the policy framework
- should handle the policy, and optionally requests the
- allocation of label state by the framework.</para>
-
- <programlisting>static struct mac_policy_ops mac_<replaceable>policy</replaceable>_ops =
-{
- .mpo_destroy = mac_<replaceable>policy</replaceable>_destroy,
- .mpo_init = mac_<replaceable>policy</replaceable>_init,
- .mpo_init_bpfdesc_label = mac_<replaceable>policy</replaceable>_init_bpfdesc_label,
- .mpo_init_cred_label = mac_<replaceable>policy</replaceable>_init_label,
-/* ... */
- .mpo_check_vnode_setutimes = mac_<replaceable>policy</replaceable>_check_vnode_setutimes,
- .mpo_check_vnode_stat = mac_<replaceable>policy</replaceable>_check_vnode_stat,
- .mpo_check_vnode_write = mac_<replaceable>policy</replaceable>_check_vnode_write,
-};</programlisting>
-
- <para>The MAC policy entry point vector,
- <varname>mac_<replaceable>policy</replaceable>_ops</varname> in this example, associates
- functions defined in the module with specific entry points. A
- complete listing of available entry points and their
- prototypes may be found in the MAC entry point reference
- section. Of specific interest during module registration are
- the <symbol>.mpo_destroy</symbol> and <symbol>.mpo_init</symbol>
- entry points. <symbol>.mpo_init</symbol> will be invoked once a
- policy is successfully registered with the module framework
- but prior to any other entry points becoming active. This
- permits the policy to perform any policy-specific allocation
- and initialization, such as initialization of any data or
- locks. <symbol>.mpo_destroy</symbol> will be invoked when a
- policy module is unloaded to permit releasing of any allocated
- memory and destruction of locks. Currently, these two entry
- points are invoked with the MAC policy list mutex held to
- prevent any other entry points from being invoked: this will
- be changed, but in the mean time, policies should be careful
- about what kernel primitives they invoke so as to avoid lock
- ordering or sleeping problems.</para>
-
- <para>The policy declaration's module name field exists so that
- the module may be uniquely identified for the purposes of
- module dependencies. An appropriate string should be selected.
- The full string name of the policy is displayed to the user
- via the kernel log during load and unload events, and also
- exported when providing status information to userland
- processes.</para>
-
- <para>The policy flags field permits the module to provide the
- framework with information about its loader-related
- capabilities. Currently, two flags are defined:</para>
-
- <variablelist>
- <varlistentry>
- <term>MPC_LOADTIME_FLAG_UNLOADOK</term>
-
- <listitem>
- <para>This flag indicates that the policy module may be
- unloaded. If this flag is not provided, then the policy
- framework will reject requests to unload the module.
- This flag might be used by modules that allocate label
- state and are unable to free that state at
- runtime.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>MPC_LOADTIME_FLAG_NOTLATE</term>
-
- <listitem><para>This flag indicates that the policy module
- must be loaded and initialized early in the boot
- process. If the flag is specified, attempts to register
- the module following boot will be rejected. The flag
- may be used by policies that require pervasive labeling
- of all system objects, and cannot handle objects that
- have not been properly initialized by the policy.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <sect3 id="mac-mpo-init">
- <title><function>&mac.mpo;_init</function</title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init</function></funcdef>
-
- <paramdef>struct mac_policy_conf
- *<parameter>conf</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>conf</parameter></entry>
- <entry>MAC policy definition</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Policy load event. The policy list mutex is held, so
- caution should be applied.</para>
- </sect3>
-
- <sect3 id="mpo-destroy">
- <title><function>&mac.mpo;_destroy</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy</function></funcdef>
-
- <paramdef>struct mac_policy_conf
- *<parameter>conf</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>conf</parameter></entry>
- <entry>MAC policy definition</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Policy load event. The policy list mutex is held, so
- caution should be applied.</para>
- </sect3>
-
- <sect3 id="mac-mpo-syscall">
- <title><function>&mac.mpo;_syscall</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_syscall</function></funcdef>
-
- <paramdef>struct thread
- *<parameter>td</parameter></paramdef>
- <paramdef>int <parameter>call</parameter></paramdef>
- <paramdef>void *<parameter>arg</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>td</parameter></entry>
- <entry>Calling thread</entry>
- </row>
-
- <row>
- <entry><parameter>call</parameter></entry>
- <entry>Syscall number</entry>
- </row>
-
- <row>
- <entry><parameter>arg</parameter></entry>
- <entry>Pointer to syscall arguments</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>This entry point provides a policy-multiplexed system
- call so that policies may provide additional services to
- user processes without registering specific system calls.
- The policy name provided during registration is used to
- demux calls from userland, and the arguments will be
- forwarded to this entry point. When implementing new
- services, security modules should be sure to invoke
- appropriate access control checks from the MAC framework as
- needed. For example, if a policy implements an augmented
- signal functionality, it should call the necessary signal
- access control checks to invoke the MAC framework and other
- registered policies.</para>
-
- <note><para>Modules must currently perform the
- <function>copyin()</function> of the syscall data on their
- own.</para></note>
- </sect3>
-
- <sect3 id="mac-mpo-thread-userret">
- <title><function>&mac.mpo;_thread_userret</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_thread_userret</function></funcdef>
-
- <paramdef>struct thread
- *<parameter>td</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>td</parameter></entry>
- <entry>Returning thread</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <!-- XXX: Maybe rewrite this section. -->
- <para>This entry point permits policy modules to perform
- MAC-related events when a thread returns to user space.
- This is required for policies that have floating process
- labels, as it's not always possible to acquire the process
- lock at arbitrary points in the stack during system call
- processing; process labels might represent traditional
- authentication data, process history information, or other
- data.</para>
- </sect3>
- </sect2>
-
- <sect2 id="mac-label-ops">
- <title>Label Operations</title>
-
- <sect3 id="mac-mpo-init-bpfdesc">
- <title><function>&mac.mpo;_init_bpfdesc_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_bpfdesc_label</function></funcdef>
-
- <paramdef>struct bpf_d
- *<parameter>bpf_d</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>bpf_d</parameter></entry>
- <entry>Object; bpf descriptor</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to apply</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly instantiated bpfdesc (BPF
- descriptor)</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-cred-label">
- <title><function>&mac.mpo;_init_cred_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_cred_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to initialize</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label for a newly instantiated
- user credential.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-devfsdirent">
- <title><function>&mac.mpo;_init_devfsdirent_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_devfsdirent_label</function></funcdef>
-
- <paramdef>struct devfs_dirent
- *<parameter>devfs_dirent</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>devfs_dirent</parameter></entry>
- <entry>Object; devfs directory entry</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to apply</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly instantiated devfs
- entry.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-ifnet">
- <title><function>&mac.mpo;_init_ifnet_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_ifnet_label</function></funcdef>
-
- <paramdef>struct ifnet
- *<parameter>ifnet</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>ifnet</parameter></entry>
- <entry>Object; network interface</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to apply</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly instantiated network
- interface.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-ipq">
- <title><function>&mac.mpo;_init_ipq_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_ipq_label</function></funcdef>
-
- <paramdef>struct ipq
- *<parameter>ipq</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>ipq</parameter></entry>
- <entry>Object; IP reassembly queue</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to apply</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly instantiated IP fragment
- reassembly queue.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-mbuf">
- <title><function>&mac.mpo;_init_mbuf_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_mbuf_label</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>mbuf</parameter></paramdef>
- <paramdef>int <parameter>how</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mbuf</parameter></entry>
- <entry>Object; mbuf</entry>
- </row>
-
- <row>
- <entry><parameter>how</parameter></entry>
- <entry>Blocking/non-blocking &man.malloc.9;; see
- below</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Policy label to initialize</entry>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly instantiated mbuf packet
- header (<parameter>mbuf</parameter>). The
- <parameter>how</parameter> field may be one of
- <symbol>M_WAITOK</symbol> and <symbol>M_NOWAIT</symbol>, and
- should be employed to avoid performing a blocking
- &man.malloc.9; during this initialization call. Mbuf
- allocation frequently occurs in performance sensitive
- environments, and the implementation should be careful to
- avoid blocking or long-lived operations. This entry point
- is permitted to fail resulting in the failure to allocate
- the mbuf header.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-mount">
- <title><function>&mac.mpo;_init_mount_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_mount_label</function></funcdef>
-
- <paramdef>struct mount
- *<parameter>mount</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mntlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <!-- XXX: Wording on label descriptions. -->
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mount</parameter></entry>
- <entry>Object; file system mount point</entry>
- </row>
-
- <row>
- <entry><parameter>mntlabel</parameter></entry>
- <entry>Policy label to be initialized for the mount
- itself</entry>
- </row>
-
- <row>
- <entry><parameter>fslabel</parameter></entry>
- <entry>Policy label to be initialized for the file
- system</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the labels on a newly instantiated mount
- point.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-mount-fs-label">
- <title><function>&mac.mpo;_init_mount_fs_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_mount_fs_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label to be initialized</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly mounted file
- system.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-pipe-label">
- <title><function>&mac.mpo;_init_pipe_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_pipe_label</function></funcdef>
-
- <paramdef>struct
- label*<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label to be filled in</entry>
- </row>
- </tbody>
- </informaltable>
-
- <para>Initialize a label for a newly instantiated pipe.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-socket">
- <title><function>&mac.mpo;_init_socket_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_socket_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- <paramdef>int <parameter>flag</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to initialize</entry>
- </row>
-
- <row>
- <entry><parameter>flag</parameter></entry>
- <entry>&man.malloc.9; flags</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize a label for a newly instantiated
- socket.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-socket-peer-label">
- <title><function>&mac.mpo;_init_socket_peer_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_socket_peer_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- <paramdef>int <parameter>flag</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to initialize</entry>
- </row>
-
- <row>
- <entry><parameter>flag</parameter></entry>
- <entry>&man.malloc.9; flags</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the peer label for a newly instantiated
- socket.</para>
- </sect3>
-
- <sect3 id="mac-mpo-init-proc-label">
- <title><function>&mac.mpo;_init_proc_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_proc_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to initialize</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label for a newly instantiated
- process.</para>
- </sect3>
-
-
- <sect3 id="mac-mpo-init-vnode">
- <title><function>&mac.mpo;_init_vnode_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_init_vnode_label</function></funcdef>
-
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>Object; file system object</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>New label to initialize</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Initialize the label on a newly instantiated vnode.</para>
- </sect3>
- <sect3 id="mac-mpo-destroy-bpfdesc">
- <title><function>&mac.mpo;_destroy_bpfdesc_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_bpfdesc_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>bpfdesc label</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a bpf descriptor. In this entry
- point a policy should free any internal storage associated
- with <parameter>label</parameter> so that it may be
- destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-cred">
- <title><function>&mac.mpo;_destroy_cred_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_cred_label</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject; user credential</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a credential. In this entry point,
- a policy module should free any internal storage associated
- with <parameter>label</parameter> so that it may be
- destroyed.</para>
- </sect3>
-
-
- <sect3 id="mac-mpo-destroy-devfsdirent">
- <title><function>&mac.mpo;_destroy_devfsdirent_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_devfsdirent_label</function></funcdef>
-
- <paramdef>struct devfs_dirent
- *<parameter>devfs_dirent</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>devfs_dirent</parameter></entry>
- <entry>Object; devfs directory entry</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a devfs entry. In this entry
- point, a policy module should free any internal storage
- asociated with <parameter>label</parameter> so that it may
- be destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-ifnet-label">
- <title><function>&mac.mpo;_destroy_ifnet_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_ifnet_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a removed interface. In this entry
- point, a policy module should free any internal storage
- associated with <parameter>label</parameter> so that it may
- be destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-ipq-label">
- <title><function>&mac.mpo;_destroy_ipq_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_ipq_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on an IP fragment queue. In this
- entry point, a policy module should free any internal
- storage associated with <parameter>label</parameter> so that
- it may be destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-mbuf-label">
- <title><function>&mac.mpo;_destroy_mbuf_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_mbuf_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on an mbuf header. In this entry
- point, a policy module should free any internal storage
- associated with <parameter>label</parameter> so that it may
- be destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-mount-label">
- <title><function>&mac.mpo;_destroy_mount_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_mount_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Mount point label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the labels on a mount point. In this entry
- point, a policy module should free the internal storage
- associated with <parameter>mntlabel</parameter> so that they
- may be destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-mount">
- <title><function>&mac.mpo;_destroy_mount_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_mount_label</function></funcdef>
-
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mntlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mp</parameter></entry>
- <entry>Object; file system mount point</entry>
- </row>
-
- <row>
- <entry><parameter>mntlabel</parameter></entry>
- <entry>Mount point label being destroyed</entry>
- </row>
-
- <row>
- <entry><parameter>fslabel</parameter></entry>
- <entry>File system label being destroyed>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the labels on a mount point. In this entry
- point, a policy module should free the internal storage
- associated with <parameter>mntlabel</parameter> and
- <parameter>fslabel</parameter> so that they may be
- destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-socket">
- <title><function>&mac.mpo;_destroy_socket_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_socket_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
-
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Socket label being destroyed</entry>
- </row>
-
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a socket. In this entry point, a
- policy module should free any internal storage associated
- with <parameter>label</parameter> so that it may be
- destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-socket-peer-label">
- <title><function>&mac.mpo;_destroy_socket_peer_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_socket_peer_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>peerlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>peerlabel</parameter></entry>
- <entry>Socket peer label being destroyed</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the peer label on a socket. In this entry
- point, a policy module should free any internal storage
- associated with <parameter>label</parameter> so that it may
- be destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-pipe-label">
- <title><function>&mac.mpo;_destroy_pipe_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_pipe_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Pipe label</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a pipe. In this entry point, a
- policy module should free any internal storage associated
- with <parameter>label</parameter> so that it may be
- destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-destroy-proc-label">
- <title><function>&mac.mpo;_destroy_proc_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_destroy_proc_label</function></funcdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Process label</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Destroy the label on a process. In this entry point, a
- policy module should free any internal storage associated
- with <parameter>label</parameter> so that it may be
- destroyed.</para>
- </sect3>
-
- <sect3 id="mac-mpo-copy-pipe-label">
- <title><function>&mac.mpo;_copy_pipe_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_copy_pipe_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>src</parameter></paramdef>
- <paramdef>struct label
- *<parameter>dest</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>src</parameter></entry>
- <entry>Source label</entry>
- </row>
-
- <row>
- <entry><parameter>dest</parameter></entry>
- <entry>Destination label</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Copy the label information in
- <parameter>src</parameter> into
- <parameter>dest</parameter>.</para>
- </sect3>
-
- <sect3 id="mac-mpo-copy-vnode-label">
- <title><function>&mac.mpo;_copy_vnode_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_copy_vnode_label</function></funcdef>
-
- <paramdef>struct label
- *<parameter>src</parameter></paramdef>
- <paramdef>struct label
- *<parameter>dest</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>src</parameter></entry>
- <entry>Source label</entry>
- </row>
-
- <row>
- <entry><parameter>dest</parameter></entry>
- <entry>Destination label</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Copy the label information in
- <parameter>src</parameter> into
- <parameter>dest</parameter>.</para>
- </sect3>
-
- <sect3 id="mac-mpo-externalize-cred-label">
- <title><function>&mac.mpo;_externalize_cred_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_externalize_cred_label</function></funcdef>
-
- &mac.externalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.externalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.externalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-externalize-ifnet-label">
- <title><function>&mac.mpo;_externalize_ifnet_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_externalize_ifnet_label</function></funcdef>
-
- &mac.externalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.externalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.externalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-externalize-pipe-label">
- <title><function>&mac.mpo;_externalize_pipe_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_externalize_pipe_label</function></funcdef>
-
- &mac.externalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.externalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.externalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-externalize-socket-label">
- <title><function>&mac.mpo;_externalize_socket_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_externalize_socket_label</function></funcdef>
-
- &mac.externalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.externalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.externalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-externalize-socket-peer-label">
- <title><function>&mac.mpo;_externalize_socket_peer_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_externalize_socket_peer_label</function></funcdef>
-
- &mac.externalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.externalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.externalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-externalize-vnode-label">
- <title><function>&mac.mpo;_externalize_vnode_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_externalize_vnode_label</function></funcdef>
-
- &mac.externalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.externalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.externalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-internalize-cred-label">
- <title><function>&mac.mpo;_internalize_cred_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_internalize_cred_label</function></funcdef>
-
- &mac.internalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.internalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.internalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-internalize-ifnet-label">
- <title><function>&mac.mpo;_internalize_ifnet_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_internalize_ifnet_label</function></funcdef>
-
- &mac.internalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.internalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.internalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-internalize-pipe-label">
- <title><function>&mac.mpo;_internalize_pipe_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_internalize_pipe_label</function></funcdef>
-
- &mac.internalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.internalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.internalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-internalize-socket-label">
- <title><function>&mac.mpo;_internalize_socket_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_internalize_socket_label</function></funcdef>
-
- &mac.internalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.internalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.internalize.para;
- </sect3>
-
- <sect3 id="mac-mpo-internalize-vnode-label">
- <title><function>&mac.mpo;_internalize_vnode_label</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_internalize_vnode_label</function></funcdef>
-
- &mac.internalize.paramdefs;
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- &mac.internalize.tbody;
- </tgroup>
- </informaltable>
-
- &mac.internalize.para;
- </sect3>
- </sect2>
-
- <sect2 id="mac-label-events">
- <title>Label Events</title>
-
- <para>This class of entry points is used by the MAC framework to
- permit policies to maintain label information on kernel
- objects. For each labeled kernel object of interest to a MAC
- policy, entry points may be registered for relevant life cycle
- events. All objects implement initialization, creation, and
- destruction hooks. Some objects will also implement
- relabeling, allowing user processes to change the labels on
- objects. Some objects will also implement object-specific
- events, such as label events associated with IP reassembly. A
- typical labeled object will have the following life cycle of
- entry points:</para>
-
- <programlisting>Label initialization o
-(object-specific wait) \
-Label creation o
- \
-Relabel events, o--<--.
-Various object-specific, | |
-Access control events ~-->--o
- \
-Label destruction o</programlisting>
-
- <para>Label initialization permits policies to allocate memory
- and set initial values for labels without context for the use
- of the object. The label slot allocated to a policy will be
- zero'd by default, so some policies may not need to perform
- initialization.</para>
-
- <para>Label creation occurs when the kernel structure is
- associated with an actual kernel object. For example, mbufs
- may be allocated and remain unused in a pool until they are
- required. mbuf allocation causes label initialization on the
- mbuf to take place, but mbuf creation occurs when the mbuf is
- associated with a datagram. Typically, context will be
- provided for a creation event, including the circumstances of
- the creation, and labels of other relevant objects in the
- creation process. For example, when an mbuf is created from a
- socket, the socket and its label will be presented to
- registered policies in addition to the new mbuf and its label.
- Memory allocation in creation events is discouraged, as it may
- occur in performance sensitive ports of the kernel; in
- addition, creation calls are not permitted to fail so a
- failure to allocate memory cannot be reported.</para>
-
- <para>Object specific events do not generally fall into the
- other broad classes of label events, but will generally
- provide an opportunity to modify or update the label on an
- object based on additional context. For example, the label on
- an IP fragment reassembly queue may be updated during the
- <symbol>MAC_UPDATE_IPQ</symbol> entry point as a result of the
- acceptance of an additional mbuf to that queue.</para>
-
- <para>Access control events are discussed in detail in the
- following section.</para>
-
- <para>Label destruction permits policies to release storage or
- state associated with a label during its association with an
- object so that the kernel data structures supporting the
- object may be reused or released.</para>
-
- <para>In addition to labels associated with specific kernel
- objects, an additional class of labels exists: temporary
- labels. These labels are used to store update information
- submitted by user processes. These labels are initialized and
- destroyed as with other label types, but the creation event is
- <symbol>MAC_INTERNALIZE</symbol>, which accepts a user label
- to be converted to an in-kernel representation.</para>
-
- <sect3 id="mac-fs-label-event-ops">
- <title>File System Object Labeling Event Operations</title>
-
- <sect4 id="mac-mpo-associate-vnode-devfs">
- <title><function>&mac.mpo;_associate_vnode_devfs</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_associate_vnode_devfs</function></funcdef>
-
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- <paramdef>struct devfs_dirent
- *<parameter>de</parameter></paramdef>
- <paramdef>struct label
- *<parameter>delabel</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mp</parameter></entry>
- <entry>Devfs mount point</entry>
- </row>
-
- <row>
- <entry><parameter>fslabel</parameter></entry>
- <entry>Devfs file system label
- (<varname>mp->mnt_fslabel</varname>)</entry>
- </row>
-
- <row>
- <entry><parameter>de</parameter></entry>
- <entry>Devfs directory entry</entry>
- </row>
-
- <row>
- <entry><parameter>delabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>de</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>vnode associated with
- <parameter>de</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>vlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Fill in the label (<parameter>vlabel</parameter>) for
- a newly created devfs vnode based on the devfs directory
- entry passed in <parameter>de</parameter> and its
- label.</para>
- </sect4>
-
- <sect4 id="mac-mpo-associate-vnode-extattr">
- <title><function>&mac.mpo;_associate_vnode_extattr</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_associate_vnode_extattr</function></funcdef>
-
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mp</parameter></entry>
- <entry>File system mount point</entry>
- </row>
-
- <row>
- <entry><parameter>fslabel</parameter></entry>
- <entry>File system label</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>Vnode to label</entry>
- </row>
-
- <row>
- <entry><parameter>vlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Attempt to retrieve the label for
- <parameter>vp</parameter> from the file system extended
- attributes. Upon success, the value <literal>0</literal>
- is returned. Should extended attribute retrieval not be
- supported, an accepted fallback is to copy
- <parameter>fslabel</parameter> into
- <parameter>vlabel</parameter>. In the event of an error,
- an appropriate value for <varname>errno</varname> should
- be returned.</para>
- </sect4>
-
- <sect4 id="mac-mpo-associate-vnode-singlelabel">
- <title><function>&mac.mpo;_associate_vnode_singlelabel</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_associate_vnode_singlelabel</function></funcdef>
-
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mp</parameter></entry>
- <entry>File system mount point</entry>
- </row>
-
- <row>
- <entry><parameter>fslabel</parameter></entry>
- <entry>File system label</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>Vnode to label</entry>
- </row>
-
- <row>
- <entry><parameter>vlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>On non-multilabel file systems, this entry point is
- called to set the policy label for
- <parameter>vp</parameter> based on the file system label,
- <parameter>fslabel</parameter>.</para>
- </sect4>
-
-
- <sect4 id="mac-mpo-create-devfs-device">
- <title><function>&mac.mpo;_create_devfs_device</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_devfs_device</function></funcdef>
-
- <paramdef>dev_t <parameter>dev</parameter></paramdef>
- <paramdef>struct devfs_dirent
- *<parameter>devfs_dirent</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>dev</parameter></entry>
- <entry>Device corresponding with
- <parameter>devfs_dirent</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>devfs_dirent</parameter></entry>
- <entry>Devfs directory entry to be labeled.</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>Label for <parameter>devfs_dirent</parameter>
- to be filled in.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Fill out the label on a devfs_dirent being created for
- the passed device. This call will be made when the device
- file system is mounted, regenerated, or a new device is made
- available.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-devfs-directory">
- <title><function>&mac.mpo;_create_devfs_directory</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_devfs_directory</function></funcdef>
-
- <paramdef>char *<parameter>dirname</parameter></paramdef>
- <paramdef>int <parameter>dirnamelen</parameter></paramdef>
- <paramdef>struct devfs_dirent
- *<parameter>devfs_dirent</parameter></paramdef>
- <paramdef>struct label
- *<parameter>label</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>dirname</parameter></entry>
- <entry>Name of directory being created</entry>
- </row>
-
- <row>
- <entry><parameter>namelen</parameter></entry>
- <entry>Length of string
- <parameter>dirname</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>devfs_dirent</parameter></entry>
- <entry>Devfs directory entry for directory being
- created.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Fill out the label on a devfs_dirent being created for
- the passed directory. This call will be made when the device
- file system is mounted, regenerated, or a new device
- requiring a specific directory hierarchy is made
- available.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-devfs-symlink">
- <title><function>&mac.mpo;_create_devfs_symlink</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_devfs_symlink</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct devfs_dirent
- *<parameter>dd</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ddlabel</parameter></paramdef>
- <paramdef>struct devfs_dirent
- *<parameter>de</parameter></paramdef>
- <paramdef>struct label
- *<parameter>delabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>mp</parameter></entry>
- <entry>Devfs mount point</entry>
- </row>
-
- <row>
- <entry><parameter>dd</parameter></entry>
- <entry>Link destination</entry>
- </row>
-
- <row>
- <entry><parameter>ddlabel</parameter></entry>
- <entry>Label associated with
- <parameter>dd</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>de</parameter></entry>
- <entry>Symlink entry</entry>
- </row>
-
- <row>
- <entry><parameter>delabel</parameter></entry>
- <entry>Label associated with
- <parameter>de</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Fill in the label (<parameter>delabel</parameter>) for
- a newly created &man.devfs.5; symbolic link entry.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-vnode-extattr">
- <title><function>&mac.mpo;_create_vnode_extattr</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_create_vnode_extattr</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>dvp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>dlabel</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vlabel</parameter></paramdef>
- <paramdef>struct componentname
- *<parameter>cnp</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>mount</parameter></entry>
- <entry>File system mount point</entry>
- </row>
-
- <row>
- <entry><parameter>label</parameter></entry>
- <entry>File system label</entry>
- </row>
-
- <row>
- <entry><parameter>dvp</parameter></entry>
- <entry>Parent directory vnode</entry>
- </row>
-
- <row>
- <entry><parameter>dlabel</parameter></entry>
- <entry>Label associated with
- <parameter>dvp</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>Newly created vnode</entry>
- </row>
-
- <row>
- <entry><parameter>vlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>vp</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>cnp</parameter></entry>
- <entry>Component name for
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Write out the label for <parameter>vp</parameter> to
- the appropriate extended attribute. If the write
- succeeds, fill in <parameter>vlabel</parameter> with the
- label, and return <returnvalue>0</returnvalue>. Otherwise,
- return an appropriate error.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mount">
- <title><function>&mac.mpo;_create_mount</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mount</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mnt</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>mp</parameter></entry>
- <entry>Object; file system being mounted</entry>
- </row>
-
- <row>
- <entry><parameter>mntlabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>mp</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>fslabel</parameter></entry>
- <entry>Policy label for the file system
- <parameter>mp</parameter> mounts.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Fill out the labels on the mount point being created by
- the passed subject credential. This call will be made when
- a new file system is mounted.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-root-mount">
- <title><function>&mac.mpo;_create_root_mount</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_root_mount</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct mount
- *<parameter>mp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mntlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fslabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry namest="first" nameend="last">See <xref
- linkend="mac-mpo-create-mount">.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Fill out the labels on the mount point being created by
- the passed subject credential. This call will be made when
- the root file system is mounted, after
- &mac.mpo;_create_mount;.</para>
- </sect4>
-
- <sect4 id="mac-mpo-relabel-vnode">
- <title><function>&mac.mpo;_relabel_vnode</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_relabel_vnode</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vnodelabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>vnode to relabel</entry>
- </row>
-
- <row>
- <entry><parameter>vnodelabel</parameter></entry>
- <entry>Existing policy label for
- <parameter>vp</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newlabel</parameter></entry>
- <entry>New, possibly partial label to replace
- <parameter>vnodelabel</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Update the label on the passed vnode given the passed
- update vnode label and the passed subject credential.</para>
- </sect4>
-
- <sect4 id="mac-mpo-setlabel-vnode-extattr">
- <title><function>&mac.mpo;_setlabel_vnode_extattr</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_setlabel_vnode_extattr</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>intlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>Vnode for which the label is being
- written</entry>
- </row>
-
- <row>
- <entry><parameter>vlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>vp</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>intlabel</parameter></entry>
- <entry>Label to write out</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Write out the policy from
- <parameter>intlabel</parameter> to an extended
- attribute. This is called from
- <function>vop_stdcreatevnode_ea</function>.</para>
- </sect4>
-
- <sect4 id="mac-mpo-update-devfsdirent">
- <title><function>&mac.mpo;_update_devfsdirent</function></title>
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_update_devfsdirent</function></funcdef>
-
- <paramdef>struct devfs_dirent
- *<parameter>devfs_dirent</parameter></paramdef>
- <paramdef>struct label
- *<parameter>direntlabel</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vnodelabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>devfs_dirent</parameter></entry>
- <entry>Object; devfs directory entry</entry>
- </row>
-
- <row>
- <entry><parameter>direntlabel</parameter></entry>
- <entry>Policy label for
- <parameter>devfs_dirent</parameter> to be
- updated.</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>Parent vnode</entry>
- <entry>Locked</entry>
- </row>
-
- <row>
- <entry><parameter>vnodelabel</parameter></entry>
- <entry>Policy label for
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Update the <parameter>devfs_dirent</parameter> label
- from the passed devfs vnode label. This call will be made
- when a devfs vnode has been successfully relabeled to commit
- the label change such that it lasts even if the vnode is
- recycled. It will also be made when when a symlink is
- created in devfs, following a call to
- <function>mac_vnode_create_from_vnode</function> to
- initialize the vnode label.</para>
- </sect4>
- </sect3>
-
- <sect3 id="mac-ipc-label-ops">
- <title>IPC Object Labeling Event Operations</title>
-
-
- <sect4 id="mac-mpo-create-mbuf-from-socket">
- <title><function>&mac.mpo;_create_mbuf_from_socket</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_from_socket</function></funcdef>
-
- <paramdef>struct socket
- *<parameter>so</parameter></paramdef>
- <paramdef>struct label
- *<parameter>socketlabel</parameter></paramdef>
- <paramdef>struct mbuf *<parameter>m</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>socket</parameter></entry>
- <entry>Socket</entry>
- <entry>Socket locking WIP</entry>
- </row>
-
- <row>
- <entry><parameter>socketlabel</parameter></entry>
- <entry>Policy label for
- <parameter>socket</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>m</parameter></entry>
- <entry>Object; mbuf</entry>
- </row>
-
- <row>
- <entry><parameter>mbuflabel</parameter></entry>
- <entry>Policy label to fill in for
- <parameter>m</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly created mbuf header from the
- passed socket label. This call is made when a new datagram
- or message is generated by the socket and stored in the
- passed mbuf.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-pipe">
- <title><function>&mac.mpo;_create_pipe</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_pipe</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct pipe
- *<parameter>pipe</parameter></paramdef>
- <paramdef>struct label
- *<parameter>pipelabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>pipe</parameter></entry>
- <entry>Pipe</entry>
- </row>
-
- <row>
- <entry><parameter>pipelabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>pipe</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly created pipe from the passed
- subject credential. This call is made when a new pipe is
- created.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-socket">
- <title><function>&mac.mpo;_create_socket</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_socket</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct socket
- *<parameter>so</parameter></paramdef>
- <paramdef>struct label
- *<parameter>socketlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- <entry>Immutable</entry>
- </row>
-
- <row>
- <entry><parameter>so</parameter></entry>
- <entry>Object; socket to label</entry>
- </row>
-
- <row>
- <entry><parameter>socketlabel</parameter></entry>
- <entry>Label to fill in for
- <parameter>so</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly created socket from the passed
- subject credential. This call is made when a socket is
- created.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-socket-from-socket">
- <title><function>&mac.mpo;_create_socket_from_socket</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_socket_from_socket</function></funcdef>
-
- <paramdef>struct socket
- *<parameter>oldsocket</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldsocketlabel</parameter></paramdef>
- <paramdef>struct socket
- *<parameter>newsocket</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newsocketlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>oldsocket</parameter></entry>
- <entry>Listening socket</entry>
- </row>
-
- <row>
- <entry><parameter>oldsocketlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>oldsocket</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newsocket</parameter></entry>
- <entry>New socket</entry>
- </row>
-
- <row>
- <entry><parameter>newsocketlabel</parameter></entry>
- <entry>Policy label associated with
- <parameter>newsocketlabel</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Label a socket, <parameter>newsocket</parameter>,
- newly &man.accept.2;ed, based on the &man.listen.2;
- socket, <parameter>oldsocket</parameter>.</para>
- </sect4>
-
- <sect4 id="mac-mpo-relabel-pipe">
- <title><function>&mac.mpo;_relabel_pipe</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_relabel_pipe</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct pipe
- *<parameter>pipe</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>pipe</parameter></entry>
- <entry>Pipe</entry>
- </row>
-
- <row>
- <entry><parameter>oldlabel</parameter></entry>
- <entry>Current policy label associated with
- <parameter>pipe</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newlabel</parameter></entry>
- <entry>Policy label update to apply to
- <parameter>pipe</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Apply a new label, <parameter>newlabel</parameter>, to
- <parameter>pipe</parameter>.</para>
- </sect4>
-
- <sect4 id="mac-mpo-relabel-socket">
- <title><function>&mac.mpo;_relabel_socket</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_relabel_socket</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct socket
- *<parameter>so</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- <entry>Immutable</entry>
- </row>
-
- <row>
- <entry><parameter>so</parameter></entry>
- <entry>Object; socket</entry>
- </row>
-
- <row>
- <entry><parameter>oldlabel</parameter></entry>
- <entry>Current label for
- <parameter>so</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newlabel</parameter></entry>
- <entry>Label update for
- <parameter>so</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Update the label on a socket from the passed socket
- label update.</para>
- </sect4>
-
- <sect4 id="mpo-set-socket-peer-from-mbuf">
- <title><function>&mac.mpo;_set_socket_peer_from_mbuf</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_set_socket_peer_from_mbuf</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>mbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mbuflabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mbuf</parameter></entry>
- <entry>First datagram received over socket</entry>
- </row>
-
- <row>
- <entry><parameter>mbuflabel</parameter></entry>
- <entry>Label for <parameter>mbuf</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>oldlabel</parameter></entry>
- <entry>Current label for the socket</entry>
- </row>
-
- <row>
- <entry><parameter>newlabel</parameter></entry>
- <entry>Policy label to be filled out for the
- socket</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the peer label on a stream socket from the passed
- mbuf label. This call will be made when the first datagram
- is received by the stream socket, with the exception of Unix
- domain sockets.</para>
- </sect4>
-
- <sect4 id="mac-mpo-set-socket-peer-from-socket">
- <title><function>&mac.mpo;_set_socket_peer_from_socket</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_set_socket_peer_from_socket</function></funcdef>
-
- <paramdef>struct socket
- *<parameter>oldsocket</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldsocketlabel</parameter></paramdef>
- <paramdef>struct socket
- *<parameter>newsocket</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newsocketpeerlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>oldsocket</parameter></entry>
- <entry>Local socket</entry>
- </row>
-
- <row>
- <entry><parameter>oldsocketlabel</parameter></entry>
- <entry>Policy label for
- <parameter>oldsocket</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newsocket</parameter></entry>
- <entry>Peer socket</entry>
- </row>
-
- <row>
- <entry><parameter>newsocketpeerlabel</parameter></entry>
- <entry>Policy label to fill in for
- <parameter>newsocket</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <!-- XXX Passed _remote_ socket endpoint ? -->
- <para>Set the peer label on a stream UNIX domain socket from
- the passed remote socket endpoint. This call will be made
- when the socket pair is connected, and will be made for both
- endpoints.</para>
- </sect4>
- </sect3>
-
- <sect3 id="mac-net-labeling-event-ops">
- <title>Network Object Labeling Event Operations</title>
-
- <sect4 id="mac-mpo-create-bpfdesc">
- <title><function>&mac.mpo;_create_bpfdesc</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_bpfdesc</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct bpf_d
- *<parameter>bpf_d</parameter></paramdef>
- <paramdef>struct label
- *<parameter>bpflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- <entry>Immutable</entry>
- </row>
-
- <row>
- <entry><parameter>bpf_d</parameter></entry>
- <entry>Object; bpf descriptor</entry>
- </row>
-
- <row>
- <entry><parameter>bpf</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>bpf_d</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly created BPF descriptor from the
- passed subject credential. This call will be made when a
- BPF device node is opened by a process with the passed
- subject credential.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-ifnet">
- <title><function>&mac.mpo;_create_ifnet</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_ifnet</function></funcdef>
-
- <paramdef>struct ifnet
- *<parameter>ifnet</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ifnetlabel</parameter></paramdeF>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>ifnet</parameter></entry>
- <entry>Network interface</entry>
- </row>
-
- <row>
- <entry><parameter>ifnetlabel</parameter></entry>
- <entry>Policy label to fill in for
- <parameter>ifnet</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly created interface. This call
- may be made when a new physical interface becomes available
- to the system, or when a pseudo-interface is instantiated
- during the boot or as a result of a user action.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-ipq">
- <title><function>&mac.mpo;_create_ipq</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_ipq</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>fragment</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fragmentlabel</parameter></paramdef>
- <paramdef>struct ipq
- *<parameter>ipq</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ipqlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>fragment</parameter></entry>
- <entry>First received IP fragment</entry>
- </row>
-
- <row>
- <entry><parameter>fragmentlabel</parameter></entry>
- <entry>Policy label for
- <parameter>fragment</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>ipq</parameter></entry>
- <entry>IP reassembly queue to be labeled</entry>
- </row>
-
- <row>
- <entry><parameter>ipqlabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>ipq</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly created IP fragment reassembly
- queue from the mbuf header of the first received
- fragment.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-datagram-from-ipq">
- <title><function>&mac.mpo;_create_datagram_from_ipq</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_create_datagram_from_ipq</function></funcdef>
-
- <paramdef>struct ipq
- *<parameter>ipq</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ipqlabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>datagram</parameter></paramdef>
- <paramdef>struct label
- *<parameter>datagramlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>ipq</parameter></entry>
- <entry>IP reassembly queue</entry>
- </row>
-
- <row>
- <entry><parameter>ipqlabel</parameter></entry>
- <entry>Policy label for
- <parameter>ipq</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>datagram</parameter></entry>
- <entry>Datagram to be labeled</entry>
- </row>
-
- <row>
- <entry><parameter>datagramlabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>datagramlabel</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on a newly reassembled IP datagram from
- the IP fragment reassembly queue from which it was
- generated.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-fragment">
- <title><function>&mac.mpo;_create_fragment</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_fragment</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>datagram</parameter></paramdef>
- <paramdef>struct label
- *<parameter>datagramlabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>fragment</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fragmentlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>datagram</parameter></entry>
- <entry>Datagram</entry>
- </row>
-
- <row>
- <entry><parameter>datagramlabel</parameter></entry>
- <entry>Policy label for
- <parameter>datagram</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>fragment</parameter></entry>
- <entry>Fragment to be labeled</entry>
- </row>
-
- <row>
- <entry><parameter>fragmentlabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>datagram</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created IP
- fragment from the label on the mbuf header of the datagram
- it was generate from.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mbuf-from-mbuf">
- <title><function>&mac.mpo;_create_mbuf_from_mbuf</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_from_mbuf</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>oldmbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldmbuflabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>newmbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newmbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>oldmbuf</parameter></entry>
- <entry>Existing (source) mbuf</entry>
- </row>
-
- <row>
- <entry><parameter>oldmbuflabel</parameter></entry>
- <entry>Policy label for
- <parameter>oldmbuf</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newmbuf</parameter></entry>
- <entry>New mbuf to be labeled</entry>
- </row>
-
- <row>
- <entry><parameter>newmbuflabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>newmbuf</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created
- datagram from the mbuf header of an existing datagram. This
- call may be made in a number of situations, including when
- an mbuf is re-allocated for alignment purposes.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mbuf-linklayer">
- <title><function>&mac.mpo;_create_mbuf_linklayer</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_linklayer</function></funcdef>
-
- <paramdef>struct ifnet
- *<parameter>ifnet</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ifnetlabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>mbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>ifnet</parameter></entry>
- <entry>Network interface</entry>
- </row>
-
- <row>
- <entry><parameter>ifnetlabel</parameter></entry>
- <entry>Policy label for
- <parameter>ifnet</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>mbuf</parameter></entry>
- <entry>mbuf header for new datagram</entry>
- </row>
-
- <row>
- <entry><parameter>mbuflabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>mbuf</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created
- datagram generated for the purposes of a link layer response
- for the passed interface. This call may be made in a number
- of situations, including for ARP or ND6 responses in the
- IPv4 and IPv6 stacks.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mbuf-from-bpfdesc">
- <title><function>&mac.mpo;_create_mbuf_from_bpfdesc</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_from_bpfdesc</function></funcdef>
-
- <paramdef>struct bpf_d
- *<parameter>bpf_d</parameter></paramdef>
- <paramdef>struct label
- *<parameter>bpflabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>mbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>bpf_d</parameter></entry>
- <entry>BPF descriptor</entry>
- </row>
-
- <row>
- <entry><parameter>bpflabel</parameter></entry>
- <entry>Policy label for
- <parameter>bpflabel</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>mbuf</parameter></entry>
- <entry>New mbuf to be labeled</entry>
- </row>
-
- <row>
- <entry><parameter>mbuflabel</parameter></entry>
- <entry>Policy label to fill in for
- <parameter>mbuf</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created
- datagram generated using the passed BPF descriptor. This
- call is made when a write is performed to the BPF device
- associated with the passed BPF descriptor.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mbuf-from-ifnet">
- <title><function>&mac.mpo;_create_mbuf_from_ifnet</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_from_ifnet</function></funcdef>
-
- <paramdef>struct ifnet
- *<parameter>ifnet</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ifnetlabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>mbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>mbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>ifnet</parameter></entry>
- <entry>Network interface</entry>
- </row>
-
- <row>
- <entry><parameter>ifnetlabel</parameter></entry>
- <entry>Policy label for
- <parameter>ifnetlabel</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>mbuf</parameter></entry>
- <entry>mbuf header for new datagram</entry>
- </row>
-
- <row>
- <entry><parameter>mbuflabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>mbuf</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created
- datagram generated from the passed network interface.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mbuf-multicast-encap">
- <title><function>&mac.mpo;_create_mbuf_multicast_encap</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_multicast_encap</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>oldmbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldmbuflabel</parameter></paramdef>
- <paramdef>struct ifnet
- *<parameter>ifnet</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ifnetlabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>newmbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newmbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>oldmbuf</parameter></entry>
- <entry>mbuf header for existing datagram</entry>
- </row>
-
- <row>
- <entry><parameter>oldmbuflabel</parameter></entry>
- <entry>Policy label for
- <parameter>oldmbuf</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>ifnet</parameter></entry>
- <entry>Network interface</entry>
- </row>
-
- <row>
- <entry><parameter>ifnetlabel</parameter></entry>
- <entry>Policy label for
- <parameter>ifnet</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newmbuf</parameter></entry>
- <entry>mbuf header to be labeled for new
- datagram</entry>
- </row>
-
- <row>
- <entry><parameter>newmbuflabel</parameter></entry>
- <entry>Policy label to be filled in for
- <parameter>newmbuf</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created
- datagram generated from the existing passed datagram when it
- is processed by the passed multicast encapsulation
- interface. This call is made when an mbuf is to be
- delivered using the virtual interface.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-mbuf-netlayer">
- <title><function>&mac.mpo;_create_mbuf_netlayer</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_mbuf_netlayer</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>oldmbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>oldmbuflabel</parameter></paramdef>
- <paramdef>struct mbuf
- *<parameter>newmbuf</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newmbuflabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>oldmbuf</parameter></entry>
- <entry>Received datagram</entry>
- </row>
-
- <row>
- <entry><parameter>oldmbuflabel</parameter></entry>
- <entry>Policy label for
- <parameter>oldmbuf</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newmbuf</parameter></entry>
- <entry>Newly created datagram</entry>
- </row>
-
- <row>
- <entry><parameter>newmbuflabel</parameter></entry>
- <entry>Policy label for
- <parameter>newmbuf</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label on the mbuf header of a newly created
- datagram generated by the IP stack in response to an
- existing received datagram (<parameter>oldmbuf</parameter>).
- This call may be made in a number of situations, including
- when responding to ICMP request datagrams.</para>
- </sect4>
-
- <sect4 id="mac-mpo-fragment-match">
- <title><function>&mac.mpo;_fragment_match</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_fragment_match</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>fragment</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fragmentlabel</parameter></paramdef>
- <paramdef>struct ipq
- *<parameter>ipq</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ipqlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>fragment</parameter></entry>
- <entry>IP datagram fragment</entry>
- </row>
-
- <row>
- <entry><parameter>fragmentlabel</parameter></entry>
- <entry>Policy label for
- <parameter>fragment</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>ipq</parameter></entry>
- <entry>IP fragment reassembly queue</entry>
- </row>
-
- <row>
- <entry><parameter>ipqlabel</parameter></entry>
- <entry>Policy label for
- <parameter>ipq</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Determine whether an mbuf header containing an IP
- datagram (<parameter>fragment</parameter>) fragment matches
- the label of the passed IP fragment reassembly queue
- (<parameter>ipq</parameter>). Return
- (<returnvalue>1</returnvalue>) for a successful match, or
- (<returnvalue>0</returnvalue>) for no match. This call is
- made when the IP stack attempts to find an existing fragment
- reassembly queue for a newly received fragment; if this
- fails, a new fragment reassembly queue may be instantiated
- for the fragment. Policies may use this entry point to
- prevent the reassembly of otherwise matching IP fragments if
- policy does not permit them to be reassembled based on the
- label or other information.</para>
- </sect4>
-
- <sect4 id="mac-mpo-ifnet-relabel">
- <title><function>&mac.mpo;_relabel_ifnet</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_relabel_ifnet</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct ifnet
- *<parameter>ifnet</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ifnetlabel</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>ifnet</parameter></entry>
- <entry>Object; Network interface</entry>
- </row>
-
- <row>
- <entry><parameter>ifnetlabel</parameter></entry>
- <entry>Policy label for
- <parameter>ifnet</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>newlabel</parameter></entry>
- <entry>Label update to apply to
- <parameter>ifnet</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Update the label of network interface,
- <parameter>ifnet</parameter>, based on the passed update
- label, <parameter>newlabel</parameter>, and the passed
- subject credential, <parameter>cred</parameter>.</para>
- </sect4>
-
- <sect4 id="mac-mpo-update-ipq">
- <title><function>&mac.mpo;_update_ipq</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_update_ipq</function></funcdef>
-
- <paramdef>struct mbuf
- *<parameter>fragment</parameter></paramdef>
- <paramdef>struct label
- *<parameter>fragmentlabel</parameter></paramdef>
- <paramdef>struct ipq
- *<parameter>ipq</parameter></paramdef>
- <paramdef>struct label
- *<parameter>ipqlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>mbuf</parameter></entry>
- <entry>IP fragment</entry>
- </row>
-
- <row>
- <entry><parameter>mbuflabel</parameter></entry>
- <entry>Policy label for
- <parameter>mbuf</parameter></entry>
- </row>
-
- <row>
- <entry><parameter>ipq</parameter></entry>
- <entry>IP fragment reassembly queue</entry>
- </row>
-
- <row>
- <entry><parameter>ipqlabel</parameter></entry>
- <entry>Policy label to be updated for
- <parameter>ipq</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Update the label on an IP fragment reassembly queue
- (<parameter>ipq</parameter>) based on the acceptance of the
- passed IP fragment mbuf header
- (<parameter>mbuf</parameter>).</para>
- </sect4>
- </sect3>
-
- <sect3 id="mac-proc-labeling-event-ops">
- <title>Process Labeling Event Operations</title>
-
- <sect4 id="mac-mpo-create-cred">
- <title><function>&mac.mpo;_create_cred</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_cred</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>parent_cred</parameter></paramdef>
- <paramdef>struct ucred
- *<parameter>child_cred</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>parent_cred</parameter></entry>
- <entry>Parent subject credential</entry>
- </row>
-
- <row>
- <entry><parameter>child_cred</parameter></entry>
- <entry>Child subject credential</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Set the label of a newly created subject credential from
- the passed subject credential. This call will be made when
- &man.crcopy.9; is invoked on a newly created <type>struct
- ucred</type>. This call should not be confused with a
- process forking or creation event.</para>
- </sect4>
-
- <sect4 id="mac-mpo-execve-transition">
- <title><function>&mac.mpo;_execve_transition</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_execve_transition</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>old</parameter></paramdef>
- <paramdef>struct ucred
- *<parameter>new</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vnodelabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>old</parameter></entry>
- <entry>Existing subject credential</entry>
- <entry>Immutable</entry>
- </row>
-
- <row>
- <entry><parameter>new</parameter></entry>
- <entry>New subject credential to be labeled</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>File to execute</entry>
- <entry>Locked</entry>
- </row>
-
- <row>
- <entry><parameter>vnodelabel</parameter></entry>
- <entry>Policy label for
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Update the label of a newly created subject credential
- (<parameter>new</parameter>) from the passed existing
- subject credential (<parameter>old</parameter>) based on a
- label transition caused by executing the passed vnode
- (<parameter>vp</parameter>). This call occurs when a
- process executes the passed vnode and one of the policies
- returns a success from the
- <function>mpo_execve_will_transition</function> entry point.
- Policies may choose to implement this call simply by
- invoking <function>mpo_create_cred</function> and passing
- the two subject credentials so as not to implement a
- transitioning event. Policies should not leave this entry
- point unimplemented if they implement
- <function>mpo_create_cred</function>, even if they do not
- implement
- <function>mpo_execve_will_transition</function>.</para>
- </sect4>
-
- <sect4 id="mac-mpo-execve-will-transition">
- <title><function>&mac.mpo;_execve_will_transition</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>int
- <function>&mac.mpo;_execve_will_transition</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>old</parameter></paramdef>
- <paramdef>struct vnode
- *<parameter>vp</parameter></paramdef>
- <paramdef>struct label
- *<parameter>vnodelabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>old</parameter></entry>
- <entry>Subject credential prior to
- &man.execve.2;</entry>
- <entry>Immutable</entry>
- </row>
-
- <row>
- <entry><parameter>vp</parameter></entry>
- <entry>File to execute</entry>
- </row>
-
- <row>
- <entry><parameter>vnodelabel</parameter></entry>
- <entry>Policy label for
- <parameter>vp</parameter></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Determine whether the policy will want to perform a
- transition event as a result of the execution of the passed
- vnode by the passed subject credential. Return
- <returnvalue>1</returnvalue> if a transition is required,
- <returnvalue>0</returnvalue> if not. Even if a policy
- returns <returnvalue>0</returnvalue>, it should behave
- correctly in the presence of an unexpected invocation of
- <function>mpo_execve_transition</function>, as that call may
- happen as a result of another policy requesting a
- transition.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-proc0">
- <title><function>&mac.mpo;_create_proc0</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_proc0</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential to be filled in</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Create the subject credential of process 0, the parent
- of all kernel processes.</para>
- </sect4>
-
- <sect4 id="mac-mpo-create-proc1">
- <title><function>&mac.mpo;_create_proc1</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_create_proc1</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential to be filled in</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Create the subject credential of process 1, the parent
- of all user processes.</para>
- </sect4>
-
- <sect4 id="mac-mpo-relabel-cred">
- <title><function>&mac.mpo;_relabel_cred</function></title>
-
- <funcsynopsis>
- <funcprototype>
- <funcdef>void
- <function>&mac.mpo;_relabel_cred</function></funcdef>
-
- <paramdef>struct ucred
- *<parameter>cred</parameter></paramdef>
- <paramdef>struct label
- *<parameter>newlabel</parameter></paramdef>
- </funcprototype>
- </funcsynopsis>
-
- <informaltable>
- <tgroup cols="3">
- &mac.thead;
-
- <tbody>
- <row>
- <entry><parameter>cred</parameter></entry>
- <entry>Subject credential</entry>
- </row>
-