diff options
| author | Doc Manager <doceng@FreeBSD.org> | 2001-09-18 22:27:35 +0000 |
|---|---|---|
| committer | Doc Manager <doceng@FreeBSD.org> | 2001-09-18 22:27:35 +0000 |
| commit | a147bf20a5cfdc48fe43a79be5dbc8d59f00fdaa (patch) | |
| tree | 15ba978bb881cc49043022c504be4729072219ad | |
| parent | 7636daf2655749322bf4e0418f8eb2e4437c888a (diff) | |
Create tag '4.4.0'.release/4.4.0
54 files changed, 72 insertions, 26089 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 ce7d2bab35..0000000000 --- a/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ /dev/null @@ -1,362 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD German Documentation Project - - Original version 1.6 - $FreeBSDde: de-docproj/books/handbook/sound/chapter.sgml,v 1.3 2001/06/27 17:33:42 alex Exp $ - $FreeBSD$ ---> - -<chapter id="sound"> - <title>Sound</title> - - <para><emphasis>Ein Beitrag von Moses Moore - <email>jm-moses@home.com</email>, 20 November - 2000.</emphasis></para> - <para><emphasis>Übersetzt von &a.de.pierau;, Februar 2001 und - &a.de.bkoehler;, Juni 2001.</emphasis></para> - - <sect1> - <title>Zusammenfassung</title> - - <para>Dieses Kapitel des Handbuchs behandelt das Thema, wie man - auf einem FreeBSD Rechner Sound aktiviert.</para> - </sect1> - - <sect1> - <title>Bestimmen des korrekten Geräts</title> - - <indexterm><primary>PCI</primary></indexterm> - <indexterm><primary>ISA</primary></indexterm> - <indexterm><primary>Soundkarten</primary></indexterm> - <para>Zuerst sollten Sie in Erfahrung bringen, was für ein - Modell Ihrer Soundkarte Sie haben, welcher Chip sie benutzt ist - und ob es sich um eine PCI- oder ISA-Karte handelt. FreeBSD - unterstützt eine ganze Reihe sowohl von PCI- als auch von - ISA-Karten. Wenn Ihre Sound-Karte in der folgenden Liste nicht - auftaucht, konsultieren Sie die &man.pcm.4; Manual-Seite. Diese - Liste ist zwar nicht vollständig, deckt jedoch einige der - verbreitesten 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>Welchen Treiber Sie in Ihrem Kernel benutzen, hängt von - dem Typ Ihrer Karte ab. Die nächsten Abschnitte liefern - genauere Informationen und erklären, was Sie zu Ihrer <!--<link - linkend="kernelconfig">-->Kernelkonfiguration<!--</link>-->. hinzufügen - müssen.</para> - - <sect2> - <title>Creative, Advance und ESS Soundkarten</title> - - <para>Haben Sie eine dieser Karten, müssen Sie</para> - - <programlisting>device pcm</programlisting> - - <para>zu Ihrer Kernelkonfiguration hinzufügen. Wenn Ihre - Karte eine PnP ISA-Karte ist, fügen Sie weiterhin</para> - - <programlisting>device sbc</programlisting> - - <para>hinzu. Für eine nicht-PnP ISA-Karte muß</para> - - <programlisting>device pcm</programlisting> - - <para>und</para> - - <programlisting>device sbc0 at isa? port0x220 irq 5 drq 1 flags - 0x15</programlisting> - - <para>in Ihre Kernelkonfiguration. Dies sind die - Voreinstellungen, Sie werden unter Umständen den IRQ - u.s.w. anpassen müssen. Schauen Sie dazu in die - &man.sbc.4; Manual-Seite für weitere - Informationen.</para> - - <note> - <para>Die Karte Sound Blaster Live wird unter FreeBSD 4.0 - nicht unterstützt. Dazu benötigt man einen Patch, - welcher in diesem Dokument nicht behandelt wird. Es ist - deshalb empfehlenswert, daß Sie in diesem Fall Ihr - System auf den neuesten -STABLE Stand aktualisieren, bevor - Sie diese Karte benutzen können.</para> - </note> - </sect2> - - <sect2> - <title>Gravis UltraSound Karten</title> - - <para>Für eine PnP ISA-Karte, müssen Sie</para> - - <programlisting>device pcm</programlisting> - - <para>und</para> - - <programlisting>device gusc</programlisting> - - <para>zu Ihrer Kernelkonfiguration zufügen. Wenn Sie eine - nicht-PnP ISA-Karte besitzen, ergänzen Sie</para> - - <programlisting>device pcm</programlisting> - - <para>und</para> - - <programlisting>device gus0 at isa? port 0x220 irq 5 drq 1 flags - 0x13</programlisting> - - <para>in Ihrer Kernelkonfiguration. Es kann sein, daß Sie - den IRQ u.s.w. anpassen müssen. Lesen Sie dazu die - &man.gusc.4; Manual-Seite für weitere - Informationen.</para> - </sect2> - - <sect2> - <title>Crystal Sound-Karten</title> - - <para>Für Crystal Karten, brauchen Sie die beiden - Zeilen</para> - - <programlisting>device pcm</programlisting> - - <para>und</para> - - <programlisting>device csa</programlisting> - - <para>in Ihrer Kernelkonfiguration.</para> - </sect2> - - <sect2> - <title>Allgemeine Unterstüzung</title> - - <para>Für PnP ISA- oder PCI-Karten fügen Sie</para> - - <programlisting>device pcm</programlisting> - - <para>zu Ihrer Kernelkonfiguration hinzu. Wenn Sie eine - nicht-PnP ISA-Karte besitzen, die keinen bridge driver hat, - geben Sie zusätzlich</para> - - <programlisting>device pcm0 at isa? irq 10 drq 1 flags - 0x0</programlisting> - - <para>in Ihrer Kernelkonfiguration an. Ändern Sie IRQ - u.s.w. so, daß es mit Ihrer Hardwarekonfiguration - überein stimmt.</para> - </sect2> - </sect1> - - <sect1> - <title>Kernel-Kompilierung</title> - - <para>Nachdem Sie den oder die Treiber zu Ihrer - Kernelkonfiguration hinzugefügt haben, müssen Sie - Ihren Kernel neu kompilieren. Lesen Sie das entsprechende - Kapitel <!-- <xref - linkend="kernelconfig-building">-->des Handbuchs für - ausführliche Informationen dazu.</para> - </sect1> - - <sect1> - <title>Erstellen und Testen der Device Nodes</title> - - <indexterm><primary>Device Nodes</primary></indexterm> - <para>Nach einem Neustart loggen Sie sich ein und geben - <command>cat /dev/sndstat</command> ein. Sie sollten etwas wie - das folgende sehen:</para> - - <programlisting>FreeBSD Audio Driver (newpcm) Sep 21 2000 18:29:53 -Installed devices: pcm0: <Aureal Vortex 8830> at memory -0xfeb40000 irq 5 (4p/1r +channels duplex)</programlisting> - - <para>Erhalten Sie eine Fehlermeldung, ist vorher irgendetwas - schief gegangen. Wenn das passiert, schauen Sie sich Ihre - Kernelkonfiguration noch einmal an und stellen Sie sicher, - daß Sie den richtigen Treiber gewählt haben.</para> - - <para>Wenn es keine Fehlermeldungen gab und das Kommando - <devicename>pcm0</devicename> ausgab, werden Sie mit - <command>su</command> zu <username>root</username> und machen - das folgende:</para> - - <screen> -&prompt.root; <userinput>cd /dev</userinput> &prompt.root; -<userinput>sh MAKEDEV snd0</userinput></screen> - - <para>Wenn es keine Fehlermeldungen gab und das Kommando - <devicename>pcm1</devicename> ausgab, werden Sie mit - <command>su</command> zu <username>root</username> und machen - das folgende:</para> - - <screen> -&prompt.root; <userinput>cd /dev</userinput> &prompt.root; -<userinput>sh MAKEDEV snd1</userinput></screen> - - <para>Beachten Sie bitte, daß die obigen Kommandos - <emphasis>kein</emphasis> Device - <devicename>/dev/snd</devicename> anlegen werden. Statt dessen - wird eine Gruppe von Device Nodes erzeugt, unter anderem:</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>Like <devicename>/dev/dsp</devicename>, but 16 bits - per 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 Sound-Karte. Falls nicht, lesen Sie den - nächsten Abschnitt.</para> - </sect1> - - <sect1> - <title>Häufige Probleme</title> - - <qandaset> - <indexterm><primary>Device Node</primary></indexterm> - <qandaentry> - <question> - <para>Ich erhalte den Fehler unsupported subdevice - XX!</para> - </question> - - <answer> - <para>Ein oder mehrere Device Nodes wurden nicht korrekt - erzeugt. Wiederholen Sie die obigen Schritte.</para> - </answer> - </qandaentry> - - <indexterm><primary>I/O port</primary></indexterm> - <qandaentry> - <question> - <para>Ich erhalte den Fehler sb_dspwr(XX) timed out!</para> - </question> - - <answer> - <para>Der I/O Port ist nicht korrekt angegeben.</para> - </answer> - </qandaentry> - - <indexterm><primary>IRQ</primary></indexterm> - <qandaentry> - <question> - <para>Ich erhalte den Fehler bad irq XX!</para> - </question> - - <answer> - <para>Der IRQ ist falsch gesetzt. Stellen Sie sicher, - daß Sie der angegebene IRQ mit dem Sound IRQ - übereinstimmt.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Ich erhalte den Fehler "xxx: gus pcm not attached, out - of memory". Was ist die Ursache dafür?</para> - </question> - - <answer> - <para>Wenn das passiert, ist nicht genug Speicher - verfügbar, um das Gerät betreiben zu - können.</para> - </answer> - </qandaentry> - </qandaset> - </sect1> -</chapter> 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 “allowed - program” 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 "weekend hackers", 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 — 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) — 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 — 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—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 “FreeBSD-current” - 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 “context diff” 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 “no strings attached” 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 “GPL”. 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 “BSD-style” 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. - - $Id$</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ö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ö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>Þórður Í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örg Lohse - <email>lohse@tech7.informatik.uni-hamburg.de</email></para> - </listitem> - - <listitem> - <para>Jö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/articles/contributing/article.sgml b/en_US.ISO8859-1/articles/contributing/article.sgml deleted file mode 100644 index f8145c6234..0000000000 --- a/en_US.ISO8859-1/articles/contributing/article.sgml +++ /dev/null @@ -1,480 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml,v 1.467 2001/08/10 22:58:11 chern Exp $ ---> - -<chapter id="contrib"> - <chapterinfo> - <authorgroup> - <author> - <firstname>Jordan</firstname> - <surname>Hubbard</surname> - <contrib>Contributed by </contrib> - </author> - </authorgroup> - </chapterinfo> - - <title>Contributing to FreeBSD</title> - - <indexterm><primary>contributing</primary></indexterm> - <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 id="contrib-what"> - <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>Ongoing 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 "weekend hackers", 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 — 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) — 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 — 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 bug fixes 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>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> - - <indexterm><primary>problem reports database</primary></indexterm> - <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, email the person it is assigned to and ask if you can - work on it—they might already have a patch ready to be tested, - or further ideas that you can discuss with them.</para> - </sect2> - </sect1> - - <sect1 id="contrib-how"> - <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. - If the patch is suitable to be applied to the source tree put - <literal>[PATCH]</literal> in the synopsis of 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> - - <indexterm><primary>documentation submissions</primary></indexterm> - <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> - - <indexterm><primary>FreeBSD-current</primary></indexterm> - <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 <quote>FreeBSD-current</quote> - 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 <quote>context diff</quote> form - being preferred. For example:</para> - - <indexterm> - <primary><command>diff</command></primary> - </indexterm> - <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. Indicate your submission by including <literal>[PATCH]</literal> - in the synopsis of the report.</para> - - <indexterm> - <primary><command>uuencode</command></primary> - </indexterm> - <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 &man.intro.9; and &man.style.9; style 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 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 uuencoded - tar files or upload them to a web or FTP site for other people to - access. If you do not have access to a web or FTP site, ask on an - appropriate FreeBSD mailing list for someone to host the changes for - you.</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> - <indexterm><primary>BSD copyright</primary></indexterm> - <listitem> - <para>The BSD copyright. This copyright is most preferred due to - its <quote>no strings attached</quote> 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> - - <indexterm><primary>GPL</primary><see>GNU General Public License</see></indexterm> - <indexterm><primary>GNU General Public License</primary></indexterm> - <listitem> - <para>The GNU General Public License, or <quote>GPL</quote>. - 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 <quote>BSD-style</quote> 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. - - $Id$</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>The FreeBSD Foundation is a non-profit, tax-exempt - foundation established to further the goals of the FreeBSD - Project. As a 501(c)3 entity, the Foundation is generally - exempt from US federal income tax as well as Colorado - State income tax. Donations to a tax-exempt entity are - often deductible from taxable federal income.</para> - - <para>Donations may be sent in check form to: - <address> - The FreeBSD Foundation - <street>7321 Brockway Dr.</street> - <city>Boulder</city>, <state>CO</state> <postcode>80303</postcode> - <country>USA</country> - </address> - The Foundation is not yet able to accept other forms - of payment such as credit cards and PayPal.</para> - - <para>More information about the FreeBSD Foundation can be - found in <ulink - url="http://people.freebsd.org/~jdp/foundation/announcement.html">The - FreeBSD Foundation -- an Introduction</ulink>. To contact - the Foundation by email, write to - <email>bod@FreeBSDFoundation.org</email>.</para> - </sect3> - - <sect3> - <title>Donating Hardware</title> - <indexterm><primary>donations</primary></indexterm> - - <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>hubs@FreeBSD.org</email> for more information.</para> - </sect3> - </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/Makefile b/en_US.ISO8859-1/books/arch-handbook/Makefile deleted file mode 100644 index a0e84f24d3..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/Makefile +++ /dev/null @@ -1,46 +0,0 @@ -# -# $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/Makefile,v 1.6 2001/06/23 04:57:31 murray Exp $ -# -# Build the FreeBSD Developers' Handbook. -# - -MAINTAINER=asmodai@FreeBSD.org - -DOC?= book - -FORMATS?= html-split - -INSTALL_COMPRESSED?= gz -INSTALL_ONLY_COMPRESSED?= - -GEN_INDEX?= yes - -# 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+= introduction/chapter.sgml -SRCS+= tools/chapter.sgml -SRCS+= secure/chapter.sgml -SRCS+= locking/chapter.sgml -SRCS+= sockets/chapter.sgml -SRCS+= ipv6/chapter.sgml -SRCS+= isa/chapter.sgml -SRCS+= pci/chapter.sgml -SRCS+= usb/chapter.sgml -SRCS+= scsi/chapter.sgml -SRCS+= x86/chapter.sgml -SRCS+= vm/chapter.sgml -SRCS+= dma/chapter.sgml -SRCS+= kerneldebug/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 6f625557bd..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/book.sgml +++ /dev/null @@ -1,311 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/book.sgml,v 1.26 2001/09/02 03:11:08 murray Exp $ ---> - -<!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 % chapters SYSTEM "chapters.ent"> %chapters; -<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> %authors -<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN"> %mailing-lists; -]> - -<book> - <bookinfo> - <title>FreeBSD Developers' Handbook</title> - - <corpauthor>The FreeBSD Documentation Project</corpauthor> - - <pubdate>August 2000</pubdate> - - <copyright> - <year>2000</year> - <year>2001</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="http://www.FreeBSD.org/">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="http://www.freebsd.org/handbook/mirrors-ftp.html">mirror - sites</ulink>.</para> - </abstract> - </bookinfo> - - <part id="Basics"> - <title>Basics</title> - - &chap.introduction; - &chap.tools; - &chap.secure; - - </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> - - <chapter id="kernelhistory"> - <title>* History of the Unix Kernel</title> - - <para>Some history of the Unix/BSD kernel, system calls, how do - processes work, blocking, scheduling, threads (kernel), - context switching, signals, interrupts, modules, etc.</para> - - <para></para> - </chapter> - - &chap.locking; - &chap.kobj; - &chap.sysinit; - &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; - - <chapter id="newbus"> - <title>* NewBus</title> - - <para>This chapter will talk about the FreeBSD NewBus - architecture.</para> - </chapter> - - <chapter id="oss"> - <title>* Sound subsystem</title> - - <para>OSS, waveforms, etc</para> - - </chapter> - - </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 allignment 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; - </part> - -</book> 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 1ef9ebe938..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/chapters.ent +++ /dev/null @@ -1,65 +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: doc/en_US.ISO8859-1/books/developers-handbook/chapters.ent,v 1.11 2001/09/02 03:11:08 murray Exp $ ---> - -<!-- Part one --> -<!ENTITY chap.introduction SYSTEM "introduction/chapter.sgml"> -<!ENTITY chap.tools SYSTEM "tools/chapter.sgml"> -<!ENTITY chap.secure SYSTEM "secure/chapter.sgml"> - -<!-- Part two --> -<!ENTITY chap.kobj SYSTEM "kobj/chapter.sgml"> -<!ENTITY chap.sysinit SYSTEM "sysinit/chapter.sgml"> -<!ENTITY chap.locking SYSTEM "locking/chapter.sgml"> - -<!-- Part three --> -<!ENTITY chap.vm SYSTEM "vm/chapter.sgml"> -<!ENTITY chap.dma SYSTEM "dma/chapter.sgml"> - -<!-- Part four --> -<!-- No significant material yet, still in book.sgml --> - -<!-- Part five --> -<!-- No significant material yet, still in book.sgml --> - -<!-- Part six --> -<!ENTITY chap.sockets SYSTEM "sockets/chapter.sgml"> -<!ENTITY chap.ipv6 SYSTEM "ipv6/chapter.sgml"> - -<!-- Part seven --> -<!-- No significant material yet, still in book.sgml --> - -<!-- Part eight --> -<!-- No significant material yet, still in book.sgml --> - -<!-- Part nine --> -<!-- No significant material yet, still in book.sgml --> - -<!ENTITY chap.kerneldebug SYSTEM "kerneldebug/chapter.sgml"> - -<!-- Part ten --> -<!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"> - -<!-- Part eleven --> -<!ENTITY chap.x86 SYSTEM "x86/chapter.sgml"> - -<!-- Part twelve --> -<!-- No significant material yet, still in book.sgml --> - -<!-- Part thirteen --> -<!-- No significant material yet, still in book.sgml --> - -<!-- Part fourteen (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 a65ec54238..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml +++ /dev/null @@ -1,391 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/driverbasics/chapter.sgml,v 1.8 2001/07/19 10:37:35 dd Exp $ ---> - -<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) man page by - &a.joerg;.</para> - - <sect1> - <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 - behaviour 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 file system hierarchy. Until - devfs is fully 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> - <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 - administrator 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 loadded - modules</simpara></listitem> - </itemizedlist> - </para> - - <para>Skeleton Layout of a kernel module</para> - -<programlisting>/* - * KLD Skeleton - * Inspired by Andrew Reiter's Daemonnews article - */ - -#include <sys/types.h> -#include <sys/module.h> -#include <sys/systm.h> /* uprintf */ -#include <sys/errno.h> -#include <sys/param.h> /* defines used in kernel.h */ -#include <sys/kernel.h> /* 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 <bsd.kmod.mk></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 - kldload -v ./skeleton.ko</screen> - </para> - </sect2> - </sect1> - - <sect1> - <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 this 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 nice.</para> - </sect2> - - </sect1> - - <sect1> - <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 <sys/types.h> -#include <sys/module.h> -#include <sys/systm.h> /* uprintf */ -#include <sys/errno.h> -#include <sys/param.h> /* defines used in kernel.h */ -#include <sys/kernel.h> /* types used in module initialization */ -#include <sys/conf.h> /* cdevsw struct */ -#include <sys/uio.h> /* uio struct */ -#include <sys/malloc.h> - -#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 mknod /dev/echo c 33 0</screen> - - <para>With this driver loaded you should now be able to type - something like :</para> - - <screen>&prompt.root echo -n "Test Data" > /dev/echo -&prompt.root cat /dev/echo -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> - <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 96f68a88c5..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml +++ /dev/null @@ -1,2479 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/isa/chapter.sgml,v 1.1 2001/05/02 01:56:01 murray Exp $ ---> - -<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> - <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 - "ep" and "aha" are good sources of information.</para> - </sect1> - - <sect1> - <title>Basic information</title> - - <para>A typical ISA driver would need the following include - files:</para> - -<programlisting>#include <sys/module.h> -#include <sys/bus.h> -#include <machine/bus.h> -#include <machine/resource.h> -#include <sys/rman.h> - -#include <isa/isavar.h> -#include <isa/pnpvar.h></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 "xxx" - 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 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> - <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 "xxx" 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 "xxx0" , "xxx1" 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 - kern/bus_subr.c.</para> - - </sect1> - - <sect1> - <title>Config file and the order of identifying and probing - during auto-configuration</title> - - <para>The ISA devices are described in the kernel config 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 needs and abilities for - auto-configuration. For example, some devices don't 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 "isa0" or "isa1", otherwise the device would be - searched for on all the ISA buses.</para> - - <para>"sensitive" 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's 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 - "sensitive" 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, 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's the responsibility of the driver to make sure - that the same device won't 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 kern/subr_bus.h. The old IDE disk driver - i386/isa/wd.c 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> - <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. But generally it's not needed nor recommended, - so this issue is not discussed further.</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 if 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 "unsigned long" and must be - cast as necessary. The resource numbers don't 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 be - normally 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 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 the only reason this - function would return an error is value of type, rid, - start or count out of 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 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's 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's 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 SEPERATE 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 "void - driver_intr_t(void *)"</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 is 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> - <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 computer</para> - - <para>In the 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's - 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 to - configure a memory hole of 1MB starting at 14MB or - 15MB. FreeBSD can handle the memory holes properly if the BIOS - reports them properly (old BIOSes may have this feature - broken).</para> - - <para>In the 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 or 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's - 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's - left at it's original location. If it is not then a fresh - conformant "bounce page" 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 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 <emphasis>alignment</emphasis> - - required physical alignment of the memory area to be - allocated for this tag. Use value 1 for "no specific - alignment". Applies only to the future - <function>bus_dmamem_alloc()</function> but not - <function>bus_dmamap_create()</function> calls. - <emphasis>boundary</emphasis> - physical address - boundary that must not be crossed when allocating the - memory. Use value 0 for "no boundary". 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 slighlty 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's 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. But - anyway the hardware normally can't support that many - scatter-gather buffers.</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 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 waiting until the memory - will become 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>. As of now - 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 as of now - 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's 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's - 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, - &tag_somedata); - if(error) - return error; - - error = bus_dmamem_alloc(tag_somedata, &vsomedata, /* flags*/ 0, - &map_somedata); - if(error) - return error; - - bus_dmamap_load(tag_somedata, map_somedata, (void *)vsomedata, - sizeof (struct somedata), alloc_callback, - (void *) &psomedata, /*flags*/0); </programlisting> - - <para> - Looks a bit long and complicated but that's 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's 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 it's processing and - check this synchronization flag. If it's 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> - <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's - 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 (as well as 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't 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's 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 probably - something 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> - <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't 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, a - well-behaved driver should do so. But in case if 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 don't - 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 don't 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 - "sensitive" flag: the sensitive devices get probed first and - the rest of 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 */ - && bus_set_resource(dev, SYS_RES_IOPORT, 0, sc->port0, - XXX_PORT_COUNT)<0) - return ENXIO;</programlisting> - - <para> - Finally allocate and activate a piece of port address space - (special values of start and end mean "use those we set by - <function>bus_set_resource()</function>"): - </para> - - <programlisting> - sc->port0_rid = 0; - sc->port0_r = bus_alloc_resource(dev, SYS_RES_IOPORT, - &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 don't 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's 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's 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 fucntion <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're 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) < 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) < 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)<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's 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> - <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, &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, &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 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, &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, &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, - &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, - &sc->data_tag); - if(error) - goto bad; - - error = bus_dmamem_alloc(sc->data_tag, &sc->data, /* flags*/ 0, - &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 &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 *) &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) < 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> - <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 reboot will be - needed anyway, so the efforts spent on writing the detach - routine may not be worth it. Another argument is 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 as well 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> - <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 don't consider it here - in any details. - </para> - - <para> - xxx_intr - </para> - - <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 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. It 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/kobj/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml deleted file mode 100644 index a9ea688b9a..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> - <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> - <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> - <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><sys/param.h> -<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 <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]. It's 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. It's 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. It's 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 isn't - 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 993d649ffc..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml +++ /dev/null @@ -1,333 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD SMP Next Generation Project - - $FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/locking/chapter.sgml,v 1.1 2000/11/29 04:15:17 jhb Exp $ ---> - -<chapter id="locking"> - <title>Locking Notes</title> - - <para><emphasis>This chapter is maintained by the FreeBSD SMP Next - Generation Project - <email>freebsd-smp@FreeBSD.org</email>.</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> - <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_COLD</constant></term> - <listitem> - <para>This mutex is initialized very early. Thus, it - must be declared via - <function>MUTEX_DECLARE</function>, and the - <constant>MTX_COLD</constant> flag must be passed to - <function>mtx_init</function>.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><constant>MTX_TOPHALF</constant></term> - <listitem> - <para>This spin mutex does not disable - interrupts.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><constant>MTX_NORECURSE</constant></term> - <listitem> - <para>This mutex is not 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_COLD</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_contested/, - <structname/proc/.<structfield/p_blocked/, - <structname/proc/.<structfield/p_flag/ - (<constant>P_PROFIL</constant> XXX, - <constant>P_INMEM</constant>, - <constant>P_SINTR</constant>, - <constant>P_TIMEOUT</constant>, - <constant>P_SWAPINREQ</constant> XXX, - <constant>P_INMEN</constant> XXX), - <structname/proc/.<structfield/p_nice/, - <structname/proc/.<structfield/p_procq/, - <structname/proc/.<structfield/p_blocked/, - <structname/proc/.<structfield/p_estcpu/, - <structname/proc/.<structfield/p_nativepri/, - <structname/proc/.<structfield/p_priority/, - <structname/proc/.<structfield/p_usrpri/, - <structname/proc/.<structfield/p_rtprio/, - <structname/proc/.<structfield/p_rqindex/, - <structname/proc/.<structfield/p_stats->p_prof/, - <structname/proc/.<structfield/p_stats->p_ru/, - <structname/proc/.<structfield/p_stat/, - <structname/proc/.<structfield/p_cpticks/ - <structname/proc/.<structfield/p_iticks/, - <structname/proc/.<structfield/p_uticks/, - <structname/proc/.<structfield/p_sticks/, - <structname/proc/.<structfield/p_swtime/, - <structname/proc/.<structfield/p_slptime/, - <structname/proc/.<structfield/p_runtime/, - <structname/proc/.<structfield/p_pctcpu/, - <structname/proc/.<structfield/p_oncpu/, - <structname/proc/.<structfield/p_asleep/, - <structname/proc/.<structfield/p_wchan/, - <structname/proc/.<structfield/p_wmesg/, - <structname/proc/.<structfield/p_slpq/, - <structname/proc/.<structfield/p_vmspace/ - (XXX - in <function>statclock</function>), - <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>, - </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> - </entry> - </row> - - <!-- The vm86 pcb lock --> - <row> - <entry>vm86pcb_lock</entry> - <entry><quote>vm86pcb lock</quote></entry> - <entry> - <constant>MTX_DEF</constant> | - <constant>MTX_COLD</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_COLD</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> - </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> - <title>Lock Manager Locks</title> - - <para>Locks that are provided via the &man.lockmgr.9; interface - are lock manager locks. These locks are reader-writer locks and - may be held by a sleeping process.</para> - - <table> - <title>&man.lockmgr.9; 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> - <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><varname>astpending</varname></para> - </listitem> - - <listitem> - <para><structname/mtx/.<structfield/mtx_lock/</para> - </listitem> - </itemizedlist> - </sect1> -</chapter> diff --git a/en_US.ISO8859-1/books/arch-handbook/pci/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/pci/chapter.sgml deleted file mode 100644 index ca94063864..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/pci/chapter.sgml +++ /dev/null @@ -1,372 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/pci/chapter.sgml,v 1.2 2001/04/09 00:33:42 dd Exp $ ---> - -<chapter id="pci"> - <title>PCI Devices</title> - - <para>This chapter will talk about the FreeBSD mechanisms for - writing a device driver for a device on a PCI bus.</para> - - <sect1> - <title>Probe and Attach</title> - - <para>Information here about how the PCI bus code iterates through - the unattached devices and see if a newly loaded kld will attach - to any of them.</para> - -<programlisting>/* - * Simple KLD to play with the PCI functions. - * - * Murray Stokely - */ - -#define MIN(a,b) (((a) < (b)) ? (a) : (b)) - -#include <sys/types.h> -#include <sys/module.h> -#include <sys/systm.h> /* uprintf */ -#include <sys/errno.h> -#include <sys/param.h> /* defines used in kernel.h */ -#include <sys/kernel.h> /* types used in module initialization */ -#include <sys/conf.h> /* cdevsw struct */ -#include <sys/uio.h> /* uio struct */ -#include <sys/malloc.h> -#include <sys/bus.h> /* structs, prototypes for pci bus stuff */ - -#include <pci/pcivar.h> /* For get_pci macros! */ - -/* Function prototypes */ -d_open_t mypci_open; -d_close_t mypci_close; -d_read_t mypci_read; -d_write_t mypci_write; - -/* Character device entry points */ - -static struct cdevsw mypci_cdevsw = { - mypci_open, - mypci_close, - mypci_read, - mypci_write, - noioctl, - nopoll, - nommap, - nostrategy, - "mypci", - 36, /* reserved for lkms - /usr/src/sys/conf/majors */ - nodump, - nopsize, - D_TTY, - -1 -}; - -/* vars */ -static dev_t sdev; - -/* We're more interested in probe/attach than with - open/close/read/write at this point */ - -int -mypci_open(dev_t dev, int oflags, int devtype, struct proc *p) -{ - int err = 0; - - uprintf("Opened device \"mypci\" successfully.\n"); - return(err); -} - -int -mypci_close(dev_t dev, int fflag, int devtype, struct proc *p) -{ - int err=0; - - uprintf("Closing device \"mypci.\"\n"); - return(err); -} - -int -mypci_read(dev_t dev, struct uio *uio, int ioflag) -{ - int err = 0; - - uprintf("mypci read!\n"); - return err; -} - -int -mypci_write(dev_t dev, struct uio *uio, int ioflag) -{ - int err = 0; - - uprintf("mypci write!\n"); - return(err); -} - -/* PCI Support Functions */ - -/* - * Return identification string if this is device is ours. - */ -static int -mypci_probe(device_t dev) -{ - uprintf("MyPCI Probe\n" - "Vendor ID : 0x%x\n" - "Device ID : 0x%x\n",pci_get_vendor(dev),pci_get_device(dev)); - - if (pci_get_vendor(dev) == 0x11c1) { - uprintf("We've got the Winmodem, probe successful!\n"); - return 0; - } - - return ENXIO; -} - -/* Attach function is only called if the probe is successful */ - -static int -mypci_attach(device_t dev) -{ - uprintf("MyPCI Attach for : deviceID : 0x%x\n",pci_get_vendor(dev)); - sdev = make_dev(<literal>&</literal>mypci_cdevsw, - 0, - UID_ROOT, - GID_WHEEL, - 0600, - "mypci"); - uprintf("Mypci device loaded.\n"); - return ENXIO; -} - -/* Detach device. */ - -static int -mypci_detach(device_t dev) -{ - uprintf("Mypci detach!\n"); - return 0; -} - -/* Called during system shutdown after sync. */ - -static int -mypci_shutdown(device_t dev) -{ - uprintf("Mypci shutdown!\n"); - return 0; -} - -/* - * Device suspend routine. - */ -static int -mypci_suspend(device_t dev) -{ - uprintf("Mypci suspend!\n"); - return 0; -} - -/* - * Device resume routine. - */ - -static int -mypci_resume(device_t dev) -{ - uprintf("Mypci resume!\n"); - return 0; -} - -static device_method_t mypci_methods[] = { - /* Device interface */ - DEVMETHOD(device_probe, mypci_probe), - DEVMETHOD(device_attach, mypci_attach), - DEVMETHOD(device_detach, mypci_detach), - DEVMETHOD(device_shutdown, mypci_shutdown), - DEVMETHOD(device_suspend, mypci_suspend), - DEVMETHOD(device_resume, mypci_resume), - - { 0, 0 } -}; - -static driver_t mypci_driver = { - "mypci", - mypci_methods, - 0, - /* sizeof(struct mypci_softc), */ -}; - -static devclass_t mypci_devclass; - -DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);</programlisting> - - <para>Additional Resources - <itemizedlist> - <listitem><simpara><ulink url="http://www.pcisig.org">PCI - Special Interest Group</ulink></simpara></listitem> - - <listitem><simpara>PCI System Architecture, Fourth Edition by - Tom Shanley, et al.</simpara></listitem> - - </itemizedlist> - </para> - </sect1> - - <sect1> - <title>Bus Resources</title> - - <para>FreeBSD provides an object-oriented mechanism for requesting - resources from a parent bus. Almost all devices will be a child - member of some sort of bus (PCI, ISA, USB, SCSI, etc) and these - devices need to acquire resources from their parent bus (such as - memory segments, interrupt lines, or DMA channels).</para> - - <sect2> - <title>Base Address Registers</title> - - <para>To do anything particularly useful with a PCI device you - will need to obtain the <emphasis>Base Address - Registers</emphasis> (BARs) from the PCI Configuration space. - The PCI-specific details of obtaining the BAR is abstracted in - the <function>bus_alloc_resource()</function> function.</para> - - <para>For example, a typical driver might have something similar - to this in the <function>attach()</function> function. : </para> - -<programlisting> sc->bar0id = 0x10; - sc->bar0res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar0id), - 0, ~0, 1, RF_ACTIVE); - if (sc->bar0res == NULL) { - uprintf("Memory allocation of PCI base register 0 failed!\n"); - error = ENXIO; - goto fail1; - } - - sc->bar1id = 0x14; - sc->bar1res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar1id), - 0, ~0, 1, RF_ACTIVE); - if (sc->bar1res == NULL) { - uprintf("Memory allocation of PCI base register 1 failed!\n"); - error = ENXIO; - goto fail2; - } - sc->bar0_bt = rman_get_bustag(sc->bar0res); - sc->bar0_bh = rman_get_bushandle(sc->bar0res); - sc->bar1_bt = rman_get_bustag(sc->bar1res); - sc->bar1_bh = rman_get_bushandle(sc->bar1res); - -</programlisting> - - <para>Handles for each base address register are kept in the - <structname>softc</structname> structure so that they can be - used to write to the device later.</para> - - <para>These handles can then be used to read or write from the - device registers with the <function>bus_space_*</function> - functions. For example, a driver might contain a shorthand - function to read from a board specific register like this : - </para> - -<programlisting>uint16_t -board_read(struct ni_softc *sc, uint16_t address) { - return bus_space_read_2(sc->bar1_bt, sc->bar1_bh, address); -} -</programlisting> - - <para>Similarly, one could write to the registers with : </para> - -<programlisting>void -board_write(struct ni_softc *sc, uint16_t address, uint16_t value) { - bus_space_write_2(sc->bar1_bt, sc->bar1_bh, address, value); -} -</programlisting> - - <para>These functions exist in 8bit, 16bit, and 32bit versions - and you should use - <function>bus_space_{read|write}_{1|2|4}</function> - accordingly.</para> - - </sect2> - <sect2> - <title>Interrupts</title> - - <para>Interrupts are allocated from the object-oriented bus code - in a way similar to the memory resources. First an IRQ - resource must be allocated from the parent bus, and then the - interrupt handler must be setup to deal with this IRQ.</para> - - <para>Again, a sample from a device - <function>attach()</function> function says more than - words.</para> - -<programlisting>/* Get the IRQ resource */ - - sc->irqid = 0x0; - sc->irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &(sc->irqid), - 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); - if (sc->irqres == NULL) { - uprintf("IRQ allocation failed!\n"); - error = ENXIO; - goto fail3; - } - - /* Now we should setup the interrupt handler */ - - error = bus_setup_intr(dev, sc->irqres, INTR_TYPE_MISC, - my_handler, sc, &(sc->handler)); - if (error) { - printf("Couldn't set up irq\n"); - goto fail4; - } - - sc->irq_bt = rman_get_bustag(sc->irqres); - sc->irq_bh = rman_get_bushandle(sc->irqres); -</programlisting> - - </sect2> - - <sect2> - <title>DMA</title> - <para>On the PC, peripherals that want to do bus-mastering DMA - must deal with physical addresses. This is a problem since - FreeBSD uses virtual memory and deals almost exclusively with - virtual addresses. Fortunately, there is a function, - <function>vtophys()</function> to help.</para> - -<programlisting>#include <vm/vm.h> -#include <vm/pmap.h> - -#define vtophys(virtual_address) (...) -</programlisting> - - <para>The solution is a bit different on the alpha however, and - what we really want is a function called - <function>vtobus()</function>.</para> - -<programlisting>#if defined(__alpha__) -#define vtobus(va) alpha_XXX_dmamap((vm_offset_t)va) -#else -#define vtobus(va) vtophys(va) -#endif -</programlisting> - - </sect2> - - <sect2> - <title>Deallocating Resources</title> - - <para>It's very important to deallocate all of the resources - that were allocated during <function>attach()</function>. - Care must be taken to deallocate the correct stuff even on a - failure condition so that the system will remain useable while - your driver dies.</para> - - </sect2> - </sect1> - -</chapter> - - diff --git a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml deleted file mode 100644 index 072aea5499..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml +++ /dev/null @@ -1,1983 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO8859-1/books/developers-handbook/scsi/chapter.sgml,v 1.4 2001/06/13 11:35:56 tom Exp $ ---> - -<chapter id="scsi"> - <title>Common Access Method SCSI Controllers</title> - - <para><emphasis>This chapter was written by &a.babkin; - Modifications for the handbook made by - &a.murray;.</emphasis></para> - - <sect1> - <title>Synopsis</title> - - <para>This document assumes that the reader has a general - understanding of device drivers in FreeBSD and of the SCSI - protocol. Much of the information in this document was - extracted from the drivers :</para> - - <itemizedlist> - - <listitem><para>ncr (<filename>/sys/pci/ncr.c</filename>) by - Wolfgang Stanglmeier and Stefan Esser</para></listitem> - - <listitem><para>sym (<filename>/sys/pci/sym.c</filename>) by - Gerard Roudier</para></listitem> - - <listitem><para>aic7xxx - (<filename>/sys/dev/aic7xxx/aic7xxx.c</filename>) by Justin - T. Gibbs</para></listitem> - - </itemizedlist> - - <para>and from the CAM code itself (by Justing T. Gibbs, see - <filename>/sys/cam/*</filename>). When some solution looked the - most logical and was essentially verbatim extracted from the code - by Justin Gibbs, I marked it as "recommended".</para> - - <para>The document is illustrated with examples in - pseudo-code. Although sometimes the examples have many details - and look like real code, it's still pseudo-code. It was written - to demonstrate the concepts in an understandable way. For a real - driver other approaches may be more modular and efficient. It - also abstracts from the hardware details, as well as issues that - would cloud the demonstrated concepts or that are supposed to be - described in the other chapters of the developers handbook. Such - details are commonly shown as calls to functions with descriptive - names, comments or pseudo-statements. Fortunately real life - full-size examples with all the details can be found in the real - drivers.</para> - - </sect1> - - <sect1> - <title>General architecture</title> - - <para>CAM stands for Common Access Method. It's a generic way to - address the I/O buses in a SCSI-like way. This allows a - separation of the generic device drivers from the drivers - controlling the I/O bus: for example the disk driver becomes able - to control disks on both SCSI, IDE, and/or any other bus so the - disk driver portion does not have to be rewritten (or copied and - modified) for every new I/O bus. Thus the two most important - active entities are:</para> - - <itemizedlist> - <listitem><para><emphasis>Peripheral Modules</emphasis> - a - driver for peripheral devices (disk, tape, CDROM, - etc.)</para></listitem> - <listitem><para><emphasis>SCSI Interface Modules </emphasis>(SIM) - - a Host Bus Adapter drivers for connecting to an I/O bus such - as SCSI or IDE.</para></listitem> - </itemizedlist> - - <para>A peripheral driver receives requests from the OS, converts - them to a sequence of SCSI commands and passes these SCSI - commands to a SCSI Interface Module. The SCSI Interface Module - is responsible for passing these commands to the actual hardware - (or if the actual hardware is not SCSI but, for example, IDE - then also converting the SCSI commands to the native commands of - the hardware).</para> - - <para>Because we are interested in writing a SCSI adapter driver - here, from this point on we will consider everything from the - SIM standpoint.</para> - - <para>A typical SIM driver needs to include the following - CAM-related header files:</para> - -<programlisting>#include <cam/cam.h> -#include <cam/cam_ccb.h> -#include <cam/cam_sim.h> -#include <cam/cam_xpt_sim.h> -#include <cam/cam_debug.h> -#include <cam/scsi/scsi_all.h></programlisting> - - <para>The first thing each SIM driver must do is register itself - with the CAM subsystem. This is done during the driver's - <function>xxx_attach()</function> function (here and further - xxx_ is used to denote the unique driver name prefix). The - <function>xxx_attach()</function> function itself is called by - the system bus auto-configuration code which we don't describe - here.</para> - - <para>This is achieved in multiple steps: first it's necessary to - allocate the queue of requests associated with this SIM:</para> - -<programlisting> struct cam_devq *devq; - - if(( devq = cam_simq_alloc(SIZE) )==NULL) { - error; /* some code to handle the error */ - }</programlisting> - - <para>Here SIZE is the size of the queue to be allocated, maximal - number of requests it could contain. It's the number of requests - that the SIM driver can handle in parallel on one SCSI - card. Commonly it can be calculated as:</para> - -<programlisting>SIZE = NUMBER_OF_SUPPORTED_TARGETS * MAX_SIMULTANEOUS_COMMANDS_PER_TARGET</programlisting> - - <para>Next we create a descriptor of our SIM:</para> - -<programlisting> struct cam_sim *sim; - - if(( sim = cam_sim_alloc(action_func, poll_func, driver_name, - softc, unit, max_dev_transactions, - max_tagged_dev_transactions, devq) )==NULL) { - cam_simq_free(devq); - error; /* some code to handle the error */ - }</programlisting> - - <para>Note that if we are not able to create a SIM descriptor we - free the <structname>devq</structname> also because we can do - nothing else with it and we want to conserve memory.</para> - - <para>If a SCSI card has multiple SCSI buses on it then each bus - requires its own <structname>cam_sim</structname> - structure.</para> - - <para>An interesting question is what to do if a SCSI card has - more than one SCSI bus, do we need one - <structname>devq</structname> structure per card or per SCSI - bus? The answer given in the comments to the CAM code is: - either way, as the driver's author prefers.</para> - - <para>The arguments are : - <itemizedlist> - - <listitem><para><function>action_func</function> - pointer to - the driver's <function>xxx_action</function> function. - <funcSynopsis><funcPrototype> - <funcDef>static void - <function>xxx_action</function> - </funcDef> - <paramdef> - <parameter>struct cam_sim *sim</parameter>, - <parameter>union ccb *ccb</parameter> - </paramdef> - </funcPrototype></funcSynopsis> - </para></listitem> - - <listitem><para><function>poll_func</function> - pointer to - the driver's <function>xxx_poll()</function> - <funcSynopsis><funcPrototype> - <funcDef>static void - <function>xxx_poll</function> - </funcDef> - <paramdef> - <parameter>struct cam_sim *sim</parameter> - </paramdef> - </funcPrototype></funcSynopsis> - </para></listitem> - - <listitem><para>driver_name - the name of the actual driver, - such as "ncr" or "wds"</para></listitem> - - <listitem><para><structName>softc</structName> - pointer to the - driver's internal descriptor for this SCSI card. This - pointer will be used by the driver in future to get private - data.</para></listitem> - - <listitem><para>unit - the controller unit number, for example - for controller "wds0" this number will be - 0</para></listitem> - - <listitem><para>max_dev_transactions - maximal number of - simultaneous transactions per SCSI target in the non-tagged - mode. This value will be almost universally equal to 1, with - possible exceptions only for the non-SCSI cards. Also the - drivers that hope to take advantage by preparing one - transaction while another one is executed may set it to 2 - but this does not seem to be worth the - complexity.</para></listitem> - - <listitem><para>max_tagged_dev_transactions - the same thing, - but in the tagged mode. Tags are the SCSI way to initiate - multiple transactions on a device: each transaction is - assigned a unique tag and the transaction is sent to the - device. When the device completes some transaction it sends - back the result together with the tag so that the SCSI - adapter (and the driver) can tell which transaction was - completed. This argument is also known as the maximal tag - depth. It depends on the abilities of the SCSI - adapter.</para></listitem> - </itemizedlist> - </para> - - <para>Finally we register the SCSI buses associated with our SCSI - adapter:</para> - -<programlisting> if(xpt_bus_register(sim, bus_number) != CAM_SUCCESS) { - cam_sim_free(sim, /*free_devq*/ TRUE); - error; /* some code to handle the error */ - }</programlisting> - - <para>If there is one <structName>devq</structName> structure per - SCSI bus (i.e. we consider a card with multiple buses as - multiple cards with one bus each) then the bus number will - always be 0, otherwise each bus on the SCSI card should be get a - distinct number. Each bus needs its own separate structure - cam_sim.</para> - - <para>After that our controller is completely hooked to the CAM - system. The value of <structName>devq</structName> can be - discarded now: sim will be passed as an argument in all further - calls from CAM and devq can be derived from it.</para> - - <para>CAM provides the framework for such asynchronous - events. Some events originate from the lower levels (the SIM - drivers), some events originate from the peripheral drivers, - some events originate from the CAM subsystem itself. Any driver - can register callbacks for some types of the asynchronous - events, so that it would be notified if these events - occur.</para> - - <para>A typical example of such an event is a device reset. Each - transaction and event identifies the devices to which it applies - by the means of "path". The target-specific events normally - occur during a transaction with this device. So the path from - that transaction may be re-used to report this event (this is - safe because the event path is copied in the event reporting - routine but not deallocated nor passed anywhere further). Also - it's safe to allocate paths dynamically at any time including - the interrupt routines, although that incurs certain overhead, - and a possible problem with this approach is that there may be - no free memory at that time. For a bus reset event we need to - define a wildcard path including all devices on the bus. So we - can create the path for the future bus reset events in advance - and avoid problems with the future memory shortage:</para> - -<programlisting> struct cam_path *path; - - if(xpt_create_path(&path, /*periph*/NULL, - cam_sim_path(sim), CAM_TARGET_WILDCARD, - CAM_LUN_WILDCARD) != CAM_REQ_CMP) { - xpt_bus_deregister(cam_sim_path(sim)); - cam_sim_free(sim, /*free_devq*/TRUE); - error; /* some code to handle the error */ - } - - softc->wpath = path; - softc->sim = sim;</programlisting> - - <para>As you can see the path includes:</para> - - <itemizedlist> - <listitem><para>ID of the peripheral driver (NULL here because we have - none)</para></listitem> - - <listitem><para>ID of the SIM driver - (<function>cam_sim_path(sim)</function>)</para></listitem> - - <listitem><para>SCSI target number of the device (CAM_TARGET_WILDCARD - means "all devices")</para></listitem> - - <listitem><para>SCSI LUN number of the subdevice (CAM_LUN_WILDCARD means - "all LUNs")</para></listitem> - </itemizedlist> - - <para>If the driver can't allocate this path it won't be able to - work normally, so in that case we dismantle that SCSI - bus.</para> - - <para>And we save the path pointer in the - <structName>softc</structName> structure for future use. After - that we save the value of sim (or we can also discard it on the - exit from <function>xxx_probe()</function> if we wish).</para> - - <para>That's all for a minimalistic initialization. To do things - right there is one more issue left. </para> - - <para>For a SIM driver there is one particularly interesting - event: when a target device is considered lost. In this case - resetting the SCSI negotiations with this device may be a good - idea. So we register a callback for this event with CAM. The - request is passed to CAM by requesting CAM action on a CAM - control block for this type of request:</para> - -<programlisting> struct ccb_setasync csa; - - xpt_setup_ccb(&csa.ccb_h, path, /*priority*/5); - csa.ccb_h.func_code = XPT_SASYNC_CB; - csa.event_enable = AC_LOST_DEVICE; - csa.callback = xxx_async; - csa.callback_arg = sim; - xpt_action((union ccb *)&csa);</programlisting> - - <para>Now we take a look at the <function>xxx_action()</function> - and <function>xxx_poll()</function> driver entry points.</para> - - <para> - <funcSynopsis><funcPrototype> - <funcDef>static void - <function>xxx_action</function> - </funcDef> - <paramdef> - <parameter>struct cam_sim *sim</parameter>, - <parameter>union ccb *ccb</parameter> - </paramdef> - </funcPrototype></funcSynopsis> - </para> - - <para>Do some action on request of the CAM subsystem. Sim - describes the SIM for the request, CCB is the request - itself. CCB stands for "CAM Control Block". It is a union of - many specific instances, each describing arguments for some type - of transactions. All of these instances share the CCB header - where the common part of arguments is stored.</para> - - <para>CAM supports the SCSI controllers working in both initiator - ("normal") mode and target (simulating a SCSI device) mode. Here - we only consider the part relevant to the initiator mode.</para> - - <para>There are a few function and macros (in other words, - methods) defined to access the public data in the struct sim:</para> - - <itemizedlist> - <listitem><para><function>cam_sim_path(sim)</function> - the - path ID (see above)</para></listitem> - - <listitem><para><function>cam_sim_name(sim)</function> - the - name of the sim</para></listitem> - - <listitem><para><function>cam_sim_softc(sim)</function> - the - pointer to the softc (driver private data) - structure</para></listitem> - - <listitem><para><function> cam_sim_unit(sim)</function> - the - unit number</para></listitem> - - <listitem><para><function> cam_sim_bus(sim)</function> - the bus - ID</para></listitem> - </itemizedlist> - - <para>To identify the device, <function>xxx_action()</function> can - get the unit number and pointer to its structure softc using - these functions.</para> - - <para>The type of request is stored in - <structField>ccb->ccb_h.func_code</structField>. So generally - <function>xxx_action()</function> consists of a big - switch:</para> - -<programlisting> struct xxx_softc *softc = (struct xxx_softc *) cam_sim_softc(sim); - struct ccb_hdr *ccb_h = &ccb->ccb_h; - int unit = cam_sim_unit(sim); - int bus = cam_sim_bus(sim); - - switch(ccb_h->func_code) { - case ...: - ... - default: - ccb_h->status = CAM_REQ_INVALID; - xpt_done(ccb); - break; - }</programlisting> - - <para>As can be seen from the default case (if an unknown command - was received) the return code of the command is set into - <structField>ccb->ccb_h.status</structField> and the completed - CCB is returned back to CAM by calling - <function>xpt_done(ccb)</function>. </para> - - <para><function>xpt_done()</function> does not have to be called - from <function>xxx_action()</function>: For example an I/O - request may be enqueued inside the SIM driver and/or its SCSI - controller. Then when the device would post an interrupt - signaling that the processing of this request is complete - <function>xpt_done()</function> may be called from the interrupt - handling routine.</para> - - <para>Actually, the CCB status is not only assigned as a return - code but a CCB has some status all the time. Before CCB is - passed to the <function>xxx_action()</function> routine it gets - the status CCB_REQ_INPROG meaning that it's in progress. There - are a surprising number of status values defined in - <filename>/sys/cam/cam.h</filename> which should be able to - represent the status of a request in great detail. More - interesting yet, the status is in fact a "bitwise or" of an - enumerated status value (the lower 6 bits) and possible - additional flag-like bits (the upper bits). The enumerated - values will be discussed later in more detail. The summary of - them can be found in the Errors Summary section. The possible - status flags are:</para> - - <itemizedlist> - - <listitem><para><emphasis>CAM_DEV_QFRZN</emphasis> - if the - SIM driver gets a serious error (for example, the device does - not respond to the selection or breaks the SCSI protocol) when - processing a CCB it should freeze the request queue by calling - <function>xpt_freeze_simq()</function>, return the other - enqueued but not processed yet CCBs for this device back to - the CAM queue, then set this flag for the troublesome CCB and - call <function>xpt_done()</function>. This flag causes the CAM - subsystem to unfreeze the queue after it handles the - error.</para></listitem> - - <listitem><para><emphasis>CAM_AUTOSNS_VALID</emphasis> - if - the device returned an error condition and the flag - CAM_DIS_AUTOSENSE is not set in CCB the SIM driver must - execute the REQUEST SENSE command automatically to extract the - sense (extended error information) data from the device. If - this attempt was successful the sense data should be saved in - the CCB and this flag set.</para></listitem> - - <listitem><para><emphasis>CAM_RELEASE_SIMQ</emphasis> - like - CAM_DEV_QFRZN but used in case there is some problem (or - resource shortage) with the SCSI controller itself. Then all - the future requests to the controller should be stopped by - <function>xpt_freeze_simq()</function>. The controller queue - will be restarted after the SIM driver overcomes the shortage - and informs CAM by returning some CCB with this flag - set.</para></listitem> - - <listitem><para><emphasis>CAM_SIM_QUEUED</emphasis> - when SIM - puts a CCB into its request queue this flag should be set (and - removed when this CCB gets dequeued before being returned back - to CAM). This flag is not used anywhere in the CAM code now, - so its purpose is purely diagnostic.</para></listitem> - - </itemizedlist> - - <para>The function <function>xxx_action()</function> is not - allowed to sleep, so all the synchronization for resource access - must be done using SIM or device queue freezing. Besides the - aforementioned flags the CAM subsystem provides functions - <function>xpt_selease_simq()</function> and - <function>xpt_release_devq()</function> to unfreeze the queues - directly, without passing a CCB to CAM.</para> - - <para>The CCB header contains the following fields:</para> - - <itemizedlist> - - <listitem><para><emphasis>path</emphasis> - path ID for the - request</para></listitem> - - <listitem><para><emphasis>target_id</emphasis> - target device - ID for the request</para></listitem> - - <listitem><para><emphasis>target_lun</emphasis> - LUN ID of - the target device</para></listitem> - - <listitem><para><emphasis>timeout</emphasis> - timeout - interval for this command, in milliseconds</para></listitem> - - <listitem><para><emphasis>timeout_ch</emphasis> - a - convenience place for the SIM driver to store the timeout handle - (the CAM subsystem itself does not make any assumptions about - it)</para></listitem> - - <listitem><para><emphasis>flags</emphasis> - various bits of - information about the request spriv_ptr0, spriv_ptr1 - fields - reserved for private use by the SIM driver (such as linking to - the SIM queues or SIM private control blocks); actually, they - exist as unions: spriv_ptr0 and spriv_ptr1 have the type (void - *), spriv_field0 and spriv_field1 have the type unsigned long, - sim_priv.entries[0].bytes and sim_priv.entries[1].bytes are byte - arrays of the size consistent with the other incarnations of the - union and sim_priv.bytes is one array, twice - bigger.</para></listitem> - - </itemizedlist> - - <para>The recommended way of using the SIM private fields of CCB - is to define some meaningful names for them and use these - meaningful names in the driver, like:</para> - -<programlisting>#define ccb_some_meaningful_name sim_priv.entries[0].bytes -#define ccb_hcb spriv_ptr1 /* for hardware control block */</programlisting> - - <para>The most common initiator mode requests are:</para> - <itemizedlist> - <listitem><para><emphasis>XPT_SCSI_IO</emphasis> - execute an - I/O transaction</para> - - <para>The instance "struct ccb_scsiio csio" of the union ccb is - used to transfer the arguments. They are:</para> - - <itemizedlist> - <listitem><para><emphasis>cdb_io</emphasis> - pointer to - the SCSI command buffer or the buffer - itself</para></listitem> - - <listitem><para><emphasis>cdb_len</emphasis> - SCSI - command length</para></listitem> - - <listitem><para><emphasis>data_ptr</emphasis> - pointer to - the data buffer (gets a bit complicated if scatter/gather is - used)</para></listitem> - - <listitem><para><emphasis>dxfer_len</emphasis> - length of - the data to transfer</para></listitem> - - <listitem><para><emphasis>sglist_cnt</emphasis> - counter - of the scatter/gather segments</para></listitem> - - <listitem><para><emphasis>scsi_status</emphasis> - place - to return the SCSI status</para></listitem> - - <listitem><para><emphasis>sense_data</emphasis> - buffer - for the SCSI sense information if the command returns an - error (the SIM driver is supposed to run the REQUEST SENSE - command automatically in this case if the CCB flag - CAM_DIS_AUTOSENSE is not set)</para></listitem> - - <listitem><para><emphasis>sense_len</emphasis> - the - length of that buffer (if it happens to be higher than size - of sense_data the SIM driver must silently assume the - smaller value) resid, sense_resid - if the transfer of data - or SCSI sense returned an error these are the returned - counters of the residual (not transferred) data. They do not - seem to be especially meaningful, so in a case when they are - difficult to compute (say, counting bytes in the SCSI - controller's FIFO buffer) an approximate value will do as - well. For a successfully completed transfer they must be set - to zero.</para></listitem> - - <listitem><para><emphasis>tag_action</emphasis> - the kind - of tag to use: - - <itemizedlist> - <listitem><para>CAM_TAG_ACTION_NONE - don't use tags for this - transaction</para></listitem> - <listitem><para>MSG_SIMPLE_Q_TAG, MSG_HEAD_OF_Q_TAG, - MSG_ORDERED_Q_TAG - value equal to the appropriate tag - message (see /sys/cam/scsi/scsi_message.h); this gives only - the tag type, the SIM driver must assign the tag value - itself</para></listitem> - </itemizedlist> - - </para></listitem> - - </itemizedlist> - - <para>The general logic of handling this request is the - following:</para> - - <para>The first thing to do is to check for possible races, to - make sure that the command did not get aborted when it was - sitting in the queue:</para> - -<programlisting> struct ccb_scsiio *csio = &ccb->csio; - - if ((ccb_h->status & CAM_STATUS_MASK) != CAM_REQ_INPROG) { - xpt_done(ccb); - return; - }</programlisting> - - <para>Also we check that the device is supported at all by our - controller:</para> - -<programlisting> if(ccb_h->target_id > OUR_MAX_SUPPORTED_TARGET_ID - || cch_h->target_id == OUR_SCSI_CONTROLLERS_OWN_ID) { - ccb_h->status = CAM_TID_INVALID; - xpt_done(ccb); - return; - } - if(ccb_h->target_lun > OUR_MAX_SUPPORTED_LUN) { - ccb_h->status = CAM_LUN_INVALID; - xpt_done(ccb); - return; - }</programlisting> - - <para>Then allocate whatever data structures (such as - card-dependent hardware control block) we need to process this - request. If we can't then freeze the SIM queue and remember - that we have a pending operation, return the CCB back and ask - CAM to re-queue it. Later when the resources become available - the SIM queue must be unfrozen by returning a ccb with the - CAM_SIMQ_RELEASE bit set in its status. Otherwise, if all went - well, link the CCB with the hardware control block (HCB) and - mark it as queued.</para> - -<programlisting> struct xxx_hcb *hcb = allocate_hcb(softc, unit, bus); - - if(hcb == NULL) { - softc->flags |= RESOURCE_SHORTAGE; - xpt_freeze_simq(sim, /*count*/1); - ccb_h->status = CAM_REQUEUE_REQ; - xpt_done(ccb); - return; - } - - hcb->ccb = ccb; ccb_h->ccb_hcb = (void *)hcb; - ccb_h->status |= CAM_SIM_QUEUED;</programlisting> - - <para>Extract the target data from CCB into the hardware control - block. Check if we are asked to assign a tag and if yes then - generate an unique tag and build the SCSI tag messages. The - SIM driver is also responsible for negotiations with the - devices to set the maximal mutually supported bus width, - synchronous rate and offset.</para> - -<programlisting> hcb->target = ccb_h->target_id; hcb->lun = ccb_h->target_lun; - generate_identify_message(hcb); - if( ccb_h->tag_action != CAM_TAG_ACTION_NONE ) - generate_unique_tag_message(hcb, ccb_h->tag_action); - if( !target_negotiated(hcb) ) - generate_negotiation_messages(hcb);</programlisting> - - <para>Then set up the SCSI command. The command storage may be - specified in the CCB in many interesting ways, specified by - the CCB flags. The command buffer can be contained in CCB or - pointed to, in the latter case the pointer may be physical or - virtual. Since the hardware commonly needs physical address we - always convert the address to the physical one.</para> - - <para>A NOT-QUITE RELATED NOTE: Normally this is done by a call - to vtophys(), but for the PCI device (which account for most - of the SCSI controllers now) drivers' portability to the Alpha - architecture the conversion must be done by vtobus() instead - due to special Alpha quirks. [IMHO it would be much better to - have two separate functions, vtop() and ptobus() then vtobus() - would be a simple superposition of them.] In case if a - physical address is requested it's OK to return the CCB with - the status CAM_REQ_INVALID, the current drivers do that. But - it's also possible to compile the Alpha-specific piece of - code, as in this example (there should be a more direct way to - do that, without conditional compilation in the drivers). If - necessary a physical address can be also converted or mapped - back to a virtual address but with big pain, so we don't do - that.</para> - -<programlisting> if(ccb_h->flags & CAM_CDB_POINTER) { - /* CDB is a pointer */ - if(!(ccb_h->flags & CAM_CDB_PHYS)) { - /* CDB pointer is virtual */ - hcb->cmd = vtobus(csio->cdb_io.cdb_ptr); - } else { - /* CDB pointer is physical */ -#if defined(__alpha__) - hcb->cmd = csio->cdb_io.cdb_ptr | alpha_XXX_dmamap_or ; -#else - hcb->cmd = csio->cdb_io.cdb_ptr ; -#endif - } - } else { - /* CDB is in the ccb (buffer) */ - hcb->cmd = vtobus(csio->cdb_io.cdb_bytes); - } - hcb->cmdlen = csio->cdb_len;</programlisting> - - <para>Now it's time to set up the data. Again, the data storage - may be specified in the CCB in many interesting ways, - specified by the CCB flags. First we get the direction of the - data transfer. The simplest case is if there is no data to - transfer:</para> - -<programlisting> int dir = (ccb_h->flags & CAM_DIR_MASK); - - if (dir == CAM_DIR_NONE) - goto end_data;</programlisting> - - <para>Then we check if the data is in one chunk or in a - scatter-gather list, and the addresses are physical or - virtual. The SCSI controller may be able to handle only a - limited number of chunks of limited length. If the request - hits this limitation we return an error. We use a special - function to return the CCB to handle in one place the HCB - resource shortages. The functions to add chunks are - driver-dependent, and here we leave them without detailed - implementation. See description of the SCSI command (CDB) - handling for the details on the address-translation issues. - If some variation is too difficult or impossible to implement - with a particular card it's OK to return the status - CAM_REQ_INVALID. Actually, it seems like the scatter-gather - ability is not used anywhere in the CAM code now. But at least - the case for a single non-scattered virtual buffer must be - implemented, it's actively used by CAM.</para> - -<programlisting> int rv; - - initialize_hcb_for_data(hcb); - - if((!(ccb_h->flags & CAM_SCATTER_VALID)) { - /* single buffer */ - if(!(ccb_h->flags & CAM_DATA_PHYS)) { - rv = add_virtual_chunk(hcb, csio->data_ptr, csio->dxfer_len, dir); - } - } else { - rv = add_physical_chunk(hcb, csio->data_ptr, csio->dxfer_len, dir); - } - } else { - int i; - struct bus_dma_segment *segs; - segs = (struct bus_dma_segment *)csio->data_ptr; - - if ((ccb_h->flags & CAM_SG_LIST_PHYS) != 0) { - /* The SG list pointer is physical */ - rv = setup_hcb_for_physical_sg_list(hcb, segs, csio->sglist_cnt); - } else if (!(ccb_h->flags & CAM_DATA_PHYS)) { - /* SG buffer pointers are virtual */ - for (i = 0; i < csio->sglist_cnt; i++) { - rv = add_virtual_chunk(hcb, segs[i].ds_addr, - segs[i].ds_len, dir); - if (rv != CAM_REQ_CMP) - break; - } - } else { - /* SG buffer pointers are physical */ - for (i = 0; i < csio->sglist_cnt; i++) { - rv = add_physical_chunk(hcb, segs[i].ds_addr, - segs[i].ds_len, dir); - if (rv != CAM_REQ_CMP) - break; - } - } - } - if(rv != CAM_REQ_CMP) { - /* we expect that add_*_chunk() functions return CAM_REQ_CMP - * if they added a chunk successfully, CAM_REQ_TOO_BIG if - * the request is too big (too many bytes or too many chunks), - * CAM_REQ_INVALID in case of other troubles - */ - free_hcb_and_ccb_done(hcb, ccb, rv); - return; - } - end_data:</programlisting> - - <para>If disconnection is disabled for this CCB we pass this - information to the hcb:</para> - -<programlisting> if(ccb_h->flags & CAM_DIS_DISCONNECT) - hcb_disable_disconnect(hcb);</programlisting> - - <para>If the controller is able to run REQUEST SENSE command all - by itself then the value of the flag CAM_DIS_AUTOSENSE should - also be passed to it, to prevent automatic REQUEST SENSE if the - CAM subsystem does not want it.</para> - - <para>The only thing left is to set up the timeout, pass our hcb - to the hardware and return, the rest will be done by the - interrupt handler (or timeout handler).</para> - -<programlisting> ccb_h->timeout_ch = timeout(xxx_timeout, (caddr_t) hcb, - (ccb_h->timeout * hz) / 1000); /* convert milliseconds to ticks */ - put_hcb_into_hardware_queue(hcb); - return;</programlisting> - - <para>And here is a possible implementation of the function - returning CCB:</para> - -<programlisting> static void - free_hcb_and_ccb_done(struct xxx_hcb *hcb, union ccb *ccb, u_int32_t status) - { - struct xxx_softc *softc = hcb->softc; - - ccb->ccb_h.ccb_hcb = 0; - if(hcb != NULL) { - untimeout(xxx_timeout, (caddr_t) hcb, ccb->ccb_h.timeout_ch); - /* we're about to free a hcb, so the shortage has ended */ - if(softc->flags & RESOURCE_SHORTAGE) { - softc->flags &= ~RESOURCE_SHORTAGE; - status |= CAM_RELEASE_SIMQ; - } - free_hcb(hcb); /* also removes hcb from any internal lists */ - } - ccb->ccb_h.status = status | - (ccb->ccb_h.status & ~(CAM_STATUS_MASK|CAM_SIM_QUEUED)); - xpt_done(ccb); - }</programlisting> - </listitem> - - <listitem><para><emphasis>XPT_RESET_DEV</emphasis> - send the SCSI "BUS - DEVICE RESET" message to a device</para> - - <para>There is no data transferred in CCB except the header and - the most interesting argument of it is target_id. Depending on - the controller hardware a hardware control block just like for - the XPT_SCSI_IO request may be constructed (see XPT_SCSI_IO - request description) and sent to the controller or the SCSI - controller may be immediately programmed to send this RESET - message to the device or this request may be just not supported - (and return the status CAM_REQ_INVALID). Also on completion of - the request all the disconnected transactions for this target - must be aborted (probably in the interrupt routine).</para> - - <para>Also all the current negotiations for the target are lost on - reset, so they might be cleaned too. Or they clearing may be - deferred, because anyway the target would request re-negotiation - on the next transaction.</para></listitem> - - <listitem><para><emphasis>XPT_RESET_BUS</emphasis> - send the RESET signal - to the SCSI bus</para> - - <para>No arguments are passed in the CCB, the only interesting - argument is the SCSI bus indicated by the struct sim - pointer.</para> - - <para>A minimalistic implementation would forget the SCSI - negotiations for all the devices on the bus and return the - status CAM_REQ_CMP.</para> - - <para>The proper implementation would in addition actually reset - the SCSI bus (possible also reset the SCSI controller) and mark - all the CCBs being processed, both those in the hardware queue - and those being disconnected, as done with the status - CAM_SCSI_BUS_RESET. Like:</para> - -<programlisting> int targ, lun; - struct xxx_hcb *h, *hh; - struct ccb_trans_settings neg; - struct cam_path *path; - - /* The SCSI bus reset may take a long time, in this case its completion - * should be checked by interrupt or timeout. But for simplicity - * we assume here that it's really fast. - */ - reset_scsi_bus(softc); - - /* drop all enqueued CCBs */ - for(h = softc->first_queued_hcb; h != NULL; h = hh) { - hh = h->next; - free_hcb_and_ccb_done(h, h->ccb, CAM_SCSI_BUS_RESET); - } - - /* the clean values of negotiations to report */ - neg.bus_width = 8; - neg.sync_period = neg.sync_offset = 0; - neg.valid = (CCB_TRANS_BUS_WIDTH_VALID - | CCB_TRANS_SYNC_RATE_VALID | CCB_TRANS_SYNC_OFFSET_VALID); - - /* drop all disconnected CCBs and clean negotiations */ - for(targ=0; targ <= OUR_MAX_SUPPORTED_TARGET; targ++) { - clean_negotiations(softc, targ); - - /* report the event if possible */ - if(xpt_create_path(&path, /*periph*/NULL, - cam_sim_path(sim), targ, - CAM_LUN_WILDCARD) == CAM_REQ_CMP) { - xpt_async(AC_TRANSFER_NEG, path, &neg); - xpt_free_path(path); - } - - for(lun=0; lun <= OUR_MAX_SUPPORTED_LUN; lun++) - for(h = softc->first_discon_hcb[targ][lun]; h != NULL; h = hh) { - hh=h->next; - free_hcb_and_ccb_done(h, h->ccb, CAM_SCSI_BUS_RESET); - } - } - - ccb->ccb_h.status = CAM_REQ_CMP; - xpt_done(ccb); - - /* report the event */ - xpt_async(AC_BUS_RESET, softc->wpath, NULL); - return;</programlisting> - - <para>Implementing the SCSI bus reset as a function may be a good - idea because it would be re-used by the timeout function as a - last resort if the things go wrong.</para></listitem> - - <listitem><para><emphasis>XPT_ABORT</emphasis> - abort the specified - CCB</para> - - <para>The arguments are transferred in the instance "struct - ccb_abort cab" of the union ccb. The only argument field in it - is:</para> - - <para><emphasis>abort_ccb</emphasis> - pointer to the CCB to be - aborted</para> - - <para>If the abort is not supported just return the status - CAM_UA_ABORT. This is also the easy way to minimally implement - this call, return CAM_UA_ABORT in any case.</para> - - <para>The hard way is to implement this request honestly. First - check that abort applies to a SCSI transaction:</para> - -<programlisting> struct ccb *abort_ccb; - abort_ccb = ccb->cab.abort_ccb; - - if(abort_ccb->ccb_h.func_code != XPT_SCSI_IO) { - ccb->ccb_h.status = CAM_UA_ABORT; - xpt_done(ccb); - return; - }</programlisting> - - <para>Then it's necessary to find this CCB in our queue. This can - be done by walking the list of all our hardware control blocks - in search for one associated with this CCB:</para> - -<programlisting> struct xxx_hcb *hcb, *h; - - hcb = NULL; - - /* We assume that softc->first_hcb is the head of the list of all - * HCBs associated with this bus, including those enqueued for - * processing, being processed by hardware and disconnected ones. - */ - for(h = softc->first_hcb; h != NULL; h = h->next) { - if(h->ccb == abort_ccb) { - hcb = h; - break; - } - } - - if(hcb == NULL) { - /* no such CCB in our queue */ - ccb->ccb_h.status = CAM_PATH_INVALID; - xpt_done(ccb); - return; - } - - hcb=found_hcb;</programlisting> - - <para>Now we look at the current processing status of the HCB. It - may be either sitting in the queue waiting to be sent to the - SCSI bus, being transferred right now, or disconnected and - waiting for the result of the command, or actually completed by - hardware but not yet marked as done by software. To make sure - that we don't get in any races with hardware we mark the HCB as - being aborted, so that if this HCB is about to be sent to the - SCSI bus the SCSI controller will see this flag and skip - it.</para> - -<programlisting> int hstatus; - - /* shown as a function, in case special action is needed to make - * this flag visible to hardware - */ - set_hcb_flags(hcb, HCB_BEING_ABORTED); - - abort_again: - - hstatus = get_hcb_status(hcb); - switch(hstatus) { - case HCB_SITTING_IN_QUEUE: - remove_hcb_from_hardware_queue(hcb); - /* FALLTHROUGH */ - case HCB_COMPLETED: - /* this is an easy case */ - free_hcb_and_ccb_done(hcb, abort_ccb, CAM_REQ_ABORTED); - break;</programlisting> - - <para>If the CCB is being transferred right now we would like to - signal to the SCSI controller in some hardware-dependent way - that we want to abort the current transfer. The SCSI controller - would set the SCSI ATTENTION signal and when the target responds - to it send an ABORT message. We also reset the timeout to make - sure that the target is not sleeping forever. If the command - would not get aborted in some reasonable time like 10 seconds - the timeout routine would go ahead and reset the whole SCSI bus. - Because the command will be aborted in some reasonable time we - can just return the abort request now as successfully completed, - and mark the aborted CCB as aborted (but not mark it as done - yet).</para> - -<programlisting> case HCB_BEING_TRANSFERRED: - untimeout(xxx_timeout, (caddr_t) hcb, abort_ccb->ccb_h.timeout_ch); - abort_ccb->ccb_h.timeout_ch = - timeout(xxx_timeout, (caddr_t) hcb, 10 * hz); - abort_ccb->ccb_h.status = CAM_REQ_ABORTED; - /* ask the controller to abort that HCB, then generate - * an interrupt and stop - */ - if(signal_hardware_to_abort_hcb_and_stop(hcb) < 0) { - /* oops, we missed the race with hardware, this transaction - * got off the bus before we aborted it, try again */ - goto abort_again; - } - - break;</programlisting> - - <para>If the CCB is in the list of disconnected then set it up as - an abort request and re-queue it at the front of hardware - queue. Reset the timeout and report the abort request to be - completed.</para> - -<programlisting> case HCB_DISCONNECTED: - untimeout(xxx_timeout, (caddr_t) hcb, abort_ccb->ccb_h.timeout_ch); - abort_ccb->ccb_h.timeout_ch = - timeout(xxx_timeout, (caddr_t) hcb, 10 * hz); - put_abort_message_into_hcb(hcb); - put_hcb_at_the_front_of_hardware_queue(hcb); - break; - } - ccb->ccb_h.status = CAM_REQ_CMP; - xpt_done(ccb); - return;</programlisting> - - <para>That's all for the ABORT request, although there is one more - issue. Because the ABORT message cleans all the ongoing - transactions on a LUN we have to mark all the other active - transactions on this LUN as aborted. That should be done in the - interrupt routine, after the transaction gets aborted.</para> - - <para>Implementing the CCB abort as a function may be quite a good - idea, this function can be re-used if an I/O transaction times - out. The only difference would be that the timed out transaction - would return the status CAM_CMD_TIMEOUT for the timed out - request. Then the case XPT_ABORT would be small, like - that:</para> - -<programlisting> case XPT_ABORT: - struct ccb *abort_ccb; - abort_ccb = ccb->cab.abort_ccb; - - if(abort_ccb->ccb_h.func_code != XPT_SCSI_IO) { - ccb->ccb_h.status = CAM_UA_ABORT; - xpt_done(ccb); - return; - } - if(xxx_abort_ccb(abort_ccb, CAM_REQ_ABORTED) < 0) - /* no such CCB in our queue */ - ccb->ccb_h.status = CAM_PATH_INVALID; - else - ccb->ccb_h.status = CAM_REQ_CMP; - xpt_done(ccb); - return;</programlisting> - </listitem> - - <listitem><para><emphasis>XPT_SET_TRAN_SETTINGS</emphasis> - explicitly - set values of SCSI transfer settings</para> - - <para>The arguments are transferred in the instance "struct ccb_trans_setting cts" -of the union ccb:</para> - - <itemizedlist> - <listitem><para><emphasis>valid</emphasis> - a bitmask showing - which settings should be updated:</para></listitem> - - <listitem><para><emphasis>CCB_TRANS_SYNC_RATE_VALID</emphasis> - - synchronous transfer rate</para></listitem> - - <listitem><para><emphasis>CCB_TRANS_SYNC_OFFSET_VALID</emphasis> - - synchronous offset</para></listitem> - - <listitem><para><emphasis>CCB_TRANS_BUS_WIDTH_VALID</emphasis> - - bus width</para></listitem> - - <listitem><para><emphasis>CCB_TRANS_DISC_VALID</emphasis> - - set enable/disable disconnection</para></listitem> - - <listitem><para><emphasis>CCB_TRANS_TQ_VALID</emphasis> - set - enable/disable tagged queuing</para></listitem> - - <listitem><para><emphasis>flags</emphasis> - consists of two - parts, binary arguments and identification of - sub-operations. The binary arguments are :</para> - <itemizedlist> - <listitem><para><emphasis>CCB_TRANS_DISC_ENB</emphasis> - enable disconnection</para></listitem> - <listitem><para><emphasis>CCB_TRANS_TAG_ENB</emphasis> - - enable tagged queuing</para></listitem> - </itemizedlist> - </listitem> - - <listitem><para>the sub-operations are:</para> - <itemizedlist> - <listitem><para><emphasis>CCB_TRANS_CURRENT_SETTINGS</emphasis> - - change the current negotiations</para></listitem> - - <listitem><para><emphasis>CCB_TRANS_USER_SETTINGS</emphasis> - - remember the desired user values sync_period, sync_offset - - self-explanatory, if sync_offset==0 then the asynchronous mode - is requested bus_width - bus width, in bits (not - bytes)</para></listitem> - </itemizedlist> - </listitem> - - </itemizedlist> - - <para>Two sets of negotiated parameters are supported, the user - settings and the current settings. The user settings are not - really used much in the SIM drivers, this is mostly just a piece - of memory where the upper levels can store (and later recall) - its ideas about the parameters. Setting the user parameters - does not cause re-negotiation of the transfer rates. But when - the SCSI controller does a negotiation it must never set the - values higher than the user parameters, so it's essentially the - top boundary.</para> - - <para>The current settings are, as the name says, - current. Changing them means that the parameters must be - re-negotiated on the next transfer. Again, these "new current - settings" are not supposed to be forced on the device, just they - are used as the initial step of negotiations. Also they must be - limited by actual capabilities of the SCSI controller: for - example, if the SCSI controller has 8-bit bus and the request - asks to set 16-bit wide transfers this parameter must be - silently truncated to 8-bit transfers before sending it to the - device.</para> - - <para>One caveat is that the bus width and synchronous parameters - are per target while the disconnection and tag enabling - parameters are per lun.</para> - - <para>The recommended implementation is to keep 3 sets of - negotiated (bus width and synchronous transfer) - parameters:</para> - - <itemizedlist> - <listitem><para><emphasis>user</emphasis> - the user set, as - above</para></listitem> - - <listitem><para><emphasis>current</emphasis> - those actually - in effect</para></listitem> - - <listitem><para><emphasis>goal</emphasis> - those requested by - setting of the "current" parameters</para></listitem> - </itemizedlist> - - <para>The code looks like:</para> - -<programlisting> struct ccb_trans_settings *cts; - int targ, lun; - int flags; - - cts = &ccb->cts; - targ = ccb_h->target_id; - lun = ccb_h->target_lun; - flags = cts->flags; - if(flags & CCB_TRANS_USER_SETTINGS) { - if(flags & CCB_TRANS_SYNC_RATE_VALID) - softc->user_sync_period[targ] = cts->sync_period; - if(flags & CCB_TRANS_SYNC_OFFSET_VALID) - softc->user_sync_offset[targ] = cts->sync_offset; - if(flags & CCB_TRANS_BUS_WIDTH_VALID) - softc->user_bus_width[targ] = cts->bus_width; - - if(flags & CCB_TRANS_DISC_VALID) { - softc->user_tflags[targ][lun] &= ~CCB_TRANS_DISC_ENB; - softc->user_tflags[targ][lun] |= flags & CCB_TRANS_DISC_ENB; - } - if(flags & CCB_TRANS_TQ_VALID) { - softc->user_tflags[targ][lun] &= ~CCB_TRANS_TQ_ENB; - softc->user_tflags[targ][lun] |= flags & CCB_TRANS_TQ_ENB; - } - } - if(flags & CCB_TRANS_CURRENT_SETTINGS) { - if(flags & CCB_TRANS_SYNC_RATE_VALID) - softc->goal_sync_period[targ] = - max(cts->sync_period, OUR_MIN_SUPPORTED_PERIOD); - if(flags & CCB_TRANS_SYNC_OFFSET_VALID) - softc->goal_sync_offset[targ] = - min(cts->sync_offset, OUR_MAX_SUPPORTED_OFFSET); - if(flags & CCB_TRANS_BUS_WIDTH_VALID) - softc->goal_bus_width[targ] = min(cts->bus_width, OUR_BUS_WIDTH); - - if(flags & CCB_TRANS_DISC_VALID) { - softc->current_tflags[targ][lun] &= ~CCB_TRANS_DISC_ENB; - softc->current_tflags[targ][lun] |= flags & CCB_TRANS_DISC_ENB; - } - if(flags & CCB_TRANS_TQ_VALID) { - softc->current_tflags[targ][lun] &= ~CCB_TRANS_TQ_ENB; - softc->current_tflags[targ][lun] |= flags & CCB_TRANS_TQ_ENB; - } - } - ccb->ccb_h.status = CAM_REQ_CMP; - xpt_done(ccb); - return;</programlisting> - - <para>Then when the next I/O request will be processed it will - check if it has to re-negotiate, for example by calling the - function target_negotiated(hcb). It can be implemented like - this:</para> - -<programlisting> int - target_negotiated(struct xxx_hcb *hcb) - { - struct softc *softc = hcb->softc; - int targ = hcb->targ; - - if( softc->current_sync_period[targ] != softc->goal_sync_period[targ] - || softc->current_sync_offset[targ] != softc->goal_sync_offset[targ] - || softc->current_bus_width[targ] != softc->goal_bus_width[targ] ) - return 0; /* FALSE */ - else - return 1; /* TRUE */ - }</programlisting> - - <para>After the values are re-negotiated the resulting values must - be assigned to both current and goal parameters, so for future - I/O transactions the current and goal parameters would be the - same and <function>target_negotiated()</function> would return - TRUE. When the card is initialized (in - <function>xxx_attach()</function>) the current negotiation - values must be initialized to narrow asynchronous mode, the goal - and current values must be initialized to the maximal values - supported by controller.</para></listitem> - - <listitem><para><emphasis>XPT_GET_TRAN_SETTINGS</emphasis> - get values of - SCSI transfer settings</para> - - <para>This operations is the reverse of - XPT_SET_TRAN_SETTINGS. Fill up the CCB instance "struct - ccb_trans_setting cts" with data as requested by the flags - CCB_TRANS_CURRENT_SETTINGS or CCB_TRANS_USER_SETTINGS (if both - are set then the existing drivers return the current - settings). Set all the bits in the valid field.</para></listitem> - - <listitem><para><emphasis>XPT_CALC_GEOMETRY</emphasis> - calculate logical - (BIOS) geometry of the disk</para> - - <para>The arguments are transferred in the instance "struct - ccb_calc_geometry ccg" of the union ccb:</para> - - <itemizedlist> - - <listitem><para><emphasis>block_size</emphasis> - input, block - (A.K.A sector) size in bytes</para></listitem> - - <listitem><para><emphasis>volume_size</emphasis> - input, - volume size in bytes</para></listitem> - - <listitem><para><emphasis>cylinders</emphasis> - output, - logical cylinders</para></listitem> - - <listitem><para><emphasis>heads</emphasis> - output, logical - heads</para></listitem> - - <listitem><para><emphasis>secs_per_track</emphasis> - output, - logical sectors per track</para></listitem> - - </itemizedlist> - - <para>If the returned geometry differs much enough from what the - SCSI controller BIOS thinks and a disk on this SCSI controller - is used as bootable the system may not be able to boot. The - typical calculation example taken from the aic7xxx driver - is:</para> - -<programlisting> struct ccb_calc_geometry *ccg; - u_int32_t size_mb; - u_int32_t secs_per_cylinder; - int extended; - - ccg = &ccb->ccg; - size_mb = ccg->volume_size - / ((1024L * 1024L) / ccg->block_size); - extended = check_cards_EEPROM_for_extended_geometry(softc); - - if (size_mb > 1024 && extended) { - ccg->heads = 255; - ccg->secs_per_track = 63; - } else { - ccg->heads = 64; - ccg->secs_per_track = 32; - } - secs_per_cylinder = ccg->heads * ccg->secs_per_track; - ccg->cylinders = ccg->volume_size / secs_per_cylinder; - ccb->ccb_h.status = CAM_REQ_CMP; - xpt_done(ccb); - return;</programlisting> - - <para>This gives the general idea, the exact calculation depends - on the quirks of the particular BIOS. If BIOS provides no way - set the "extended translation" flag in EEPROM this flag should - normally be assumed equal to 1. Other popular geometries - are:</para> - -<programlisting> 128 heads, 63 sectors - Symbios controllers - 16 heads, 63 sectors - old controllers</programlisting> - - <para>Some system BIOSes and SCSI BIOSes fight with each other - with variable success, for example a combination of Symbios - 875/895 SCSI and Phoenix BIOS can give geometry 128/63 after - power up and 255/63 after a hard reset or soft reboot.</para> - </listitem> - - <listitem><para><emphasis>XPT_PATH_INQ</emphasis> - path inquiry, in other - words get the SIM driver and SCSI controller (also known as HBA - - Host Bus Adapter) properties</para> - - <para>The properties are returned in the instance "struct -ccb_pathinq cpi" of the union ccb:</para> - - <itemizedlist> - - <listitem><para>version_num - the SIM driver version number, now - all drivers use 1</para></listitem> - - <listitem><para>hba_inquiry - bitmask of features supported by - the controller:</para></listitem> - - <listitem><para>PI_MDP_ABLE - supports MDP message (something - from SCSI3?)</para></listitem> - - <listitem><para>PI_WIDE_32 - supports 32 bit wide - SCSI</para></listitem> - - <listitem><para>PI_WIDE_16 - supports 16 bit wide - SCSI</para></listitem> - - <listitem><para>PI_SDTR_ABLE - can negotiate synchronous - transfer rate</para></listitem> - - <listitem><para>PI_LINKED_CDB - supports linked - commands</para></listitem> - - <listitem><para>PI_TAG_ABLE - supports tagged - commands</para></listitem> - - <listitem><para>PI_SOFT_RST - supports soft reset alternative - (hard reset and soft reset are mutually exclusive within a - SCSI bus)</para></listitem> - - <listitem><para>target_sprt - flags for target mode support, 0 - if unsupported</para></listitem> - - <listitem><para>hba_misc - miscellaneous controller - features:</para></listitem> - - <listitem><para>PIM_SCANHILO - bus scans from high ID to low - ID</para></listitem> - - <listitem><para>PIM_NOREMOVE - removable devices not included in - scan</para></listitem> - - <listitem><para>PIM_NOINITIATOR - initiator role not - supported</para></listitem> - - <listitem><para>PIM_NOBUSRESET - user has disabled initial BUS - RESET</para></listitem> - - <listitem><para>hba_eng_cnt - mysterious HBA engine count, - something related to compression, now is always set to - 0</para></listitem> - - <listitem><para>vuhba_flags - vendor-unique flags, unused - now</para></listitem> - - <listitem><para>max_target - maximal supported target ID (7 for - 8-bit bus, 15 for 16-bit bus, 127 for Fibre - Channel)</para></listitem> - - <listitem><para>max_lun - maximal supported LUN ID (7 for older - SCSI controllers, 63 for newer ones)</para></listitem> - - <listitem><para>async_flags - bitmask of installed Async - handler, unused now</para></listitem> - - <listitem><para>hpath_id - highest Path ID in the subsystem, - unused now</para></listitem> - - <listitem><para>unit_number - the controller unit number, - cam_sim_unit(sim)</para></listitem> - - <listitem><para>bus_id - the bus number, - cam_sim_bus(sim)</para></listitem> - - <listitem><para>initiator_id - the SCSI ID of the controller - itself</para></listitem> - - <listitem><para>base_transfer_speed - nominal transfer speed in - KB/s for asynchronous narrow transfers, equals to 3300 for - SCSI</para></listitem> - - <listitem><para>sim_vid - SIM driver's vendor id, a - zero-terminated string of maximal length SIM_IDLEN including - the terminating zero</para></listitem> - - <listitem><para>hba_vid - SCSI controller's vendor id, a - zero-terminated string of maximal length HBA_IDLEN including - the terminating zero</para></listitem> - - <listitem><para>dev_name - device driver name, a zero-terminated - string of maximal length DEV_IDLEN including the terminating - zero, equal to cam_sim_name(sim)</para></listitem> - - </itemizedlist> - - <para>The recommended way of setting the string fields is using - strncpy, like:</para> - -<programlisting> strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN);</programlisting> - - <para>After setting the values set the status to CAM_REQ_CMP and mark the -CCB as done.</para> - </listitem> - </itemizedlist> - - </sect1> - - <sect1> - <title>Polling</title> - - <funcSynopsis><funcPrototype> - <funcDef>static void - <function>xxx_poll</function> - </funcDef> - <paramdef> - <parameter>struct cam_sim *sim</parameter> - </paramdef> - </funcPrototype></funcSynopsis> - - <para>The poll function is used to simulate the interrupts when - the interrupt subsystem is not functioning (for example, when - the system has crashed and is creating the system dump). The CAM - subsystem sets the proper interrupt level before calling the - poll routine. So all it needs to do is to call the interrupt - routine (or the other way around, the poll routine may be doing - the real action and the interrupt routine would just call the - poll routine). Why bother about a separate function then ? - Because of different calling conventions. The - <function>xxx_poll</function> routine gets the struct cam_sim - pointer as its argument when the PCI interrupt routine by common - convention gets pointer to the struct - <structName>xxx_softc</structName> and the ISA interrupt routine - gets just the device unit number. So the poll routine would - normally look as:</para> - -<programlisting>static void -xxx_poll(struct cam_sim *sim) -{ - xxx_intr((struct xxx_softc *)cam_sim_softc(sim)); /* for PCI device */ -}</programlisting> - - <para>or</para> - -<programlisting>static void -xxx_poll(struct cam_sim *sim) -{ - xxx_intr(cam_sim_unit(sim)); /* for ISA device */ -}</programlisting> - - </sect1> - - <sect1> - <title>Asynchronous Events</title> - - <para>If an asynchronous event callback has been set up then the - callback function should be defined.</para> - -<programlisting>static void -ahc_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg)</programlisting> - - <itemizedlist> - <listitem><para>callback_arg - the value supplied when registering the - callback</para></listitem> - - <listitem><para>code - identifies the type of event</para></listitem> - - <listitem><para>path - identifies the devices to which the event - applies</para></listitem> - - <listitem><para>arg - event-specific argument</para></listitem> - </itemizedlist> - - <para>Implementation for a single type of event, AC_LOST_DEVICE, - looks like:</para> - -<programlisting> struct xxx_softc *softc; - struct cam_sim *sim; - int targ; - struct ccb_trans_settings neg; - - sim = (struct cam_sim *)callback_arg; - softc = (struct xxx_softc *)cam_sim_softc(sim); - switch (code) { - case AC_LOST_DEVICE: - targ = xpt_path_target_id(path); - if(targ <= OUR_MAX_SUPPORTED_TARGET) { - clean_negotiations(softc, targ); - /* send indication to CAM */ - neg.bus_width = 8; - neg.sync_period = neg.sync_offset = 0; - neg.valid = (CCB_TRANS_BUS_WIDTH_VALID - | CCB_TRANS_SYNC_RATE_VALID | CCB_TRANS_SYNC_OFFSET_VALID); - xpt_async(AC_TRANSFER_NEG, path, &neg); - } - break; - default: - break; - }</programlisting> - - </sect1> - - <sect1> - <title>Interrupts</title> - - <para>The exact type of the interrupt routine depends on the type - of the peripheral bus (PCI, ISA and so on) to which the SCSI - controller is connected.</para> - - <para>The interrupt routines of the SIM drivers run at the - interrupt level splcam. So <function>splcam()</function> should - be used in the driver to synchronize activity between the - interrupt routine and the rest of the driver (for a - multiprocessor-aware driver things get yet more interesting but - we ignore this case here). The pseudo-code in this document - happily ignores the problems of synchronization. The real code - must not ignore them. A simple-minded approach is to set - <function>splcam()</function> on the entry to the other routines - and reset it on return thus protecting them by one big critical - section. To make sure that the interrupt level will be always - restored a wrapper function can be defined, like:</para> - -<programlisting> static void - xxx_action(struct cam_sim *sim, union ccb *ccb) - { - int s; - s = splcam(); - xxx_action1(sim, ccb); - splx(s); - } - - static void - xxx_action1(struct cam_sim *sim, union ccb *ccb) - { - ... process the request ... - }</programlisting> - - <para>This approach is simple and robust but the problem with it - is that interrupts may get blocked for a relatively long time - and this would negatively affect the system's performance. On - the other hand the functions of the <function>spl()</function> - family have rather high overhead, so vast amount of tiny - critical sections may not be good either.</para> - - <para>The conditions handled by the interrupt routine and the - details depend very much on the hardware. We consider the set of - "typical" conditions.</para> - - <para>First, we check if a SCSI reset was encountered on the bus - (probably caused by another SCSI controller on the same SCSI - bus). If so we drop all the enqueued and disconnected requests, - report the events and re-initialize our SCSI controller. It is - important that during this initialization the controller won't - issue another reset or else two controllers on the same SCSI bus - could ping-pong resets forever. The case of fatal controller - error/hang could be handled in the same place, but it will - probably need also sending RESET signal to the SCSI bus to reset - the status of the connections with the SCSI devices.</para> - -<programlisting> int fatal=0; - struct ccb_trans_settings neg; - struct cam_path *path; - - if( detected_scsi_reset(softc) - || (fatal = detected_fatal_controller_error(softc)) ) { - int targ, lun; - struct xxx_hcb *h, *hh; - - /* drop all enqueued CCBs */ - for(h = softc->first_queued_hcb; h != NULL; h = hh) { - hh = h->next; - free_hcb_and_ccb_done(h, h->ccb, CAM_SCSI_BUS_RESET); - } - - /* the clean values of negotiations to report */ - neg.bus_width = 8; - neg.sync_period = neg.sync_offset = 0; - neg.valid = (CCB_TRANS_BUS_WIDTH_VALID - | CCB_TRANS_SYNC_RATE_VALID | CCB_TRANS_SYNC_OFFSET_VALID); - - /* drop all disconnected CCBs and clean negotiations */ - for(targ=0; targ <= OUR_MAX_SUPPORTED_TARGET; targ++) { - clean_negotiations(softc, targ); - - /* report the event if possible */ - if(xpt_create_path(&path, /*periph*/NULL, - cam_sim_path(sim), targ, - CAM_LUN_WILDCARD) == CAM_REQ_CMP) { - xpt_async(AC_TRANSFER_NEG, path, &neg); - xpt_free_path(path); - } - - for(lun=0; lun <= OUR_MAX_SUPPORTED_LUN; lun++) - for(h = softc->first_discon_hcb[targ][lun]; h != NULL; h = hh) { - hh=h->next; - if(fatal) - free_hcb_and_ccb_done(h, h->ccb, CAM_UNREC_HBA_ERROR); - else - free_hcb_and_ccb_done(h, h->ccb, CAM_SCSI_BUS_RESET); - } - } - - /* report the event */ - xpt_async(AC_BUS_RESET, softc->wpath, NULL); - - /* re-initialization may take a lot of time, in such case - * its completion should be signaled by another interrupt or - * checked on timeout - but for simplicity we assume here that - * it's really fast - */ - if(!fatal) { - reinitialize_controller_without_scsi_reset(softc); - } else { - reinitialize_controller_with_scsi_reset(softc); - } - schedule_next_hcb(softc); - return; - }</programlisting> - - <para>If interrupt is not caused by a controller-wide condition - then probably something has happened to the current hardware - control block. Depending on the hardware there may be other - non-HCB-related events, we just do not consider them here. Then - we analyze what happened to this HCB:</para> - -<programlisting> struct xxx_hcb *hcb, *h, *hh; - int hcb_status, scsi_status; - int ccb_status; - int targ; - int lun_to_freeze; - - hcb = get_current_hcb(softc); - if(hcb == NULL) { - /* either stray interrupt or something went very wrong - * or this is something hardware-dependent - */ - handle as necessary; - return; - } - - targ = hcb->target; - hcb_status = get_status_of_current_hcb(softc);</programlisting> - - <para>First we check if the HCB has completed and if so we check - the returned SCSI status.</para> - -<programlisting> if(hcb_status == COMPLETED) { - scsi_status = get_completion_status(hcb);</programlisting> - - <para>Then look if this status is related to the REQUEST SENSE - command and if so handle it in a simple way.</para> - -<programlisting> if(hcb->flags & DOING_AUTOSENSE) { - if(scsi_status == GOOD) { /* autosense was successful */ - hcb->ccb->ccb_h.status |= CAM_AUTOSNS_VALID; - free_hcb_and_ccb_done(hcb, hcb->ccb, CAM_SCSI_STATUS_ERROR); - } else { - autosense_failed: - free_hcb_and_ccb_done(hcb, hcb->ccb, CAM_AUTOSENSE_FAIL); - } - schedule_next_hcb(softc); - return; - }</programlisting> - - <para>Else the command itself has completed, pay more attention to - details. If auto-sense is not disabled for this CCB and the - command has failed with sense data then run REQUEST SENSE - command to receive that data.</para> - -<programlisting> hcb->ccb->csio.scsi_status = scsi_status; - calculate_residue(hcb); - - if( (hcb->ccb->ccb_h.flags & CAM_DIS_AUTOSENSE)==0 - && ( scsi_status == CHECK_CONDITION - || scsi_status == COMMAND_TERMINATED) ) { - /* start auto-SENSE */ - hcb->flags |= DOING_AUTOSENSE; - setup_autosense_command_in_hcb(hcb); - restart_current_hcb(softc); - return; - } - if(scsi_status == GOOD) - free_hcb_and_ccb_done(hcb, hcb->ccb, CAM_REQ_CMP); - else - free_hcb_and_ccb_done(hcb, hcb->ccb, CAM_SCSI_STATUS_ERROR); - schedule_next_hcb(softc); - return; - }</programlisting> - - <para>One typical thing would be negotiation events: negotiation - messages received from a SCSI target (in answer to our - negotiation attempt or by target's initiative) or the target is - unable to negotiate (rejects our negotiation messages or does - not answer them).</para> - -<programlisting> switch(hcb_status) { - case TARGET_REJECTED_WIDE_NEG: - /* revert to 8-bit bus */ - softc->current_bus_width[targ] = softc->goal_bus_width[targ] = 8; - /* report the event */ - neg.bus_width = 8; - neg.valid = CCB_TRANS_BUS_WIDTH_VALID; - xpt_async(AC_TRANSFER_NEG, hcb->ccb.ccb_h.path_id, &neg); - continue_current_hcb(softc); - return; - case TARGET_ANSWERED_WIDE_NEG: - { - int wd; - - wd = get_target_bus_width_request(softc); - if(wd <= softc->goal_bus_width[targ]) { - /* answer is acceptable */ - softc->current_bus_width[targ] = - softc->goal_bus_width[targ] = neg.bus_width = wd; - - /* report the event */ - neg.valid = CCB_TRANS_BUS_WIDTH_VALID; - xpt_async(AC_TRANSFER_NEG, hcb->ccb.ccb_h.path_id, &neg); - } else { - prepare_reject_message(hcb); - } - } - continue_current_hcb(softc); - return; - case TARGET_REQUESTED_WIDE_NEG: - { - int wd; - - wd = get_target_bus_width_request(softc); - wd = min (wd, OUR_BUS_WIDTH); - wd = min (wd, softc->user_bus_width[targ]); - - if(wd != softc->current_bus_width[targ]) { - /* the bus width has changed */ - softc->current_bus_width[targ] = - softc->goal_bus_width[targ] = neg.bus_width = wd; - - /* report the event */ - neg.valid = CCB_TRANS_BUS_WIDTH_VALID; - xpt_async(AC_TRANSFER_NEG, hcb->ccb.ccb_h.path_id, &neg); - } - prepare_width_nego_rsponse(hcb, wd); - } - continue_current_hcb(softc); - return; - }</programlisting> - - <para>Then we handle any errors that could have happened during - auto-sense in the same simple-minded way as before. Otherwise we - look closer at the details again.</para> - -<programlisting> if(hcb->flags & DOING_AUTOSENSE) - goto autosense_failed; - - switch(hcb_status) {</programlisting> - - <para>The next event we consider is unexpected disconnect. Which - is considered normal after an ABORT or BUS DEVICE RESET message - and abnormal in other cases.</para> - -<programlisting> case UNEXPECTED_DISCONNECT: - if(requested_abort(hcb)) { - /* abort affects all commands on that target+LUN, so - * mark all disconnected HCBs on that target+LUN as aborted too - */ - for(h = softc->first_discon_hcb[hcb->target][hcb->lun]; - h != NULL; h = hh) { - hh=h->next; - free_hcb_and_ccb_done(h, h->ccb, CAM_REQ_ABORTED); - } - ccb_status = CAM_REQ_ABORTED; - } else if(requested_bus_device_reset(hcb)) { - int lun; - - /* reset affects all commands on that target, so - * mark all disconnected HCBs on that target+LUN as reset - */ - - for(lun=0; lun <= OUR_MAX_SUPPORTED_LUN; lun++) - for(h = softc->first_discon_hcb[hcb->target][lun]; - h != NULL; h = hh) { - hh=h->next; - free_hcb_and_ccb_done(h, h->ccb, CAM_SCSI_BUS_RESET); - } - - /* send event */ - xpt_async(AC_SENT_BDR, hcb->ccb->ccb_h.path_id, NULL); - - /* this was the CAM_RESET_DEV request itself, it's completed */ - ccb_status = CAM_REQ_CMP; - } else { - calculate_residue(hcb); - ccb_status = CAM_UNEXP_BUSFREE; - /* request the further code to freeze the queue */ - hcb->ccb->ccb_h.status |= CAM_DEV_QFRZN; - lun_to_freeze = hcb->lun; - } - break;</programlisting> - - <para>If the target refuses to accept tags we notify CAM about - that and return back all commands for this LUN:</para> - -<programlisting> case TAGS_REJECTED: - /* report the event */ - neg.flags = 0 & ~CCB_TRANS_TAG_ENB; - neg.valid = CCB_TRANS_TQ_VALID; - xpt_async(AC_TRANSFER_NEG, hcb->ccb.ccb_h.path_id, &neg); - - ccb_status = CAM_MSG_REJECT_REC; - /* request the further code to freeze the queue */ - hcb->ccb->ccb_h.status |= CAM_DEV_QFRZN; - lun_to_freeze = hcb->lun; - break;</programlisting> - - <para>Then we check a number of other conditions, with processing - basically limited to setting the CCB status:</para> - -<programlisting> case SELECTION_TIMEOUT: - ccb_status = CAM_SEL_TIMEOUT; - /* request the further code to freeze the queue */ - hcb->ccb->ccb_h.status |= CAM_DEV_QFRZN; - lun_to_freeze = CAM_LUN_WILDCARD; - break; - case PARITY_ERROR: - ccb_status = CAM_UNCOR_PARITY; - break; - case DATA_OVERRUN: - case ODD_WIDE_TRANSFER: - ccb_status = CAM_DATA_RUN_ERR; - break; - default: - /* all other errors are handled in a generic way */ - ccb_status = CAM_REQ_CMP_ERR; - /* request the further code to freeze the queue */ - hcb->ccb->ccb_h.status |= CAM_DEV_QFRZN; - lun_to_freeze = CAM_LUN_WILDCARD; - break; - }</programlisting> - - <para>Then we check if the error was serious enough to freeze the - input queue until it gets proceeded and do so if it is:</para> - -<programlisting> if(hcb->ccb->ccb_h.status & CAM_DEV_QFRZN) { - /* freeze the queue */ - xpt_freeze_devq(ccb->ccb_h.path, /*count*/1); - - /* re-queue all commands for this target/LUN back to CAM */ - - for(h = softc->first_queued_hcb; h != NULL; h = hh) { - hh = h->next; - - if(targ == h->targ - && (lun_to_freeze == CAM_LUN_WILDCARD || lun_to_freeze == h->lun) ) - free_hcb_and_ccb_done(h, h->ccb, CAM_REQUEUE_REQ); - } - } - free_hcb_and_ccb_done(hcb, hcb->ccb, ccb_status); - schedule_next_hcb(softc); - return;</programlisting> - - <para>This concludes the generic interrupt handling although - specific controllers may require some additions.</para> - - </sect1> - - <sect1> - <title>Errors Summary</title> - - <para>When executing an I/O request many things may go wrong. The - reason of error can be reported in the CCB status with great - detail. Examples of use are spread throughout this document. For - completeness here is the summary of recommended responses for - the typical error conditions:</para> - - <itemizedlist> - - <listitem><para><emphasis>CAM_RESRC_UNAVAIL</emphasis> - some - resource is temporarily unavailable and the SIM driver cannot - generate an event when it will become available. An example of - this resource would be some intra-controller hardware resource - for which the controller does not generate an interrupt when - it becomes available.</para></listitem> - - <listitem><para><emphasis>CAM_UNCOR_PARITY</emphasis> - - unrecovered parity error occurred</para></listitem> - - <listitem><para><emphasis>CAM_DATA_RUN_ERR</emphasis> - data - overrun or unexpected data phase (going in other direction - than specified in CAM_DIR_MASK) or odd transfer length for - wide transfer</para></listitem> - - <listitem><para><emphasis>CAM_SEL_TIMEOUT</emphasis> - selection - timeout occurred (target does not respond)</para></listitem> - - <listitem><para><emphasis>CAM_CMD_TIMEOUT</emphasis> - command - timeout occurred (the timeout function ran)</para></listitem> - - <listitem><para><emphasis>CAM_SCSI_STATUS_ERROR</emphasis> - the - device returned error</para></listitem> - - <listitem><para><emphasis>CAM_AUTOSENSE_FAIL</emphasis> - the - device returned error and the REQUEST SENSE COMMAND - failed</para></listitem> - - <listitem><para><emphasis>CAM_MSG_REJECT_REC</emphasis> - MESSAGE - REJECT message was received</para></listitem> - - <listitem><para><emphasis>CAM_SCSI_BUS_RESET</emphasis> - received - SCSI bus reset</para></listitem> - - <listitem><para><emphasis>CAM_REQ_CMP_ERR</emphasis> - - "impossible" SCSI phase occurred or something else as weird or - just a generic error if further detail is not - available</para></listitem> - - <listitem><para><emphasis>CAM_UNEXP_BUSFREE</emphasis> - - unexpected disconnect occurred</para></listitem> - - <listitem><para><emphasis>CAM_BDR_SENT</emphasis> - BUS DEVICE - RESET message was sent to the target</para></listitem> - - <listitem><para><emphasis>CAM_UNREC_HBA_ERROR</emphasis> - - unrecoverable Host Bus Adapter Error</para></listitem> - - <listitem><para><emphasis>CAM_REQ_TOO_BIG</emphasis> - the request - was too large for this controller</para></listitem> - - <listitem><para><emphasis>CAM_REQUEUE_REQ</emphasis> - this - request should be re-queued to preserve transaction ordering. - This typically occurs when the SIM recognizes an error that - should freeze the queue and must place other queued requests - for the target at the sim level back into the XPT - queue. Typical cases of such errors are selection timeouts, - command timeouts and other like conditions. In such cases the - troublesome command returns the status indicating the error, - the and the other commands which have not be sent to the bus - yet get re-queued.</para></listitem> - - <listitem><para><emphasis>CAM_LUN_INVALID</emphasis> - the LUN - ID in the request is not supported by the SCSI - controller</para></listitem> - - <listitem><para><emphasis>CAM_TID_INVALID</emphasis> - the - target ID in the request is not supported by the SCSI - controller</para></listitem> - </itemizedlist> - </sect1> - - <sect1> - <title>Timeout Handling</title> - - <para>When the timeout for an HCB expires that request should be - aborted, just like with an XPT_ABORT request. The only - difference is that the returned status of aborted request should - be CAM_CMD_TIMEOUT instead of CAM_REQ_ABORTED (that's why - implementation of the abort better be done as a function). But - there is one more possible problem: what if the abort request - itself will get stuck? In this case the SCSI bus should be - reset, just like with an XPT_RESET_BUS request (and the idea - about implementing it as a function called from both places - applies here too). Also we should reset the whole SCSI bus if a - device reset request got stuck. So after all the timeout - function would look like:</para> - -<programlisting>static void -xxx_timeout(void *arg) -{ - struct xxx_hcb *hcb = (struct xxx_hcb *)arg; - struct xxx_softc *softc; - struct ccb_hdr *ccb_h; - - softc = hcb->softc; - ccb_h = &hcb->ccb->ccb_h; - - if(hcb->flags & HCB_BEING_ABORTED - || ccb_h->func_code == XPT_RESET_DEV) { - xxx_reset_bus(softc); - } else { - xxx_abort_ccb(hcb->ccb, CAM_CMD_TIMEOUT); - } -}</programlisting> - - <para>When we abort a request all the other disconnected requests - to the same target/LUN get aborted too. So there appears a - question, should we return them with status CAM_REQ_ABORTED or - CAM_CMD_TIMEOUT ? The current drivers use CAM_CMD_TIMEOUT. This - seems logical because if one request got timed out then probably - something really bad is happening to the device, so if they - would not be disturbed they would time out by themselves.</para> - - </sect1> - -</chapter> diff --git a/en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml deleted file mode 100644 index 468e739d12..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml +++ /dev/null @@ -1,161 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: $ ---> - -<chapter id="sysinit"> - <title>The Sysinit Framework</title> - - <para>Sysinit is the framework for a generic call sort and dispatch - mechanisim. FreeBSD currently uses it for the dynamic - initialization of the kernel. Sysinit allows FreeBSD's kernel - subsystems to be reordered, and added, removed, and replaced at - kernel link time when the kernel or one of its modules is loaded - without having to edit a staticly ordered initilization routing - and recompile the kernel. This system also allows kernel modules, - currently called <firstterm>KLD's</firstterm>, to be seperatly - compiled, linked, and initilized at boot time and loaded even - later while the system is already running. This is accomplished - using the <quote>kernel linker</quote> and <quote>linker - sets</quote>.</para> - - <sect1> - <title>Terminology</title> - - <variablelist> - <varlistentry> - <term>Linker Set</term> - <listitem> - <para>A linker technique in which the linker gathers - staticly declared data throughout a program's source files - into a single contagiously addressable unit of - data.</para> - </listitem> - </varlistentry> - </variablelist> - </sect1> - - <sect1> - <title>Sysinit Operation</title> - - <para>Sysinit relies on the ability of the linker to take static - data declared at multiple locations throughout a program's - source and group it together as a single contagious chunk of - data. This linker technique is called a <quote>linker - set</quote>. Sysinit uses two linker sets to maintain two data - sets containing each consumer's call order, function, and a - pointer to the data to pass to taht function.</para> - - <para>Sysinit uses two priorites when ordering the functions for - execution. The first priority is a subsystem ID giving an - overall order Sysinit's dispatch of funtions. Current predeclard - ID's are in <filename><sys/kernel.h></filename> in the enum - list <literal>sysinit_sub_id</literal>. The second priority used - is an element order within the subsystem. Current predeclard - subsystem element orders are in - <filename><sys/kernel.h></filename> in the enum list - <literal>sysinit_elem_order</literal>.</para> - - <para>There are currently two uses for Sysinit. Function dispatch - at system startup and kernel module loads, and function dispatch - at system shutdown and kernel module unload.</para> - </sect1> - - - <sect1> - <title>Using Sysinit</title> - - <sect2> - <title>Interface</title> - - <sect3> - <title>Headers</title> - - <programlisting><sys/kernel.h></programlisting> - </sect3> - - <sect3> - <title>Macros</title> - - <programlisting>SYSINIT(uniquifier, subsystem, order, func, ident) - SYSUNINIT(uniquifier, subsystem, order, func, ident)</programlisting> - </sect3> - </sect2> - - <sect2> - <title>Startup</title> - - <para>The <literal>SYSINIT()</literal> macro creates the - necessary sysinit data in Sysinit's startup data set for - Sysinit to sort and dispatch a function at system startup and - module load. <literal>SYSINIT()</literal> takes a uniquifier - that Sysinit uses identify the particular function dispatch - data, the subsystem order, the subsystem element order, the - function to call, and the data to pass the fuction. All - functions must take a constant pointer argument. - </para> - - <para>For example:</para> - - <programlisting>#include <sys/kernel.h> - -void foo_null(void *unused) -{ - foo_doo(); -} -SYSINIT(foo_null, SI_SUB_FOO, SI_ORDER_FOO, NULL); - -struct foo foo_voodoo = { - FOO_VOODOO; -} - -void foo_arg(void *vdata) -{ - struct foo *foo = (struct foo *)vdata; - foo_data(foo); -} -SYSINIT(foo_arg, SI_SUB_FOO, SI_ORDER_FOO, foo_voodoo); - </programlisting> - </sect2> - - <sect2> - <title>Shutdown</title> - - <para>The <literal>SYSUNINIT()</literal> macro behaves similarly - to the <literal>SYSINIT()</literal> macro except that it adds - the Sysinit data to Sysinit's shutdown data set.</para> - - <para>For example:</para> - - <programlisting>#include <sys/kernel.h> - -void foo_cleanup(void *unused) -{ - foo_kill(); -} -SYSUNINIT(foo_cleanup, SI_SUB_FOO, SI_ORDER_FOO, NULL); - -struct foo_stack foo_stack = { - FOO_STACK_VOODOO; -} - -void foo_flush(void *vdata) -{ -} -SYSUNINIT(foo_flush, SI_SUB_FOO, SI_ORDER_FOO, foo_stack); - </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/usb/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/usb/chapter.sgml deleted file mode 100644 index 9656256e31..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/usb/chapter.sgml +++ /dev/null @@ -1,623 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD$ ---> - -<chapter id="usb"> - <title>USB Devices</title> - - <para><emphasis>This chapter was written by &a.nhibma;. Modifications made for - the handbook by &a.murray;.</emphasis></para> - - <sect1> - <title>Introduction</title> - - <para>The Universal Serial Bus (USB) is a new way of attaching - devices to personal computers. The bus architecture features - two-way communication and has been developed as a response to - devices becoming smarter and requiring more interaction with the - host. USB support is included in all current PC chipsets and is - therefore available in all recently built PCs. Apple's - introduction of the USB-only iMac has been a major incentive for - hardware manufacturers to produce USB versions of their devices. - The future PC specifications specify that all legacy connectors - on PCs should be replaced by one or more USB connectors, - providing generic plug and play capabilities. Support for USB - hardware was available at a very early stage in NetBSD and was - developed by Lennart Augustsson for the NetBSD project. The - code has been ported to FreeBSD and we are currently maintaining - a shared code base. For the implementation of the USB subsystem - a number of features of USB are important.</para> - - <para><emphasis>Lennart Augustsson has done most of the implementation of - the USB support for the NetBSD project. Many thanks for this - incredible amount of work. Many thanks also to Ardy and Dirk for - their comments and proofreading of this paper.</emphasis></para> - - <itemizedlist> - - <listitem><para>Devices connect to ports on the computer - directly or on devices called hubs, forming a treelike device - structure.</para></listitem> - - <listitem><para>The devices can be connected and disconnected at - run time.</para></listitem> - - <listitem><para>Devices can suspend themselves and trigger - resumes of the host system</para></listitem> - - <listitem><para>As the devices can be powered from the bus, the - host software has to keep track of power budgets for each - hub.</para></listitem> - - <listitem><para>Different quality of service requirements by the - different device types together with the maximum of 126 - devices that can be connected to the same bus, require proper - scheduling of transfers on the shared bus to take full - advantage of the 12Mbps bandwidth available. (over 400Mbps - with USB 2.0)</para></listitem> - - <listitem><para>Devices are intelligent and contain easily - accessible information about themselves</para></listitem> - - </itemizedlist> - - <para>The development of drivers for the USB subsystem and devices - connected to it is supported by the specifications that have - been developed and will be developed. These specifications are - publicly available from the USB home pages. Apple has been very - strong in pushing for standards based drivers, by making drivers - for the generic classes available in their operating system - MacOS and discouraging the use of separate drivers for each new - device. This chapter tries to collate essential information for a - basic understanding of the present implementation of the USB - stack in FreeBSD/NetBSD. It is recommended however to read it - together with the relevant specifications mentioned in the - references below.</para> - - <sect2> - <title>Structure of the USB Stack</title> - - <para>The USB support in FreeBSD can be split into three - layers. The lowest layer contains the host controller driver, - providing a generic interface to the hardware and its scheduling - facilities. It supports initialisation of the hardware, - scheduling of transfers and handling of completed and/or failed - transfers. Each host controller driver implements a virtual hub - providing hardware independent access to the registers - controlling the root ports on the back of the machine.</para> - - <para>The middle layer handles the device connection and - disconnection, basic initialisation of the device, driver - selection, the communication channels (pipes) and does - resource management. This services layer also controls the - default pipes and the device requests transferred over - them.</para> - - <para>The top layer contains the individual drivers supporting - specific (classes of) devices. These drivers implement the - protocol that is used over the pipes other than the default - pipe. They also implement additional functionality to make the - device available to other parts of the kernel oruserland. They - use the USB driver interface (USBDI) exposed by the services - layer.</para> - </sect2> - </sect1> - - <sect1 id="usb-hc"> - <title>Host Controllers</title> - - <para>The host controller (HC) controls the transmission of - packets on the bus. Frames of 1 millisecond are used. At the - start of each frame the host controller generates a Start of - Frame (SOF) packet.</para> - - <para>The SOF packet is used to synchronise to the start of the - frame and to keep track of the frame number. Within each frame - packets are transferred, either from host to device (out) or - from device to host (in). Transfers are always initiated by the - host (polled transfers). Therefore there can only be one host - per USB bus. Each transfer of a packet has a status stage in - which the recipient of the data can return either ACK - (acknowledge reception), NAK (retry), STALL (error condition) or - nothing (garbled data stage, device not available or - disconnected). Section 8.5 of the <ulink - url="http://www.usb.org/developers/docs.html">USB - specification</ulink> explains the details of packets in more - detail. Four different types of transfers can occur on a USB - bus: control, bulk, interrupt and isochronous. The types of - transfers and their characteristics are described below (`Pipes' - subsection).</para> - - <para>Large transfers between the device on the USB bus and the - device driver are split up into multiple packets by the host - controller or the HC driver.</para> - - <para>Device requests (control transfers) to the default endpoints - are special. They consist of two or three phases: SETUP, DATA - (optional) and STATUS. The set-up packet is sent to the - device. If there is a data phase, the direction of the data - packet(s) is given in the set-up packet. The direction in the - status phase is the opposite of the direction during the data - phase, or IN if there was no data phase. The host controller - hardware also provides registers with the current status of the - root ports and the changes that have occurred since the last - reset of the status change register. Access to these registers - is provided through a virtualised hub as suggested in the USB - specification [ 2]. Thevirtual hub must comply with the hub - device class given in chapter 11 of that specification. It must - provide a default pipe through which device requests can be sent - to it. It returns the standard andhub class specific set of - descriptors. It should also provide an interrupt pipe that - reports changes happening at its ports. There are currently two - specifications for host controllers available: <ulink - url="http://developer.intel.com/design/USB/UHCI11D.htm">Universal - Host Controller Interface</ulink> (UHCI; Intel) and <ulink - url="http://www.compaq.com/productinfo/development/openhci.html">Open - Host Controller Interface</ulink> (OHCI; Compaq, Microsoft, - National Semiconductor). The UHCI specification has been - designed to reduce hardware complexity byrequiring the host - controller driver to supply a complete schedule of the transfers - for each frame. OHCI type controllers are much more independent - by providing a more abstract interface doing alot of work - themselves. </para> - - <sect2> - <title>UHCI</title> - - <para>The UHCI host controller maintains a framelist with 1024 - pointers to per frame data structures. It understands two - different data types: transfer descriptors (TD) and queue - heads (QH). Each TD represents a packet to be communicated to - or from a device endpoint. QHs are a means to groupTDs (and - QHs) together.</para> - - <para>Each transfer consists of one or more packets. The UHCI - driver splits large transfers into multiple packets. For every - transfer, apart from isochronous transfers, a QH is - allocated. For every type of transfer these QHs are collected - at a QH for that type. Isochronous transfers have to be - executed first because of the fixed latency requirement and - are directly referred to by the pointer in the framelist. The - last isochronous TD refers to the QH for interrupt transfers - for that frame. All QHs for interrupt transfers point at the - QH for control transfers, which in turn points at the QH for - bulk transfers. The following diagram gives a graphical - overview of this:</para> - - <para>This results in the following schedule being run in each - frame. After fetching the pointer for the current frame from - the framelist the controller first executes the TDs for all - the isochronous packets in that frame. The last of these TDs - refers to the QH for the interrupt transfers for - thatframe. The host controller will then descend from that QH - to the QHs for the individual interrupt transfers. After - finishing that queue, the QH for the interrupt transfers will - refer the controller to the QH for all control transfers. It - will execute all the subqueues scheduled there, followed by - all the transfers queued at the bulk QH. To facilitate the - handling of finished or failed transfers different types of - interrupts are generatedby the hardware at the end of each - frame. In the last TD for a transfer the Interrupt-On - Completion bit is set by the HC driver to flag an interrupt - when the transfer has completed. An error interrupt is flagged - if a TD reaches its maximum error count. If the short packet - detect bit is set in a TD and less than the set packet length - is transferred this interrupt is flagged to notify - the controller driver of the completed transfer. It is the host - controller driver's task to find out which transfer has - completed or produced an error. When called the interrupt - service routine will locate all the finished transfers and - call their callbacks.</para> - - <para>See for a more elaborate description the <ulink - url="http://developer.intel.com/design/USB/UHCI11D.htm">UHCI - specification.</ulink></para> - - </sect2> - - <sect2> - <title>OHCI</title> - - <para>Programming an OHCI host controller is much simpler. The - controller assumes that a set of endpoints is available, and - is aware of scheduling priorities and the ordering of the - types of transfers in a frame. The main data structure used by - the host controller is the endpoint descriptor (ED) to which - aqueue of transfer descriptors (TDs) is attached. The ED - contains the maximum packet size allowed for an endpoint and - the controller hardware does the splitting into packets. The - pointers to the data buffers are updated after each transfer - and when the start and end pointer are equal, the TD is - retired to the done-queue. The four types of endpoints have - their own queues. Control and bulk endpoints are queued each at - their own queue. Interrupt EDs are queued in a tree, with the - level in the tree defining the frequency at which they - run.</para> - - <para>framelist interruptisochronous control bulk</para> - - <para>The schedule being run by the host controller in each - frame looks as follows. The controller will first run the - non-periodic control and bulk queues, up to a time limit set - by the HC driver. Then the interrupt transfers for that frame - number are run, by using the lower five bits of the frame - number as an index into level 0 of the tree of interrupts - EDs. At the end of this tree the isochronous EDs are connected - and these are traversed subsequently. The isochronous TDs - contain the frame number of the first frame the transfer - should be run in. After all the periodic transfers have been - run, the control and bulk queues are traversed - again. Periodically the interrupt service routine is called to - process the done queue and call the callbacks for each - transfer and reschedule interrupt and isochronous - endpoints.</para> - - <para>See for a more elaborate description the <ulink - url="http://www.compaq.com/productinfo/development/openhci.html"> - OHCI specification</ulink>. Services layer The middle layer - provides access to the device in a controlled way and - maintains resources inuse by the different drivers and the - services layer. The layer takes care of the following - aspects:</para> - - <itemizedlist> - <listitem><para>The device configuration - information</para></listitem> - <listitem><para>The pipes to communicate with a - device</para></listitem> - <listitem><para>Probing and attaching and detaching form a - device.</para></listitem> - </itemizedlist> - - </sect2> - </sect1> - - <sect1 id="usb-dev"> - <title>USB Device Information</title> - - <sect2> - <title>Device configuration information</title> - - <para>Each device provides different levels of configuration - information. Each device has one or more configurations, of - which one is selected during probe/attach. A configuration - provides power and bandwidth requirements. Within each - configuration there can be multiple interfaces. A device - interface is a collection of endpoints. For example USB - speakers can have an interface for the audio data (Audio - Class) and an interface for the knobs, dials and buttons (HID - Class). All interfaces in a configuration areactive at the - same time and can be attached to by different drivers. Each - interface can have alternates, providing different quality of - service parameters. In for example cameras this is used to - provide different frame sizes and numbers of frames per - second.</para> - - <para>Within each interface 0 or more endpoints can be - specified. Endpoints are the unidirectional access points for - communicating with a device. They provide buffers to - temporarily store incoming or outgoing data from the - device. Each endpoint has a unique address within - a configuration, the endpoint's number plus its direction. The - default endpoint, endpoint 0, is not part of any interface and - available in all configurations. It is managed by the services - layer and not directly available to device drivers.</para> - - <para>Level 0 Level 1 Level 2 Slot 0</para> - <para>Slot 3 Slot 2 Slot 1</para> - <para>(Only 4 out of 32 slots shown)</para> - - <para>This hierarchical configuration information is described - in the device by a standard set of descriptors (see section 9.6 - of the USB specification [ 2]). They can be requested through - the Get Descriptor Request. The services layer caches these - descriptors to avoid unnecessary transferson the USB - bus. Access to the descriptors is provided through function - calls.</para> - - <itemizedlist> - <listitem><para>Device descriptors: General information about - the device, like Vendor, Product and Revision Id, supported - device class, subclass and protocol if applicable, maximum - packet size for the default endpoint, etc.</para></listitem> - - <listitem><para>Configuration descriptors: The number of - interfaces in this configuration, suspend and resume - functionality supported and power - requirements.</para></listitem> - - <listitem><para>Interface descriptors: interface class, - subclass and protocol if applicable, number of alternate - settings for the interface and the number of - endpoints.</para></listitem> - - <listitem><para>Endpoint descriptors: Endpoint address, - direction and type, maximum packet size supported and - polling frequency if type is interrupt endpoint. There is no - descriptor for thedefault endpoint (endpoint 0) and it is - never counted in an interface descriptor.</para></listitem> - - <listitem><para>String descriptors: In the other descriptors - string indices are supplied for some fields.These can be - used to retrieve descriptive strings, possibly in multiple - languages.</para></listitem> - - </itemizedlist> - - <para>Class specifications can add their own descriptor types - that are available through the GetDescriptor Request.</para> - - <para>Pipes Communication to end points on a device flows - through so-called pipes. Drivers submit transfers to endpoints - to a pipe and provide a callback to be called on completion or - failure of the transfer (asynchronous transfers) or wait for - completion (synchronous transfer). Transfers to an endpoint - are serialised in the pipe. A transfer can either complete, - fail or time-out (if a time-out has been set). There are two - types of time-outs for transfers. Time-outs can happen due to - time-out on the USBbus (milliseconds). These time-outs are - seen as failures and can be due to disconnection of the - device. A second form of time-out is implemented in software - and is triggered when a transfer does not complete within a - specified amount of time (seconds). These are caused by a - device acknowledging negatively (NAK) the transferred - packets. The cause for this is the device not being ready to - receive data, buffer under- or overrun or protocol - errors.</para> - - <para>If a transfer over a pipe is larger than the maximum - packet size specified in the associated endpoint descriptor, - the host controller (OHCI) or the HC driver (UHCI) will split - the transfer into packets of maximum packet size, with the - last packet possibly smaller than the maximum - packetsize.</para> - - <para>Sometimes it is not a problem for a device to return less - data than requested. For example abulk-in-transfer to a modem - might request 200 bytes of data, but the modem has only 5 - bytes available at that time. The driver can set the short - packet (SPD) flag. It allows the host controller to accept a - packet even if the amount of data transferred is less than - requested. This flag is only valid for in-transfers, as the - amount of data to be sent to a device is always known - beforehand. If an unrecoverable error occurs in a device - during a transfer the pipe is stalled. Before any more data is - accepted or sent the driver needs to resolve the cause of the - stall and clear the endpoint stall condition through send the - clear endpoint halt device request over the default - pipe. The default endpoint should never stall.</para> - - <para>There are four different types of endpoints and - corresponding pipes: - Control pipe / default pipe: There is - one control pipe per device, connected to the default endpoint - (endpoint 0). The pipe carries the device requests and - associated data. The difference between transfers over the - default pipe and other pipes is that the protocol for - thetransfers is described in the USB specification [ 2]. These - requests are used to reset and configure the device. A basic - set of commands that must be supported by each device is - provided in chapter 9 of the USB specification [ 2]. The - commands supported on this pipe canbe extended by a device - class specification to support additional - functionality.</para> - - <itemizedlist> - <listitem><para>Bulk pipe: This is the USB equivalent to a raw - transmission medium.</para></listitem> - <listitem><para>Interrupt pipe: The host sends a request for - data to the device and if the device has nothing to send, it - will NAK the data packet. Interrupt transfers are scheduled - at a frequency specifiedwhen creating the - pipe.</para></listitem> - - <listitem><para>Isochronous pipe: These pipes are intended for - isochronous data, for example video oraudio streams, with - fixed latency, but no guaranteed delivery. Some support for - pipes of this type is available in the current - implementation. Packets in control, bulk and interrupt - transfers are retried if an error occurs during transmission - or the device acknowledges the packet negatively (NAK) due to - for example lack of buffer space to store the incoming - data. Isochronous packets are however not retried in case of - failed delivery or NAK of a packet as this might violate the - timing constraints.</para></listitem> - </itemizedlist> - - <para>The availability of the necessary bandwidth is calculated - during the creation of the pipe. Transfersare scheduled within - frames of 1 millisecond. The bandwidth allocation within a - frame is prescribed by the USB specification, section 5.6 [ - 2]. Isochronous and interrupt transfers areallowed to consume - up to 90% of the bandwidth within a frame. Packets for control - and bulk transfers are scheduled after all isochronous and - interrupt packets and will consume all the remaining - bandwidth.</para> - - <para>More information on scheduling of transfers and bandwidth - reclamation can be found in chapter 5of the USB specification - [ 2], section 1.3 of the UHCI specification [ 3] and section - 3.4.2 of the OHCI specification [4].</para> - - </sect2> - </sect1> - - <sect1 id="usb-devprobe"> - <title>Device probe and attach</title> - - <para>After the notification by the hub that a new device has been - connected, the service layer switcheson the port, providing the - device with 100 mA of current. At this point the device is in - its default state and listening to device address 0. The - services layer will proceed to retrieve the various descriptors - through the default pipe. After that it will send a Set Address - request to move the device away from the default device address - (address 0). Multiple device drivers might be able to support - the device. For example a modem driver might beable to support - an ISDN TA through the AT compatibility interface. A driver for - that specific model of the ISDN adapter might however be able to - provide much better support for this device. To support this - flexibility, the probes return priorities indicating their level - of support. Support for a specific revision of a product ranks - the highest and the generic driver the lowest priority. It might - also be that multiple drivers could attach to one device if - there are multiple interfaceswithin one configuration. Each - driver only needs to support a subset of the interfaces.</para> - - <para>The probing for a driver for a newly attached device checks - first for device specific drivers. If notfound, the probe code - iterates over all supported configurations until a driver - attaches in a configuration. To support devices with multiple - drivers on different interfaces, the probe iteratesover all - interfaces in a configuration that have not yet been claimed by - a driver. Configurations that exceed the power budget for the - hub are ignored. During attach the driver should initialise the - device to its proper state, but not reset it, as this will make - the device disconnect itself from the bus and restart the - probing process for it. To avoid consuming unnecessary bandwidth - should not claim the interrupt pipe at attach time, but - should postpone allocating the pipe until the file is opened and - the data is actually used. When the file is closed the pipe - should be closed again, eventhough the device might still be - attached.</para> - - <sect2> - <title>Device disconnect and detach</title> - - <para>A device driver should expect to receive errors during any - transaction with the device. The designof USB supports and - encourages the disconnection of devices at any point in - time. Drivers should make sure that they do the right thing - when the device disappears.</para> - - <para>Furthermore a device that has been disconnected and - reconnected will not be reattached at the same device - instance. This might change in the future when more devices - support serial numbers (see the device descriptor) or other - means of defining an identity for a device have been - developed.</para> - - <para>The disconnection of a device is signalled by a hub in the - interrupt packet delivered to the hub driver. The status - change information indicates which port has seen a connection - change. The device detach method for all device drivers for - the device connected on that port are called and the structures - cleaned up. If the port status indicates that in the mean time - a device has been connected to that port, the procedure for - probing and attaching the device will be started. A device - reset will produce a disconnect-connect sequence on the hub - and will be handled as described above.</para> - - </sect2> - </sect1> - - <sect1 id="usb-protocol"> - <title>USB Drivers Protocol Information</title> - - <para>The protocol used over pipes other than the default pipe is - undefined by the USB specification. Information on this can be - found from various sources. The most accurate source is the - developer's section on the USB home pages [ 1]. From these pages - a growing number of deviceclass specifications are - available. These specifications specify what a compliant device - should look like from a driver perspective, basic functionality - it needs to provide and the protocol that is to be used over the - communication channels. The USB specification [ 2] includes the - description of the Hub Class. A class specification for Human - Interface Devices (HID) has been created to cater for keyboards, - tablets, bar-code readers, buttons, knobs, switches, etc. A - third example is the class specification for mass storage - devices. For a full list of device classes see the developers - sectionon the USB home pages [ 1].</para> - - <para>For many devices the protocol information has not yet been - published however. Information on the protocol being used might - be available from the company making the device. Some companies - will require you to sign a Non -Disclosure Agreement (NDA) - before giving you the specifications. This in most cases - precludes making the driver open source.</para> - - <para>Another good source of information is the Linux driver - sources, as a number of companies have started to provide drivers - for Linux for their devices. It is always a good idea to contact - the authors of those drivers for their source of - information.</para> - - <para>Example: Human Interface Devices The specification for the - Human Interface Devices like keyboards, mice, tablets, buttons, - dials,etc. is referred to in other device class specifications - and is used in many devices.</para> - - <para>For example audio speakers provide endpoints to the digital - to analogue converters and possibly an extra pipe for a - microphone. They also provide a HID endpoint in a separate - interface for the buttons and dials on the front of the - device. The same is true for the monitor control class. It is - straightforward to build support for these interfaces through - the available kernel and userland libraries together with the - HID class driver or the generic driver. Another device that - serves as an example for interfaces within one configuration - driven by different device drivers is a cheap keyboard with - built-in legacy mouse port. To avoid having the cost of - including the hardware for a USB hub in the device, - manufacturers combined the mouse data received from the PS/2 port - on the back of the keyboard and the keypresses from the keyboard - into two separate interfaces in the same configuration. The - mouse and keyboard drivers each attach to the appropriate - interface and allocate the pipes to the two independent - endpoints.</para> - - <para>Example: Firmware download Many devices that have been - developed are based on a general purpose processor with - anadditional USB core added to it. Because the development of - drivers and firmware for USB devices is still very new, many - devices require the downloading of the firmware after they - have been connected.</para> - - <para>The procedure followed is straightforward. The device - identifies itself through a vendor and product Id. The first - driver probes and attaches to it and downloads the firmware into - it. After that the device soft resets itself and the driver is - detached. After a short pause the devicere announces its presence - on the bus. The device will have changed its - vendor/product/revision Id to reflect the fact that it has been - supplied with firmware and as a consequence a second driver will - probe it and attach to it.</para> - - <para>An example of these types of devices is the ActiveWire I/O - board, based on the EZ-USB chip. For this chip a generic firmware - downloader is available. The firmware downloaded into the - ActiveWire board changes the revision Id. It will then perform a - soft reset of the USB part of the EZ-USB chip to disconnect from - the USB bus and again reconnect.</para> - - <para>Example: Mass Storage Devices Support for mass storage - devices is mainly built around existing protocols. The Iomega - USB Zipdrive is based on the SCSI version of their drive. The - SCSI commands and status messages are wrapped in blocks and - transferred over the bulk pipes to and from the device, - emulating a SCSI controller over the USB wire. ATAPI and UFI - commands are supported in a similar fashion.</para> - - <para>The Mass Storage Specification supports 2 different types of - wrapping of the command block.The initial attempt was based on - sending the command and status through the default pipe and - using bulk transfers for the data to be moved between the host - and the device. Based on experience a second approach was - designed that was based on wrapping the command and status - blocks and sending them over the bulk out and in endpoint. The - specification specifies exactly what has to happen when and what - has to be done in case an error condition is encountered. The - biggest challenge when writing drivers for these devices is to - fit USB based protocol into theexisting support for mass storage - devices. CAM provides hooks to do this in a fairly straight - forward way. ATAPI is less simple as historically the IDE - interface has never had many different appearances.</para> - - <para>The support for the USB floppy from Y-E Data is again less - straightforward as a new command set has been designed.</para> - - </sect1> - -</chapter>
\ No newline at end of file diff --git a/en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml deleted file mode 100644 index 4710973d5f..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml +++ /dev/null @@ -1,255 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/usb/chapter.sgml,v 1.1 2001/04/13 09:05:13 murray Exp $ ---> - -<chapter id="vm"> - <title>Virtual Memory System</title> - - <sect1 id="internals-vm"> - <title>The FreeBSD VM System</title> - - <para><emphasis>Contributed by &a.dillon;. 6 Feb 1999</emphasis></para> - - <sect2> - <title>Management of physical - memory—<literal>vm_page_t</literal></title> - - <para>Physical memory is managed on a page-by-page basis through the - <literal>vm_page_t</literal> structure. Pages of physical memory are - categorized through the placement of their respective - <literal>vm_page_t</literal> structures on one of several paging - queues.</para> - - <para>A page can be in a wired, active, inactive, cache, or free state. - Except for the wired state, the page is typically placed in a doubly - link list queue representing the state that it is in. Wired pages - are not placed on any queue.</para> - - <para>FreeBSD implements a more involved paging queue for cached and - free pages in order to implement page coloring. Each of these states - involves multiple queues arranged according to the size of the - processor's L1 and L2 caches. When a new page needs to be allocated, - FreeBSD attempts to obtain one that is reasonably well aligned from - the point of view of the L1 and L2 caches relative to the VM object - the page is being allocated for.</para> - - <para>Additionally, a page may be held with a reference count or locked - with a busy count. The VM system also implements an <quote>ultimate - locked</quote> state for a page using the PG_BUSY bit in the page's - flags.</para> - - <para>In general terms, each of the paging queues operates in a LRU - fashion. A page is typically placed in a wired or active state - initially. When wired, the page is usually associated with a page - table somewhere. The VM system ages the page by scanning pages in a - more active paging queue (LRU) in order to move them to a less-active - paging queue. Pages that get moved into the cache are still - associated with a VM object but are candidates for immediate reuse. - Pages in the free queue are truly free. FreeBSD attempts to minimize - the number of pages in the free queue, but a certain minimum number of - truly free pages must be maintained in order to accommodate page - allocation at interrupt time.</para> - - <para>If a process attempts to access a page that does not exist in its - page table but does exist in one of the paging queues ( such as the - inactive or cache queues), a relatively inexpensive page reactivation - fault occurs which causes the page to be reactivated. If the page - does not exist in system memory at all, the process must block while - the page is brought in from disk.</para> - - <para>FreeBSD dynamically tunes its paging queues and attempts to - maintain reasonable ratios of pages in the various queues as well as - attempts to maintain a reasonable breakdown of clean v.s. dirty pages. - The amount of rebalancing that occurs depends on the system's memory - load. This rebalancing is implemented by the pageout daemon and - involves laundering dirty pages (syncing them with their backing - store), noticing when pages are activity referenced (resetting their - position in the LRU queues or moving them between queues), migrating - pages between queues when the queues are out of balance, and so forth. - FreeBSD's VM system is willing to take a reasonable number of - reactivation page faults to determine how active or how idle a page - actually is. This leads to better decisions being made as to when to - launder or swap-out a page.</para> - </sect2> - - <sect2> - <title>The unified buffer - cache—<literal>vm_object_t</literal></title> - - <para>FreeBSD implements the idea of a generic <quote>VM object</quote>. - VM objects can be associated with backing store of various - types—unbacked, swap-backed, physical device-backed, or - file-backed storage. Since the filesystem uses the same VM objects to - manage in-core data relating to files, the result is a unified buffer - cache.</para> - - <para>VM objects can be <emphasis>shadowed</emphasis>. That is, they - can be stacked on top of each other. For example, you might have a - swap-backed VM object stacked on top of a file-backed VM object in - order to implement a MAP_PRIVATE mmap()ing. This stacking is also - used to implement various sharing properties, including, - copy-on-write, for forked address spaces.</para> - - <para>It should be noted that a <literal>vm_page_t</literal> can only be - associated with one VM object at a time. The VM object shadowing - implements the perceived sharing of the same page across multiple - instances.</para> - </sect2> - - <sect2> - <title>Filesystem I/O—<literal>struct buf</literal></title> - - <para>vnode-backed VM objects, such as file-backed objects, generally - need to maintain their own clean/dirty info independent from the VM - system's idea of clean/dirty. For example, when the VM system decides - to synchronize a physical page to its backing store, the VM system - needs to mark the page clean before the page is actually written to - its backing s tore. Additionally, filesystems need to be able to map - portions of a file or file metadata into KVM in order to operate on - it.</para> - - <para>The entities used to manage this are known as filesystem buffers, - <literal>struct buf</literal>'s, and also known as - <literal>bp</literal>'s. When a filesystem needs to operate on a - portion of a VM object, it typically maps part of the object into a - struct buf and the maps the pages in the struct buf into KVM. In the - same manner, disk I/O is typically issued by mapping portions of - objects into buffer structures and then issuing the I/O on the buffer - structures. The underlying vm_page_t's are typically busied for the - duration of the I/O. Filesystem buffers also have their own notion of - being busy, which is useful to filesystem driver code which would - rather operate on filesystem buffers instead of hard VM pages.</para> - - <para>FreeBSD reserves a limited amount of KVM to hold mappings from - struct bufs, but it should be made clear that this KVM is used solely - to hold mappings and does not limit the ability to cache data. - Physical data caching is strictly a function of - <literal>vm_page_t</literal>'s, not filesystem buffers. However, - since filesystem buffers are used placehold I/O, they do inherently - limit the amount of concurrent I/O possible. As there are usually a - few thousand filesystem buffers available, this is not usually a - problem.</para> - </sect2> - - <sect2> - <title>Mapping Page Tables - vm_map_t, vm_entry_t</title> - - <para>FreeBSD separates the physical page table topology from the VM - system. All hard per-process page tables can be reconstructed on the - fly and are usually considered throwaway. Special page tables such as - those managing KVM are typically permanently preallocated. These page - tables are not throwaway.</para> - - <para>FreeBSD associates portions of vm_objects with address ranges in - virtual memory through <literal>vm_map_t</literal> and - <literal>vm_entry_t</literal> structures. Page tables are directly - synthesized from the - <literal>vm_map_t</literal>/<literal>vm_entry_t</literal>/ - <literal>vm_object_t</literal> hierarchy. Remember when I mentioned - that physical pages are only directly associated with a - <literal>vm_object</literal>. Well, that isn't quite true. - <literal>vm_page_t</literal>'s are also linked into page tables that - they are actively associated with. One <literal>vm_page_t</literal> - can be linked into several <emphasis>pmaps</emphasis>, as page tables - are called. However, the hierarchical association holds so all - references to the same page in the same object reference the same - <literal>vm_page_t</literal> and thus give us buffer cache unification - across the board.</para> - </sect2> - - <sect2> - <title>KVM Memory Mapping</title> - - <para>FreeBSD uses KVM to hold various kernel structures. The single - largest entity held in KVM is the filesystem buffer cache. That is, - mappings relating to <literal>struct buf</literal> entities.</para> - - <para>Unlike Linux, FreeBSD does NOT map all of physical memory into - KVM. This means that FreeBSD can handle memory configurations up to - 4G on 32 bit platforms. In fact, if the mmu were capable of it, - FreeBSD could theoretically handle memory configurations up to 8TB on - a 32 bit platform. However, since most 32 bit platforms are only - capable of mapping 4GB of ram, this is a moot point.</para> - - <para>KVM is managed through several mechanisms. The main mechanism - used to manage KVM is the <emphasis>zone allocator</emphasis>. The - zone allocator takes a chunk of KVM and splits it up into - constant-sized blocks of memory in order to allocate a specific type - of structure. You can use <command>vmstat -m</command> to get an - overview of current KVM utilization broken down by zone.</para> - </sect2> - - <sect2> - <title>Tuning the FreeBSD VM system</title> - - <para>A concerted effort has been made to make the FreeBSD kernel - dynamically tune itself. Typically you do not need to mess with - anything beyond the <literal>maxusers</literal> and - <literal>NMBCLUSTERS</literal> kernel config options. That is, kernel - compilation options specified in (typically) - <filename>/usr/src/sys/i386/conf/<replaceable>CONFIG_FILE</replaceable></filename>. - A description of all available kernel configuration options can be - found in <filename>/usr/src/sys/i386/conf/LINT</filename>.</para> - - <para>In a large system configuration you may wish to increase - <literal>maxusers</literal>. Values typically range from 10 to 128. - Note that raising <literal>maxusers</literal> too high can cause the - system to overflow available KVM resulting in unpredictable operation. - It is better to leave maxusers at some reasonable number and add other - options, such as <literal>NMBCLUSTERS</literal>, to increase specific - resources.</para> - - <para>If your system is going to use the network heavily, you may want - to increase <literal>NMBCLUSTERS</literal>. Typical values range from - 1024 to 4096.</para> - - <para>The <literal>NBUF</literal> parameter is also traditionally used - to scale the system. This parameter determines the amount of KVA the - system can use to map filesystem buffers for I/O. Note that this - parameter has nothing whatsoever to do with the unified buffer cache! - This parameter is dynamically tuned in 3.0-CURRENT and later kernels - and should generally not be adjusted manually. We recommend that you - <emphasis>not</emphasis> try to specify an <literal>NBUF</literal> - parameter. Let the system pick it. Too small a value can result in - extremely inefficient filesystem operation while too large a value can - starve the page queues by causing too many pages to become wired - down.</para> - - <para>By default, FreeBSD kernels are not optimized. You can set - debugging and optimization flags with the - <literal>makeoptions</literal> directive in the kernel configuration. - Note that you should not use <option>-g</option> unless you can - accommodate the large (typically 7 MB+) kernels that result.</para> - - <programlisting>makeoptions DEBUG="-g" -makeoptions COPTFLAGS="-O -pipe"</programlisting> - - <para>Sysctl provides a way to tune kernel parameters at run-time. You - typically do not need to mess with any of the sysctl variables, - especially the VM related ones.</para> - - <para>Run time VM and system tuning is relatively straightforward. - First, use softupdates on your UFS/FFS filesystems whenever possible. - <filename>/usr/src/contrib/sys/softupdates/README</filename> contains - instructions (and restrictions) on how to configure it up.</para> - - <para>Second, configure sufficient swap. You should have a swap - partition configured on each physical disk, up to four, even on your - <quote>work</quote> disks. You should have at least 2x the swap space - as you have main memory, and possibly even more if you do not have a - lot of memory. You should also size your swap partition based on the - maximum memory configuration you ever intend to put on the machine so - you do not have to repartition your disks later on. If you want to be - able to accommodate a crash dump, your first swap partition must be at - least as large as main memory and <filename>/var/crash</filename> must - have sufficient free space to hold the dump.</para> - - <para>NFS-based swap is perfectly acceptable on -4.x or later systems, - but you must be aware that the NFS server will take the brunt of the - paging load.</para> - </sect2> - </sect1> - -</chapter> diff --git a/en_US.ISO8859-1/books/handbook/basics/disk-layout.kil b/en_US.ISO8859-1/books/handbook/basics/disk-layout.kil Binary files differdeleted file mode 100644 index 85820c2878..0000000000 --- a/en_US.ISO8859-1/books/handbook/basics/disk-layout.kil +++ /dev/null diff --git a/en_US.ISO8859-1/books/handbook/book.sgml b/en_US.ISO8859-1/books/handbook/book.sgml index f07264b320..1ff7706f47 100644 --- a/en_US.ISO8859-1/books/handbook/book.sgml +++ b/en_US.ISO8859-1/books/handbook/book.sgml @@ -1,7 +1,7 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/book.sgml,v 1.110 2001/08/04 19:32:09 jim Exp $ + $FreeBSD: doc/en_US.ISO8859-1/books/handbook/book.sgml,v 1.114 2001/09/18 04:14:43 murray Exp $ --> <!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ @@ -18,13 +18,13 @@ <!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN"> %authors; <!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN"> %mailing-lists; -<!ENTITY % newsgroups SYSTEM "newsgroups.ent"> %newsgroups; +<!ENTITY % newsgroups PUBLIC "-//FreeBSD//ENTITIES DocBook Newsgroup Entities//EN"> %newsgroups; <!ENTITY % not.published "INCLUDE"> <!-- The currently released version of FreeBSD. This value is used to create some links on web sites and such, so do NOT change it until it's really release time --> -<!ENTITY rel.current CDATA "4.3"> +<!ENTITY rel.current CDATA "4.4"> <!ENTITY % chap.introduction "IGNORE"> <!ENTITY % chap.install "IGNORE"> @@ -46,7 +46,6 @@ <!ENTITY % chap.advanced-networking "IGNORE"> <!ENTITY % chap.mail "IGNORE"> <!ENTITY % chap.cutting-edge "IGNORE"> -<!ENTITY % chap.contrib "IGNORE"> <!ENTITY % chap.policies "IGNORE"> <!ENTITY % chap.kerneldebug "IGNORE"> <!ENTITY % chap.linuxemu "IGNORE"> @@ -169,7 +168,6 @@ <![ %chap.security; [ &chap.security; ]]> <![ %chap.printing; [ &chap.printing; ]]> <![ %chap.disks; [ &chap.disks; ]]> - <![ %chap.backups; [ &chap.backups; ]]> <![ %chap.l10n; [ &chap.l10n; ]]> <![ %chap.sound; [ &chap.sound; ]]> <![ %chap.serialcomms; [ &chap.serialcomms; ]]> @@ -177,7 +175,6 @@ <![ %chap.advanced-networking; [ &chap.advanced-networking; ]]> <![ %chap.mail; [ &chap.mail; ]]> <![ %chap.cutting-edge; [ &chap.cutting-edge; ]]> - <![ %chap.contrib; [ &chap.contrib; ]]> <![ %chap.policies; [ &chap.policies; ]]> <![ %chap.kerneldebug; [ &chap.kerneldebug; ]]> <![ %chap.linuxemu; [ &chap.linuxemu; ]]> diff --git a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml index c4b8b02501..0f8d1937b5 100644 --- a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml @@ -1,7 +1,7 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml,v 1.58 2001/08/14 23:02:37 logo Exp $ + $FreeBSD: doc/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml,v 1.59 2001/08/16 18:35:03 chern Exp $ --> <chapter id="introduction"> @@ -34,8 +34,8 @@ read about <link linkend="history">the history of FreeBSD</link>, or the <link linkend="relnotes">current release</link>. If you are interested in contributing something to the Project (code, - hardware, unmarked bills), see the <link - linkend="contrib">contributing to FreeBSD</link> section.</para> + hardware, unmarked bills), see the <ulink url=" + http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/article.html">Contributing to FreeBSD</ulink> article.</para> </sect1> <sect1 id="nutshell"> @@ -767,8 +767,9 @@ <para>Providing code is not the only way of contributing to the project; for a more complete list of things that need - doing, please refer to the <link linkend="contrib">how to - contribute</link> section in this handbook.</para> + doing, please refer to the <ulink + url="http://www.FreeBSD.org">FreeBSD Project web + site</ulink>.</para> </listitem> </varlistentry> </variablelist> diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml index c447e38c9c..3e320d91af 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,7 +1,7 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml,v 1.150 2001/09/02 11:16:16 murray Exp $ + $FreeBSD: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml,v 1.155 2001/09/18 12:54:12 dcs Exp $ --> <appendix id="mirrors"> @@ -51,7 +51,7 @@ <listitem> <address> <otheraddr>Daemon News</otheraddr> - <street>2680 Bayshore Parkway, Suite 307</street> + <street>2672 Bayshore Parkway, Suite 610</street> <city>Mountain View</city>, <state>CA</state> <postcode>94043</postcode> <country>USA</country> Phone: <phone>+1 650 694-4949</phone> @@ -83,7 +83,7 @@ <listitem> <address> <otheraddr>Cylogistics</otheraddr> - <street>2680 Bayshore Parkway, Suite 307</street> + <street>2672 Bayshore Parkway, Suite 610</street> <city>Mountain View</city>, <state>CA</state> <postcode>94043</postcode> <country>USA</country> Phone: <phone>+1 650 694-4949</phone> @@ -1116,6 +1116,15 @@ </varlistentry> <varlistentry> + <term>RELENG_4_4</term> + + <listitem> + <para>The release branch for FreeBSD-4.4, used only + for security advisories and other seriously critical fixes.</para> + </listitem> + </varlistentry> + + <varlistentry> <term>RELENG_4_3</term> <listitem> @@ -1150,6 +1159,14 @@ <variablelist> <varlistentry> + <term>RELENG_4_4_0_RELEASE</term> + + <listitem> + <para>FreeBSD 4.4.</para> + </listitem> + </varlistentry> + + <varlistentry> <term>RELENG_4_3_0_RELEASE</term> <listitem> @@ -1985,6 +2002,16 @@ </varlistentry> <varlistentry> + <term>tag=RELENG_4_4</term> + + <listitem> + <para>The release branch for FreeBSD-4.4, used only + for security advisories and other seriously critical + fixes.</para> + </listitem> + </varlistentry> + + <varlistentry> <term>tag=RELENG_4_3</term> <listitem> @@ -2018,6 +2045,14 @@ <variablelist> <varlistentry> + <term>tag=RELENG_4_4_0_RELEASE</term> + + <listitem> + <para>FreeBSD 4.4.</para> + </listitem> + </varlistentry> + + <varlistentry> <term>tag=RELENG_4_3_0_RELEASE</term> <listitem> @@ -3296,6 +3331,11 @@ doc/ja_JP.eucJP</screen> <para>cvsup3.br.FreeBSD.org (maintainer <email>camposr@matrix.com.br</email>)</para> </listitem> + + <listitem> + <para>cvsup4.br.FreeBSD.org (maintainer + <email>cvsup@tcoip.com.br</email>)</para> + </listitem> </itemizedlist> </listitem> </varlistentry> @@ -3821,7 +3861,7 @@ doc/ja_JP.eucJP</screen> <itemizedlist> <listitem> <para>cvsup1.FreeBSD.org (maintainer - <email>skynyrd@opus.cts.cwu.edu</email>), Washington + <email>cwt@networks.cwu.edu</email>), Washington state</para> </listitem> @@ -3846,6 +3886,11 @@ doc/ja_JP.eucJP</screen> </listitem> <listitem> + <para>cvsup6.FreeBSD.org (maintainer + <email>cvsup@cvsup.adelphiacom.net</email>), Illinois</para> + </listitem> + + <listitem> <para>cvsup7.FreeBSD.org (maintainer <email>jdp@FreeBSD.org</email>), Washington state</para> </listitem> diff --git a/en_US.ISO8859-1/books/handbook/multimedia/Makefile b/en_US.ISO8859-1/books/handbook/multimedia/Makefile deleted file mode 100644 index 0ea7f84352..0000000000 --- a/en_US.ISO8859-1/books/handbook/multimedia/Makefile +++ /dev/null @@ -1,15 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# - -CHAPTERS= sound/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml b/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml deleted file mode 100644 index 5ceb0bf41c..0000000000 --- a/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ /dev/null @@ -1,368 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/sound/chapter.sgml,v 1.15 2001/08/16 18:35:08 chern Exp $ ---> - -<chapter id="sound"> - <chapterinfo> - <authorgroup> - <author> - <firstname>Moses</firstname> - <surname>Moore</surname> - <contrib>Contributed by </contrib> - </author> - </authorgroup> - <!-- 20 November 2000 --> - </chapterinfo> - - <title>Sound</title> - - <sect1> - <title>Synopsis</title> - - <para>FreeBSD supports a wide variety of sound cards, allowing you - to enjoy high fidelity output from your computer. This includes - the ability to record and playback audio in the MPEG Audio Layer - 3 (MP3), WAV, and Ogg Vorbis formats as well as many other - formats. The FreeBSD Ports Collection also contains - applications allowing you to edit your recorded audio, add sound - effects, and control attached MIDI devices.</para> - -<!-- XXX we need to talk about ripping MP3s here. --> - - <para>After reading this chapter you will know:</para> - <itemizedlist> - <listitem><para>How to locate your sound card.</para></listitem> - <listitem><para>How to configure your system so that your sound card is - recognized.</para></listitem> - <listitem><para>Methods to test that your card is working using - sample applications.</para></listitem> - <listitem><para>How to troubleshoot your sound setup.</para></listitem> - </itemizedlist> - - <para>Before reading this chapter you should:</para> - - <itemizedlist> - <listitem><para>Know how to configure and install a new kernel (<xref - linkend="kernelconfig">).</para></listitem> - </itemizedlist> - </sect1> - - <sect1> - <title>Locating the Correct Device</title> - - <indexterm><primary>PCI</primary></indexterm> - <indexterm><primary>ISA</primary></indexterm> - <indexterm><primary>sound cards</primary></indexterm> - <para>Before you begin, you should know the model of the card you - have, the chip it uses, and whether it is a PCI or ISA card. - FreeBSD supports a wide variety of both PCI and ISA cards. If you - do not see your card in the following list, check the &man.pcm.4; - manual page. This is not a complete list; however, it does list - some of the most common cards.</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>configuration</secondary> - </indexterm> - <para>The driver you use in your kernel depends on the kind of card - you have. The sections below provide more information and what - you will need to add to your <link linkend="kernelconfig">kernel - configuration</link>.</para> - - <sect2> - <title>Creative, Advance, and ESS Sound Cards</title> - - <para>If you have one of the above cards, you will need to - add</para> - - <programlisting>device pcm</programlisting> - - <para>to your kernel. If you have a PnP ISA card, you will also - need to add</para> - - <programlisting>device sbc</programlisting> - - <para>to your kernel. For a non-PnP ISA card, add</para> - - <programlisting>device pcm</programlisting> - - <para>and</para> - - <programlisting>device sbc0 at isa? port0x220 irq 5 drq 1 flags 0x15</programlisting> - - <para>to your kernel. Those are the default settings. You may - need to change the IRQ, etc. See the &man.sbc.4; manual page for - more information.</para> - - <note> - <para>The Sound Blaster Live is not supported under FreeBSD 4.0 - without a patch, which this document will not cover. It is - recommended that you update to the latest -STABLE before - trying to use this card.</para> - </note> - </sect2> - - <sect2> - <title>Gravis UltraSound Cards</title> - - <para>For a PnP ISA card, you will need to add</para> - - <programlisting>device pcm</programlisting> - - <para>and</para> - - <programlisting>device gusc</programlisting> - - <para>to your kernel. If you have a non-PnP ISA card, you will - need to add</para> - - <programlisting>device pcm</programlisting> - - <para>and</para> - - <programlisting>device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13</programlisting> - - <para>to your kernel. You may need to change the IRQ, etc. See - the &man.gusc.4; manual page for more information.</para> - </sect2> - - <sect2> - <title>Crystal Sound Cards</title> - - <para>For Crystal cards, you will need both</para> - - <programlisting>device pcm</programlisting> - - <para>and</para> - - <programlisting>device csa</programlisting> - - <para>in your kernel.</para> - </sect2> - - <sect2> - <title>Generic Support</title> - - <para>For PnP ISA or PCI cards, you will need to add</para> - - <programlisting>device pcm</programlisting> - - <para>to your kernel configuration. If you have a non-PnP ISA - sound card that does not have a bridge driver, you will need - to add</para> - - <programlisting>device pcm0 at isa? irq 10 drq 1 flags 0x0</programlisting> - - <para>to your kernel configuration. You may need to change the - IRQ, etc., to match your hardware configuration.</para> - </sect2> - </sect1> - - <sect1> - <title>Recompiling the Kernel</title> - - <para>After adding the driver(s) you need to your kernel - configuration, you will need to recompile your kernel. Please see - <xref linkend="kernelconfig-building"> of the handbook for - more information.</para> - </sect1> - - <sect1> - <title>Creating and Testing the Device Nodes</title> - - <indexterm><primary>device nodes</primary></indexterm> - <para>After you reboot, log in and run <command>cat - /dev/sndstat</command>. You should see output similar to the - following:</para> - - <programlisting>FreeBSD Audio Driver (newpcm) Sep 21 2000 18:29:53 -Installed devices: -pcm0: <Aureal Vortex 8830> at memory 0xfeb40000 irq 5 (4p/1r +channels duplex)</programlisting> - - <para>If you see an error message, something went wrong earlier. If - that happens, go through your kernel configuration file again and - make sure you chose the correct device.</para> - - <para>If it reported no errors and returned - <devicename>pcm0</devicename>, <command>su</command> to - <username>root</username> and do the following:</para> - - <screen>&prompt.root; <userinput>cd /dev</userinput> -&prompt.root; <userinput>sh MAKEDEV snd0</userinput></screen> - - <para>If it reported no errors and returned - <devicename>pcm1</devicename>, <command>su</command> to - <username>root</username> and do the following:</para> - - <screen>&prompt.root; <userinput>cd /dev</userinput> -&prompt.root; <userinput>sh MAKEDEV snd1</userinput></screen> - - <para>Please note that either of the above commands will - <emphasis>not</emphasis> create a - <devicename>/dev/snd</devicename> device! Instead it creates a - group of device nodes including:</para> - - <informaltable frame="none"> - <tgroup cols="2"> - <thead> - <row> - <entry>Device</entry> - <entry>Description</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>Like <devicename>/dev/dsp</devicename>, but 16 bits - per 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>If all goes well, you should now have a functioning sound - card. If you do not, see the next section.</para> - </sect1> - - <sect1> - <title>Common Problems</title> - - <qandaset> - <indexterm><primary>device node</primary></indexterm> - <qandaentry> - <question> - <para>I get an unsupported subdevice XX error!</para> - </question> - - <answer> - <para>One or more of the device nodes was not created - correctly. Repeat the steps above.</para> - </answer> - </qandaentry> - - <indexterm><primary>I/O port</primary></indexterm> - <qandaentry> - <question> - <para>I get a sb_dspwr(XX) timed out error!</para> - </question> - - <answer> - <para>The I/O port is not set correctly.</para> - </answer> - </qandaentry> - - <indexterm><primary>IRQ</primary></indexterm> - <qandaentry> - <question> - <para>I get a bad irq XX error!</para> - </question> - - <answer> - <para>The IRQ is set incorrectly. Make sure that the set IRQ - and the sound IRQ are the same.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>I get a <errorname>xxx: gus pcm not attached, out of - memory</errorname> - error. What causes that?</para> - </question> - - <answer> - <para>If this happens, it is because there is not enough - available memory to use the device.</para> - </answer> - </qandaentry> - </qandaset> - </sect1> -</chapter> diff --git a/en_US.ISO8859-1/share/sgml/newsgroups.ent b/en_US.ISO8859-1/share/sgml/newsgroups.ent new file mode 100644 index 0000000000..04f5cc7c7b --- /dev/null +++ b/en_US.ISO8859-1/share/sgml/newsgroups.ent @@ -0,0 +1,10 @@ +<!-- + Names of FreeBSD newsgroups + + $FreeBSD: doc/en_US.ISO8859-1/books/handbook/newsgroups.ent,v 1.2 1999/09/06 06:52:47 peter Exp $ +--> + +<!ENTITY ng.misc "the + <ulink url='news:comp.unix.bsd.freebsd.misc'>comp.unix.bsd.freebsd.misc</ulink> + newsgroup"> + diff --git a/ja_JP.eucJP/articles/contributing/article.sgml b/ja_JP.eucJP/articles/contributing/article.sgml deleted file mode 100644 index 3ffd682fa5..0000000000 --- a/ja_JP.eucJP/articles/contributing/article.sgml +++ /dev/null @@ -1,6535 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD Japanese Documentation Project - - Original revision: 1.458 - $FreeBSD: doc/ja_JP.eucJP/books/handbook/contrib/chapter.sgml,v 1.70 2001/07/19 16:25:22 hrs Exp $ ---> - -<chapter id="contrib"> - <title>FreeBSD �ؤι׸�</title> - - <para><emphasis>����: &a.jkh;.</emphasis></para> - - <para><emphasis>��: &a.jp.iwasaki;, - 1997 ǯ 4 �� 27 ��.</emphasis></para> - - <indexterm><primary>�׸�</primary></indexterm> - - <para>���ʤ��ⲿ�� FreeBSD �Τ���˹׸��������ʤ�ޤ�����? - �����餷��! �䤿���Ͼ�˻ٱ��������Ѱդ�����ޤ���, FreeBSD - �������Ĥ뤿��˥桼 - ���١����ι׸���<emphasis>���</emphasis>�褦�ʥ����ƥ�ΰ�ĤǤ�. - ���ʤ��ι׸��� ���դ��������ǤϤʤ�, FreeBSD - ����Ĺ��³���뤿��˶ˤ�ƽ��פʤ�Τ� �ΤǤ�!</para> - - <para>�����ο�ã�����äƤ���ΤȤϵդ�, - �׸�������դ��Ƥ�餦��������� ���Υץ�����ޡ��ˤʤ�Ȥ� - FreeBSD ����������οͤȿ�ͧ�ˤʤ�ɬ�פϤ� ��ޤ���. FreeBSD - �ץ��������Ȥγ�ȯ��, ¿���Τ����Ʊס����ä��������� - �ι׸���ã�ˤ�äƤʤ���Ƥ���, ����ǯ��, - ���絻��ʬ���¿�����Ϥ�� ��. - �����Ƽ�ζ����Ƥ���ͤ��� - �������٤��Ż����������¿���ΤǤ�.</para> - - <para>FreeBSD - �ץ��������Ȥ������ͥ�件�ߤ��Ƥ���桼�ƥ���ƥ�����, - ���ڥ졼�ƥ��󥰥����ƥ�Ķ� (��, ���Υ��󥹥ȡ���) - ���Ф�����Ǥ����� �褦�ˤʤä�����, - �䤿����<filename>TODO</filename>�ꥹ�Ȥϥɥ�����ơ������, - �١����� ����, - ���٤����粽���줿�����פΥ����ͥ볫ȯ�ι����Ҳ𤹤�ʤ����� - �����ϰϤΥ��������Ϥ�ޤ�. ���ʤ��ε�ǽ��٥�˴ؤ�餺, - �ץ��������� ��ٱ�Ǥ��뤳�Ȥ�ɬ����������ޤ�!</para> - - <para>FreeBSD - ��Ϣ�λ��Ȥ˽������Ƥ��뾦�����Τ��䤿���˥��󥿥��Ȥ��뤳�� - �ⴿ�ޤ��ޤ�. ���ʤ������ʤ� (FreeBSD ���) ư�����ˤ�, - ���̤ʳ�ĥ ��ɬ�פǤϤ���ޤ���? - ���ޤ�ˤ����Ѥ����׵�Ǥʤ����, �������� - ������Ѱդ��䤿���ˤ���Ȥ狼��Ϥ��Ǥ�. - �ղò��ͤΤ������ʤǤ���? �䤿�����Τ餻�Ƥ�������! ¿ʬ�䤿����, - ���� �̤ˤ����ƶ�Ʊ���ƺ�Ȥò¤¹¤ë¤³ï¿½È¤ï¿½ï¿½Ç¤ï¿½ï¿½ï¿½Ç¤ï¿½ï¿½ç¤¦. - �ե꡼���եȥ������� ��, - ���եȥ����������Υ饤�ե���������̤��ƤɤΤ褦�˳�ȯ����, - ����, �ݼ餵��Ƥ������ˤĤ���, ��¸�β����ĩ�路�Ƥ��ޤ�. - ���ʤ��Ȥ�⤦�� - �ٹ�θ���Ƥߤ뤳�Ȥ�䤿���϶��������ᤷ�ޤ�.</para> - - <sect1 id="contrib-what"> - <title>����ɬ��?</title> - - <para>���Υ������ȥ��֥ץ��������ȤΥꥹ�Ȥ�, �������������� - <filename>TODO</filename> �� - ���ȤȺǶ�2����ǽ��᤿�桼���ꥯ�����Ȥ��碌����ΤǤ�. - ��ǽ�ʤȤ� ���Ǥ�, �۵��٤ˤ�äƥ���������󥯤Ť�����Ƥ��ޤ�. - �⤷�����ˤ��륿 �����μ¹Ԥ˶�̣������ΤǤ�����, - �����ǥ��͡�����̾���ò¥¯¥ï¿½Ã¥ï¿½ï¿½ï¿½ï¿½Æ¥á¡¼ ������äƤ�������. - �⤷�����ǥ��͡�������ޤäƤ��ʤ����, ���ʤ����� - ���ƥ������Ƥߤޤ���?</para> - - <sect2> - <title>ͥ���٤ι⤤������</title> - <indexterm><primary>�ʤ��٤���ȤΥꥹ��(todo list)</primary></indexterm> - - <para>���Υ��������̾�, �Ҥɤ�����Ƥ���Ȥ�, - �ȤƤ�ɬ�פȤ���Ƥ��벿���� ɽ���Ƥ��뤿��, - ��̳�ȹͤ����Ƥ��ޤ�:</para> - - <orderedlist> - <listitem> - <para>��3���ơ������֡�������. ���Υ����ǥ��͡������: - &a.hackers;</para> - - <itemizedlist> - <listitem> - <para>��3���ơ������ǥ������� BIOS - ������ȥ�����Τʥޥåԥ󥰤��� �Ǥ���褦�� WinNT - ����ѥ��֥�ʥɥ饤�֤����פò¤ª¤ï¿½ï¿½Ê¤ï¿½.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>�ե����륷���ƥ�����. ���Υ����ǥ��͡������: - &a.fs;</para> - - <itemizedlist> - <listitem> - <para>nullfs �ե����륷���ƥॳ���ɤΥ��꡼�󥢥åפ� - �ɥ�����ơ������. �����ǥ��͡���: &a.eivind;</para> - </listitem> - - <listitem> - <para>union �ե����륷���ƥ�ν���. �����ǥ��͡���: - &a.dg;</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>Int13 vm86 �ǥ������ɥ饤�Фμ���. �����ǥ��͡���: - &a.hackers;</para> - </listitem> - - <listitem> - <para>New bus �������ƥ����㥫���ͥ�. �����ǥ��͡���: - &a.newbus;</para> - - <itemizedlist> - <listitem> - <para>���٤Ƥθ�¸ ISA �ɥ饤�Ф� - �������������ƥ�����ؤΰܿ�.</para> - </listitem> - - <listitem> - <para>���٤Ƥγ����߽��������ɤ� - Ŭ�ڤʥХ��ɥ饤�Ф˰�ư.</para> - </listitem> - - <listitem> - <para>PCI ���֥����ƥ�� - �������������ƥ�����ؤΰܿ�. �����ǥ��͡���: - &a.dfr;</para> - </listitem> - - <listitem> - <para>��ࡼ�Х֥�ǥХ�����������������ˡ�ò¸«¤ï¿½ï¿½Ð¤ï¿½, - PC-Card �� CardBus ��������뤿�������ˤ���.</para> - </listitem> - - <listitem> - <para>�ץ����֡������å���ͥ���̤������ - ���Ǥ��ä���Ȳ�褹��.</para> - </listitem> - - <listitem> - <para>����¾�Ĥ�ΥХ��ò¤¹¤Ù¤Æ¿ï¿½ï¿½ï¿½ï¿½ï¿½ - �������ƥ�����ؤȰܹԤ���.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>�����ͥ�ν�����. ���Υ����ǥ��͡������: - &a.hackers;</para> - </listitem> - - <listitem> - <para>����Ѷ�Ū�˥������ƥ����פ�������ʤ��. - ���Υ����ǥ��͡������: &a.security;</para> - - <itemizedlist> - <listitem> - <para>Tripwire(TM) �Τ褦�ʤ�Τò¥«¡ï¿½ï¿½Í¥ï¿½ï¿½ï¿½ï¿½ - ��⡼�ȡ���������ξ��ʬ��������. - ������������¸�������, �Ź浻�Ѥ˴ؤ������꤬ - ���������Ⱦ夬�äƤ��ޤ�. - �ܺ٤ˤĤ��Ƥϥ����ǥ��͡�����Ϣ�����äƤߤƤ�������. - �����ǥ��͡���: &a.eivind;</para> - </listitem> - - <listitem> - <para>�����ͥ�� (UID ��) 0 ����Ӥ��Ƥ�����ʬ�� - ���٤� <literal>suser()</literal> ��Ȥ��褦�ˤ���. - ����, ��Ⱦʬ�βս꤬�ȤäƤ��ޤ�. - �����ǥ��͡���: &a.eivind;</para> - </listitem> - - <listitem> - <para>�����奢��٥�ò¤¤¤ï¿½ï¿½Ä¤ï¿½ï¿½ï¿½ï¿½ï¿½Ê¬ï¿½ï¿½Ê¬ï¿½ï¿½ï¿½ï¿½. - ����ˤ�äƴ����Ԥ�, �������Ƥ⹽��ʤ� - ���¤ˤĤ��Ƥ������Ǥ���褦�ˤʤ�ޤ�. - �����ʤ���, ���Υ����奢��٥�ò¥»¥Ã¥È¤ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½ï¿½ - ���̤ϸ��ߤΤޤޤˤ��ʤ���Фʤ�ޤ���. - �����ǥ��͡���: &a.eivind;</para> - </listitem> - - <listitem> - <para>BPF ������ <quote>���Ĥ��줿�ץ������</quote> - �Υꥹ�Ȥò¥¢¥Ã¥×¥ï¿½ï¿½ï¿½ï¿½É¤Ç¤ï¿½ï¿½ï¿½è¤¦ï¿½Ë¤ï¿½ï¿½Æ¡ï¿½ BPF ������ʳ��� - �ץ���������������Τò¿©¤ï¿½ï¿½ß¤ï¿½ï¿½. - ����ˤ�ä�, BPF ���㤨�� DHCP �˻Ȥ���, ��������� - ��������ͥåȥ���ò¤³¤Ã¤ï¿½ï¿½ï¿½Ãµï¿½ï¿½ï¿½ë¤³ï¿½È¤ï¿½Ê¤ï¿½ï¿½Ê¤ï¿½ - �Ǥ��礦.</para> - </listitem> - - <listitem> - <para>�������ƥ������å�������ץȤò¹¹¿ï¿½ï¿½ï¿½ï¿½ï¿½. - ���ϤȤ⤢��, ¾�� BSD ���������ƥ�ˤ�������å��� - ���٤Ƽ�����. �����, �����ƥब�����奢��٥�� - �⤯���Ƥ�����ˤ�, ��Ϣ�ս�ˤĤ���Ŭ�ڤʥե饰�� - ���ꤷ�Ƥ��뤫�ɤ����Υ����å���Ԥ��褦�ˤ���. - �����ǥ��͡���: &a.eivind;</para> - </listitem> - - <listitem> - <para>�����ͥ��ǧ�ڵ������ߤ�, ǧ�ڥݥꥷ���� - ʣ�����ݡ��Ȥ���. ������� <literal>suser()</literal> - �������뤳�ȤDz�ǽ�Ǥ��礦. - �����ǥ��͡���: &a.eivind;</para> - </listitem> - - <listitem> - <para>NFS �쥤��˥����ɤ��ɲä�, NFS �ѡ��ƥ������� - ���˽Ф�褦�� <literal>chdir("..")</literal> �� - �Ǥ��ʤ��褦�ˤ���. �㤨��, <filename>/usr</filename> - �� UFS �� <filename>/usr/src</filename> �� NFS - �������ݡ��Ȥ���Ƥ���Ȥ��ޤ�. ���ߤǤ�, - <filename>/usr/src</filename> �ؤ� NFS �ե����� - �ϥ�ɥ��Ȥä� <filename>/usr</filename> �� - ���������Ǥ��Ƥ��ޤ���ǽ��������ޤ�.</para> - </listitem> - </itemizedlist> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>ͥ���٤����ۤɹ⤯�ʤ�������</title> - - <para>���Υ������Ϥ�äƤ����٤��ǤϤ���ޤ���, - �äˤ������äƤ���櫓�� �Ϥ���ޤ���:</para> - - <orderedlist> - <listitem> - <para>������ KLD �١����Υɥ饤�ФΥ��ݡ��� / - ����ե����졼�����ޥ͡� ����.</para> - - <itemizedlist> - <listitem> - <para>���䤫����ˡ�ǥϡ��ɥ��������Τ��� - ����ե����졼�����ޥ͡����� ��� - (��3���ơ������֡��Ȥ����?). �ϡ��ɥ�������ɬ�פȤ��� - KLD ������ �Ĥ���.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>PCMCIA/PCCARD. �����ǥ��͡���: &a.msmith; �� &a.imp;</para> - - <itemizedlist> - <listitem> - <para>�ɥ�����ơ������!</para> - </listitem> - - <listitem> - <para>pcic �ɥ饤�Фο������Τ������ (�ƥ�����).</para> - </listitem> - - <listitem> - <para><filename>sio.c</filename> - �Υꥳ���ʥ����ȥϥ�ɥ� (�ܴۤ�λ).</para> - </listitem> - - <listitem> - <para><filename>ed.c</filename> �Υꥳ���ʥ����ȥϥ�ɥ� - (�ܴۤ�λ).</para> - </listitem> - - <listitem> - <para><filename>ep.c</filename> �Υꥳ���ʥ����ȥϥ�ɥ� - (�ܴۤ�λ).</para> - </listitem> - - <listitem> - <para>User-mode �Υꥳ���ʥ����ȥϥ�ɥ� - (��ʬŪ�˴�λ).</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>���Ū�ʥѥ�ޥ͡�������. �����ǥ��͡���: &a.nate; - �� &a.phk;</para> - - <itemizedlist> - <listitem> - <para>APM ���֥ɥ饤�� (�ܴۤ�λ).</para> - </listitem> - - <listitem> - <para>IDE/ATA �ǥ��������֥ɥ饤�� (��ʬŪ�˴�λ).</para> - </listitem> - - <listitem> - <para>syscons/pcvt ���֥ɥ饤��.</para> - </listitem> - - <listitem> - <para>PCMCIA/PCCARD �ɥ饤�з��Ȥ����� (�����ڥ�� / - �쥸�塼��).</para> - </listitem> - </itemizedlist> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>ͥ���٤��㤤������</title> - - <para>���Υ������������Τ��鱣��, - �ޤ���ï�⤹���ˤ����ʤ�������ʤ���� - �Τ褦�ʻŻ���ɽ���ޤ�:</para> - - <para>�ǽ�� N ���ܤ� Terry Lambert - <email>terry@lambert.org</email> ����Τ�ΤǤ�.</para> - - <orderedlist> - <listitem> - <para>�ͥåȥ�������ɤȰ����󶡤���� ODI - �����ɥɥ饤�Ф���Ѥ� ����褦�ˤ���, NetWare ������ - (�ץ��ƥ��ȥ⡼�ɤ� ODI �ɥ饤��) ���� ���ȥ��֥����ӥ�. - NDIS �ɥ饤�Ф� NetWare �� SCSI �ɥ饤�ФˤĤ��Ƥ�Ʊ - ��.</para> - </listitem> - - <listitem> - <para>���Υ�ӥ����� FreeBSD �ޥ���ǤϤʤ�, Linux - �ޥ����ư��� �֥��åץ��졼�� - �����ƥ�ץ��ץ����.</para> - </listitem> - - <listitem> - <para>�����ͥ�Υޥ������åɲ� - (�����ͥ�Υץꥨ��ץ����ɬ��).</para> - </listitem> - - <listitem> - <para>�����ͥ�Υץꥨ��ץ�����դ��оΥޥ���ץ����å��� - (�����ͥ� �Υץꥨ��ץ����ɬ��).</para> - </listitem> - - <listitem> - <para>�ݡ����֥륳��ԥ塼���Υ��ݡ��Ȥˤ����붨Ĵ�λ��. - ����� PCMCIA - �֥�å��󥰵�§���Ÿ��������٥�Ƚ������ѹ��ˤ��, ���� - �餫�Ͻ����Ǥ��ޤ�. ������, - ��¢�ǥ����ץ쥤�ȳ����ǥ����ץ쥤�θ���, ���� 2 - ����Υǥ����ץ쥤������Ȥ������¤˴�Ť� - �ۤʤ�����٤�����, �ޥ��󤬥ɥå��ˤ�����ˤ� - �ǥ������Υ⡼����ߤ��ɻߤ��뤳��, �ޥ���� - �֡���ǽ�Ϥ˱ƶ���Ϳ�����˥ɥå��١����Υ����ɤξ��Ǥ� - ��ǽ�ˤ��뤳�� (PCMCIA ��Ʊ������) - �ʤɤ����꤬����ޤ�.</para> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>��äȴ�ñ�ʥ�����</title> - - <para>��Υ��������ǵ󤲤�������������ʻ��֤����ޤ��� - FreeBSD �Υ����ͥ�˴ؤ��뿼���μ���ɬ�פȤ��ޤ� - (�⤷���Ϥ��Τɤ����). �������ʤ���, - "�����ϥå���"��ץ�����ߥ󥰤Υ������� - ���ʤ��͡���Ŭ����Ω�ɤʥ��������¿������ޤ�.</para> - - <orderedlist> - <listitem> - <para>FreeBSD-current ���Ѥ��Ƥ���, - ���֤��ɤ����󥿡��ͥå���³���� ��ʤ��, <hostid - role="fqdn">current.FreeBSD.org</hostid> - �Ȥ��������˰��ե��꡼����ԤäƤ��� �ޥ��󤬤���ޤ� - — ������ǿ��Υ�꡼���ò¤½¤ï¿½ï¿½ï¿½ï¿½é¥¤ï¿½ó¥¹¥È¡ï¿½ï¿½ë¤·, ���� - �����Dz������꤬����ʤ���𤷤Ʋ�����.</para> - </listitem> - - <listitem> - <para>freebsd-bugs - �᡼��󥰥ꥹ�Ȥ��ɤ�Ǥ�������. �����ǤϤ��ʤ����� - ��Ū�ʥ����Ȥ��դ�����ƥ��ȤǤ���ѥå��� - �󶡤���Ƥ���褦�����꤬���� ���⤷��ޤ���. - �⤷���Ϥ���������ΰ�Ĥò¤¢¤Ê¤ï¿½ï¿½ï¿½ï¿½È¤Ç½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ë¤³ï¿½È¤ï¿½ï¿½ï¿½ - �Ǥ��뤫�⤷��ޤ���.</para> - </listitem> - - <listitem> - <para>���Ū�� FAQ �ȥϥ�ɥ֥å����̤����ɤ�ǤߤƤ�������. - �⤷�ޤ���������Ť������䴰���˴ְ�äƤ��뤳�Ȥʤɤ� - ����в桹�� ���餻�Ʋ�����. - ������ɤ��Τϲ桹�˽����Ƥ����뤳�ȤǤ� (SGML - �ϳؤ֤Τˤ���ۤ��ñ¤·¤ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½, - �ץ쥤��ƥ����ȤǤ������ ����ޤ���).</para> - </listitem> - - <listitem> - <para>(�⤷�ޤ��ʤ��ʤ��) FreeBSD - �Υɥ�����Ȥ�ʬ����������� - ����Τ�����äƤ������� — - ��Ȥ��Ƥ���ͤ����뤫�ɤ��� &a.doc; �˥᡼��� - ���ä�ʹ�������Ǥ�. �ȤϤ��äƤ�, - �������뤳�Ȥˤ�äƤ��ʤ������Ƥ� FreeBSD - �ɥ�����Ȥ������˷Ȥ��褦�� - �ʤ�Ȥ����櫓�ǤϤʤ��Ǥ����� �� — �º�, - ��äȤ�������ɬ�פȤ���Ƥ���ɥ�����Ȥϥ��󥹥ȡ����� - ˡ�Ǥ�.</para> - </listitem> - - <listitem> - <para>���ޤ�(�⤷�������Ū��) freebsd-questions - �᡼��󥰥ꥹ�Ȥ� - <literal>comp.unix.bsd.freebsd.misc</literal> - ���ɤ�Ǥ�������. �����, ���ʤ��λ��äƤ� - ���������Í������ï���������Ƥ�������� - ��褹��Τ�����Í���� ��Τˤʤ����뤳�ȤǤ�. - ���ˤϤ��ʤ����Ȥǿ��������Ȥ�ؤ֤��Ȥ��� - �Ǥ��뤫�⤷��ޤ���. - �����Υե������Ϥ��٤����ȤΥ����ǥ��� - �θ��ˤ�ʤ�����ΤǤ�.</para> - </listitem> - - <listitem> - <para>-current �����������Ƥ��뤬���Ф餯�ФäƤ�(�̾�� - 2, 3 ����) -stable - �˼����ޤ�Ƥʤ��褦�ʥХ��ե��å���������ʤ�� - ���ߥå����� ��ǫ�˻פ��Ф����Ƥ�������.</para> - </listitem> - - <listitem> - <para>��£���եȥ������ò¥½¡ï¿½ï¿½ï¿½ï¿½Ä¥ê¡¼ï¿½ï¿½ - <filename>src/contrib</filename> - �˰�ư�����Ƥ�������.</para> - </listitem> - - <listitem> - <para><filename>src/contrib</filename> - �ʲ��Υ����ɤ��ǿ��Τ�ΤǤ��뤫��ǧ���Ƥ�������.</para> - </listitem> - - <listitem> - <para>�ٹ��ܺ٤���𤹤�褦�ˤ��� - �������ĥ꡼����(�⤷���Ϥ��ΰ���)���ۤ��ƤߤƤ�������. - �����Ʒٹ𤬽Фʤ��褦�ˤ��Ƥ�������.</para> - </listitem> - - <listitem> - <para>ports ��, gets() ��ȤäƤ���Ȥ� malloc.h - �ò¥¤¥ó¥¯¥ë¡¼ï¿½É¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ - �ʤɤȤ��ä��ٹ𤬽Фʤ��褦�ˤ��Ƥ�������.</para> - </listitem> - - <listitem> - <para>�⤷�ʤ�餫�� ports �˴ؤ�äƤ���ʤ�, - ���ʤ��Υѥå����Ԥ� �ե����ɥХå����Ƥ������� - (���ΥС�����󤬽Ф����ˤ��ʤ����ڤˤʤ�ޤ�).</para> - </listitem> - - <listitem> - <para>���Υꥹ�Ȥ��ɲä��륿��������Ƥ��Ʋ�����!</para> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>�㳲���(PR; Problem Report)�ǡ����١����ˤ�������</title> - - <indexterm><primary>�㳲��� (PR) �ǡ����١���</primary></indexterm> - - <para><ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi"> - FreeBSD �㳲���ꥹ��</ulink>�Ǥ�, ��������ȤʤäƤ�������, - FreeBSD �����ѼԤˤ�ä���Ф��줿���ɤ���˾�˴ؤ��� - ���ƤΥꥹ�Ȥ�������Ƥ��ޤ�. - open ���֤ξ㳲����ò¸«¤ï¿½, ��̣��������Ƥ��ɤ����Τ���Ʋ�����. - ������ʣ���ʤ�Τ�ޤޤ�Ƥ���Ǥ��礦��, - �㤨��, �㳲�����Ф��뽤���������Ȥ�����ΤǤ��뤫�ɤ��� - ñ�˥����å���������ΤȤƤ��ñ�ʺ�Ȥ⤢��Ǥ��礦.</para> - - <para>�ޤ�, �ޤ�ï�ˤ������Ƥ��Ƥ��ʤ��㳲��𤫤��Ȥ� - �Ϥ�Ʋ�����. �⤷, ï��¾�οͤ˳�����Ƥ���ޤäƤ��뤱��ɤ� - ��ʬ����Ȳ�ǽ��, �Ȥ�����Τ������, ��Ȥ��Ǥ��뤫�ɤ���— - ���˥ƥ����ѥѥå����Ѱդ���Ƥ���Τ��ɤ���, ���뤤�� - ��������ˤĤ��Ƥ��ʤ����ͤ��Ƥ���, - ���ʤ���ͤ��˴ؤ��Ƶ������Ǥ��뤫�ɤ���, - ������Ƥ��Ƥ���ͤ��Żҥ᡼����䤤��碌�Ʋ�����. - </para> - - </sect2> - </sect1> - - <sect1 id="contrib-how"> - <title>�׸��λ���</title> - - <para>����Ū��, �����ƥ�ؤι׸��ϼ��� 6 - �ĤΥ��ƥ����1�İʾ��ʬ�व��ޤ�:</para> - - <sect2 id="contrib-general"> - <title>�Х����Ȱ���Ū����ɾ</title> - - <para>��𤹤�٤��Х������ä���, ��Ƥ��������Ȥ������:</para> - - <para><emphasis>����Ū��</emphasis> - ����Ū�ؿ����˴ؤ��륢���ǥ�����Ƥ� &a.hackers; - �إ᡼�뤷�Ƥ�������. Ʊ�ͤ�, ���Τ褦�ʻ����˶�̣�Τ��� - (������<emphasis>�����</emphasis>�᡼��! ���Ѥ�����) �ͤ�, - &a.majordomo; �إ᡼������ä� hackers - �᡼��󥰥ꥹ�Ȥ˻��ä�����ɤ��Ǥ��礦. ����ˤĤ��Ƥ� - <link linkend="eresources-mail">�᡼��󥰥ꥹ��</link> - �ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - - <para>�Х���ȯ���������ѹ������դ��褦�Ȥ��Ƥ������ - &man.send-pr.1; �ץ�����फ <ulink - url="http://www.FreeBSD.org/send-pr.html">WEB �١����� - send-pr</ulink> ����Ѥ�����𤷤Ƥ�������. - �Х���ݡ��Ȥγƹ��ܤ�����褦�ˤ��Ƥ�������. 65KB - ��Ķ����ΤǤʤ����, ��ݡ������ľ�� - �ѥå�������Ƥ������äƷ빽�Ǥ�. - ����, ���åȡ��ڡ����Ȥ�<emphasis>���ʤ���</emphasis> - ��������. ���åȡ��ڡ����ȤǤϥ��֤����ڡ�����Ÿ������� - �ѥå����Ȥ�ʪ�ˤʤ�ʤ��ʤäƤ��ޤ��ޤ�. - 20KB ��Ķ�������, - ������ compress ���� &man.uuencode.1; - ���뤳�Ȥ⸡Ƥ���Ƥ�������. �ȤƤ��ç¤ï¿½ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½ <ulink - url="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/"> - ftp.FreeBSD.org:/pub/FreeBSD/incoming/</ulink> - �����Ѥ��Ƥ�������. - </para> - - <para>��ݡ��Ȥ��ե�����󥰤�����, �Х����γ�ǧ�� - �ȥ�å����ֹ��᡼��Ǽ������Ϥ��Ǥ�. - ���Υȥ�å����ֹ��Ф��Ƥ���, ����˴ؤ���ܺپ���� - <email>bug-followup@FreeBSD.org</email> �� - �᡼������äƹ����Ǥ���褦�ˤ��Ƥ�������. �㤨�� - <literal>"Re: kern/3377"</literal> �Τ褦��, - �����ֹ�ò¥µ¥Ö¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È¹Ô¤Ë»ï¿½ï¿½Ñ¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½. - ���٤ƤΥХ���ݡ��Ȥ��ɲþ����, - ������ˡ�����դ���ʤ���Ф����ޤ���.</para> - - <para>�⤷�������� (���ʤ����Żҥ᡼����³���֤ˤ���ޤ���, - 3������ 1����) ��ǧ������Ȥ�ʤ��Ȥ�, ���餫����ͳ�� - &man.send-pr.1; ���ޥ�ɤ� ���ѤǤ��ʤ����ˤ�, &a.bugs; - �إ᡼�������, ï�����˥Х����� - ���դ��Ƥ�餦�褦�����ͤƤ�������.</para> - </sect2> - - <sect2> - <title>ʸ����ѹ�</title> - - <indexterm><primary>ʸ��˴ؤ������</primary></indexterm> - - <para>ʸ����ѹ��� &a.doc; �����Ĥ��Ƥ��ޤ�. <link - linkend="contrib-general">�Х����Ȱ���Ū����ɾ</link> - �˵��Ҥ���Ƥ���褦�� <command>send-pr</command> - ���ޥ�ɤ���Ѥ���, ��Ƥ��ѹ� - (�ɤ�ʺ��٤ʤ�ΤǤⴿ�ޤ��ޤ�!) �����äƤ�������.</para> - </sect2> - - <sect2> - <title>��¸�Υ����������ɤ��ѹ�</title> - - <indexterm><primary>FreeBSD-current</primary></indexterm> - - <para>��¸�Υ����������ɤؤ��ɲäޤ����ѹ���, - �����餫�ȥ�å����ʻŻ��� ����, core �� FreeBSD - ��ȯ�θ����ˤ��ʤ����ɤ�����̤��Ƥ��뤫���� ������¸���ޤ�. - <quote>FreeBSD-current</quote>�Ȥ����Τ��� FreeBSD �����̤� - ��³Ū��꡼��������ޤ�. FreeBSD-current - �ϳ�ȯ�Ԥ��Ѷ�Ū�ʳ�ư�� �ص��Τ����, - ��������ˡ�����Ѳ�ǽ�ˤʤäƤ��ޤ�. FreeBSD-current - ������Ȼ�����ˡ�ˤĤ��Ƥξܤ�������ˤĤ��Ƥ� <link - linkend="current">�ǿ��� FreeBSD ���ɤ�������</link> - �ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - - <para>�Թ��ˤ��ƸŤ����������Ȥ˻Ż��ò¤¹¤ë¤³ï¿½È¤ï¿½, - �������ʤ����ѹ����� ���٤�, �ޤ��� FreeBSD - �ؤδ�ñ�ʺ�����˹��ʤ��ʤäƤ��뤳�Ȥ�� ̣���ޤ�. - �����ƥ�θ����˴ؤ�������������ʤ��Ƥ��� &a.announce; �� - &a.current; �ػ��ä��뤳�Ȥ�, - ���β�ǽ����Ǿ��¤ˤ��뤳�Ȥ��Ǥ��ޤ�.</para> - - <para>�����ʺǿ��Υ��������ѹ��Υ١����ˤǤ��뤳�Ȥ� - �μ¤ˤʤä��Ȳ��ꤷ ��, ���Υ��ƥåפ� FreeBSD - ���ݼ�ô���Ԥ����뺹ʬ�ե�����������Ǥ�. ����� &man.diff.1; - ���ޥ�ɤ���Ѥ��Ƥ����ʤ��ޤ���, <quote>context - diff</quote>���������ޤ��褦�Ǥ�. �㤨��:</para> - - <indexterm> - <primary><command>diff</command></primary> - </indexterm> - <screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen> - - <para>�ޤ���</para> - - <screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen> - - <para>����ǻ��ꤵ�줿�������ե�����ޤ��ϥǥ��쥯�ȥ곬�ؤ� - �Ф��륳��� �����ȷ����κ�ʬ����������ޤ�. �ܤ��������� - &man.diff.1; �Υ� �˥奢��ڡ����ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - - <para>��ʬ�ե����� (&man.patch.1; ���ޥ�ɤǥƥ��ȤǤ��ޤ�) - �����, ������ FreeBSD - �˴ޤ�Ƥ�餦�褦�᡼������äƤ�������. <link - linkend="contrib-general">�Х����Ȱ���Ū����ɾ</link> - �˵��Ҥ���Ƥ���褦�� &man.send-pr.1; - ���ޥ�ɤ���Ѥ��Ƥ�������. ��ʬ�ե���������� &a.hackers; - �����äƤϤ����ޤ���. �����ˤ���Ƥ��ޤ��ޤ�! - �䤿����¿˻�ʤΤ�, ���ʤ�����Ƥ����Ѵ��դ��ޤ� - (����ϥܥ��ƥ����Υץ��������ȤǤ�!). - �����˼�꤫���뤳�ȤϤǤ��ޤ���, ���������ޤǤ� ������ - pr �ǡ����١����˻ĤäƤ��ޤ�.</para> - - <indexterm> - <primary><command>uuencode</command></primary> - </indexterm> - <para>���ʤ��������������������Ȼפ���� (�㤨��, - �ե�������ɲ�, ����ޤ���̾���ѹ��ʤ�), �ѹ��� - <command>tar</command> �ե�����ˤޤȤ�, &man.uuencode.1; - �ץ������ˤ����Ƥ�������. shar - ���������֤ⴿ�ޤ��ޤ�.</para> - - <para>�㤨�Ф��ʤ������켫�ȤΤ���ʤ����ۤ�������� - ���ԡ��饤��������� ��ʬ���äƤ��ʤ��Ȥ�, - ñ�˸�������ӥ塼�ò¤ª¤ï¿½ï¿½Ê¤Ã¤Æ¤ï¿½ï¿½é¤º, ��꡼�� - ����������Ǥ��Ƥ��ʤ��ʤ�, - ���ʤ����ѹ�������Ū���԰����������� �Ĥ�ΤǤ�����, - &man.send-pr.1; �����դ�����ष�� &a.core; - ��ľ�����äƤ�������. ����������᡼��󥰥ꥹ�Ȱ��Υ᡼���, - �����λŻ��ΤۤȤ�ɤ� FreeBSD �Ǥ����ʤäƤ���ͤ�����, - ��꾮���ʥ��롼 �פ��Ϥ��ޤ�. - ���Υ��롼�פ�ޤ�<emphasis>�ȤƤ�˻����</emphasis> - ���Ȥ����դ� ��, ������ɬ�פʾ��˥�������������˥᡼��� - ��������ˤ��Ƥ�������.</para> - - <para>�����ǥ��󥰥�������˴ؤ������� - &man.intro.9; ����� &man.style.9; - �ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½. �����ɤ���Ф������ˤ�, - ���ʤ��Ȥ⤳�ξ����ռ����Ƥ����Ƥ�������褦���ꤤ���ޤ�. - </para> - </sect2> - - <sect2> - <title>�����ʥ����ɤ�᥸�㡼���ղò��ͤι⤤�ѥå�����</title> - - <para>���פ��ç¤ï¿½ï¿½ï¿½Å»ï¿½ï¿½Î´ï¿½Â£ï¿½ï¿½, ���פʿ�������ǽ�� - FreeBSD ���ɲä�����ˤ�, �ѹ����� tar/uuencode - �����ե�����ˤ������뤫, ������ web �� FTP �����Ȥ� - ���åץ����ɤ��ƥ��������Ǥ���褦�ˤ��뤳�Ȥ� - �ɤ��餫���̾�ɬ�פˤʤ�ޤ�. web �� FTP �����ȤؤΥ��������� - �Ǥ��ʤ��Ȥ���Ŭ�ڤ� FreeBSD �Υ᡼��󥰥ꥹ�Ȥ�ï���� - �ѹ��������ä���äƤ�������.</para> - - <para>���̤Υ����ɤ�ȼ�ä��Ż��ξ��, - ���ԡ��饤�Ȥο��в��Ҥ����꤬��˽ФƤ��ޤ�. FreeBSD - �˴ޤ�륳���ɤΥ��ԡ��饤�ȤȤ��Ƽ�������뤳�Ȥ��Ǥ���Τ�, - �ʲ�����ĤǤ�:</para> - - <orderedlist> - <indexterm><primary>BSD copyright</primary></indexterm> - <listitem> - <para>BSD ���ԡ��饤��. - ���Υ��ԡ��饤�Ȥ�<quote>�����������ʤ�</quote>���� - �Ⱦ��Ѵ�ȤˤȤäư���Ū��̥�Ϥ��Ĥ���˺Ǥ⹥�ޤ�ޤ�. - FreeBSD �ץ��������ȤϾ������Ѥ��ˤ���ꤻ��, ������ - FreeBSD - ����ñ¤¹¤ëµ¤ï¿½Ë¤Ê¤Ã¤ï¿½ï¿½ï¿½ï¿½È´Ø·ï¿½ï¿½Ô¤Ë¤ï¿½ë»²ï¿½Ã¤ï¿½ï¿½Ñ¶ï¿½Åªï¿½Ë¾ï¿½ï¿½ï¿½ - ���ޤ�.</para> - </listitem> - - <indexterm><primary>GPL</primary></indexterm> - <indexterm><primary>GNU Public License</primary></indexterm> - <listitem> - <para>GNU���̸�Í���ѵ���, �ޤ���<quote>GPL</quote>. - ���Υ饤���󥹤ϥ����� - ������Ū�˻��Ѥ������;ʬ�����Ϥ������뤿��, - �䤿���ˤ��ޤ�ɾȽ���ɤ��Ȥ����櫓�ǤϤ���ޤ���. ������, - �䤿���ϴ��� GPL ���ι��ʼ��ʥ����� (����ѥ���, - ������֥�, �ƥ����ȥե����ޥå���) ���󶡤�����Ƥ���, - �䤿���ϸ��ߤ����ɬ�פȤ��Ƥ��ޤ�. ������, - ���Υ饤���󥹤ˤ�뿷���ʹ׸�����䤹 - ��Ȥ����Τ϶ò¤«¤Ê¤ï¿½ï¿½È¤Ç¤ï¿½ï¿½ç¤¦. GPL - ���Υ����ɤϥ������ĥ꡼ ���̤���ʬ, ���ߤΤȤ��� - <filename>/sys/gnu</filename> �� - <filename>/usr/src/gnu</filename> �����äƤ��ޤ�. - ������, GPL ������Ȥʤ�褦�ʿͤ�, - ï�Ǥ��ñ�ˤ���Ȥ狼��褦�ˤʤäƤ��ޤ�.</para> - </listitem> - </orderedlist> - - <para>����ʳ��Υ����פΥ��ԡ��饤�Ȥˤ���£��, FreeBSD - �شޤ�뤳�Ȥ��θ��������, - ���տ�����ӥ塼������ʤ���Фʤ�ޤ���. ��Ԥ��ȼ� - �Υ���ͥ���̤������ۤ��Ƥ���, - ���Τ褦���ѹ��ò¤ª¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½Ë¾ï¿½ï¿½å¤·ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½Ç¤ï¿½, - �ä˸���Ū�ʾ��ѤΥ��ԡ��饤�Ȥ�Ŭ�Ѥ����� - £�ϰ��̤˵��ݤ���ޤ�.</para> - - <para>���ʤ��κ��ʤ� <quote>BSD-��������</quote> - �Υ��ԡ��饤�Ȥ��դ���ˤ�, �ݸ�� - �������������ɥե����뤹�٤Ƥΰ��ֺǽ�� - �ʲ��Υƥ����Ȥ������, <literal>%%</literal> - �δ֤�Ŭ�ڤʾ�����֤�������������.</para> - - <programlisting>Copyright (c) %%Ŭ�ڤ�ǯ%% - %%���ʤ���̾��%%, %%���ʤ��ν�%% %%͹���ֹ�%%. - 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 %%���ʤ���̾��%% ``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 %%���ʤ���̾��%% 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. - - $Id$</programlisting> - - <para>�ص���Ϥ��뤿��, - ���Υƥ����ȤΥ��ԡ��ϼ��ξ����֤��Ƥ���ޤ�. - <filename>/usr/share/examples/etc/bsd-style-copyright</filename>. - </para> - - <para>(����: �ʲ��Ͽ����ҹ������£���줿 bsd-style-copyright - �����ܸ����Ǥ�. - �������ե�����˴ޤ���Τϸ�ʸ�����Ǥ��뤳�Ȥ����դ��� - �����Ѥ�������. �ޤ�, ��ʸ�Ȥδ֤˼�ݤκ��ۤ����������, - ��ʸ�����Ƥ� FreeBSD �ץ��������Ȥ� - �ջפǤ����ΤȤ��ޤ�.)</para> - - <programlisting> -Copyright (C) [ǯ] - [���ʤ���̾��] All rights reserved. - -�������ȥХ��ʥ�����κ����ۤ���ӻ��Ѥ�, �ѹ���Í̵�ˤ�����餺�ʲ��� -�������������˸¤���Ĥ����: -1. �����������ɤκ����ۤ�, �åµï¿½ï¿½ï¿½ï¿½ï¿½î¸¢É½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î¾ï¿½ï¿½Î¥ê¥¹ï¿½È¡ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ - ��ǧ����ʸ���ݻ����ʤ���Фʤ�ʤ�. - -2. �Х��ʥ�����κ����ۤ�, �åµï¿½ï¿½ï¿½ï¿½ï¿½î¸¢É½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î¾ï¿½ï¿½Î¥ê¥¹ï¿½È¡ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ - ��ǧ����ʸ��, ����ʪ�ȶ����󶡤����ʸ�ñ¤ª¤ï¿½ï¿½/�ޤ���¾�λ�������� - �ޤ�ʤ���Фʤ�ʤ�. - -(����:�����������ǧ����ʸ�פǤ�) - -���Υ��եȥ�������[���ʤ���̾��]����ӹ׸��Ԥˤ�ä� ``���뤬�ޤޤξ���'' -���󶡤���, ���������������Ū���Ф���Ŭ�����ˤĤ��Ƥΰ��ۤ��ݾڤ�α�� -�餺, �����ʤ���������Ӱ��ۤ��ݾڤ�ǧ��ʤ�. [���ʤ���̾��]����ӹ׸� -�Ԥ�, ������ľ��Ū������Ū����ȯŪ���ü�Ū��ŵ��Ū��ɬ��Ū��»�� (�� -�����ʤޤ������إ����ӥ��γ�����; ���ѡ��ǡ��������פ��Ӽ�; �ޤ��϶�̳ -���Ǥ�ޤ�, �ޤ����������α�ޤ�ʤ�»��) ������, ���Ȥ��ɤΤ褦�ˤ� -���������Ȥ��Ƥ�, �����Ƥ��Υ��եȥ������λ��Ѥˤ�äƤɤΤ褦�ˤǤ��� -������, �����Ǥ�������, ��̩����Ǥ��Ǥ�������, ���뤤�������԰� (�� -���䤽���Ǥʤ�����ޤ�) �ˤ�������Ǥ������Ȥ�, �����ʤ���Ǥ�����, -���Ȥ����Τ褦��»���β�ǽ����ͽ������Ƥ����Ȥ��Ƥ�, ���ڤ���Ǥ����� -�ʤ�. - -����: �����ҹ� -�涨�� (�޽����硦�ɾ�ά): - ���ĸ���, ���� ���, ƣ¼ �Ѽ�, ��餿���夦�������� - ���� ����, ���ġ����Ե� - </programlisting> - </sect2> - - <sect2> - <title>����, �ϡ��ɥ������ޤ��ϥ��󥿡��ͥåȥ�������</title> - - <para>FreeBSD �ץ��������Ȥ���Ū��ʤ�뤿��δ��դ�, - �䤿����Ʊ���褦�� �ܥ��ƥ����κ٤�Ĺ��! ���Ϥ�, - �䤿���Ͼ�˴��Ǽ�������Ƥ��ޤ�. - �ޤ�����Ū�˻䤿���ϼ�ʬã�� - ���յ�����㤦��⤬��Â���Ƥ��뤿��, - ���յ���Υ��ݡ��Ȥò½¼¼Â¤ï¿½ï¿½ï¿½ï¿½ï¿½Î¤ï¿½ - �ϡ��ɥ������δ��դϤȤƤ���פǤ�.</para> - - <sect3 id="donations"> - <title>�����</title> - - <para>FreeBSD Foundation ����������Ԥ��Τ���, - ���ι��ܤϤޤ��ñ¤«¤ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½.</para> - </sect3> - - <sect3> - <title>�ϡ��ɥ������δ�£</title> - - <indexterm><primary>��£</primary></indexterm> - - <para>FreeBSD �ץ��������Ȥ�, - ����3�ĤΥ��ƥ���Τɤ�ʥϡ��ɥ������δ�£��, - ���Ǽ����դ��ޤ�:</para> - - <itemizedlist> - <listitem> - <para>�ǥ������ɥ饤��, - ����ޤ��ϴ����ʥ����ƥ�Ȥ��ä��������ӤΥϡ��ɥ�������, - <emphasis>�����</emphasis>����ˤ��� - FreeBSD, Inc. �ν���ޤ����� �Ƥ�������.</para> - </listitem> - - <listitem> - <para>�ʹ���μ�������ƥ��ȤΤ���� - �ϡ��ɥ�������ɬ�פȤ���Ƥ��� ��. - �����ʥ�꡼�����Ŭ�ڤʵչԥƥ��Ȥ��Ǥ���褦��, - �䤿���ϸ���, FreeBSD - �����ݡ��Ȥ��뤹�٤ƤΥ���ݡ��ͥ�Ȥ� - �ƥ��ȥ�ܤ����֤��褦 �Ȥ��Ƥ��ޤ�. �䤿���ˤϤޤ�, - ��������ν��פ����� (�ͥåȥ��������, - �ޥ����ܡ��ɤʤ�) ����Â���Ƥ��ޤ��Τ�, - ���Τ褦�ʴ�£�ò¤·¤ï¿½ï¿½ï¿½ï¿½È»×¤Ã¤ï¿½ ����ʤ��, &a.dg; - �إ��󥿥��Ȥ��Ƥɤ����ʤ��ޤ�ɬ�פȤ���Ƥ��뤫 - �ξ�������Ƥ�������.</para> - </listitem> - - <listitem> - <para>���� FreeBSD �˥��ݡ��Ȥ���Ƥ��ʤ��ϡ��ɥ�������, - ���ݡ��Ȥ��ɲä����ߤ������. - �䤿�����������ϡ��ɥ�����������Ȥ����ˤ��Υ������� - ���������Ƥ���볫ȯ�Ԥ�õ��ɬ�פ����뤿��, - �������ʤ��������� &a.core; - �˥��󥿥��Ȥ��äƤ�������.</para> - </listitem> - </itemizedlist> - </sect3> - - <sect3> - <title>���󥿡��ͥåȥ��������δ���</title> - - <para>�䤿���Ͼ�� FTP, WWW �� <command>cvsup</command> - �ο������ߥ顼�����Ȥ��罸���Ƥ��ޤ�. - �ߥ顼�����Ȥˤʤꤿ�����ˤ� the FreeBSD project - administrators <email>hubs@FreeBSD.org</email> - �˥��󥿥��Ȥ��ä�, �ܤ��������������Ƥ�������.</para> - </sect3> - </sect2> - </sect1> - - <sect1 id="donors"> - <title>��£�ԥ����꡼</title> - - <para>FreeBSD �ץ��������Ȥϼ��δ�£�Ԥ˲���������Ƥ���, - �����˸�ɽ���ƴ��դΰդ�ɽ�������Ȼפ��ޤ�.</para> - - <itemizedlist> - <listitem> - <para><emphasis> - ����ȥ�륵���Хץ��������Ȥؤδ�£��:</emphasis></para> - - <para>���˵󤲤�Ŀͤ���Ӵ�Ȥ����, - ����ȥ�륵���Хޥ���Τ���� ���ʤδ�£��ĺ���Ƥ���, - ����ˤ�ä� <hostid - role="fqdn">freefall.FreeBSD.org</hostid> - ���ץ졼�����ƿ����� FreeBSD - �ץ��������ȤΥ���ȥ�륵���Хޥ���� - ���ۤ��뤳�Ȥ��Ǥ��ޤ���:</para> - - <itemizedlist> - <listitem> - <para>&a.mbarkah - ��������� <ulink - url="http://www.hemi.com/">Hemisphere Online</ulink> - ��, <emphasis>Pentium Pro (P6) 200MHz CPU</emphasis> - ���£���Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para><ulink url="http://www.asacomputers.com/">ASA - Computers</ulink> ��, <emphasis>Tyan 1662 - �ޥ����ܡ���</emphasis> - ���£���Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para><ulink url="http://www.via.net/">ViaNet - Communications</ulink> �� Joe McGuckin - <email>joe@via.net</email> ��, <emphasis>Kingston - �������ͥåȥ���ȥ�����</emphasis> - ���£���Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para>Jack O'Neill - <email>jack@diamond.xtalwind.net</email> ��, - <emphasis>NCR 53C875 SCSI ����ȥ����饫����</emphasis> - ���£���Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para><ulink url="http://www.Alameda.net/">Alameda - Networks</ulink> �� Ulf Zimmermann - <email>ulf@Alameda.net</email> ��, <emphasis>128MB - ����</emphasis>, ������ <emphasis>4 GB - �Υǥ������ɥ饤�֤ȶ���</emphasis> - ���£���Ƥ��������ޤ���.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para><emphasis>ľ��Ū�ʻ����:</emphasis></para> - - <para>���˵󤲤�Ŀͤ���Ӵ�Ȥ���� FreeBSD - �ץ��������Ȥ��Ф���ľ��Ū�� - ����󶡤�ĺ���Ƥ���ޤ�:</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.bluemountain.com/">Blue Mountain - Arts</ulink></para> - </listitem> - - <listitem> - <para><ulink url="http://www.epilogue.com/"> - Epilogue Technology Corporation</ulink></para> - </listitem> - - <listitem> - <para>&a.sef</para> - </listitem> - - <listitem> - <para><ulink url="http://www.gta.com/">Global Technology - Associates, Inc</ulink></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><ulink url="http://www.imagescape.com/"> - Imaginary Landscape, LLC.</ulink> - �� Kenneth P. Stox - <email>ken@stox.sa.enteract.com</email></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> - ��, ���ޤ��ޤʼ���� FreeBSD CD ���������פΰ����� - ���դ��Ƥ���ޤ���.</para> - </listitem> - - <listitem> - <para><ulink url="http://www.mmjp.or.jp/fuki/"> - ������</ulink> ��, <emphasis>�Ϥ���Ƥ� FreeBSD - </emphasis> �����夲�ΰ����� FreeBSD �ץ��������ȵڤ� - XFree86 �ץ��������Ȥش��դ��Ƥ���ޤ���.</para> - </listitem> - - <listitem> - <para><ulink url="http://www.ascii.co.jp/">��������</ulink> - �� FreeBSD ��Ϣ�ν��Ҥ����夲�ΰ����� FreeBSD - �ץ��������ȵڤ� FreeBSD ͧ�β�ش��դ��Ƥ���ޤ���. - </para> - </listitem> - - <listitem> - <para><ulink url="http://www.yokogawa.co.jp/"> - �����ŵ��������</ulink> ����� FreeBSD - �ץ��������Ȥ�¿��ʴ��դò¤¤¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½.</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 Andre Albsmeier - <email>andre.albsmeier@mchp.siemens.de</email></para> - </listitem> - - <listitem> - <para>Chris Silva <email>ras@interaccess.com</email></para> - </listitem> - - </itemizedlist> - </listitem> - - <listitem> - <para><emphasis>�ϡ��ɥ������δ�£��:</emphasis></para> - - <para>���˵󤲤�Ŀͤ���Ӵ�Ȥ����, - �ƥ��Ȥ�ǥХ����ɥ饤�Фγ�ȯ / ���ݡ��� - �Τ���Υϡ��ɥ������δ�£��ĺ���Ƥ���ޤ�:</para> - - <itemizedlist> - <listitem> - <para>BSDi ��, - �ͥåȥ���ؤΥ������������ - ¾�Υϡ��ɥ������꥽�����δ�£�Ϥ����ޤǤ�ʤ�, - ��ȯ�˻Ȥ������ Pentium P5-90 �� 486/DX2-66 EISA/VL - �Υ����ƥ������󶡤��Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para>TRW Financial Sysytems �Ҥ�, PC 130��, 68 GB - �Υե����륵���� 3��, 12�Υ������ͥå�, - �ǥ������쥹�����ɤΥǥХå��ò¤ª¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ �롼�� - 2��ڤ� ATM �����å����󶡤��Ƥ��������ޤ���. �ޤ�, - ���� 2, 3�ͤ� FreeBSD �ϥå�����ۤä�, FreeBSD - ����ǰ�����Ƥ������äƤ���ޤ�. - ���꤬�Ȥ��������ޤ�!</para> - </listitem> - - <listitem> - <para>Dermot McDonnell ��, ��� XM3401B CD-ROM �ɥ饤�֤� - ��£���Ƥ��������ޤ���. ���� CD-ROM �ɥ饤�֤ϸ��� - freefall �ǻ��Ѥ���Ƥ��ޤ�.</para> - </listitem> - - <listitem> - <para>&a.chuck; ��, �¸��ѤΥե��åԡ��ơ��ץ��ȥ꡼�ޤ� - ���դ��Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para>Larry Altneu <email>larry@ALR.COM</email> �� - &a.wilko;��, <devicename>wt</devicename> - �ɥ饤�Ф���ɤ��뤿��� Wangtek �� Archive �� QIC-02 - �ơ��ץɥ饤�֤��󶡤��Ƥ��������ޤ���.</para> - </listitem> - - <listitem> - <para>Ernst Winter <email>ewinter@lobo.muc.de</email> ��, - ���Υץ��������Ȥ� 2.88 MB - �Υե��åԡ��ɥ饤�֤��󶡤��Ƥ��������ޤ���. - ���ޤ�������, - ����ǥե��åԡ��ǥ������ɥ饤�Ф��ľ������� - �ץ�å��㡼��������Ǥ��礦.</para> - </listitem> - - <listitem> - <para><ulink url="http://www.tekram.com/">Tekram - Technologies</ulink> �� NCR �ɥ饤�Ф� AMD - �ɥ饤�Фȼ��ҤΥ����ɤεչԥƥ��ȤΤ��� FAST/ULTRA - SCSI �ۥ��ȥ����ץ� DC-390, DC-390U, DC-390F �� - �ƣ����󶡤��Ƥ��������ޤ���. �ޤ�, �ե꡼�� OS - �Τ���Υɥ饤�Ф� �������ò¼«¼Ò¤ï¿½ FTP ������ <ulink - url="ftp://ftp.tekram.com/scsi/FreeBSD/"> - ftp://ftp.tekram.com/scsi/FreeBSD/</ulink> - �Ǹ�������Ƥ��뤳�Ȥ�λ����ͤ���Ǥ��礦.</para> - </listitem> - - <listitem> - <para>Larry M. Augustin - �� Symbios Sym8751S SCSI - �����ɤ��£���Ƥ������ä������Ǥʤ�, Ultra-2 �� LVD - �ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½ë¼¡ï¿½ï¿½ï¿½ï¿½ï¿½Ã¥ï¿½ Sym53c895 �Τ�Τ�ޤ� - �ǡ����֥å��Υ��åȤ�, �ǿ��� Symbios SCSI - ���åפ��������Ū��ǽ������˻Ȥ���ˡ�ˤĤ��ƽñ¤«¤ì¤¿ - �ǿ��Υץ�����ߥ󥰥ޥ˥奢����£���Ƥ��������ޤ���. - �����ˤ��꤬�Ȥ��������ޤ�!</para> - </listitem> - - <listitem> - <para>Christoph Kukulies <email>kuku@FreeBSD.org</email> - ��, IDE CD-ROM �ɥ饤�г�ȯ�Ѥ� FX120 12 ��® Mitsumi - CD-ROM �ɥ饤�֤��󶡤��Ƥ��������ޤ���.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para><emphasis>��ɮ���٤���£��:</emphasis></para> - - <itemizedlist> - <listitem> - <para><ulink url="http://www.bsdi.com/">BSDi - </ulink> ��, - ����ɽ���ʤ��ۤ�¿���δ��դò¤·¤Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ (�ܺ٤� - <link linkend="history">FreeBSD ����</link>�ò»²¾ï¿½). - �ä�, �䤿���Τ�Ȥ�ȤΥץ饤�ޥ곫ȯ�ޥ���Ǥ��� - <hostid role="fqdn">freefall.FreeBSD.org</hostid>, - �ƥ��Ȥ���ӥӥ�ɥޥ���Ǥ��� <hostid - role="fqdn">thud.FreeBSD.org</hostid> - �ǻ��Ѥ��Ƥ���ϡ��ɥ��������Ф����դ������Ȼפ��ޤ�. - �ޤ����ˤ�, ��ǯ�ˤ錄�뿧���ʹ׸��Ԥؤλ���󶡤�, - ���󥿡��ͥåȤؤ� T1 ���ͥ�������̵���»��Ѥ��󶡤��� - ĺ��������������ޤ�.</para> - </listitem> - - <listitem> - <para><ulink - url="http://www.interface-business.de/">interface - business GmbH, Dresden</ulink> ��, &a.joerg; - �òº¬µï¿½ï¿½è¤¯ï¿½ï¿½ï¿½Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½. ����ܿ���� - FreeBSD �λŻ��ò¹¥¤ß¤ï¿½ï¿½ï¿½ï¿½Ç¤ï¿½ï¿½ï¿½, ��Ŀͤ���³�����ޤ�� - �٤��ʤä������ڤ줿�ꤷ�ƻŻ��ˤʤ�ʤ�����ɬ�� - interface business �� (���˹����) EUnet - ���󥿡��ͥå���³����ä���ΤǤ�...</para> - </listitem> - - <listitem> - <para><ulink url="http://www.bsdi.com/">Berkeley Software - Design, Inc.</ulink> ��, Ʊ�Ҥ� DOS - ���ߥ�졼���Υ����ɤ� - BSD ���ߥ�˥ƥ����Τ��Ф����󶡤��Ƥ���ޤ���. ���Υ����ɤ�, - <emphasis>doscmd</emphasis> - ���ޥ�ɤ����Ѥ���Ƥ��ޤ�.</para> - </listitem> - </itemizedlist> - </listitem> - </itemizedlist> - </sect1> - - <sect1 id="contrib-corealumni"> - <title>�����������´����</title> - - <indexterm><primary>����������(core team)</primary></indexterm> - - <para>���˵󤲤�͡���()�ǵ���������, FreeBSD - ����������Υ��С��Ǥ���. FreeBSD - �ץ��������Ȥˤ������������Ϥ˴��դΰդ�ɽ���ޤ�. - </para> - - <para><emphasis>����������ǯ���:</emphasis></para> - - <itemizedlist> - <listitem> - <para>&a.ache (1993 - 2000)</para> - </listitem> - - <listitem> - <para>&a.jmb (1993 - 2000)</para> - </listitem> - - <listitem> - <para>&a.bde (1992 - 2000)</para> - </listitem> - - <listitem> - <para>&a.gibbs (1993 - 2000)</para> - </listitem> - - <listitem> - <para>&a.rich (1994 - 2000)</para> - </listitem> - - <listitem> - <para>&a.phk (1992 - 2000)</para> - </listitem> - - <listitem> - <para>&a.gpalmer (1993 - 2000)</para> - </listitem> - - <listitem> - <para>&a.sos (1993 - 2000)</para> - </listitem> - - <listitem> - <para>&a.wollman (1993 - 2000)</para> - </listitem> - - <listitem> - <para>&a.joerg (1995 - 2000)</para> - </listitem> - - <listitem> - <para>&a.jdp (1997 - 2000)</para> - </listitem> - - <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 id="contrib-develalumni"> - <title>��ȯ�������´����</title> - - <indexterm><primary>��ȯ������(development team)</primary></indexterm> - - <para>���ˤ�����Τ�, ���Ĥ� FreeBSD - ��ȯ������ΰ�����ä��͡��Ǥ�. - FreeBSD �ץ��������Ȥ˹׸����Ƥ������ä����˴��դ��ޤ�.</para> - - <para><emphasis>�ۤ�ǯ����:</emphasis></para> - - <itemizedlist> - <listitem> - <para>&a.tedm (???? - 2000)</para> - </listitem> - <listitem> - <para>&a.karl (???? - 2000)</para> - </listitem> - <listitem> - <para>&a.gclarkii (1993 - 2000)</para> - </listitem> - <listitem> - <para>&a.jraynard (???? - 2000)</para> - </listitem> - <listitem> - <para>&a.jgreco (???? - 1999)</para> - </listitem> - <listitem> - <para>&a.ats (???? - 1999)</para> - </listitem> - <listitem> - <para>Jamil Weatherby (1997 - 1999)</para> - </listitem> - <listitem> - <para>meganm (???? - 1998)</para> - </listitem> - <listitem> - <para>&a.dyson (???? - 1998)</para> - </listitem> - <listitem> - <para>Amancio Hasty (1997 - 1998)</para> - </listitem> - <listitem> - <para>Drew Derbyshire (1997 - 1998)</para> - </listitem> - </itemizedlist> - </sect1> - - <sect1 id="contrib-derived"> - <title>BSD �������եȥ������ؤΥ���ȥ�ӥ塼��</title> - - <para>���Υ��եȥ������Ϻǽ�� William F. Jolitz �� 386BSD release - 0.1 �����������ޤ�����, ���ꥸ�ʥ�� 386BSD - �˸�Í�Υ����ɤϤۤȤ�ɻĤäƤ��ޤ���. - ���Υ��եȥ������ϴ���Ū�ˤϥ���ե���˥���� �С����쥤���� - Computer Science Research Group (CSRG) �Ȥ��ζ�Ʊ����� - �����ˤ�� 4.4BSD-Lite ��꡼������Ƽ�������ޤ���.</para> - - <para>�ޤ�, NetBSD �� OpenBSD ����� FreeBSD - �˼����ޤ�Ƥ��ޤ�. �������äƻ䤿���� NetBSD �� OpenBSD - �ع׸������͡����٤Ƥ˴��դ��ޤ�.</para> - </sect1> - - <sect1 id="contrib-additional"> - <title>����¾�� FreeBSD �ؤΥ���ȥ�ӥ塼��</title> - - <para>(̾���ǥ���ե��٥åȽ��):</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 Herzog <email>adam@herzogdesigns.com</email></para> - </listitem> - - <listitem> - <para>Adam Kranzel <email>adam@alameda.edu</email></para> - </listitem> - - <listitem> - <para>Adam McDougall <email>mcdouga9@egr.msu.edu</email></para> - </listitem> - - <listitem> - <para>Adam Strohl <email>troll@digitalspark.net</email></para> - </listitem> - - <listitem> - <para>Adoal Xu <email>adoal@iname.com</email></para> - </listitem> - - <listitem> - <para>Adrian Colley <email>aecolley@ois.ie</email></para> - </listitem> - - <listitem> - <para>Adrian Hall <email>ahall@mirapoint.com</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>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>Aleksandr A Babaylov <email>.@babolo.ru</email></para> - </listitem> - - <listitem> - <para>Alex G. Bulushev <email>bag@demos.su</email></para> - </listitem> - - <listitem> - <para>Alex D. Chen - <email>dhchen@Canvas.dorm7.nccu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Alex Le Heux <email>alexlh@funk.org</email></para> - </listitem> - - <listitem> - <para>Alex Kapranoff <email>kappa@zombie.antar.bryansk.ru</email></para> - </listitem> - - <listitem> - <para>Alex Perel <email>veers@disturbed.net</email></para> - </listitem> - - <listitem> - <para>Alex Semenyaka <email>alex@rinet.ru</email></para> - </listitem> - - <listitem> - <para>Alex Varju <email>varju@webct.com</email></para> - </listitem> - - <listitem> - <para>Alex Zepeda <email>garbanzo@hooked.net</email></para> - </listitem> - - <listitem> - <para>Alexander B. Povolotsky <email>tarkhil@mgt.msk.ru</email></para> - </listitem> - - <listitem> - <para>Alexander Gelfenbain <email>mail@gelf.com</email></para> - </listitem> - - <listitem> - <para>Alexander Leidinger - <email>netchild@wurzelausix.CS.Uni-SB.DE</email></para> - </listitem> - - <listitem> - <para>Alexandre Peixoto - <email>alexandref@tcoip.com.br</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 Bowhill <email>bowhill@bowhill.vservers.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>Amir Shalem <email>amir@boom.org.il</email></para> - </listitem> - - <listitem> - <para>Amy Baron <email>amee@beer.org</email></para> - </listitem> - - <listitem> - <para>The Anarcat <email>beaupran@iro.umontreal.ca</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 Andersson <email>anders@codefactory.se</email></para> - </listitem> - - <listitem> - <para>Anders Nordby <email>anders@fix.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 Goeree <email>abgoeree@uwnet.nl</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 L. Neporada <email>andrew@chg.ru</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 Novikov <email>andrey@novikov.com</email></para> - </listitem> - - <listitem> - <para>Andrey Simonenko <email>simon@comsys.ntu-kpi.kiev.ua</email></para> - </listitem> - - <listitem> - <para>Andrey Tchoritch <email>andy@venus.sympad.net</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 N. Bruesov <email>antonz@library.ntu-kpi.kiev.ua</email></para> - </listitem> - - <listitem> - <para>Anton Voronin <email>anton@urc.ac.ru</email></para> - </listitem> - - <listitem> - <para>Antti Kaipila <email>anttik@iki.fi</email></para> - </listitem> - - <listitem> - <para>arci <email>vega@sophia.inria.fr</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>Arindum Mukerji <email>rmukerji@execpc.com</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>Arun Sharma <email>adsharma@sharmas.dhs.org</email></para> - </listitem> - - <listitem> - <para>Arnaud S. Launay <email>asl@launay.org</email></para> - </listitem> - - <listitem> - <para>Ask Bjoern Hansen <email>ask@valueclick.com</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>Atushi Sakauchi <email>sakauchi@yamame.to</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 Walter <email>bwalter@itachi.swcp.com</email></para> - </listitem> - - <listitem> - <para>Benjamin Lewis <email>bhlewis@gte.net</email></para> - </listitem> - - <listitem> - <para>Berend de Boer <email>berend@pobox.com</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 Wilcox <email>bob@obiwan.uucp</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 Faulkner <email>faulkner@mpd.tandem.com</email></para> - </listitem> - - <listitem> - <para>Boyd R. Faulkner <email>faulkner@asgard.bga.com</email></para> - </listitem> - - <listitem> - <para>Brad Chapman <email>chapmanb@arches.uga.edu</email></para> - </listitem> - - <listitem> - <para>Brad Hendrickse <email>bradh@uunet.co.za</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>Brad Jones <email>brad@kazrak.com</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>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.runet.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 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>Chad David <email>davidc@acns.ab.ca</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@scientech.com</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>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>&a.cshumway;</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@mips.inka.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 N. Harrell <email>cnh@ivmg.net</email></para> - </listitem> - - <listitem> - <para>Christopher Preston <email>rbg@gayteenresource.org</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>Cliff Rowley <email>dozprompt@onsea.com</email></para> - </listitem> - - <listitem> - <para>Colman Reilly <email>careilly@tcd.ie</email></para> - </listitem> - - <listitem> - <para>Conrad Sabatier <email>conrads@home.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>Cyrille Lefevre <email>clefevre@citeweb.net</email></para> - </listitem> - - <listitem> - <para>Cyrus Rahman <email>cr@jcmax.com</email></para> - </listitem> - - <listitem> - <para>Dai Ishijima <email>ishijima@tri.pref.osaka.jp</email></para> - </listitem> - - <listitem> - <para>Daisuke Watanabe <email>NU7D-WTNB@asahi-net.or.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 Langille <email>dan@freebsddiary.org</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 Papasian <email>bugg@bugg.strangled.net</email></para> - </listitem> - - <listitem> - <para>Dan Piponi <email>wmtop@tanelorn.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Dan Walters <email>hannibal@cyberstation.net</email></para> - </listitem> - - <listitem> - <para>Daniel Hagan - <email>dhagan@cs.vt.edu</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>Daniel W. McRobb <email>dwm@caimis.com</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@eece.unm.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>unknown</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 Muir Sharnoff <email>muir@idiom.com</email></para> - </listitem> - - <listitem> - <para>David Sugar <email>dyfet@gnu.org</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>Denis Shaposhnikov <email>dsh@vlink.ru</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>der Mouse <email>mouse@Collatz.McRCIM.McGill.EDU</email></para> - </listitem> - - <listitem> - <para>Derek Inksetter <email>derek@saidev.com</email></para> - </listitem> - - <listitem> - <para>DI. Christian Gusenbauer - <email>cg@scotty.edvz.uni-linz.ac.at</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>Dishanker Rajakulendren <email>draj@oceanfree.net</email></para> - </listitem> - - <listitem> - <para>Dmitry A. Yanko<email>fm@astral.ntu-kpi.kiev.ua</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>Domas Mituzas <email>midom@dammit.lt</email></para> - </listitem> - - <listitem> - <para>Dominik Brettnacher <email>domi@saargate.de</email></para> - </listitem> - - <listitem> - <para>Dominik Rothert <email>dr@domix.de</email></para> - </listitem> - - <listitem> - <para>Don Croyle <email>croyle@gelemna.ft-wayne.in.us</email></para> - </listitem> - - <listitem> - <para>Donn Miller <email>dmmiller@cvzoom.net</email></para> - </listitem> - - <listitem> - <para>Dan Pelleg <email>dpelleg+unison@cs.cmu.edu</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>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>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 Chuang <email>edwardc@firebird.org.tw</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>Edwin Mons <email>e@ik.nu</email></para> - </listitem> - - <listitem> - <para>Ege Rekk <email>aagero@aage.priv.no</email></para> - </listitem> - - <listitem> - <para>Eiji-usagi-MATSUmoto <email>usagi@clave.gr.jp</email></para> - </listitem> - - <listitem> - <para>Eike Bernhardt <email>eike.bernhardt@gmx.de</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>Eoin Lawless <email>eoin@maths.tcd.ie</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>Erich Zigler <email>erich@tacni.net</email></para> - </listitem> - - <listitem> - <para>Erik H. Bakke <email>erikhb@bgnett.no</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 de Haan <email>ernst@heinz.jollem.com</email></para> - </listitem> - - <listitem> - <para>Ernst Winter <email>ewinter@lobo.muc.de</email></para> - </listitem> - - <listitem> - <para>Espen Skoglund <email>esk@ira.uka.de</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>Eugeny Kuzakov <email>CoreDumped@coredumped.null.ru</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@batmule.dk</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>Francisco Reyes <email>fjrm@yahoo.com</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 Nobis <email>fn@Radio-do.de</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>Frank Volf <email>volf@oasis.IAEhv.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>FURUSAWA Kazuhisa - <email>furusawa@com.cs.osakafu-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>&a.stanislav;</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>Garance A Drosehn <email>gad@eclipse.its.rpi.edu</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>Gene Raytsin <email>pal@paladin7.net</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>Gianlorenzo Masini <email>masini@uniroma3.it</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>Giles Lean <email>giles@nemeton.com.au</email></para> - </listitem> - - <listitem> - <para>Ginga Kawaguti - <email>ginga@amalthea.phys.s.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Giorgos Keramidas <email>keramida@ceid.upatras.gr</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 Robinson <email>greg@rosevale.com.au</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>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>Harry Newton <email>harry_newton@telinco.co.uk</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 Lamm <email>holger@eit.uni-kl.de</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>HONDA Yasuhiro - <email>honda@kashio.info.mie-u.ac.jp</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>HOSOBUCHI Noriyuki <email>hoso@buchi.tama.or.jp</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>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 Serikov <email>bt@turtle.pangeatech.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>Ilia Chipitsine <email>ilia@jane.cgu.chel.su</email></para> - </listitem> - - <listitem> - <para>Ilya V. Komarov <email>mur@lynx.ru</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>Itsuro Saito <email>saito@miv.t.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>IWASHITA Yoji <email>shuna@pop16.odn.ne.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@photino.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>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 Hamby <email>jehamby@anobject.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 da Silva <email>jds@cs.umd.edu</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>Jamie Heckford <email>jamie@jamiesdomain.co.uk</email></para> - </listitem> - - <listitem> - <para>Jan Conard - <email>charly@fachschaften.tu-muenchen.de</email></para> - </listitem> - - <listitem> - <para>Jan Jungnickel <email>Jan@Jungnickel.com</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 DiCioccio <email>geniusj@ods.org</email></para> - </listitem> - - <listitem> - <para>Jason Garman <email>init@risen.org</email></para> - </listitem> - - <listitem> - <para>Jason R. Mastaler - <email>jason-freebsd@mastaler.com</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>Jay Krell <email>jay.krell@cornell.edu</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 Brown <email>jabrown@caida.org</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>Jeff Palmer <email>scorpio@drkshdw.org</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>Jeremy Allison <email>jallison@whistle.com</email></para> - </listitem> - - <listitem> - <para>Jeremy Chadwick <email>yoshi@parodius.com</email></para> - </listitem> - - <listitem> - <para>Jeremy Chatfield <email>jdc@xinside.com</email></para> - </listitem> - - <listitem> - <para>Jeremy Karlson <email>karlj000@unbc.ca</email></para> - </listitem> - - <listitem> - <para>Jeremy Prior <email>unknown</email></para> - </listitem> - - <listitem> - <para>Jeremy Shaffner <email>jeremy@external.org</email></para> - </listitem> - - <listitem> - <para>Jesse McConnell <email>jesse@cylant.com</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 Bloom <email>bloom@acm.org</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 Sloan <email>odinn@atlantabiker.net</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>kuebart@mathematik.uni-ulm.de</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@marcuscom.com</email></para> - </listitem> - - <listitem> - <para>Joe Abley <email>jabley@automagic.org</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>jsutton@bbcon.com.au</email></para> - </listitem> - - <listitem> - <para>Jordan DeLong <email>fracture@allusion.net</email></para> - </listitem> - - <listitem> - <para>Joseph Scott <email>joseph@randomnetworks.com</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 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 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 Merryweather Cooper <email>jmcoopr@webmail.bmi.net</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 Reynolds <email>jjreynold@home.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 Wehle <email>john@feith.com</email></para> - </listitem> - - <listitem> - <para>John Woods <email>jfw@eddie.mit.edu</email></para> - </listitem> - - <listitem> - <para>Johny Mattsson <email>lonewolf@flame.org</email></para> - </listitem> - - <listitem> - <para>Jon Morgan <email>morgan@terminus.trailblazer.com</email></para> - </listitem> - - <listitem> - <para>Jonathan Belson <email>jon@witchspace.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>Jonathan Pennington <email>john@coastalgeology.org</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 Marques <email>jose@nobody.org</email></para> - </listitem> - - <listitem> - <para>Josef Grosch - <email>jgrosch@superior.mooseriver.com</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>jau@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>Justas <email>justas@mbank.lv</email></para> - </listitem> - - <listitem> - <para>Justin Stanford <email>jus@security.za.net</email></para> - </listitem> - - <listitem> - <para>K.Higashino <email>a00303@cc.hc.keio.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>Kang-ming Liu <email>gugod@gugod.org</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 Tsuguru <email>tkato@prontomail.ne.jp</email></para> - </listitem> - - <listitem> - <para>Kawanobe Koh <email>kawanobe@st.rim.or.jp</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>kew@icehouse.net</email></para> - </listitem> - - <listitem> - <para>Keith Moore <email>unknown</email></para> - </listitem> - - <listitem> - <para>Keith Sklower <email>unknown</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 Meltzer <email>perlguy@perlguy.com</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>Killer <email>killer@prosalg.no</email></para> - </listitem> - - <listitem> - <para>Kim Scarborough <email>sluggo@unknown.nu</email></para> - </listitem> - - <listitem> - <para>Kiril Mitev <email>kiril@ideaglobal.com</email></para> - </listitem> - - <listitem> - <para>Kiroh HARADA <email>kiroh@kh.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Klaus Herrmann <email>klaus.herrmann@gmx.net</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>Konrad Heuer <email>kheuer@gwdu60.gwdg.de</email></para> - </listitem> - - <listitem> - <para>Konstantin Chuguev <email>Konstantin.Chuguev@dante.org.uk</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>Kris Dow <email>kris@vilnya.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>KUNISHIMA Takeo <email>kunishi@c.oka-pu.ac.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>Larry Altneu <email>larry@ALR.COM</email></para> - </listitem> - - <listitem> - <para>Lars Bernhardsson <email>lab@fnurt.net</email></para> - </listitem> - - <listitem> - <para>Lars Köller - <email>Lars.Koeller@Uni-Bielefeld.DE</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>Leo Kim <email>leo@florida.sarang.net</email></para> - </listitem> - - <listitem> - <para>Leo Serebryakov <email>lev@serebryakov.spb.ru</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>Lowell Gilbert <email>lowell@world.std.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.ab.ca</email></para> - </listitem> - - <listitem> - <para>M. L. Dodson <email>bdodson@scms.utmb.EDU</email></para> - </listitem> - - <listitem> - <para>M.C. Wong <email>unknown</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>Makoto YAMAKURA <email>makoto@pinpott.spnet.ne.jp</email></para> - </listitem> - - <listitem> - <para>Malte Lance <email>malte.lance@gmx.net</email></para> - </listitem> - - <listitem> - <para>MANTANI Nobutaka <email>nobutaka@nobutaka.com</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>Marcin Cieslak <email>saper@system.pl</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 Knight <email>markk@knigma.org</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@thuvia.org</email></para> - </listitem> - - <listitem> - <para>Markus Holmberg <email>saska@acc.umu.se</email></para> - </listitem> - - <listitem> - <para>Martin Birgmeier <email>unknown</email></para> - </listitem> - - <listitem> - <para>Martin Blapp <email>blapp@attic.ch</email></para> - </listitem> - - <listitem> - <para>Martin Hinner <email>mhi@linux.gyarab.cz</email></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 Minkus <email>diskiller@cnbinc.com</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>Masahiro Sekiguchi - <email>seki@sysrap.cs.fujitsu.co.jp</email></para> - </listitem> - - <listitem> - <para>Masahiro TAKEMURA - <email>mastake@msel.t.u-tokyo.ac.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 Heckaman <email>matt@LUCIDA.QC.CA</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 Emmerton <email>root@gabby.gsicomp.on.ca</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>Matthew West <email>mwest@uct.ac.za</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 Konovalov <email>maxim@macomnet.ru</email></para> - </listitem> - - <listitem> - <para>Maxime Henrion <email>mhenrion@cybercable.fr</email></para> - </listitem> - - <listitem> - <para>Micha Class - <email>michael_class@hpbbse.bbn.hp.com</email></para> - </listitem> - - <listitem> - <para>Michael Alyn Miller <email>malyn@strangeGizmo.com</email></para> - </listitem> - - <listitem> - <para>Michael Lucas <email>mwlucas@blackhelicopters.org</email></para> - </listitem> - - <listitem> - <para>Michael Lyngbøl <email>michael@lyngbol.dk</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 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>Michael Urban <email>murban@tznet.com</email></para> - </listitem> - - <listitem> - <para>Michael Vasilenko <email>acid@stu.cn.ua</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 Bristow <email>mike@urgle.com</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 Futerko <email>mike@LITech.lviv.ua</email></para> - </listitem> - - <listitem> - <para>Mike Grupenhoff <email>kashmir@umiacs.umd.edu</email></para> - </listitem> - - <listitem> - <para>Mike Harding <email>mvh@ix.netcom.com</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@mired.org</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 Sherwood <email>mike@fate.com</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>Ming-I Hseh <email>PA@FreeBSD.ee.Ntu.edu.TW</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>MOROHOSHI Akihiko <email>moro@race.u-tokyo.ac.jp</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>N.G.Smith <email>ngs@sesame.hensa.ac.uk</email></para> - </listitem> - - <listitem> - <para>Nadav Eiron <email>nadav@barcode.co.il</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>NAKATA, Maho <email>chat95@mbox.kyoto-inet.or.jp</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 Dorfman <email>nathan@rtfm.net</email></para> - </listitem> - - <listitem> - <para>Neal Fachan <email>kneel@ishiboo.com</email></para> - </listitem> - - <listitem> - <para>Niall Smart <email>rotel@indigo.ie</email></para> - </listitem> - - <listitem> - <para>Nicholas Esborn <email>nick@netdot.net</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>Nick Johnson <email>freebsd@spatula.net</email></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>NIIMI Satoshi <email>sa2c@and.or.jp</email></para> - </listitem> - - <listitem> - <para>Niklas Hallqvist <email>niklas@filippa.appli.se</email></para> - </listitem> - - <listitem> - <para>Nils M. Holm <email>nmh@t3x.org</email></para> - </listitem> - - <listitem> - <para>Nisha Talagala <email>nisha@cs.berkeley.edu</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>frf@xocolatl.com</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>No Name <email>ZW6T-KND@j.asahi-net.or.jp</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>NOKUBI Hirotaka <email>h-nokubi@yyy.or.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>Oddbjorn Steffenson <email>oddbjorn@tricknology.org</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 Semyonov <email>os@altavista.net</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>Olexander Kunytsa <email>kunia@wolf.istc.kiev.ua</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 Helmling - <email>oliver.helmling@stud.uni-bayreuth.de</email></para> - </listitem> - - <listitem> - <para>Oliver Laumann - <email>net@informatik.uni-bremen.de</email></para> - </listitem> - - <listitem> - <para>Oliver Lehmann - <email>Kai_Allard_Liao@gmx.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 Alken <email>cosine@ellipse.mcs.drexel.edu</email></para> - </listitem> - - <listitem> - <para>Patrick Bihan-Faou <email>patrick@mindstep.com</email></para> - </listitem> - - <listitem> - <para>Patrick Hausen <email>unknown</email></para> - </listitem> - - <listitem> - <para>Patrick Li <email>pat@databits.net</email></para> - </listitem> - - <listitem> - <para>Patrick Seal <email>patseal@hyperhost.net</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 M. Lambert <email>plambert@plambert.net</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 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>Per Wigren <email>wigren@home.se</email></para> - </listitem> - - <listitem> - <para>Pete Bentley <email>pete@demon.net</email></para> - </listitem> - - <listitem> - <para>Pete Fritchman <email>petef@databits.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>peter.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>Peter van Heusden <email>pvh@egenetics.com</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>Philippe Lefebvre <email>nemesis@balistik.net</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>Priit Järv <email>priit@cc.ttu.ee</email></para> - </listitem> - - <listitem> - <para>R Joseph Wright <email>rjoseph@mammalia.org</email></para> - </listitem> - - <listitem> - <para>R. Kym Horsell</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>Rasmus Kaj <email>kaj@Raditex.se</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>Rich Wood <email>rich@FreeBSD.org.uk</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@enteract.com</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 P Ricci <email>ricci@cs.utah.edu</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 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>Rod Taylor <email>rod@idiotswitch.org</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>Roman Shterenzon <email>roman@xpert.com</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>cejkar@dcse.fee.vutbr.cz</email></para> - </listitem> - - <listitem> - <para>Ruslan Belkin <email>rus@home2.UA.net</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@af.airnet.ne.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>Samuel Tardieu <email>sam@inf.enst.fr</email></para> - </listitem> - - <listitem> - <para>Samuele Zannoli <email>zannoli@cs.unibo.it</email></para> - </listitem> - - <listitem> - <para>Sander Janssen <email>janssen@rendo.dekooi.nl</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>SANETO Takanori <email>sanewo@strg.sony.co.jp</email></para> - </listitem> - - <listitem> - <para>SASAKI Shunsuke <email>ele@pop17.odn.ne.jp</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>SAWADA Mizuki <email>miz@qb3.so-net.ne.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 A. Moberly <email>smoberly@xavier.dyndns.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 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 N. Vorokov <email>serg@tmn.ru</email></para> - </listitem> - - <listitem> - <para>Sergey Potapov <email>sp@alkor.ru</email></para> - </listitem> - - <listitem> - <para>Sergey Samoyloff <email>gonza@techline.ru</email></para> - </listitem> - - <listitem> - <para>Sergey Shkonda <email>serg@bcs.zp.ua</email></para> - </listitem> - - <listitem> - <para>Sergey Skvortsov <email>skv@protey.ru</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>Shinya FUJIE <email>fujie@tk.elec.waseda.ac.jp</email></para> - </listitem> - - <listitem> - <para>Shuichi Tanaka <email>stanaka@bb.mbn.or.jp</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 Dick <email>simond@irrelevant.org</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@wheel.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>Eric D. Futch <email>efutch@nyct.net</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@unm.edu</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 Enderle <email>panic@subphase.de</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>Stijn Hoop <email>stijn@win.tue.nl</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>SUGIMURA Takashi <email>sugimura@jp.FreeBSD.org</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>Sungman Cho <email>smcho@tsp.korea.ac.kr</email></para> - </listitem> - - <listitem> - <para>Sune Stjerneby <email>stjerneby@usa.net</email></para> - </listitem> - - <listitem> - <para>SURANYI Peter - <email>suranyip@jks.is.tsukuba.ac.jp</email></para> - </listitem> - - <listitem> - <para>Suzuki Yoshiaki - <email>zensyo@ann.tama.kawasaki.jp</email></para> - </listitem> - - <listitem> - <para>Svein Skogen - <email>tds@nsn.no</email></para> - </listitem> - - <listitem> - <para>Sybolt de Boer <email>bolt@xs4all.nl</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>TAKAHASHI Kaoru <email>kaoru@kaisei.org</email></para> - </listitem> - - <listitem> - <para>Takahiro Yugawa <email>yugawa@orleans.rim.or.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>Tatsuya Kudoh <email>cdr@cosmonet.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 Graichen - <email>graichen@omega.physik.fu-berlin.de</email></para> - </listitem> - - <listitem> - <para>Thomas König - <email>Thomas.Koenig@ciw.uni-karlsruhe.de</email></para> - </listitem> - - <listitem> - <para>Thomas Ptacek <email>unknown</email></para> - </listitem> - - <listitem> - <para>Thomas Quinot <email>thomas@cuivre.fr.eu.org</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>Þórður Ívarsson - <email>totii@est.is</email></para> - </listitem> - - <listitem> - <para>Thierry Thomas <email>tthomas@mail.dotcom.fr</email></para> - </listitem> - - <listitem> - <para>Timothy Jensen <email>toast@blackened.com</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>Tobias Reifenberger <email>treif@mayn.de</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 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>Trenton Schulz <email>twschulz@cord.edu</email></para> - </listitem> - - <listitem> - <para>Trevor Blackwell <email>tlb@viaweb.com</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>URATA Shuichiro <email>s-urata@nmit.tmg.nec.co.jp</email></para> - </listitem> - - <listitem> - <para>Uwe Arndt <email>arndt@mailhost.uni-koblenz.de</email></para> - </listitem> - - <listitem> - <para>Vadim Belman <email>vab@lflat.vas.mobilix.dk</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>Valentin Nechayev <email>netch@lucky.net</email></para> - </listitem> - - <listitem> - <para>&a.logo;</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>Veselin Slavov <email>vess@btc.net</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>Vince Valenti <email>vince@blue-box.net</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>Walt M. Shandruk <email>walt@erudition.net</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>Wiljo Heinen <email>wiljo@freeside.ki.open.de</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>Yasuhiro Fukama <email>yasuf@big.or.jp</email></para> - </listitem> - - <listitem> - <para>Yasuhito FUTATSUKI <email>futatuki@fureai.or.jp</email></para> - </listitem> - - <listitem> - <para>Yen-Ming Lee <email>leeym@bsd.ce.ntu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Yen-Shuo Su <email>yssu@CCCA.NCTU.edu.tw</email></para> - </listitem> - - <listitem> - <para>Yin-Jieh Chen <email>yinjieh@Crazyman.Dorm13.NCTU.edu.tw</email></para> - </listitem> - - <listitem> - <para>Yixin Jin <email>yjin@rain.cs.ucla.edu</email></para> - </listitem> - - <listitem> - <para>Yoichi Asai <email>yatt@msc.biglobe.ne.jp</email></para> - </listitem> - - <listitem> - <para>Yoichi Nakayama <email>yoichi@eken.phys.nagoya-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Yoshiaki Uchikawa <email>yoshiaki@kt.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Yoshihiko SARUMRU <email>mistral@imasy.or.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>Yu-Shun Wang <email>yushunwa@isi.edu</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>Yuuki SAWADA <email>mami@whale.cc.muroran-it.ac.jp</email></para> - </listitem> - - <listitem> - <para>Yuuichi Narahara <email>aconitum@po.teleway.ne.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>Zach Zurflu <email>zach@pabst.bendnet.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> - </itemizedlist> - </sect1> - - <sect1 id="contrib-386bsd"> - <title>386BSD �ѥå����åȤؤΥѥå��󶡼�</title> - - <para>(̾���ǥ���ե��٥åȽ�):</para> - - <itemizedlist> - <listitem> - <para>Adam Glass <email>glass@postgres.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>Adrian Hall <email>ahall@mirapoint.com</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 Antony Halse <email>guy@rucus.ru.ac.za</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örg Lohse - <email>lohse@tech7.informatik.uni-hamburg.de</email></para> - </listitem> - - <listitem> - <para>Jö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>Konstantinos Konstantinidis <email>kkonstan@duth.gr</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: ("../book.sgml" "part" "chapter") - End: ---> diff --git a/ja_JP.eucJP/books/handbook/multimedia/Makefile b/ja_JP.eucJP/books/handbook/multimedia/Makefile deleted file mode 100644 index 2487a8c522..0000000000 --- a/ja_JP.eucJP/books/handbook/multimedia/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= sound/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml b/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml deleted file mode 100644 index 7f28fa7578..0000000000 --- a/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml +++ /dev/null @@ -1,397 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD Japanese Documentation Project - - Original revision: 1.11 - $FreeBSD: doc/ja_JP.eucJP/books/handbook/sound/chapter.sgml,v 1.4 2001/07/24 16:54:07 hrs Exp $ ---> - -<chapter id="sound"> - <chapterinfo> - <authorgroup> - <author> - <firstname>Moses</firstname> - <surname>Moore</surname> - <contrib>���</contrib> - </author> - </authorgroup> - <!-- 20 November 2000 --> - </chapterinfo> - - <title>�������</title> - - <sect1> - <title>���ξϤǤ�</title> - - <para>FreeBSD �Ϥ��ʤ��Υ���ԥ塼�����鸶������¤ʺ�����ڤ��ि���, - ��¿���μ���Υ�����ɥ����ɤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½. - ����ˤ��, MPEG Audio Layer 3 (MP3) �� WAV, Ogg Vorbis �ʤɤ� - ���ڤ�Ͽ�����������������Ǥ���褦�ˤʤ�ޤ�. - ��� FreeBSD Ports ���쥯�����ˤ�, ���ʤ���Ͽ���������ڤ� - �Խ�������, �������̤�ä�����, ��³���줿 MIDI ��������椷���� - ���뤿��Υ��ץꥱ������󤬴ޤޤ�Ƥ��ޤ�.</para> - -<!-- XXX we need to talk about ripping MP3s here. --> - - <para>���ξϤ��ɤ��, �ʲ��Τ��Ȥ��Τ뤳�Ȥ��Ǥ��ޤ�:</para> - <itemizedlist> - <listitem><para>������ɥ����ɤò¥¤¥ó¥¹¥È¡ï¿½ï¿½ë¤¹ï¿½ï¿½ï¿½ï¿½Ë¡.</para></listitem> - <listitem><para>�����ƥ�����ꤷ�ƥ�����ɥ����ɤ�ǧ����������ˡ. - </para></listitem> - <listitem><para>����ץ륢�ץꥱ�����������Ѥ��ƥ�����ɥ����ɤ� - ���ޤ�ư���Ƥ��뤫�ɤ�����ƥ��Ȥ�����ˡ.</para></listitem> - <listitem><para>������ɴ�Ϣ������Υȥ�֥륷�塼����ˡ. - </para></listitem> - </itemizedlist> - - <para>���ξϤ��ɤ�����, �ʲ��Τ��Ȥ����ò¤·¤Æ¤ï¿½ï¿½ï¿½É¬ï¿½×¤ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½: - - <itemizedlist> - <listitem><para>�����������ͥ�����ꤷ�ƥ��󥹥ȡ��뤹����ˡ (<xref - linkend="kernelconfig">)</para></listitem> - </itemizedlist> - </sect1> - - <sect1> - <title>�������ǥХ����γ�ǧ</title> - - <indexterm><primary>PCI</primary></indexterm> - <indexterm><primary>ISA</primary></indexterm> - <indexterm><primary>������ɥ�����</primary></indexterm> - <para>�����Ϥ��������, ���ʤ������äƤ��륫���ɤΥ�ǥ�, - ���Υ����ɤ����Ѥ��Ƥ�����å�, ������ PCI, ISA - �ɤ���Υ����ɤʤΤ����ǧ����ɬ�פ�����ޤ�. - FreeBSD ��, ���ޤ��ޤ� PCI ����� ISA �Υ����ɤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½. - �⤷���ʤ��Υ����ɤ����Υꥹ�Ȥ�̵������, - &man.pcm.4; �Υޥ˥奢��ڡ������ǧ���Ƥ�������. - ����ϴ����ʥꥹ�ȤǤϤ���ޤ���, - �ɤ��Ȥ��Ƥ��륫���ɤ����������ޤޤ�Ƥ��ޤ�.</para> - - <itemizedlist> - <listitem> - <para>Crystal 4237, 4236, 4232, 4231</para> - </listitem> - - <listitem> - <para>��ޥ� 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, ����� Logic ALS120</para> - </listitem> - - <listitem> - <para>ES 1868, 1869, 1879, 1888</para> - </listitem> - - <listitem> - <para>Gravis UltraSound</para> - </listitem> - - <listitem> - <para>Aureal Vortex 1 ����� 2</para> - </listitem> - </itemizedlist> - - <indexterm> - <primary>�����ͥ�</primary> - <secondary>����ե����졼�����</secondary> - </indexterm> - <para>�����ͥ���ǻ��Ѥ���ɥ饤�Ф�, - ���Ѥ��륫���ɤμ���ˤ�äưۤʤ�ޤ�. - ������Ǥ�, �����ξܤ��������, - <link linkend="kernelconfig">�����ͥ륳��ե����졼�����ե�����</link>�� - �����ɲä�����ɤ��Τ��ˤĤ����������ޤ�.</para> - - <sect2> - <title>Creative, Advance, ����� ESS ����������ɥ�����</title> - - <para>�����Υ����ɤ���Ѥ������, - �����ͥ륳��ե����졼�����ե�����˰ʲ���������ɲä��ޤ�.</para> - - <programlisting>device pcm</programlisting> - - <para>PnP �� ISA �����ɤ���Ѥ������, �����</para> - - <programlisting>device sbc</programlisting> - - <para>��ä��Ƥ�������. - PnP �ǤϤʤ� ISA �Υ����ɤ���Ѥ������,</para> - - <programlisting>device pcm</programlisting> - - <para>��</para> - - <programlisting>device sbc0 at isa? port0x220 irq 5 drq 1 flags 0x15</programlisting> - - <para>��ä��ޤ�. - ������ɸ�������ˤ��碌����ΤǤ��Τ�, - IRQ �ʤɤ������ɬ�פ˱������ѹ�����ɬ�פ�����ޤ�. - �ޤ�, ����ξܺ٤ˤĤ��Ƥ�, &man.sbc.4; - �Υޥ˥奢��ڡ����ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - - <note> - <para>�ѥå���Ŭ�Ѥ��Ƥ��ʤ� FreeBSD 4.0 �� - Sound Blaster Live ���б����Ƥ��ޤ���. - �ޤ�, ����ʸ��ǤϤ���������ˡ�ˤĤ��Ƥϰ����ޤ���. - ���Υ����ɤ���Ѥ�������, �ǿ��� -STABLE - �˥��åץǡ��Ȥ���褦�ˤ��Ƥ�������.</para> - </note> - </sect2> - - <sect2> - <title>Gravis ���� UltraSound ������</title> - - <para>PnP �� ISA �����ɤ���Ѥ���ˤ�, - �����ͥ륳��ե����졼�����ե�����˼��� - 2 �Ĥ�������ɲä��ޤ�.</para> - - <programlisting>device pcm</programlisting> - - <programlisting>device gusc</programlisting> - - <para>PnP �ǤϤʤ� ISA �����ɤξ��ˤ�,</para> - - <programlisting>device pcm</programlisting> - - <para>��</para> - - <programlisting>device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13</programlisting> - - <para>��ä��ޤ�. - IRQ �ʤɤ������ɬ�פ˱������ѹ�����ɬ�פ�����ޤ�. - �ޤ�, ����ξܺ٤ˤĤ��Ƥ�, &man.gusc.4; - �Υޥ˥奢��ڡ����ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - </sect2> - - <sect2> - <title>Crystal ����������ɥ�����</title> - - <para>Crystal �����Υ����ɤ���Ѥ������, - �����ͥ륳��ե����졼�����ե������</para> - - <programlisting>device pcm</programlisting> - - <para>��</para> - - <programlisting>device csa</programlisting> - - <para>��ξ����ɬ�פǤ�.</para> - </sect2> - - <sect2> - <title>����Ū�ʥ����ɤΥ��ݡ���</title> - - <para>PnP ISA �����ɤ� PCI �����ɤ���Ѥ������,</para> - - <programlisting>device pcm</programlisting> - - <para>�ò¥«¡ï¿½ï¿½Í¥ë¥³ï¿½ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ì¡¼ï¿½ï¿½ï¿½ï¿½ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½É²Ã¤ï¿½ï¿½Þ¤ï¿½. - �֥�å��ɥ饤�Ф�����ʤ�, PnP ����� ISA - �����ɤξ���,</para> - - <programlisting>device pcm0 at isa? irq 10 drq 1 flags 0x0</programlisting> - - <para>��ä��ޤ�. - IRQ �ʤɤ������, - �ϡ��ɥ�����������˹礦�褦��ɬ�פ˱������ѹ����Ƥ�������.</para> - </sect2> - </sect1> - - <sect1> - <title>�����ͥ�κƹ���</title> - - <para>ɬ�פ�����ò¥«¡ï¿½ï¿½Í¥ë¥³ï¿½ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ì¡¼ï¿½ï¿½ï¿½ï¿½ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½É²Ã¤ï¿½ï¿½ï¿½ï¿½ï¿½, - �����ͥ��ƹ��ۤ��ޤ�. - �ܺ٤ˤĤ��Ƥϥϥ�ɥ֥å���<xref linkend="kernelconfig-building">�ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - </sect1> - - <sect1> - <title>�ǥХ����Ρ��ɤκ����ȥƥ���</title> - - <indexterm><primary>�ǥХ����Ρ���</primary></indexterm> - <para>�Ƶ�ư������, �������󤷤� <command>cat /dev/sndstat</command> - ��¹Ԥ��ޤ�. �����, �ʲ��Τ褦�˽��Ϥ����Ϥ��Ǥ�.</para> - - <programlisting>FreeBSD Audio Driver (newpcm) Sep 21 2000 18:29:53 -Installed devices: -pcm0: <Aureal Vortex 8830> at memory 0xfeb40000 irq 5 (4p/1r +channels duplex)</programlisting> - - <para>���顼��å����������Ϥ�������, - ���ޤǤμ��Τɤ������ְ�äƤ��ޤ�. - �����ͥ륳��ե����졼�����ե������⤦���ٸ�ľ����, - �������ǥХ��������ò¤·¤Æ¤ï¿½ï¿½ë¤«ï¿½É¤ï¿½ï¿½ï¿½ï¿½ï¿½Ç§ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½.</para> - - <para>���顼�����Ϥ��줺�� <devicename>pcm0</devicename> - �����Ϥ��줿����, - <command>su</command> ���ޥ�ɤ� - <username>root</username> �ˤʤ�, - ���Τ褦�˼¹Ԥ��ޤ�.</para> - - <screen>&prompt.root; <userinput>cd /dev</userinput> -&prompt.root; <userinput>sh MAKEDEV snd0</userinput></screen> - - <para>���顼�����Ϥ��줺�� <devicename>pcm1</devicename> - �����Ϥ��줿����, - <command>su</command> ���ޥ�ɤ� - <username>root</username> �ˤʤ�, - ���Τ褦�˼¹Ԥ��ޤ�.</para> - - <screen>&prompt.root; <userinput>cd /dev</userinput> -&prompt.root; <userinput>sh MAKEDEV snd1</userinput></screen> - - <para>��Υ��ޥ�ɤϤɤ����, - <devicename>/dev/snd</devicename> �Ȥ��� - �ǥХ��������������<emphasis>�ǤϤʤ�</emphasis>�Ȥ����������դ��Ƥ�������! - �����������, - ���Τ褦��ʣ���ΥǥХ����Ρ��ɤ�������ޤ�.</para> - - <informaltable frame="none"> - <tgroup cols="2"> - <thead> - <row> - <entry>�ǥХ���</entry> - <entry>����</entry> - </row> - </thead> - - <tbody> - <row> - <entry><devicename>/dev/audio</devicename></entry> - <entry>SPARC �ߴ������ǥ����ǥХ���</entry> - </row> - - <row> - <entry><devicename>/dev/dsp</devicename></entry> - <entry>(����: 8 �ӥåȤ�) ����ץ�󥰤��벻���ǥХ���</entry> - </row> - - <row> - <entry><devicename>/dev/dspW</devicename></entry> - <entry><devicename>/dev/dsp</devicename>��Ʊ��. - ����������ץ�󥰤� 16 �ӥå�.</entry> - </row> - - <row> - <entry><devicename>/dev/midi</devicename></entry> - <entry>Raw MIDI ���������ǥХ���</entry> - </row> - - <row> - <entry><devicename>/dev/mixer</devicename></entry> - <entry>����ȥ�����ݡ��ȥߥ������ǥХ���</entry> - </row> - - <row> - <entry><devicename>/dev/music</devicename></entry> - <entry>��٥� 2 �������󥵥��󥿥ե�����</entry> - </row> - - <row> - <entry><devicename>/dev/sequencer</devicename></entry> - <entry>�������󥵥ǥХ���</entry> - </row> - - <row> - <entry><devicename>/dev/pss</devicename></entry> - <entry>�ץ�������ǽ�ʥǥХ������󥿥ե�����</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>���٤Ƥ��ޤ��Ԥ���, - ������ɥ����ɤε�ǽ����Ѥ��뤳�Ȥ��Ǥ��ޤ�. - ���ޤ��Ԥ��ʤ�����, �����������������.</para> - </sect1> - - <sect1> - <title>�褯��������</title> - - <qandaset> - <indexterm><primary>�ǥХ����Ρ���</primary></indexterm> - <qandaentry> - <question> - <para>unsupported subdevice XX error ���Фޤ���!</para> - </question> - - <answer> - <para>�����Ĥ��ΥǥХ����Ρ��ɤ���������������Ƥ��ޤ���. - ����μ���⤦���٤�äƤߤƤ�������.</para> - </answer> - </qandaentry> - - <indexterm><primary>I/O �ݡ���</primary></indexterm> - <qandaentry> - <question> - <para>sb_dspwr(XX) timed out error ���Фޤ���!</para> - </question> - - <answer> - <para>I/O �ݡ��Ȥ����������ꤵ��Ƥ��ޤ���.</para> - </answer> - </qandaentry> - - <indexterm><primary>IRQ</primary></indexterm> - <qandaentry> - <question> - <para>bad irq XX error ���Фޤ���!</para> - </question> - - <answer> - <para>IRQ �����������ꤵ��Ƥ��ޤ���. - �����ͥ륳��ե����졼�����ե�������� - IRQ �������, - ������ɥ����ɤ� IRQ �����꤬Ʊ���Ǥ��뤫��ǧ���Ƥ�������.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para><errorname>xxx: gus pcm not attached, out of memory</errorname> �Ȥ������顼���Фޤ�. - �����������ΤǤ��礦��?</para> - </question> - - <answer> - <para>�����, - �ǥХ�������Ѥ��뤿���ɬ�פʥ��꤬���ݤǤ��ʤ�����ɽ������ޤ�.</para> - </answer> - </qandaentry> - </qandaset> - </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/ja_JP.eucJP/man/man1/gtar.1 b/ja_JP.eucJP/man/man1/gtar.1 deleted file mode 100644 index 61b73b3d81..0000000000 --- a/ja_JP.eucJP/man/man1/gtar.1 +++ /dev/null @@ -1,597 +0,0 @@ -.\" Copyright (c) 1991, 1992, 1993 Free Software Foundation -*- nroff -*- -.\" See /usr/src/gnu/COPYING for conditions of redistribution -.\" -.\" Written by John F. Woods <jfw@jfwhome.funhouse.com> -.\" Updated by Robert Eckardt <roberte@mep.ruhr-uni-bochum.de> -.\" -.\" %FreeBSD: src/gnu/usr.bin/tar/tar.1,v 1.22.2.11 2001/08/16 10:14:58 ru Exp % -.\" -.\" $FreeBSD: doc/ja_JP.eucJP/man/man1/tar.1,v 1.22 2001/08/17 05:42:08 horikawa Exp $ -.Dd December 23, 2000 -.Os -.Dt TAR 1 -.Sh ̾�� -.Nm tar -.Nd "�ơ��ץ���������; ""tar"" ���������֥ե���������" -.Sh �� -.Nm -.Op Oo Fl Oc Ns Ar bundled-options Ar Args -.Op Ar gnu-style-flags -.Op Ar filenames | Fl C Ar directory-name -.Ar ... -.Sh ���� -.Nm -�ϡ����Ū����ͳ�ˤ�� -.Dq tape archiver -���ά����̾�դ����ޤ����� -.Nm -�ץ������ϡ� -.Ar tarfile -�ȸƤФ�� -.Nm -�ե����ޥåȤΥ��������֥ե����������������������֤˥ե�������ɲä����ꡢ -�ޤ����������֤���ե��������Ф����ꤷ�ޤ��� -.Ar tarfile -���̾Ｇ���ơ��פ�ؤ��ޤ������ե��åԥǥ������åȤ� -�̾�Υե�����Ǥ⹽���ޤ��� -.Pp -�̾ -.Nm -���ޥ�ɥ饤��κǽ�ΰ����ϡ���ǽʸ������ӵ�ǽ�ѹ�ʸ������ʤ�ñ��Ǥ��ꡢ -�������� ����� (-) ���դ��Ƥ��դ��ʤ��Ƥ⤤���褦�ˤʤäƤ��ޤ��� -ñ��ˤϡ����ε�ǽʸ���Τ������� 1 �Ĥ�ޤ�Ǥ���ɬ�פ�����ޤ�: -.Cm A , -.Cm c , -.Cm d , -.Cm r , -.Cm t , -.Cm u , -.Cm x , -�����Ϥ��줾�졢 -.Em �ɲ� (append) -�� -.Em ���� (create) -�� -.Em ��ʬ (difference) -�� -.Em �ִ� (replace) -�� -.Em �ꥹ��ɽ�� (table of contents) -�� -.Em ���� (update) -�� -.Em ��� (extract) -���̣���Ƥ��ޤ� (�����˾ܺ٤�����ޤ�)�� -������¾�ˡ��ʲ��˾ܺ٤�Ҥ٤뵡ǽ�ѹ�ʸ���ò¡¢¥ï¿½ï¿½Þ¥ï¿½ï¿½Ã±ï¿½ï¿½ï¿½ -�ޤ�뤳�Ȥ��Ǥ��ޤ��������Τ����Ĥ��ϡ����ޥ��ñ�����Ʊ����� -���ޥ�ɥ饤��������׵ᤷ�ޤ� ( -.Sx ������ -����ò»²¾ï¿½)�� -��ǽʸ���ȵ�ǽ�ѹ�ʸ���ϡ�GNU �����ΰ����ǻ��ꤹ�뤳�Ȥ�Ǥ��ޤ� -(2 �ĤΥ��å����ǽ���դ���1 �ĤΥ��ޥ��ñ�줴�Ȥ˵�ǽʸ���� -��ǽ�ѹ�ʸ���� 1 �Ĥ������ꤹ��)�� -���������֤ؤ��ɲá����������֤������С������ƥꥹ��ɽ���Τ���� -���ޥ�ɥ饤����ꤹ��ե�����̾�ˤϡ� -������Υѥ�����ޥå�ʸ�������Ѥ��뤳�Ȥ��Ǥ��ޤ��� -.Sh ��ǽ -�ʲ��ε�ǽ�Τ����줫 1 �Ĥ�����ɬ�����ꤹ��ɬ�פ�����ޤ��� -.Pp -.Bl -tag -width "--concatenate" -compact -.It Fl A -.It Fl -catenate -.It Fl "-concatenate" -���ꤵ�줿 ( -.Nm -���������ַ�����) �ե������ tar ���������֤����� -���ɲä��ޤ� (�ɲä������θŤ� end-of-archive �֥��å��Ϻ���� -��ޤ�)�� -����ϡ����ꤵ�줿�ե����뤬���������֤���� 1 �ե�����Ȥʤ�Τ� -�Ϥʤ������ꤷ���ե��������˴ޤޤ�Ƥ���ե�����ò¡¢ºÇ½ï¿½Ë»ï¿½ï¿½ï¿½ -�������������֤��ɲä���Ȥ������̤�����ޤ��� -.Em �� : -���Υ��ץ����� -.Ar tarfile -��ƽñ¤¹ï¿½ï¿½ß¤ï¿½ï¿½ï¿½É¬ï¿½×¤ï¿½ï¿½ï¿½ï¿½ë¤¿ï¿½á¡¢1/4 -����������ȥ�å��ơ��פǤ�ư��ޤ��� -.It Fl c -.It Fl -create -���������������֤�������� (�⤷���ϸŤ����Ƥ��ڤ�ΤƤ�)������ -���줿�ե�����ò¥¢¡ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ö¤Ë½ñ¤¹ï¿½ï¿½ß¤Þ¤ï¿½ï¿½ï¿½ -.It Fl d -.It Fl -diff -.It Fl -compare -���������֤���Υե�����ȡ��������������ե����륷���ƥ���� -�ե�����Ȥΰ㤤��Ĵ�����ޤ��� -.It Fl -delete -���ꤵ�줿�ե�����ò¥¢¡ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ö¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ -(1/4 ������ơ��פǤ�ư��ޤ���)�� -.It Fl r -.It Fl -append -���������֤������˥ե�������ɲä��ޤ� -(1/4 ������ơ��פǤ�ư��ޤ���)�� -.It Fl t -.It Fl -list -�������������ƤΥꥹ��ɽ���ò¤·¤Þ¤ï¿½ï¿½ï¿½ï¿½â¤·ï¿½ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½ï¿½ -.Ar filename -�����ꤵ��Ƥ���С����Υե�����������ꥹ��ɽ������ޤ��� -�����Ǥʤ���С����������֤˴ޤޤ�뤹�٤ƤΥե�����ꥹ�Ȥ�ɽ������ޤ��� -.It Fl u -.It Fl -update -���ꤷ���ե�����Τ�����������������Υե��������ǥ�������� -�ե�������ѹ����郎��������Τ������ɲä��ޤ���1/4 ������ơ��� -�Ǥ�ư��ޤ��� -.It Fl x -.It Fl -extract -.It Fl -get -���������֤���ե��������Ф��ޤ�����ǽ�ʤ�С���Í�ԡ� -�ѹ�����ե�����°���ϥꥹ�ȥ�����ޤ����⤷ -.Ar file -���������ꤵ��Ƥ��ʤ���С�����������������ե����뤬��Ф���ޤ��� -�⤷ -.Ar filename -�������ơ��׾�Υǥ��쥯�ȥ�̾�˥ޥå����Ƥ���С����Υǥ��쥯�ȥ�� -�ǥ��쥯�ȥ���Υե����뤬��Ф���ޤ� (�ǥ��쥯�ȥ���� -���٤ƤΥǥ��쥯�ȥ�ˤĤ��Ƥ�Ʊ�ͤ���Ф���ޤ�)�� -�⤷������������ˡ���������Ʊ���ե����뤬ʣ���ޤޤ�Ƥ���� (�åµï¿½ï¿½ -.Fl -append -���ޥ�ɤò»²¾ï¿½)���Ǹ�˴ޤޤ�Ƥ����Τ�¾�Τ��٤ƤΥե������ -��ñ¤¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ð¤ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.El -.Sh ���ץ���� -.Nm -��¾�Υ��ץ����ϡ��Ȥ߹�碌�ƻ��Ѥ��뤳�Ȥ��Ǥ��ޤ��� -1 ʸ�����ץ����ϡ����ޥ��ñ�����ǻ��ꤹ�뤳�Ȥ��Ǥ��ޤ��� -������Ϳ����٤����ץ����ξ�硢���ץ�����³���ư�������ꤷ -�ޤ���1 ʸ�����ץ����Ǥ���С������³�����ޥ�ɥ饤������� -���Ѥ��ޤ� (�ʲ��� -.Sx ������ -�ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½)�� -.Pp -.Bl -tag -width "--preserve-permissions" -compact -.It Fl -help -.Nm -�Τ��٤ƤΥ��ޥ�ɥ��ץ����ˤĤ��ư����Ȳ����ɽ�����ޤ��� -.It Fl -atime-preserve -�ơ��פ˽ñ¤«¤ï¿½Æ¤ï¿½ï¿½ë¡¢ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½Î¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ê¥¹ï¿½È¥ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -(inode ���ѹ����郎�ѹ�����뤳�Ȥ����դ��Ƥ�������!) -.It Fl b -.It Fl -block-size Ar number -�ɤ߽ñ¤¤ï¿½ï¿½ï¿½Ö¥ï¿½ï¿½Ã¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Ar number -* 512-byte �֥��å� �����ꤷ�ޤ��� -.It Fl B -.It Fl -read-full-blocks -û���ɤߤ����֥��å��ò¡¢´ï¿½ï¿½ï¿½ï¿½Ê¥Ö¥ï¿½ï¿½Ã¥ï¿½ï¿½Ëºï¿½ï¿½È¤ï¿½Î©ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ ( -.Bx 4.2 -�ѥ��פ��ɤ߹�����)�� -.It Fl C Ar directory -.It Fl -directory Ar directory -�Ĥ�ΰ���������������� -.Ar directory -�ذ�ư���ޤ��� -.It Fl -checkpoint -���������֤��ɤ߽ñ¤¤ï¿½ï¿½ï¿½Ö¤ï¿½ï¿½É¤ß½ñ¤¤ï¿½ï¿½ï¿½ï¿½Ð¥Ã¥Õ¥ï¿½ï¿½Î¿ï¿½ï¿½ï¿½É½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl f Xo -.Oo Ar hostname : Oc Ns Ar file -.Xc -.It Fl -file Xo -.Oo Ar hostname : Oc Ns Ar file -.Xc -���ꤵ�줿 -.Ar file -(�ǥե���Ȥ� -.Pa /dev/sa0 ) -���ɤ߽ñ¤¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -�⤷ -.Ar hostname -�����ꤵ��Ƥ���С� -.Nm -�� -.Xr rmt 8 -��Ȥäơ���⡼�ȥޥ����� -.Ar file -���ɤ߽ñ¤¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Dq Ar - -�ϥե�����̾�Ȥ��ƻ��Ѥ���뤳�Ȥ⤢��ޤ����� -�����ɸ�����Ϥ����ɤ߽Ф����ꡢɸ����Ϥؽñ¤½Ð¤ï¿½ï¿½ï¿½ï¿½ê¤¹ï¿½ë¤¿ï¿½ï¿½Ë»ï¿½ï¿½Ñ¤ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl -force-local -�����󤬤�����Ǥ��������������֥ե�����ϥ�������Τ�ΤȤ��ޤ��� -.It Fl F Ar file -.It Fl -info-script Ar file -.It Fl -new-volume-script Ar file -���줾��Υ��������֤�����ȡ�������ץȤ�¹Ԥ��ޤ� (���ۤ� -.Fl M -���꤬�Ԥʤ��ޤ�)�� -.It Fl -fast-read -�磻��ɥ����ɤǻ��ꤵ��Ƥ��ʤ����٤Ƥ���Х������åȤ� -������������˸��Ĥ��ä��顢���λ����ǽ�λ���ޤ��� -.It Fl G -.It Fl -incremental -�Ť� GNU-format ���󥯥��󥿥�Хå����åץե���������/�ꥹ��/��Ф��ޤ��� -.It Fl g Ar file -.It Fl -listed-incremental Ar file -������ GNU-format ���󥯥��󥿥�Хå����åץե������ -����/�ꥹ��/��Ф��ޤ��� -.It Fl h -.It Fl -dereference -����ܥ�å���󥯤ò¥·¥ï¿½Ü¥ï¿½Ã¥ï¿½ï¿½Î¤Þ¤Þ½ñ¤¹ï¿½ï¿½ß¤Þ¤ï¿½ï¿½ó¡£¥ï¿½ï¿½ï¿½Ü¥ï¿½Ã¥ï¿½ï¿½ï¿½ó¥¯¤ï¿½ -�ؤ��Ƥ���ǡ�����ñ¤¹ï¿½ï¿½ß¤Þ¤ï¿½ï¿½ï¿½ -.It Fl i -.It Fl -ignore-zeros -���������֤���Υ����֥��å� (�̾End-Of-File ���̣����) ��̵�뤷�ޤ��� -.It Fl -ignore-failed-read -�ե����뤬�ɤ�ʤ��Ƥ⡢�� 0 �Υ��ơ������� exit ���ޤ��� -.It Fl j -.It Fl y -.It Fl -bzip -.It Fl -bzip2 -.It Fl -bunzip2 -���������֤� -.Xr bzip2 1 -�ǥե��륿��󥰤��ޤ��� -.It Fl k -.It Fl -keep-old-files -�ǥ�������˴��ˤ���ե�������ݻ����ޤ����Ĥޤꡢ���������֤��� -��Ф���ե�����ϡ��ǥ�������Υե�����ؾ�ñ¤¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl K Ar file -.It Fl -starting-file Ar file -���������֤���� -.Ar file -���� (��С��ꥹ�Ȥʤɤ�) �Ϥ�ޤ��� -.It Fl l -.It Fl -one-file-system -����ե����륷���ƥ���ˤ���ե���������ǥ��������֤�������ޤ� -(¾�ե����륷���ƥ�ؤΥޥ���ȥݥ���Ȥ�٤��ޤ���)�� -.It Fl L Ar number -.It Fl -tape-length Ar number -.Ar number -* 1024 �Х��Ƚñ¤¹ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç¥Æ¡ï¿½ï¿½×¤Î¸ò´¹¤ï¿½ï¿½×µá¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl m -.It Fl -modification-time -�ե�������ѹ��������Ф��ޤ��� -.It Fl M -.It Fl -multi-volume -�ޥ���ܥ�塼�ॢ�������֤����/�ꥹ��/��Ф��ޤ��� -.It Fl n -.It Fl -norecurse -�������˺Ƶ�Ū�˥��֥ǥ��쥯�ȥ���������ޤ��� -.It Fl -volno-file Ar file -�ܥ�塼���ֹ��դ��Υե�����̾�Ǥ��� -.It Fl N Ar date -.It Fl -after-date Ar date -.It Fl -newer Ar date -�������֤� -.Ar date -��꿷�����ե������������Ф��ޤ��� -.It Fl -newer-mtime Ar date -�ѹ����֤� -.Ar date -��꿷�����ե������������Ф��ޤ��� -.It Fl o -.It Fl -old-archive -.It Fl -portability -POSIX �ե����ޥåȤǤϤʤ���V7 �ե����ޥåȤΥ��������֤�������ޤ��� -.It Fl O -.It Fl -to-stdout -�ե������ɸ����Ϥ���Ф��ޤ��� -.It Fl p -.It Fl -same-permissions -.It Fl -preserve-permissions -�ݸ�����������Ф��ޤ��� -.It Fl -preserve -.Fl p s -�λ����Ʊ�����̤�����ޤ��� -.It Fl P -.It Fl -absolute-paths -�ե�����̾������Ƭ�� -.Ql / -��Ȥ�ޤ��� -.It Fl R -.It Fl -record-number -��å�������˥�����������Υ쥳�����ֹ��������ɽ�����ޤ��� -.It Fl -remove-files -���������֤��ɲä����ե�������ɲø�˺�����ޤ��� -.It Fl s -.It Fl -same-order -.It Fl -preserve-order -�����������⤫����Ф���ե�����ò¡¢»ï¿½ï¿½ê¤µï¿½ì¤¿ï¿½ï¿½Î¤Þ¤Þ¤Ë¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl -show-omitted-dirs -���������ֺ�����˽������줿�ǥ��쥯�ȥ��ɽ�����ޤ��� -.It Fl S -.It Fl -sparse -.Dq �¤� -�ե�������ΨŪ�˰����褦�ˤ��ޤ��� -.It Fl T Ar file -.It Fl I Ar file -.It Fl -files-from Ar file -.Ar file -������Ф⤷���Ϻ�������ե�����̾�����ޤ� (1 �� 1 �ե�����̾)�� -.It Fl -null -null �ǽ���äƤ���̾�����θ���� -.Fl T -�ο�����ѹ����ޤ��� -����� -.Fl C -�����̵���ˤ��ޤ��� -.It Fl -totals -.Fl -create -�ˤ�äƽñ¤«¤ì¤¿ï¿½ï¿½ï¿½Ð¥ï¿½ï¿½È¿ï¿½ï¿½ï¿½É½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl U -.It Fl -unlink -.It Fl -unlink-first -�ե����������������ˡ����ä��������ޤ��� -.It Fl v -.It Fl -verbose -.Fl -create -�ǥ��������֤˽ñ¤¯¥Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Fl -extract -�ǥ��������֤��� -���Ф��ե�����̾��ꥹ��ɽ�����ޤ��� -�ե�������ݸ�����ե�����̾�ȤȤ��ɽ��������ˤϡ� -.Fl -list -��Ȥ��ޤ��� -.It Fl V Ar volume-name -.It Fl -label Ar volume-name -���ꤵ�줿 -.Ar volume-name -����ä����������֤�������ޤ��� -.It Fl -version -.Nm -�ץ������ΥС�������ֹ��ɽ�����ޤ��� -.It Fl w -.It Fl -interactive -.It Fl -confirmation -���٤Ƥ�ư����Ф��ơ���ǧ�����褦�ˤʤ�ޤ��� -.It Fl W -.It Fl -verify -���������֤�ñ¤¹ï¿½ï¿½ï¿½ï¿½ï¿½å¡¢ï¿½Ù¥ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ß¤Þ¤ï¿½ï¿½ï¿½ -.It Fl -exclude Ar pattern -.Ar pattern -�˥ޥå�����ե������������ޤ� -(��Ф��ޤ����ɲä��ޤ��󡣥ꥹ��ɽ�����ޤ���)�� -.It Fl X Ar file -.It Fl -exclude-from Ar file -.Ar file -�˰�������Ƥ���ե������������ޤ��� -.It Fl Z -.It Fl -compress -.It Fl -uncompress -���������֤� -.Xr compress 1 -�ǥե��륿��󥰤��ޤ��� -.It Fl z -.It Fl -gzip -.It Fl -gunzip -���������֤� -.Xr gzip 1 -�ǥե��륿��󥰤��ޤ��� -.It Fl -use-compress-program Ar program -���������֤� -.Ar program -�ǥե��륿��󥰤��ޤ� -(����ϡ� -.Fl d -�����ꤵ�줿�Ȥ��� -.Dq decompress -���̣���ʤ���Фʤ�ޤ���)�� -.It Fl -block-compress -�ơ��פ⤷���ϥե��åԤΤ���ˡ����̥ץ������ν��Ϥ�֥��å� -�����ޤ� (�������ʤ��ȡ��֥��å�Ĺ�����������ʤꡢ�ǥХ����ɥ饤�Ф� -���Υ֥��å�����䤹��Ǥ��礦)�� -.It Fl Xo -.Op Cm 0 Ns - Ns Cm 7 Ns -.Op Cm lmh -.Xc -�ơ��ץɥ饤�֤�̩�٤���ꤷ�ޤ��� -.El -.Sh �Ķ� -�Ķ��ѿ� -.Ev TAR_OPTIONS -�� -.Nm -�Υǥե���ȥ��ץ������ݻ������뤳�Ȥ���ǽ�Ǥ��� -�����Υ��ץ����Ϻǽ�˲�ᤵ��ޤ��Τǡ� -����Ū�ʥ��ޥ�ɥ饤��ѥ�᡼���Ǿ�ñ¤²ï¿½Ç½ï¿½Ç¤ï¿½ï¿½ï¿½ -.Sh ������ -.Pa bert -�� -.Pa ernie -�Ȥ����ե������ޤࡢ -�֥��å��������� 20 �֥��å��Υ��������֤� -�ơ��ץɥ饤�� -.Pa /dev/sa0 -�˺��ˤϡ� -.Dl "tar cfb /dev/sa0 20 bert ernie" -�⤷���� -.Dl "tar --create --file /dev/sa0 --block-size 20 bert ernie" -�����Ϥ��ޤ��� -.Fl f -����� -.Fl b -�ե饰��ξ���Ȥ������ɬ�פȤ��Ƥ��뤳�Ȥ����դ��Ƥ��������� -���ΰ����ϡ����ޥ��ñ��˽ñ¤«¤ï¿½Æ¤ï¿½ï¿½ï¿½Î¤ï¿½Æ±ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç¥ï¿½ï¿½Þ¥ï¿½É¥é¥¤ï¿½ó¤«¤ï¿½ -��������ޤ��� -.Pp -.Pa /dev/sa0 -�ϥǥե���ȤΥǥХ����Ǥ��ꡢ20 �ϥǥե���ȤΥ֥��å� -�������Ǥ��Τǡ��åµï¿½ï¿½ï¿½ï¿½Ï¼ï¿½ï¿½Î¤è¤¦ï¿½ï¿½Ã±ï¿½ã²½ï¿½Ç¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Dl "tar c bert ernie" -\&"backup.tar" �Ȥ������������֤��顢���٤Ƥ� C �������ڤӥإå��� -��Ф���ˤϡ����Τ褦�˥����פ��ޤ��� -.Pp -.Dl tar xf backup.tar '*.[ch]' -.Pp -�����뤬�����ȥǥ��쥯�ȥ���Υե�����̾��Ÿ�����ʤ��褦���ѥ������ -�������Ȥ��ʤ���Фʤ�ʤ����Ȥ����դ��Ƥ������� (������ -������ϥ�����������Υե���������˥����������뤳�ȤϤǤ��ޤ���)�� -.Pp -�ե�������ع�¤���ȥ��ԡ�����ˤϡ����Τ褦�˥��ޥ�ɤ���Ѥ��Ƥ�������: -.Bd -literal -tar cf - -C srcdir . | tar xpf - -C destdir -.Ed -.Pp -�ǥ������åȤˡ� -.Xr gzip 1 -��Ȥä����̥��������֤��������ˤϡ����� -�褦�ʥ��ޥ�ɥ饤���Ȥ��Ȥ����Ǥ��礦�� -.Dl "tar --block-compress -z -c -v -f /dev/fd1a -b 36 tar/" -.Pp -�ޤȤ����ե饰�� -.Fl - -��������Υե饰�òº®ºß¤ï¿½ï¿½ï¿½ï¿½ë¤³ï¿½È¤ï¿½ï¿½Ç¤ï¿½ï¿½Ê¤ï¿½ -���Ȥ����դ��Ƥ������������Τ褦�˥����פ��ʤ���Фʤ�ʤ��櫓�� -�Ϥʤ����åµï¿½Î¤è¤¦ï¿½Ê½ï¿½ï¿½ï¿½ï¿½ï¿½ 1 ʸ���ե饰��Ȥ����Ȥ��Ǥ��ޤ��� -.Dl "tar --block-compress --gzip --verbose --file /dev/fd1a --block-size 20 tar/" -.Pp -��Τ褦�ˤ��ƺ��������ǥ����������Ƥϡ����Τ褦�ˤ���Хꥹ�� -ɽ���Ǥ��ޤ��� -.Pp -.Dl "tar tvfbz /dev/fd1a 36" -.Pp -2 �Ĥ� -.Nm -���������֤� 1 �ĤΥ��������֤ˤޤȤ��ˤϡ� -.Dl "tar Af archive1.tar archive2.tar" -��Ȥ��ޤ�����������ȡ� -.Pa archive2.tar -�˴ޤޤ�Ƥ���ե����뤬 -.Pa archive1.tar -���������ɲä���ޤ� (� -.Dl "cat archive2.tar >> archive1.tar" -�ȥ����פ��Ƥ⤦�ޤ������ʤ����Ȥ����դ��Ƥ����������ʤ��ʤ顢 -.Nm -���������֤������ˤ� end-of-file �֥��å������뤫��Ǥ�)�� -.Pp -.Pa srcdir -�ǥ��쥯�ȥ꤫�� 1997 ǯ 2 �� 9 �� 13:00 �ʹߤ��ѹ��ò¤µ¤ì¤¿ -���ƤΥե�����ò¥¢¡ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ö¤ï¿½ï¿½ë¤¿ï¿½ï¿½Ë¤Ï¡ï¿½ï¿½Ê²ï¿½ï¿½Î·ï¿½ï¿½ï¿½ï¿½ï¿½È¤Ã¤Æ²ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Dl "tar -c -f backup.tar --newer-mtime 'Feb 9 13:15 1997' srcdir/" -.Pp -¾�λ��ֻ�������Ȥ��Ƥϡ� -.Sq "02/09/97 13:15" , -.Sq "1997-02-09 13:15" , -.Sq "13:15 9 Feb 1997" , -.Sq "'9 Feb 1997 13:15" , -.Sq "Feb. 9, 1997 1:15pm" , -.Sq "09-Feb" , -.Sq "3 weeks ago" , -.Sq "May first Sunday" -������ޤ��� -�����������ॾ�������ꤹ�뤿��ˤϡ� -.Sq "13:15 CEST" -�� -.Sq "13:15+200" -����Ѥ��Ʋ������� -.Sh �Ķ��ѿ� -.Nm -�ץ������ϡ��ʲ��δĶ��ѿ��ò»²¾È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Bl -tag -width "POSIXLY_CORRECT" -.It Ev POSIXLY_CORRECT -�̾ -.Nm -�ϥե�����������˺����ä��ե饰��������ޤ��� -���δĶ��ѿ������ꤹ��ȡ� -.Nm -�Ϻǽ�Υե饰�ʳ��ΰ����ò¸«¤Ä¤ï¿½ï¿½ï¿½ -�Ȥ���ʹߤΰ������Ф��ƥե饰������Ԥʤ�ʤ��Ȥ�����POSIX ���� -�˹�碌��ư���Ԥʤ��褦�ˤʤ�ޤ��� -.It Ev SHELL -���󥿥饯�ƥ��֥⡼�ɤˤ����ơ����֥�����ε�ư���׵ᤵ�줿�Ȥ��� -.Ev SHELL -�ѿ������ꤵ��Ƥ���Ф��줬�����ꤵ��Ƥ��ʤ���� -.Pa /bin/sh -�����Ѥ���ޤ��� -.It Ev TAPE -.Nm -�Υǥե���ȤΥơ��ץɥ饤�֤��ѹ����ޤ� (����ϡ������ -.Fl f -�ե饰�ˤ�ä��ѹ����뤳�Ȥ��Ǥ��ޤ�)�� -.It TAR_RSH -TAR_RSH �Ķ��ѿ��ϡ��ǥե���ȥ������ͥ�褷�ơ� -.Nm tar -�Υǡ���ž���˻��Ѥ���ޤ��� -.El -.Sh ��Ϣ�ե����� -.Bl -tag -width "/dev/sa0" -.It Pa /dev/sa0 -�ǥե���ȤΥơ��ץɥ饤�� -.El -.Sh �ߴ��� -.Fl y -�� FreeBSD �����ε�ǽ�Ǥ��� -GNU -.Nm -���ƥʤϡ� -.Fl j -�� GNU -.Nm -1.13.18 �ʹߤˤ���������� -.Xr bzip2 1 -���̥��ץ����Ȥ��ƺ��Ѥ��ޤ����� -.Fl I -���ץ����ϡ�Solaris �� -.Nm -�Ȥθߴ����Τ���ˤ���ޤ��� -.Sh ��Ϣ���� -.Xr bzip2 1 , -.Xr compress 1 , -.Xr gzip 1 , -.Xr pax 1 , -.Xr rmt 8 -.Sh ��� -.Nm -�ե����ޥåȤ�Ω�ɤ���ˤ���äƤ��ơ�Sixth Edition UNIX �� -����������ޤ��� -���� -.Nm -����� GNU �����Ǥ��ꡢ -.An John Gilmore -�ˤ�äƽñ¤«¤ì¤¿ -�ѥ֥�å��ɥᥤ�� -.Nm -�����ˤʤäƤ��ޤ��� -.Sh ��� -.An -nosplit -���οͤ�ޤࡢ����¿���ο͡���[����������� -.Pa ChangeLog -�ե�����˵��Ҥ���Ƥ���͡�] -.An John Gilmore -(���ꥸ�ʥ�Υѥ֥�å��ɥᥤ���Ǥκ��), -.An Jay Fenlason -(�ǽ�� GNU ���), -.An Joy Kendall , -.An Jim Kingdon , -.An David J. MacKenzie , -.An Michael I Bushnell , -.An Noah Friedman -������ -�Х��ե��å������ɲä�׸����Ƥ��줿̵���ο͡��� -.Pp -���Υޥ˥奢��ڡ����� -.Nx 1.0 -release ���顢 -.Fx -���롼�פ� -���������ΤǤ��� -.Sh �Х� -��ħŪ�� -.Fl C -���ץ�����ư��ϡ�����Ū�� -.Nm -�ץ������Τ���Ȥϰۤʤ�Τǡ� -���ޤ����ˤϤǤ��ޤ��� -.Pp -.Fl A -���ޥ�ɤ�Ǥ�դο��� -.Nm -���������֤���Ǥ���Ф����ΤǤ���������ϤǤ��ޤ��� -����������Ȥ��Ƥ⡢2 ���ܰʹߤΥ��������֤� -end-of-archive �֥��å���������줺�˻ĤäƤ��ޤ��ޤ��� -.Pp -.Nm -�ե�����ե����ޥåȤϽ�������ե�����ɥե����ޥåȤǤ��ꡢ -�ǥХ����ֹ��ѤΥե�����ɤ� 16 �ӥå��� -(�᥸�㡼 8 �ӥåȤǥޥ��� 8 �ӥå�) -�˥ǥ����󤵤�Ƥ��ꡢ�桹�� 32 �ӥå��ֹ� -(�᥸�㡼 8 �ӥåȤǥޥ��� 16+8 �ӥå�) -��ۼ��Ǥ��ޤ��� diff --git a/ja_JP.eucJP/man/man4/man4.i386/aic.4 b/ja_JP.eucJP/man/man4/man4.i386/aic.4 deleted file mode 100644 index f0c01ec9ef..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/aic.4 +++ /dev/null @@ -1,51 +0,0 @@ -.\" -.\" Copyright (c) 1994 James A. Jegers -.\" 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. -.\" 2. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: aic.4,v 1.4 1997/02/22 13:25:10 peter Exp % -.\" $FreeBSD$ -.\" -.Dd November 29, 1994 -.Dt AIC 4 i386 -.Os -.Sh ̾�� -.Nm aic -.Nd Adaptec �� AIC-6260 �� AIC-6360 �� SCSI �ɥ饤�� -.Sh �� -.Cd "device aic0 at isa? port 0x340 bio irq 11" -.Sh ���� -.Nm aic -�ɥ饤�Ф� Adaptec �� AIC-6260 �� AIC-6360 �� SCSI -����ȥ�������åפΥ��ݡ��Ȥ��󶡤��ޤ��� -����ϡ�Adaptec 152x �� Creative -Labs SoundBlaster SCSI �ۥ��ȥ����ץ���ޤߤޤ��� -.Pp -�����Υ���ȥ�������åפ��Ѥ���¿���Υ����ƥ�� -�֡��� ROM ����äƤ��ޤ��󡣤������äơ���������֡��ȤϤǤ��ޤ��� -.Sh ��Ϣ���� -.Xr cd 4 , -.Xr ch 4 , -.Xr intro 4 , -.Xr sd 4 , -.Xr st 4 - - diff --git a/ja_JP.eucJP/man/man4/man4.i386/apm.4 b/ja_JP.eucJP/man/man4/man4.i386/apm.4 deleted file mode 100644 index 779f0a77f1..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/apm.4 +++ /dev/null @@ -1,160 +0,0 @@ -.\" LP (Laptop Package) -.\" -.\" Copyright (c) 1994 by HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp> -.\" -.\" This software may be used, modified, copied, and distributed, in -.\" both source and binary form provided that the above copyright and -.\" these terms are retained. Under no circumstances is the author -.\" responsible for the proper functioning of this software, nor does -.\" the author assume any responsibility for damages incurred with its -.\" use. -.\" -.\" %Id: apm.4,v 1.9 1998/12/18 03:08:57 jkoshy Exp % -.\" $FreeBSD$ -.\" -.Dd November 1, 1994 -.Dt APM 4 i386 -.Os -.Sh ̾�� -.Nm apm -.Nd APM BIOS ���󥿥ե����� -.Sh �� -.Cd device apm0 at isa? -.Sh ���� -.Nm apm -�ϥ�åץȥå� PC �� Intel / Microsoft APM (Advanced Poewr Management) -BIOS �ؤΥ��󥿥ե������Ǥ��� -.Pp -.Nm apm -�ϼ����Ÿ�������ǽ���󶡤��ޤ��� -.Bl -enum -offset indent -.It -�����ƥब�����ڥ�ɥ⡼�ɤ��������������ˡ� -.Nm apm -�ϥ����ƥ�λ��פ� RTC �˹�碌�ޤ��� -.It -�����ƥब�����ڥ�ɥ⡼�ɤ��������������ˡ� -�����ƥब������������ȥ����ڥ�ɥ⡼����˷вᤷ�����֤ǹ�������� -�������� -.Nm apm -�� -.Xr syslogd 8 -�����Τ��ޤ��� -.It -.Nm apm -�ϥ����ƥ�γ�ư (�¹Բ�ǽ�ʥץ������������ߤʤ�) ���ʤ����� -CPU �Υ����å���®���ޤ��� -���ε�ǽ�� APM �� CPU �Υ����ɥ�󥰤ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½ë¥·ï¿½ï¿½ï¿½Æ¥ï¿½Ç¤Î¤ï¿½Í���Ǥ��� -.It -.Nm apm -�ϥ���饯�����ǥХ����Ȥ��ƥ��ץꥱ������󥤥󥿥ե��������󶡤��ޤ��� -���ץꥱ�������Ϥ��Υ��󥿥ե�������𤷤� APM �����椷���ꡢ -APM �ξ��־��������Ф����ꤹ�뤳�Ȥ��Ǥ��ޤ��� -.Nm apm -�ϼ��Υ��󥿥ե��������󶡤��ޤ��������Υ���ܥ�� -.Dq Pa /usr/include/machine/apm_bios.h -���������Ƥ��ޤ��� -.Bl -tag -width 4n -offset indent -.It Sy APMIO_SUSPEND -�����ƥ�ò¥µ¥ï¿½ï¿½Ú¥ï¿½É¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Sy APMIO_GET -�Ÿ�������������ꤷ�ޤ��� -.It Sy APMIO_ENABLE -.It Sy APMIO_DISABLE -�Ÿ�������Í�� / ̵���ˤ��ޤ��� -.It Sy APMIO_HALTCPU -.It Sy APMIO_NOTHALTCPU -�����ͥ륳��ƥ������ڤ��ؤ��롼����Ǥ� HLT �μ¹Ԥ����椷�ޤ��� -.Pp -HLT -.Pq �����ߤ�ȯ������ޤ� CPU ����� -̿��� -.Dq Pa Idle CPU -�ƤӽФ�����Ǽ¹Ԥ��� APM �μ����⤢��ޤ����������Ǥʤ���Τ⤢��ޤ��� -�Ǥ����餳���Í���ˤ���ȡ� -.Dq Pa Idle CPU -��ƤӽФ������ͥ륳��ƥ������ڤ��ؤ��롼���� -���� HLT ̿���¹Ԥ��뤳�Ȥˤ�ꡢ -;ʬ�� HLT ̿���¹Ԥ��뤳�Ȥˤʤ��ǽ��������ޤ��� -���η�̡������ƥ�Υԡ�����ǽ�ò¸º¾ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -�ޤ��������ͥ륳��ƥ������ڤ��ؤ��롼����Ǥ� HLT ̿���̵���ˤ�����硢 -�ޥ���� APM ����� -.Dq Pa Idle CPU -�� HLT ��¹Ԥ��ʤ����ˤϡ������ƥ�ϥϥ󥰥��åפ��ޤ��� -CPU �����å��θ�®�ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç¤Ï¡ï¿½APM �� HLT -��¹Ԥ��ʤ����⤷��ޤ��� -���Τ褦�ʥޥ���Ǥϡ� -.Nm apm -�� -.Sy APMIO_NOTHALTCPU -������̵���ˤ��ޤ��� -.Pp -���ߤΥС������� -.Nm apm -�ϡ������å��θ�®�����ݡ��Ȥ���Ƥ��ʤ����ˤϡ� -�����ͥ륳��ƥ������ڤ��ؤ��롼���󤫤� -.Dq Pa Idle CPU -��ƤӽФ������ǥե���ȤǤ� HLT ̿���¹Ԥ��ޤ��� -�������äơ�����ξ��ˤϤ����� 2 �Ĥ�����Ԥ�ɬ�פϤ���ޤ��� -.El -.Pp -�����Υ��󥿥ե������� -.Xr apm 8 -�� -.Xr apmconf 8 -�����Ѥ��ޤ��� -.It -.Nm apm -�� APM ���٥�Ȥ�ݡ���󥰤������Υ��٥�Ȥ�������ޤ��� -.Bl -column PMEV_POWERSTATECHANGEXXX "suspend system xxxxx" -.It Sy "̾�� " "ư�� " "����" -.It Dv "PMEV_STANDBYREQ " No "�����ڥ�� " "�Ե��׵�" -.It Dv "PMEV_SUSPENDREQ " No "�����ڥ�� " "�����ڥ���׵�" -.It Dv "PMEV_USERSUSPENDREQ " No "�����ڥ�� " "�桼�������ڥ���׵�" -.It Dv "PMEV_CRITSUSPEND " No "�����ڥ�� " "��掠���ڥ���׵�" -.It Dv "PMEV_NORMRESUME " No "�쥸�塼�� " "�̾������" -.It Dv "PMEV_CRITRESUME " No "�쥸�塼�� " "�������" -.It Dv "PMEV_STANDBYRESUME " No "�쥸�塼�� " "�Ե�����" -.It Dv "PMEV_BATTERYLOW " No "���������� " "������Â" -.It Dv "PMEV_UPDATETIME " No "���׹�碌 " "����ò¹¹¿ï¿½" -.El -.El -.Sh �Х� -�ٹ�! -���ߤΤȤ�������åץȥåץޥ���� APM BIOS �μ����ϡ� -�ۤȤ�ɤȤޤǤϤ����ʤ��Ƥ�Х����餱�Ǥ��� -���Υ��󥿥ե���������Ѥ���� LCD �ǥ����ץ쥤�����Ӥ� -�����ˤ��餹��ǽ��������ޤ��� -(���줬 MS-Windows ������Ȥʤ�ʤ���ͳ�ϥꥢ��⡼�ɥ��󥿥ե����� -����Ѥ��Ƥ��뤫��Ǥ���) -���Υ����ɤ���Ѥ��Ƥ��ʤ��Υ����ƥब��̯��ư��ò¤¹¤ï¿½Î¤ï¿½È¯ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ë¤Ï¡ï¿½ -�Ÿ��ץ饰�����Ӥ�ľ���ˤȤޤǤϤ����ʤ��Ƥ�Ǥ�������᤯ȴ���� -���Υ����ɤ�̵���ˤ��Ƥ��������� -.Pp -��ã�Ϥ��Υ����ɤ�ư���褦�ˤʤ뤳�Ȥ˴ؿ�����äƤ��ޤ��� -�۾��ư��δѻ���̤ò¤¼¤Ò»ï¿½Ã£ï¿½ï¿½Ï¢ï¿½ï¿½ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Pp -.Nm apm -��Í���Ǥ�������ۥåȥ�����Ȥä� BIOS ����롼�����ƤӽФ��� -�����ƥ�쥸�塼����˽���ʾ㳲�������������ǽ��������ޤ��� -BIOS ����ץ������ϥ֡��ȥ��ȥ�å׻��ޤ��� DOS ����ƤӽФ��٤��Ǥ��� -.Pp -APM �μ����ˤ�äƤϡ��Ÿ��ܥ���ò²¡¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È¤ä¥«ï¿½Ð¡ï¿½ï¿½ï¿½ï¿½Ä¤ï¿½ï¿½ï¿½È¤ï¿½ï¿½Ã¤ï¿½ -���٥�Ȥò°·¤ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½Ç¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ç¤¬ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -���Τ褦�ʼ����ǥ����ƥ�ò¥µ¥ï¿½ï¿½Ú¥ï¿½É¤ï¿½ï¿½ï¿½ï¿½ï¿½Ë¤Ï¡ï¿½ -.Ar ɬ�� -.Xr apm 8 -�ޤ��� -.Xr zzz 8 -.Ar ���� -����Ѥ��Ƥ��������� -.Pp -�ǥ�������®��LCD �Хå��饤�����桢�ѥ����ǥޥ�ɤ� -���ߤΥС������Ǥϥ��ݡ��Ȥ���Ƥ��ޤ��� -.Sh ��Ϣ���� -.Xr apm 8 , -.Xr apmconf 8 , -.Xr zzz 8 -.Sh ��� -Tatsumi Hosokawa <hosokawa@jp.FreeBSD.org> diff --git a/ja_JP.eucJP/man/man4/man4.i386/ar.4 b/ja_JP.eucJP/man/man4/man4.i386/ar.4 deleted file mode 100644 index 561ef5afaf..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/ar.4 +++ /dev/null @@ -1,108 +0,0 @@ -.\" -.\" Copyright (c) 1995 John Hay. 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. -.\" 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. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by John Hay. -.\" 4. Neither the name of the author nor the names of any co-contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY John Hay ``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 John Hay 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. -.\" -.\" %Id: ar.4,v 1.9 1998/10/22 14:12:55 bde Exp % -.\" $FreeBSD$ -.\" -.\" WORD: link level layer ��󥯥�٥���� -.\" -.Dd November 19, 1995 -.Dt AR 4 i386 -.Os -.Sh ̾�� -.Nm ar -.Nd -Ʊ�� Arnet �ǥХ����ɥ饤�� -.Sh �� -.Cd "device ar0 at isa? port 0x300 net irq 10 iomem 0xd0000" -.Cd "device ar1 at isa? port 0x310 net irq 11 iomem 0xd0000" -.Pp -.Cd "pseudo-device sppp" -.Sh ���� -.Nm ar -�ɥ饤�Ф� HD64570 ���åפ���Ѥ��� Arnet SYNC/570i ISA �����ɤ� -���ݡ��Ȥ��ޤ��� -2 �ݡ��Ȥ� 4 �ݡ��Ȥ�ξ���Υ����ɤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½ï¿½ï¿½ï¿½Æ°ï¿½ï¿½ï¿½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -����®�٤Ϻ���� 2Mbps �ޤ������ޤ�������®�٤Ǥ� 486DX �ץ����å��� -�Ӱ���� 85 % ����Ѥ��뤳�Ȥ��Ǥ��ޤ��� -.Pp -��󥯥�٥���ؤˡ�ɸ��� -.\" link level layer �� OSI ��ǥ�Ǥ� data link layer ������������ -.\" �⤷���� data link layer �ΰ��������������ΤȻפ��ޤ�������ʸ�� -.\" º�Ť��ơ֥�󥯥�٥���ءפȤ����� -.Tn FreeBSD -sppp �����ɤ���Ѥ��ޤ��� -�ǥե���ȤΥץ��ȥ���� PPP �Ǥ��� -Cisco HDLC �ץ��ȥ���� -.Xr ifconfig 8 -�� -.Ar link2 -���ɲä��뤳�Ȥˤ�äƻ��ѤǤ��ޤ��� -.Sh �ֹ� -�����ͥ�����ե�����Ǥϡ���������� 1 �ԤΤߤ�ɬ�פǤ��� -�ǽ�Υ����ɤΥݡ��Ȥϡ�ar0 ����Ƴ������ޤ��� -���Υ����ɤ��ֹ�ϡ��ǽ�Υ����ɤǻߤޤä��꤫��³���ޤ��� -�Ĥޤꡢ�⤷�ǽ�Υ����ɤ� 2 �ݡ��ȤΥ����ɤʤ顢���Υ����ɤ� ar0 �� ar1 -��Ȥ��ޤ��������Ƽ��Υ����ɤϡ�ar2 ����Ϥ�ޤ��� -.Pp -�����ɤ� IRQ 3, 5, 7, 10, 11, 12, 15 �Τߤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -iomem �ΰ�ϡ�16Kb �֥��å��Ǥ��ꡢ16Kb ��������Ϥޤ�ɬ�פ�����ޤ��� -.Pp -.Sh ���� -.Bl -diag -.It "ar%d: Warning illegal interrupt %d." -�����ɤ����ꤵ�줿�����ߤ���ѤǤ��ޤ���¾�γ����ߤ�����Ǥ��������� -.El -.Sh ��Ϣ�ե����� -.Bl -tag -width /sys/i386/isa/ic/hd64570.h -compact -.It Pa /sys/i386/isa/ic/hd64570.h -.It Pa /sys/i386/isa/if_arregs.h -.It Pa /sys/i386/isa/if_ar.c -.El -.Sh �Х� -�������� V.35 �� X.21 ���󥿥ե��������������Ƥ��ޤ��� -¾�Τ�ΤǤϥ����å���ʬ�Υ����ɤ���Ĵ������ɬ�פ�����Ǥ��礦�� -.Pp -���Υ����ɤˤϡ������餯��Ŭ����;�Ϥ�����ޤ��� -.Pp -���Υ����ɤϡ��ޤ��Ǥ����Ф���Ǥ���������¿���ΥХ�������Ǥ��礦�� -���� jhay@mikom.csir.co.za ����𤷤Ƥ��������� -.Sh ��Ϣ���� -.Xr cx 4 , -.Xr netintro 4 , -.Xr ifconfig 8 , -.Xr lsdev 8 -.Sh ��� -.Nm ar -�ǥХ����ɥ饤�Ф� -.An John Hay Aq jhay@mikom.csir.co.za -���������ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/cs.4 b/ja_JP.eucJP/man/man4/man4.i386/cs.4 deleted file mode 100644 index fa87b907ed..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/cs.4 +++ /dev/null @@ -1,105 +0,0 @@ -.\" -.\" Copyright (c) 1998 Michael Smith -.\" 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. -.\" 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 AUTHOR 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 AUTHOR 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. -.\" -.\" %Id: cs.4,v 1.2 1998/10/22 14:12:55 bde Exp % -.\" $FreeBSD$ -.\" -.Dd July 20, 1998 -.Dt CS 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm cs -.Nd �������ͥåȥǥХ����ɥ饤�� -.Sh �� -.Cd "device cs0 at isa? port 0x300 net irq ?" -.Cd "device cs1 at isa? port 0x300 net irq 10 iomem 0xd0000" -.Sh ���� -.Nm -�ɥ饤�Ф� -.Nm Crystal Semiconductor CS8900 �� CS8920 -NIC ��١����ˤ��� ISA �������ͥåȥ����ץ��ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -�����ΥǥХ����� CS89x0 �ե��ߥ�η������䤦������ -�⤤�����٤Ⱦ��������������ʲ���¸������� -.Nm IBM EtherJet ISA -�����ץ������Ʊ�ǥХ������Ȥ߹����¿�������ʤˤ����ƻȤ��Ƥ��ޤ��� -.Pp -.Nm -�ɥ饤�Ф�����ѥ�᡼�������ꥨ��ȥ�ޤ��ϥ����ɤΤɤ��餫��Ǥ� -�����Ǥ��ޤ������ꥨ��ȥ�ǻ��ꤵ�줿�ѥ�᡼�����⤷¸�ߤ���� -���������Ѥ��ޤ����������ɤϥ��եȥ�����������Ǥ���Τǡ� -�����������Ŭ�����ͤˤʤäƤ���Ȼפ��ޤ��� -CS8920 �١����Υ����ץ��ϡ��̾� PnP ������󶡤���Τǡ��ɥ饤�Ф� -.Nm IBM EtherJet -�� -.Nm CSC6040 -��ưŪ�˸��Ф��ޤ��� -.Pp -CS8900 �� 4 �Ĥ� IRQ �ͤ˸��ꤵ��Ƥ��뤳�Ȥ����դ��Ƥ����������������ͤ� -�̾� 5, 10, 11, 12 �ȤʤäƤ��ޤ���CS8920 �ˤϤ��Τ褦�����¤Ϥ���ޤ��� -.Pp -����ޥåפ� DMA ư��ϸ������Ǥϥ��ݡ��Ȥ���Ƥ��ޤ��� -.Sh ���� -.Bl -diag -.It "cs%d: full/half duplex negotiation timeout" -�ϥ֤Ȥ����������ͥ��������Ȼ�Ԥ������ॢ���Ȥòµ¯¤ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -���Τ��Ȥϥ����֥���³�����꤬���뤫����٤����ߴ����Τʤ��ϥ֤Ǥ��뤳�Ȥ� -�����Ƥ��ޤ��� -.It "cs%d: failed to enable <media>" -CS89x0 �ϻؼ����줿��ǥ���������˼��Ԥ��ޤ��������Υ�ǥ�����¸�ߤ��ʤ����� -������������ޤ��� -.It "cs%d: No EEPROM, assuming defaults" -CS89x0 �� EEPROM ���ʤ�������˾Ū��»�����Ƥ��ޤ������ꥨ��ȥ꤬�����ץ��� -�ͤ�Ŭ�����ͤˤʤäƤ������ˤ������Ǥ��ޤ��� -.It "cs%d: Invalid irq" -���ꥨ��ȥ�ǻ��ꤵ�줿 IRQ �������ץ��ˤ��äƤ��ޤ��� -.It "cs%d: Could not allocate memory for NIC" -��̿Ū�ʥ�����Â�Ǥ��������ץ���ư���ޤ��� -.It "cs%d: Adapter has no media" -�����ץ�������Υ�ǥ��������פ����ꤵ��Ƥ��ޤ��� -��ǥ��������פϼ�ư�ǥ��åȤ���ɬ�פ�����ޤ��� -.It "This is a %s, but LDN %d is disabled" -PnP õ�������ɤϽ�����ǽ�ʥ����ץ��ò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -�����ץ���̵��������Ƥ��ޤ��� -.It "failed to read pnp parms" -PnP �����ץ������Ф���ޤ����������Υ����ץ��Ѥ�����ѥ�᡼�����ɤ�ޤ��� -.It "failed to pnp card parametars" -PnP ��ͳ�������ѥ�᡼����ɥ饤�Фϼ����Ȥ�ޤ���Ǥ����������ץ��Ϥ��֤� -ư���ʤ��Ǥ��礦�� -.Sh �ٹ� -CS89x0 �ե��ߥ�Υ����ץ��ϡ��ȤƤ⾮���� RAM �Хåե� (4K) ���� -���äƤ��ޤ��󡣤��Τ��Ȥ϶�ü�˹⤤�ͥåȥ����٤� -��ȯŪ�ʥͥåȥ���ȥ�ե��å����Ǥ�����òµ¯¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½â¤·ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -�ºݡ�NFS ���ϥ����Х����ɤ�����ˡ� 1k ���ɤ߽ñ¤½ï¿½ï¿½ï¿½ï¿½ï¿½ -���¤���٤��Ǥ��� -.Sh ��� -.Nm -�ǥХ����ɥ饤�Ф� -.An Maxim Bolotin -�� -.An Oleg Sharoiko -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -���Υޥ˥奢��ڡ����� -.An Michael Smith -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ diff --git a/ja_JP.eucJP/man/man4/man4.i386/cx.4 b/ja_JP.eucJP/man/man4/man4.i386/cx.4 deleted file mode 100644 index ab92ab9b43..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/cx.4 +++ /dev/null @@ -1,289 +0,0 @@ -.\" -.\" %Id: cx.4,v 1.4 1997/06/23 04:02:37 steve Exp % -.\" $FreeBSD$ -.\" -.Dd December 12, 1994 -.Dt CX 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm cx , -.Nm if_cx -.Nd Ʊ��/��Ʊ�� Cronyx-Sigma �����ץ��ɥ饤�� -.Sh ���� -.Cd "device cx0 at isa? port 0x240 irq 15 drq 7" -.Cd "device cx1 at isa? port 0x260 irq 12 drq 6" -.Cd pseudo-device sppp -.Pp -i/o �١������ɥ쥹�ϡ��ܡ��ɾ�Υ����Ѥ����ꤵ��ޤ��� -DMA ����ͥ�ȳ����ߥꥯ�������ֹ�ϡ� -�����ץ���������˥��եȥ����������ꤵ��ޤ��� -�̾���ͤϰʲ����̤�Ǥ��� -.Pp -.Bl -tag -compact -width Port -.It Port -0x240, 0x260, 0x280, 0x300, 0x320, 0x380 -.It IRQ -3, 5, 7, 10, 11, 12, 15 -.It DMA -5, 6, 7 -.Sh ���� -Cronyx-Sigma �ɥ饤�Фϥ�ǥ� 100, -400, 500, 401, 404, 410, 440, 703, 801, 810, 840 �ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -��ǥ뤬�ۤʤ�ȡ�����ͥ�Υ��åȤ��ۤʤ�ޤ��� -.Pp -.Bl -tag -compact -width Cronyx-Sigma-999 -.It ��ǥ� -����ͥ� -.It Cronyx-Sigma-100 -0 -.It Cronyx-Sigma-400 -4, 5, 6, 7 -.It Cronyx-Sigma-500 -0, 4, 5, 6, 7 -.It Cronyx-Sigma-401 -0, 1, 2, 3 -.It Cronyx-Sigma-404 -0, 1, 2, 3 -.It Cronyx-Sigma-410 -0, 1, 2, 3 -.It Cronyx-Sigma-440 -0, 1, 2, 3 -.It Cronyx-Sigma-703 -0, 1, 2, 4, 5, 6, 7 -.It Cronyx-Sigma-801 -0, 1, 2, 3, 4, 5, 6, 7 -.It Cronyx-Sigma-810 -0, 1, 2, 3, 4, 5, 6, 7 -.It Cronyx-Sigma-840 -0, 1, 2, 3, 4, 5, 6, 7 -.El -.Pp -�դ��ĤΥ����ץ��ϡ��ܡ��ɴ���³�Ѥ�û�����ѥ����֥����³���뤳�Ȥ��Ǥ��ޤ��� -�դ��Ĥ���³���줿�����ץ��ϡ�Ʊ�� IRQ �� DMA ����ͥ����Ѥ��� -�ɥ饤�Ф��鸫��ФҤȤĤ� 16 ����ͥ�ޥ���ץ쥯���Ȥ���ư��ޤ��� -��³���줿�ܡ��ɤ������� ``�ޥ���'' �ˡ��⤦������ ``���졼��'' �ˤʤ�ޤ��� -.Pp -���졼�֤ˤʤä��ܡ��ɤΥ���ͥ�ϡ� -�ɥ饤�Фˤ�ä� 8 ����Ϥޤ��ֹ椬������Ƥ��ޤ��� -���Ȥ��Х�ǥ� 100 �� ��ǥ� 500 ����³����ȡ� -0, 8, 12, 13, 14, 15 �֤Υ���ͥ��ֹ椬������Ƥ��ޤ��� -.Pp -RS-232C ���󥿥ե��������ĥ���ͥ�ϡ� -Ʊ���⡼�ɤ���Ʊ���⡼�ɤΤɤ���Ǥ�ư��뤳�Ȥ���ǽ -(cxconfig �桼�ƥ���ƥ��ˤ�äƥ��եȥ�����Ū�����ò¤·¤Þ¤ï¿½) �Ǥ��ꡢ -������ ``��˥С��������ͥ�'' �ȸƤФ�ޤ��� -.Pp -Cronyx-Sigma �����ץ��ѤΥǥХ������ü�ե����� -.Pa /dev/* -�ϡ� -.Xr MAKEDEV 8 -�ˤ�ú���ޤ��� -���Ȥ��С��ʲ��Τ褦�˺��ޤ�: -.Bd -literal -cd /dev -sh MAKEDEV cronyx ttyx0 ttyx1 ttyy0 -.El -.Sh ��Ʊ���ɥ饤�� -.Pp -��Ʊ������ͥ�ΥǥХ����ե�����ˤϼ��Τ褦��̾�����դ����ޤ�: -.Pa /dev/ttyx# -- �ϥ����ץ� cx0 �ˡ� -.Pa /dev/ttyy# -- �ϥ����ץ� cx1 �ˡ� -.Pa /dev/ttyz# -- �ϥ����ץ� cx2 ���դ����ޤ��� -������ # �� 0-9-a-f �Ρ�16 �ʿ��ǤΥ���ͥ��ֹ�Ǥ��� -.Pp -�ɥ饤�Фϰʲ���ɸ�� ioctl ������դ��ޤ� ( -.Xr ioctl -�ò»²¾ï¿½): -.Pp -.Bl -tag -width TIOCXXXXX -compact -.It Dv TIOCSBRK -BREAK ���������Ϥ��ޤ��� -.It Dv TIOCCBRK -BREAK ����������ߤ��ޤ��� -.It Dv TIOCSDTR -DTR ����ò¥»¥Ã¥È¤ï¿½ï¿½Þ¤ï¿½ (DTR := 1)�� -DTR ����Ϻǽ�� open(2) ��ɬ�����åȤ��졢 -.Dv TIOCCDTR , -.Dv TIOCSDTR , -.Dv TIOCMSET , -.Dv TIOCMBIS , -.Dv TIOCMBIC -�� ioctl �ˤ���ѹ���ǽ�Ǥ��� -.It TIOCCDTR -DTR ����ò¥¯¥ê¥¢ï¿½ï¿½ï¿½Þ¤ï¿½ (DTR := 0)�� -.It TIOCMSET -DTR ����� RTS ����ˡ����ꤷ���ͤò¥»¥Ã¥È¤ï¿½ï¿½Þ¤ï¿½ (<DTR:RTS> := data)�� -DTR ����� RTS ����ϡ� -ioctl �����ƥॳ����ΰ������ -.Dv TIOCM_DTR -�� -.Dv TIOCM_RTS -�ΥӥåȤˤ�������ǽ�Ǥ��� -.It TIOCMBIS -DTR ����� RTS ����ò¥»¥Ã¥È¤ï¿½ï¿½Þ¤ï¿½ (<DTR:RTS> |= data)�� -DTR ����� RTS ����ϡ� -ioctl �����ƥॳ����ΰ������ -.Dv TIOCM_DTR -�� -.Dv TIOCM_RTS -�ΥӥåȤˤ�������ǽ�Ǥ��� -.It TIOCMBIC -DTR ����� RTS ����ò¥¯¥ê¥¢ï¿½ï¿½ï¿½Þ¤ï¿½ (<DTR:RTS> &= ~data)�� -DTR ����� RTS ����ϡ� -ioctl �����ƥॳ����ΰ������ -.Dv TIOCM_DTR -�� -.Dv TIOCM_RTS -�ΥӥåȤˤ�������ǽ�Ǥ��� -.It TIOCMGET -�饤���Υ�ǥ࿮��ξ��֤�Ƚ�ꤷ�ޤ��� -�ƤӽФ��Τ��ȡ������Υǡ����ϲ����ΥӥåȤ��ݻ����Ƥ��ޤ�: -.Pp -.Bl -tag -width TIOCM_XXX -compact -.It TIOCM_LE -��˥��å� (�饤�󥤥͡��֥����) -.It TIOCM_DSR -�ǡ������åȥ�ǥ����� (DSR) ������ -.It TIOCM_CTS -������ǽ���� (CTS) ������ -.It TIOCM_CD -�ǡ�������ꥢ���п��� (CD) ������ -.It TIOCM_DTR -�ǡ���ü����ǥ� (DTR) ���������� -.It TIOCM_RTS -�����׵� (RTS) ������ -.El -.El -.Sh Ʊ���ɥ饤�� -.Pp -Ʊ������ͥ�ȥ�˥С��������ͥ�ϡ� -.Xr cxconfig 8 -�桼�ƥ���ƥ��ˤ�ä�Ʊ���⡼�ɤ����ꤹ��ȡ� -�ͥåȥ�����󥿥ե����� ``cx#'' -(# �� 0 ���� 47 �ޤǤΥ���ͥ��ֹ�) �Ȥ��ƥ���������ǽ�Ǥ��� -���٤Ƥ�ɸ��Ū�ʥͥåȥ�����󥿥ե������ѥ�᡼���ϡ� -.Xr ifconfig 8 -�ˤ�ä������ǽ�Ǥ��� -�ޤ� -.Xr cxconfig 8 -���ޥ�ɤϡ���ĥ���줿����ͥ륪�ץ������ѹ��䡢 -��̥�٥�Υ��եȥ������ץ��ȥ��� -(PpP �� Cisco HDLC �ʤ�) ������˻��Ѥ���ޤ��� -.Pp -��˥С��������ͥ��Ʊ���⡼�ɤǤ���Ʊ���⡼�ɤǤ���Ѥ��뤳�Ȥ��Ǥ��ޤ��� -�ǥե���ȤǤ���Ʊ���⡼�ɤ����ꤵ��Ƥ��ꡢ�⡼�ɤ� -.Xr cxconfig 8 -�桼�ƥ���ƥ��ˤ�ä��ѹ���ǽ�Ǥ��� -����ͥ뤬�ӥ������� (��Ʊ������ͥ뤬�����ץ���֤ξ��䡢 -�ͥåȥ�����󥿥ե�������ư���� (up) ��) -�δ֡��⡼�ɤϥ֥��å�����ޤ��� -.Sh Ʊ���ݥ���ȥġ��ݥ���ȥץ��ȥ��� -.Pp -Cronyx-Sigma �ɥ饤�Фϡ��Ȥ߹��ߤ�Ʊ���ݥ���ȥġ��ݥ���ȥץ��ȥ��� -(sppp) ����Ѥ��ޤ��� -�ܥץ��ȥ���ˤϡ�PpP/HDLC �� Cisco/HDLC��keepalive �ѥ��åȤˤ�� -��ưŪ�ʥ��ͥ������������Ф⥵�ݡ��Ȥ��Ƥ��ޤ��� -sppp �ץ��ȥ��륻�åȤ���Ω�����⥸�塼��Ȥ��Ƽ������졢 -¾��Ʊ�����ꥢ�����ͥ�Υɥ饤�Фˤ�äƻ��Ѥ��뤳�Ȥ��ǽ�Ǥ��� -BSD/386 (BSDI) �Ѥ� -�ɥ饤�ФǤϡ�OS ¦�Ǽ�������Ƥ������Ū��Ʊ���ץ��ȥ���Υ��åȤ���� -��ǽ�Ǥ��������ץ��ȥ��륻�åȤϡ�``cxconfig ext'' ���ޥ�� -( -.Xr cxconfig 8 -�ò»²¾ï¿½) �ˤ�ä������ǽ�Ǥ��� -.Sh ����ͥ륪�ץ����δ��� -.Pp -.Xr cxconfig 8 -�桼�ƥ���ƥ��ϡ�����ͥ륪�ץ��������ꤹ��Τ˻��Ѥ���ޤ��� -����ͥ륪�ץ����ϡ��̾���ڥ졼�ƥ��󥰥����ƥब��ư����ݤ� (���Ȥ��� -.Pa /etc/rc -�ե�����ʤɤ�) ���ꤵ��ޤ��� -���٤Ƥξ��ˤ����ơ� -���٤ƤΥ��ץ���󤬰�̣����ĤȤϸ¤�ʤ����Ȥ����դ��Ƥ��������� -�ޤ��� -���ץ���������ˤ�äƤϡ� -����ͥ�⤷���ϥ����ץ����ΤΥϥ󥰥��åפθ����ˤʤ�ޤ��� -.Pp -�ºݤΥ���ͥ륪�ץ��������浡ǽ�ϡ� -�ǥХ������ü�ե����� /dev/cronyx ������ -�����Ĥ��� ioctl ���ͳ������Ǽ�������Ƥ��ꡢ�ʲ��� ioctl �����ѤǤ��ޤ��� -.Pp -.Bl -tag -width CXIOCXXXXXXX -compact -.It CXIOCGETMODE -����ͥ륪�ץ������ͤ�������ޤ��� -.It CXIOCSETMODE -����ͥ륪�ץ������ͤ����ꤷ�ޤ��� -.El -.Pp -ioctl ������Υǡ��������ϰʲ��Υ��ץ����¤�ΤΥ��ɥ쥹������ޤ�: -.Bd -literal -typedef struct { - unsigned char board; /* �����ץ��ֹ�Ǥ��ꡢ0..2 */ - unsigned char channel; /* ����ͥ��ֹ�Ǥ��ꡢ0..15 */ - unsigned char type; /* ����ͥ륿���� (�ɤ߹�������) */ - unsigned char iftype; /* chan0 ���󥿥ե����� */ - unsigned long rxbaud; /* ����®�� */ - unsigned long txbaud; /* ž��®�� */ - cx_chan_mode_t mode; /* ����ͥ�⡼�� */ - cx_chan_opt_t opt; /* ���̤Υ���ͥ륪�ץ���� */ - cx_opt_async_t aopt; /* ��Ʊ���⡼�ɥ��ץ���� */ - cx_opt_hdlc_t hopt; /* hdlc �⡼�ɥ��ץ���� */ - cx_opt_bisync_t bopt; /* bisync �⡼�ɥ��ץ���� */ - cx_opt_x21_t xopt; /* x.21 �⡼�ɥ��ץ���� */ - cx_soft_opt_t sopt; /* ���եȥ��������ץ����Ⱦ��֥ե饰 */ -} cx_options_t; /* �桼���������ǽ�ʥ��ץ���� */ -.Ed -.Pp -.Bl -tag -width rxbaudxxx -.It Fa board -0..2 �Ρ������ץ��ֹ� -.It Fa channel -0..15 �Ρ�����ͥ��ֹ� -.It Fa type -����ͥ�Υ����� (�ɤ߼�����Ѥΰ���) -.It Fa iftype -0 �� (�� 8 ��) ����ͥ�Υ��󥿥ե����������ס� 0 - RS-232, 1 - RS-449/V.35�� -.It Fa rxbaud -�����ܡ��졼�� -.It Fa txbaud -�����ܡ��졼�� -.It Fa mode -����ͥ�⡼��: ��Ʊ��/HDLC/Bisync/X.21 -.It Fa opt -���̤Υ���ͥ륪�ץ���� -.It Fa aopt -��Ʊ���⡼�ɥ��ץ���� -.It Fa hopt -HDLC �⡼�ɥ��ץ���� -.It Fa bopt -Bisync �⡼�ɥ��ץ���� -.It Fa xopt -X.21 �⡼�ɥ��ץ���� -.It Fa sopt -���եȥ������ץ��ȥ��륪�ץ���� -.El -.Sh ��Ϣ�ե����� -.Bl -tag -width /dev/cxXXXX -compact -.It Pa /dev/cx?? -��Ʊ������ͥ� -.It Pa /dev/cronyx -����ͥ륪�ץ��������ѤΥǥХ������ü�ե����� -.El -.Pp -�ɥ饤�Ф�ޤ�Ǥ��륽�����ե�����ϰʲ����̤�Ǥ�: -.Pp -.Bl -tag -width /dev/cxXXXX -compact -.It Pa /sys/i386/isa/cronyx.c -.It Pa /sys/i386/isa/cx.c -.It Pa /sys/i386/isa/if_cx.c -.It Pa /sys/i386/isa/cronyx.h -.It Pa /sys/i386/isa/cxreg.h -.It Pa /sys/net/if_spppsubr.c -.It Pa /sys/net/if_sppp.h -.El -.Sh ��Ϣ���� -.Xr cxconfig 8 , -.Xr ifconfig 8 diff --git a/ja_JP.eucJP/man/man4/man4.i386/el.4 b/ja_JP.eucJP/man/man4/man4.i386/el.4 deleted file mode 100644 index 674a44c505..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/el.4 +++ /dev/null @@ -1,58 +0,0 @@ -.\" -.\" Copyright (c) 1994 James A. Jegers -.\" 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. -.\" 2. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: el.4,v 1.7 1998/10/22 14:12:55 bde Exp % -.\" $FreeBSD$ -.\" -.Dd July 10, 1995 -.Dt EL 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm el -.Nd 3Com Etherlink 3C501 �ǥХ����ɥ饤�ФΤ���Υ������ͥåȥɥ饤�� -.Sh �� -.Cd "device el0 at isa? port 0x300 net irq 9" -.Sh ���� -.Nm -���󥿥ե������ϡ� -3Com 3c501 8 �ӥå� ISA �������ͥåȥ����ɤΥ��ݡ��Ȥ��󶡤��ޤ��� -3c501 �����ɤϤ��ʤ��٤����Ȥ��Τ��Ƥ��ޤ��Τǡ� -�⤷��ǽ�ʤ�¾�Υ������ͥåȥ����ɤ��Ѥ���٤��Ǥ��� -��������10 Mb/s �������ͥåȥͥåȥ���ؤΥ��������Ȥ��Ƥϰ²��Ǥ��� -.Pp -Í���� I/O �ݡ��Ȥ� 0x280-0x3f0 ���ϰϤǤ��� -.Sh �Х� -�ɥ饤�Фϥ����ɤ������ͥ��Ʊ�� IRQ �����ꤵ��Ƥ���Ȳ��ꤷ�ޤ��� -���줬���������ɤ����Τ����ץ����֤�����å��ϹԤ��Ƥ��ޤ��� -.Pp -���ߡ�DMA �ϥ��ݡ��Ȥ��Ƥ��ޤ��� -.Pp -���ߡ��ޥ�����㥹�Ȥϥ��ݡ��Ȥ��Ƥ��ޤ��� -.Sh ��Ϣ���� -.Xr ed 4 , -.Xr eg 4 , -.Xr ep 4 , -.Xr ie 4 , -.Xr intro 4 , -.Xr le 4 , -.Xr ifconfig 8 diff --git a/ja_JP.eucJP/man/man4/man4.i386/ep.4 b/ja_JP.eucJP/man/man4/man4.i386/ep.4 deleted file mode 100644 index 6fdb3ba408..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/ep.4 +++ /dev/null @@ -1,121 +0,0 @@ -.\" -.\" Copyright (c) 1994 Herb Peyerl -.\" 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. -.\" 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. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by Herb Peyerl -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: ep.4,v 1.9 1998/10/22 14:12:55 bde Exp % -.\" $FreeBSD$ -.\" -.Dd February 04, 1993 -.Dt EP 4 i386 -.Os -.Sh ̾�� -.Nm ep -.Nd -3Com Etherlink III �������ͥåȥǥХ����ɥ饤�� (3c5x9) -.Sh �� -.Cd "device ep0 at isa? port 0x300 net irq 10" -.Sh ���� -.Nm ep -�ɥ饤�Ф� 3c509 (ISA) �� 3c579 (EISA) �Υ��ݡ��Ȥ��󶡤��ޤ��� -�����Υ����ɤΤ��ޤ��ޤʥ�ǥ�ϡ����ͥ��������󤬤��줾��ۤʤ�ޤ��� -.Pp -.Bl -tag -width xxxxxxxxxxxxxxxxxxxx -.It AUI/DIX -ɸ�� 15 �ԥ󥳥ͥ��� -.It 10Base2 -BNC (���󥱡��֥�Ȥ��Ƥ��Τ��Ƥ�����) -.It 10BaseT -UTP (�ĥ����ȥڥ��Ȥ��Ƥ��Τ��Ƥ�����) -.El -.Pp -�ǥե���Ȥǻ��Ѥ����ݡ��Ȥϡ� -���åȥ��åץ桼�ƥ���ƥ������ò¤µ¤ï¿½Æ¤ï¿½ï¿½ï¿½Ý¡ï¿½ï¿½È¤Ç¤ï¿½ï¿½ï¿½ -����ò¥ª¡ï¿½ï¿½Ð¥é¥¤ï¿½É¤ï¿½ï¿½ï¿½Ë¤Ï¡ï¿½ -.Xr ifconfig 8 -�ޤ��� -.Pa /etc/rc.conf -�ե�����Ǽ��Υե饰����Ѥ��ޤ��� -.Pp -.Bl -tag -width xxxxxxxxxxxxxxxxxxxx -.It link0 -AUI �ݡ��Ȥ���� -.It link1 -BNC �ݡ��Ȥ���� -.It link2 -UTP �ݡ��Ȥ���� -.El -.Pp -����ԥ塼����ʣ���Υ����ɤ����夷�Ƥ�����ϡ����ν��֤�õ����ޤ��� -�ǽ�� 3c579 EISA �����ɤ�õ����ޤ� -- -������ EISA �����å��ֹ��˸��Ф���ޤ��� -���ˡ�3c509 ISA �����ɤ�õ����ޤ� -- -�������ͥåȥ��ɥ쥹�ξ���˸��Ф���ޤ��� -���ˡ��ɤΤ褦�˥ץ����֤���뤫����ò¼¨¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -ep0 at isa0 port 0x6000-0x600f irq 10: aui/bnc address 00:60:8c:70:e5:c5 -ep1 at isa0 port 0x300-0x30f irq 3: aui/bnc/utp address 00:20:af:10:62:ab -.Pp -�����ɤ�ȯ������뤳�Ȥ����Ԥ����ݡ��Ȥ� IRQ ����ꤹ�뤳�Ȥ�Ǥ��ޤ����� -���λ����ɬ������ɬ�פǤϤ���ޤ��� -�����ɤ� ISA �Х���Ǥμ�ʬ�ε����桹��������� -��ʬ�ʥ���ƥꥸ���󥹤������Ƥ���ΤǤ��� -.Pp -.Sh ���� -3c509 �����ɤˤϥ��ɥ쥹�����ꤹ�른���Ѥ�����ޤ��� -3Com �ϥ����ɤΥ��ɥ쥹�����ꤹ�륽�եȥ��������󶡤��Ƥ��ޤ��� -ISA �Х���Ǥ��Υ����ɤò¸«¤Ä¤ï¿½ï¿½ë¤¿ï¿½ï¿½Ë¡ï¿½ -�����ͥ�� IO ���ɥ쥹 0x110 ��ʣ���ʥ����������Ԥ��ޤ��� -���դ��Ƥ�������! ���Υ��ɥ쥹��¾�Υ����ɤ����֤��뤳�Ȥ��ò¤±¤Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Pp -.Sh ���� -ep0: reset (status: %x) -.in +4 -�ɥ饤�Ф� FIFO �Υ�������ޤ��ϥ����Х��ò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½É¥é¥¤ï¿½Ð¤ï¿½ -�����ɤ�ꥻ�åȤ����ѥ��åȤ������ޤ����������̿Ū�ǤϤ���ޤ��� -.in -4 -ep0: eeprom failed to come ready -.in +4 -EEPROM �ν������Ǥ��Ƥ��ޤ��󡣤����餯�����ɤ����Ǥ��ޤ��� -.in -4 -ep0: 3c509 in test mode. Erase pencil mark! -.in +4 -ï���������ɤξ�Υƥ����ΰ�˱�ɮ����ñ¤¤ò¤·¤Æ¤ï¿½ï¿½ë¤«ï¿½â¤·ï¿½ï¿½Þ¤ï¿½ï¿½ó¡£±ï¿½É®ï¿½ï¿½ -���פ�ä��ƥ�֡��Ȥ��Ƥ������� (����ϥ��硼���ǤϤ���ޤ���)�� -.in -4 -.Sh ��Ϣ���� -.Xr ed 4 , -.Xr eg 4 , -.Xr el 4 , -.Xr ie 4 , -.Xr intro 4 , -.Xr le 4 , -.Xr vx 4 , -.Xr ifconfig 8 -.Sh ���� -�ϰ���ʤꡣË�٤�����褬����ޤ��� - diff --git a/ja_JP.eucJP/man/man4/man4.i386/ex.4 b/ja_JP.eucJP/man/man4/man4.i386/ex.4 deleted file mode 100644 index d7e46e0d6d..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/ex.4 +++ /dev/null @@ -1,84 +0,0 @@ -.\" -.\" Copyright (c) 1997 David E. O'Brien -.\" -.\" 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. -.\" 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 DEVELOPERS ``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 DEVELOPERS 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. -.\" -.\" %Id: ex.4,v 1.6 1998/10/22 14:32:20 bde Exp % -.\" $FreeBSD$ -.\" -.\" WORD: Plug-N-Play �ץ饰����ɥץ쥤 -.\" -.Dd January 19, 1997 -.Dt EX 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm ex -.Nd -Intel EtherExpress Pro/10 �� Pro/10+ �������ͥåȥǥХ����ɥ饤�� -.Sh �� -.Cd "device ex0 at isa? port? net irq ?" -.Sh ���� -.Nm -�ɥ饤�Ф� Intel i82595 ���åפ���ܤ��� 16 �ӥå� PCI �� -Intel EtherExpress Pro/10 �� Pro/10+ �������ͥåȥ����ɤ� -���ݡ��Ȥ��󶡤��ޤ��� -.Pp -�ݡ��Ȥγ��ϥ��ɥ쥹�����Ĥ���ʤ���С� -I/O ���ɥ쥹�� 0x200 ���� 0x3a0 ���ϰϤ��饫���ɤ�õ���ޤ��� -IRQ �����ꤵ��Ƥ��ʤ���С������ɤ� EEPROM �����ɤ߽Ф���ޤ��� -������Υ����ɤǤ����������Τ���ˤ� -�ץ饰����ɥץ쥤�Υ��ݡ��Ȥ�̵���ˤ��٤��Ǥ��� -.Pp -.Sh ���� -.Bl -diag -.It "ex%d: Intel EtherExpress Pro/10, address %6D, connector %s" -�ǥХ����ץ����֤ϥ��󥹥ȡ��뤵�줿�����ɤ�ȯ�����ơ� -�ǥХ����ɥ饤�Ф����������󥹥ȡ��뤹�뤳�Ȥ��Ǥ��ޤ����� -.It "ex%d: WARNING: board's EEPROM is configured for IRQ %d, using %d" -�ǥХ����ץ����֤ϥ����ͥ�����ե�����ǻ��ꤵ�줿��ΤȤ� -�ۤʤ�����ߤ����ꤵ��Ƥ���ܡ��ɤò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.It "ex%d: invalid IRQ." -�ǥХ����ץ����֤������� IRQ ����ò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.El -.Pp -.Sh �Х� -���ߤϡ��ɥ饤�Фϥޥ�����㥹�Ȥò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -.Sh ��Ϣ���� -.Xr arp 4 , -.Xr netintro 4 , -.Xr ifconfig 8 -.Sh ��� -.Nm -�ǥХ����ɥ饤�Ф� -.Fx 2.2 -�˽����о줷�ޤ����� -.Sh ��� -.Nm -�ǥХ����ɥ饤�Ф� -.ie t .An Javier Mart\)'in Rueda -.el .An Javier Martin Rueda -�ˤ�äƽñ¤«¤ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -���Υޥ˥奢��ڡ����� -.An David E. O'Brien -�ˤ�äƽñ¤«¤ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ diff --git a/ja_JP.eucJP/man/man4/man4.i386/fe.4 b/ja_JP.eucJP/man/man4/man4.i386/fe.4 deleted file mode 100644 index cb1bdb394a..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/fe.4 +++ /dev/null @@ -1,284 +0,0 @@ -.\" All Rights Reserved, Copyright (C) Fujitsu Limited 1995 -.\" -.\" This document may be used, modified, copied, distributed, and sold, in -.\" both source and printed form provided that the above copyright, these -.\" terms and the following disclaimer are retained. The name of the author -.\" and/or the contributor may not be used to endorse or promote products -.\" derived from this software without specific prior written permission. -.\" -.\" THIS DOCUMENT IS PROVIDED BY THE AUTHOR AND THE CONTRIBUTOR ``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 AUTHOR OR THE CONTRIBUTOR 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 DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" Contributed by M. Sekiguchi <seki@sysrap.cs.fujitsu.co.jp>. -.\" for fe driver. -.\" -.\" %Id: fe.4,v 1.11 1998/10/22 13:01:19 bde Exp % -.\" $FreeBSD$ -.\"" lair events -> typo of "rare" events (approved by original writer) -.Dd March 3, 1996 -.Dt FE 4 i386 -.Sh ̾�� -.Nm fe -.Nd �ٻ��� MB86960A/MB86965A ��١����Ȥ����������ͥåȥ����ץ� -.Sh �� -.Cd "device fe0 at isa? port 0x300 net irq ?" -.Sh ���� -.Nm fe -�ϡ��ٻ��� MB86960A, MB86965A �ޤ��Ϥ���¾�θߴ����åפ�١����Ȥ��� -�������ͥåȥ����ץ��Τ���Υͥåȥ���ǥХ����ɥ饤�ФǤ��� -.Pp -���Υɥ饤�Фϡ������ץ��Υϡ��ɥ��������б����Ƥ���С� -I/O �ݡ��ȥ��ɥ쥹�� IRQ �������ưŪ�˹Ԥʤ��ޤ��� -.Pp -���Υɥ饤�Фϥץ������ I/O �ǡ���ž�����Ѥ���Ѥ��Ƥ��ꡢ -�ޤ��ޤ��Υѥե����ޥ󥹤������ޤ��� -�����ץ������Ȥ����äƤ����Ȥ��Ƥ⡢��Í����ϻ��Ѥ��ޤ��� -.Pp -���Υɥ饤�Фϸ��ߤΤȤ�����ISA �Ѥ��ٻ��� FMV-180 ���꡼���� -ISA �Ѥ� ���饤�ɥƥ쥷�� AT1700 ���꡼���� RE2000 ���꡼���� -�ٻ��� MBH10302 PC �����ɤ��б����Ƥ��ޤ��� -.Ss �ѥ�᡼�� -�����ͥ�����ե�����ˤ����ơ�2 �ĤΥѥ�᡼�� -.Ar port -�� -.Ar irq -�ˤϡ������ץ��Υϡ��ɥ����������ȿ�Ǥ����ͤ���ꤹ��ɬ�פ�����ޤ��� -�⤦ 1 �ĥ��ץ����Ȥ��� -.Ar flags -�ѥ�᡼�������ꡢ�ղ�Ū�������Ԥʤ����Ȥ��Ǥ��ޤ��� -����¾�� device ʸ�ˤ�����ѥ�᡼���Ͻñ¼°¤Ë½ñ¤«¤ï¿½Æ¤ï¿½ï¿½ï¿½È¤ï¿½ï¿½ï¿½ï¿½ -��ɬ�פ�����ޤ��� -.Pp -.Ar port -�ѥ�᡼���ϡ������ץ��Υ١��� I/O �ݡ��ȥ��ɥ쥹����ꤷ�ޤ��� -�����ͤϥ����ץ��Υϡ��ɥ���������ȹ��פ��Ƥ���ɬ�פ�����ޤ��� -.Ar port -�ϡ� -.Dq Li \&? -�ˤ��ơ����ꤻ���˻Ĥ��Ƥ������Ȥ�Ǥ��ޤ��� -���ξ�硢�ɥ饤�Ф� I/O ���ɥ쥹�˴ؤ���ϡ��ɥ���������θ��Ф� -��ưŪ�˻�ߤޤ��� -���ε�ǽ�ϥ����ץ��ϡ��ɥ������ˤ�äƤ�ư���ʤ����⤷��ޤ��� -.Pp -.Ar irq -�ѥ�᡼���ϡ������ץ������Ѥ��� IRQ �ֹ����ꤷ�ޤ��� -�����ͤϥ����ץ��Υϡ��ɥ���������ȹ��פ��Ƥ���ɬ�פ�����ޤ��� -.Ar irq -�ϡ� -.Dq Li \&? -�ˤ��ơ����ꤻ���˻Ĥ��Ƥ������Ȥ�Ǥ��ޤ��� -���ξ�硢�ɥ饤�Ф� IRQ �˴ؤ���ϡ��ɥ���������θ��Ф� -��ưŪ�˻�ߤޤ��� -���ε�ǽ�ϥ����ץ��ϡ��ɥ������ˤ�äƤ�ư���ʤ����⤷��ޤ��� -.Pp -.Ar flags -�ϡ��͡��ʥǥХ���������Ȥ߹�碌����ʤ���ͤǤ��� -���ߤΥС������Ǥϰʲ��� flags ���������Ƥ��ޤ��� -2 �İʾ�������ǥХ��������ꤹ��ˤϡ� -���줾��� flag �ͤ���ͤDzû����Ƥ��������� -�ʲ��ǻ��ꤵ��Ƥ��ʤ� flag �ӥåȤ�ͽ�󤵤�Ƥ��ꡢ0 �ˤ��ʤ���� -�ʤ�ޤ��󡣼ºݤˤϡ����줾��ΥӥåȤ�ñ��̵�뤵��뤫���ƥ����Ѥ� -�ɥ饤�Ф�ʸ�ñ²½¤ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½Ç½ï¿½ï¿½ï¿½ï¿½ï¿½æ¤¹ï¿½ë¤¿ï¿½ï¿½Ë»È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -ʸ�ñ²½¤ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½Ç½ï¿½Ë¤Ä¤ï¿½ï¿½Æ¤Ï¡ï¿½ï¿½×¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Bl -tag -width "99999999" -.It Li 0x007F -������ flag �ӥåȤϡ� -.Ar flags -�� -.Li 0x0080 -�ӥåȤ����ꤵ��Ƥ�����ˡ�MB86960A/MB86965A ���åפ� DLCR6 �쥸������ -��������뤿��˻��Ѥ���ޤ��� -DLCR6 ��ñ¤µï¿½Ç½ï¿½Ë´Ø¤ï¿½ï¿½ï¿½ÜºÙ¤Ï°Ê²ï¿½ï¿½ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -����ΥС������ˤ�����ɥ饤�Фθߴ������ݻ����뤿��ˡ� -.Li 0x0080 -�ӥåȤ����åȤ���Ƥ��ʤ����ʳ��� -.Li 0x007F -flag �ӥåȤ� 0 �ˤ��Ƥ����Ƥ��������� -.It Li 0x0080 -���� flag �ϡ�MB86960A/MB86965A ���åפ� DLCR6 �쥸�������Ф��� -�ǥե��������� flag �ͤ� ��� 7 bit ���Ѥ��ƾ�ñ¤¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -���� flag ���������ѤΤ�ΤǤ��ꡢ�����ץ��ϡ��ɥ������˴ؤ��� -�μ�������ͤΤߤ����Ѥ��Ƥ��������� -DLCR6 ����˴ؤ���ܺ٤ʾ���ϡ��ٻ��̤Υޥ˥奢��ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.El -.Sh ���ץ���� -.Nm fe -�ɥ饤�Фϥ����ͥ�����ե�����ˤ����ơ� -.Dq option -ʸ�ǻ���Ǥ��뤤���Ĥ��λ�Ū�ʥ��ץ�������äƤ��ޤ��� -�ʲ��˻�Ū���ץ�����ꥹ�Ȥ��ޤ��� -�ɥ饤�ФϤ���ʳ��ˤ�ʸ�ñ²½¤ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½×¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Õ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -������̾���ˤ����� -.Dv "FE_" -�Ȥ������ꤵ�줿��Ƭ�����դ����Ƥ��ޤ��� -ʸ�ñ²½¤ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Ê¤ï¿½ï¿½ï¿½ï¿½×¥ï¿½ï¿½ï¿½ï¿½Ë¤Ä¤ï¿½ï¿½Æ¤Ï¡ï¿½ï¿½×¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Bl -tag -width "FE_" -.It Dv "FE_DEBUG=" Ns Ar level -���Υ��ץ����ϡ��ǥХ����� (�ޤ���) �ɥ饤�ФΥǥХå��󥰥�٥�� -���椹����ͤ�����Ȥ�ޤ��� -.Dv "FE_DEBUG" -�����˥ꥹ�Ȥ���Ƥ��ʤ��ͤ˥��ץ��������ꤹ��ȡ� -ʸ�ñ²½¤ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Ê¤ï¿½Æ°ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½â¤·ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -���Υ��ץ����˴ؤ���ǥե���Ȥ������ͤ� 1 �Ǥ��� -.Bl -bullet -.It -.Dv "FE_DEBUG=0" -�����ꤹ��ȡ��������γ�ǧ��ޤ᤿¿���ΥǥХå��ѥ����ɤ��� -�ɥ饤�ФΥ��֥������ȥ����ɤ��������ޤ��� -��������ϺǤ�®���ƾ����ʥ��֥������ȥ����ɤ��������ޤ��� -��������Ǥ��äƤ⡢�����Ĥ���������å������ϵ�Ͽ����ޤ��� -.It -.Dv "FE_DEBUG=1" -�����ꤹ��ȡ�����¤ΥǥХå��ѥ����ɤ��ޤޤ졢 -�Ǿ��̤Υ�å���������Ͽ����ޤ��� -��������Ǥ���̿Ū�ʥ��顼��å������Τߤ���Ͽ����ޤ��� -.It -.Dv "FE_DEBUG=2" -�����ꤹ��ȡ�ɸ��Ū�ʥǥХå��ѥ����ɤ��ޤޤ졢 -����̤Υ�å���������Ͽ����ޤ��� -��������Ǥ���¿�ˤʤ����٥�Ȥ�������ʾ��֤ǤΥ�å���������Ͽ����ޤ��� -.It -.Dv "FE_DEBUG=3" -�����ꤹ��ȡ����ƤΥǥХå��ѥ����ɤ��ޤޤ졢 -�����̤Υ�å���������Ͽ����ޤ��� -��������Ǥ��̾�ư�������쥸�����ͤΥ���פʤɤ� -��Ĺ�ʥ�å���������Ͽ����ޤ��� -.El -.El -.Sh �ϡ��ɥ�������ǥ����Í�ε�ǽ -.Nm fe -�ɥ饤�Фˤϡ������ץ��Υϡ��ɥ�������ǥ����Í�ε�ǽ�����¤� -�����Ĥ�����ޤ��� -�ʲ��Ϥ��Τ褦�������γ�ά�Ǥ��� -.Ss �ٻ��� FMV-180 ���꡼�������ץ� -�����Υ����ץ��Ǥϡ�IRQ �� I/O �ݡ��ȥ��ɥ쥹��ξ���� -��ưŪ�˸��в�ǽ�Ǥ��� -.Pp -FMV-180 ���꡼���Ǥ� -.Nm fe -�μ�ư I/O �ݡ��ȥ��ɥ쥹���е�ǽ�Ϥ����Ƥ��ξ�����ɤ�ư���ޤ��� -�⤷�����ƥ�� 2 �İʾ�� FMV-180 �����ä��Ȥ��Ƥ⡢ -������ư���ޤ��� -������������ʳ��Υ����ץ��Ȥ��Ȥ߹�碌�ϡ��ɥ饤�Ф��𤵤��뤫�� -����ޤ��� -�ϡ��ɥ��������ФDz�������ò´¶¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ï¡ï¿½ -.Em "port ?" -��Ȥ�ʤ����Ȥò¤ª´ï¿½ï¿½á¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -FMV-180 ���꡼���Ǥ� -.Nm fe -�μ�ư IRQ ���е�ǽ�ϳμ¤�ư���ޤ��� -FMV-180 �ˤϾ�� -.Em "irq ?" -��Ȥ����Ȥò¤ª´ï¿½ï¿½á¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -IRQ �Υϡ��ɥ���������ϡ������ͥ�����ե�����ˤ����� IRQ �ͤ����ꤵ��� -�����Ȥ��Ƥ⡢�����ץ��� EEPROM ���꤫���ɤ߹��ޤ�ޤ��� -�ɥ饤�Фϥ����ͥ�����ե�����ǻ��ꤵ�줿 IRQ �� EEPROM ����¸���줿�ͤ� -��äƤ�����硢�ٹ��å��������������� -����ե�����ǻ��ꤵ�줿�ͤ���Ѥ��ޤ� -(���ο��������Υ�꡼������ѹ��ˤʤäƤ��ޤ�)�� -.Ss ���饤�ɥƥ쥷�� AT1700 ���꡼���� RE2000 ���꡼�������ץ� -���饤�ɥƥ쥷�� AT1700 ���꡼���� RE2000 ���꡼���Ǥϡ� -��ư I/O �ݡ��ȥ��ɥ쥹���е�ǽ��ư���ޤ����� -FMV-180 ���꡼�����ϳμ��٤�����ޤ��� -���饤�ɥƥ쥷���Υ����ץ��Ǥ��ε�ǽ����Ѥ���ΤϤ�����Ǥ��ޤ��� -.Pp -��ư IRQ ���Ф����¤Ĥ��Ǥ�����ǽ�Ǥ��� -.Nm fe -�ɥ饤�Ф�����ե������ -.Dq irq \&? -�����ꤵ��Ƥ�����硢�ܡ��ɤ� EEPROM ������ IRQ ��������褦�Ȥ��ޤ��� -�Թ��ʤ��Ȥˡ�AT1700 ���꡼���� RE2000 ���꡼���ˤ� 2 ����Υ�ǥ뤬 -����褦�˻פ��ޤ�; -���륿���פ� IRQ �� 3/4/5/9 ���������ǽ�ǡ��⤦������ 10/11/12/15 �������� -��ǽ�Ǥ��� -�����Υ�ǥ�μ�����ˡ�ϡ��ɤ��Τ��Ƥ��ޤ��� -���Τ��ᡢ���饤�ɥƥ쥷���Υ����ץ��Ǥμ�ư IRQ ���Фϳμ¤Ǥʤ��褦�Ǥ��� -�����ȥ�֥뤬���������ϡ����Τ� IRQ �ֹ����ꤷ�Ƥ��������� -.Pp -AT17000 ���꡼���� RE2000 ���꡼���ΰ㤤�䡢 -�����Υ��꡼����ǤΥޥ��ʥ�ǥ�θ�ʬ���Ϥ��Ƥ��ޤ��� -.Ss �ٻ��� MBH10302 PC ������ -.Nm fe -�ɥ饤�Ф��ٻ��� MBH10302 �ȸߴ� PC �����ɤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -ư��ˤ� PC ������ (PCMCIA) ���ݡ��ȥѥå�������ɬ�פǤ��� -.Sh ��Ϣ���� -.Xr netstat 1 , -.Xr crd 4 , -.Xr ed 4 , -.Xr netintro 4 , -.Xr ifconfig 8 , -.Xr pccardd 8 -.Sh �Х� -�ʲ��ϡ����Τ��ç¤ï¿½Ê¥Ð¥ï¿½ï¿½Ç¤ï¿½: -.Pp -.Nm fe -�ɥ饤�Фˤ�ä��ݤ���Ƥ��륳�ꥸ���������פ����ΤǤϤ���ޤ���; -.Xr netstat 1 -�� -.Fi i -���ץ����ϼºݤΥ��ꥸ�������㴳���ʤ��ͤò¼¨¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -�פä�����¿���� mbuf ���饹�������ñ¤µ¤ï¿½Þ¤ï¿½ï¿½ï¿½ -�ѥ��åȼ����롼���󤬡�mbuf ���饹���γ�����ƥݥꥷ�ˡ��虜 -�Ȱ�ȿ���Ƥ��뤫��Ǥ��� -��ɬ�פ˳�����Ƥ�줿���饹����û����¸���֤Dz�������뤿�ᡢ -Ĺ���ܤǸ���Х����ͥ��������̤ˤϱƶ����ޤ��� -.Pp -XNS �� IPX �ؤΥ��ݡ��Ȥ��ɥ饤�Фˤϴޤޤ�Ƥ��ޤ����� -���٤�ƥ��ȤϤ���Ƥ��餺����������ΥХ�������Ϥ��Ǥ��� -.Sh ��ԡ���������վ�� -.Pp -.Nm fe -�ɥ饤�Ф� -.An David Greenman -���ñ¤¤¤ï¿½ -.Nm ed -�ɥ饤�Ф����ϤȤ��ơ� -.An M. Sekiguchi Aq seki@sysrap.cs.fujitsu.co.jp -���ȼ��˺������ƴ�£���ޤ����� -.Nm fe -�ˤ����� PC �����ɥ��ݡ��Ȥ� -.An Hidetoshi Kimura Aq h-kimura@tokyo.se.fujitsu.co.jp -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -���Υޥ˥奢��ڡ����� -.An M. Sekiguchi -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.Pp -.Em "All Rights Reserved, Copyright (C) Fujitsu Limited 1995" -.Pp -This document and the associated software may be used, modified, -copied, distributed, and sold, in both source and binary form provided -that the above copyright, these terms and the following disclaimer are -retained. The name of the author and/or the contributor may not be -used to endorse or promote products derived from this document and the -associated software without specific prior written permission. -.Pp -THIS DOCUMENT AND THE ASSOCIATED SOFTWARE IS PROVIDED BY THE AUTHOR -AND THE CONTRIBUTOR -.Dq 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 AUTHOR OR THE -CONTRIBUTOR 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 -DOCUMENT AND THE ASSOCIATED SOFTWARE, EVEN IF ADVISED OF THE -POSSIBILITY OF SUCH DAMAGE. -.Sh ��� -.Nm -�ɥ饤�Ф� -.Fx 2.0.5 -�����о줷�ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/ie.4 b/ja_JP.eucJP/man/man4/man4.i386/ie.4 deleted file mode 100644 index 7c314c8cc9..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/ie.4 +++ /dev/null @@ -1,96 +0,0 @@ -.\" $FreeBSD$ -.\" -.\" Copyright (c) 1994, Wilko Bulte -.\" All rights reserved. -.\" -.\" %Id: ie.4,v 1.7 1998/10/22 14:12:55 bde Exp % -.\" -.Dd September 23, 1994 -.Dt IE 4 i386 -.Os -.Sh ̾�� -.Nm ie -.Nd -���������ͥåȥǥХ����ɥ饤�� -.Sh �� -.Cd "device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000" -.Sh ���� -.Nm ie -�ɥ饤�Фϡ�8 �ӥåȵڤ� 16�ӥåȤ� Intel i82586 ���åפ�١����ˤ����� -ISA �������ͥåȥ����ɤΥ��ݡ��Ȥ��󶡤��ޤ��� -����� AT&T �� Starlan 10 �ڤ� Starlan Fiber�� -EN100��Intel EtherExpress 16��3COM 3C507 �ڤ� RACAL Interlan NI5210 -�ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -.Sh ���� -.Bl -diag -.It "ie%d: unknown board type code %d" -i82586 ���åפϸ��Ĥ���ޤ������� -�ɥ饤�Фϥץ�������˼ºݤΥܡ��ɥ����פ����Ǥ��ޤ���Ǥ����� -.It "ie%d: kernel configured maddr %x doesn't match board configured maddr %x" -�ǥХ����ץ����֤ϡ� -�����ͥ�����ե�����˻��ꤵ�줿 maddr �Ȱۤʤ� maddr �ò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.It "ie%d: can't find shared memory" -�ǥХ����ץ����֤ϡ� -��Í������ç¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ë¤¿ï¿½ï¿½Î¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½Ç¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.It "ie%d: kernel configured msize %d doesn't match board configured msize %d" -�ǥХ����ץ����֤ϡ� -��Í������ç¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Í¥ï¿½ï¿½ï¿½ï¿½ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½Ë»ï¿½ï¿½ê¤µï¿½ì¤¿ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È°Û¤Ê¤ë¤³ï¿½È¤ï¿½ -���Ф��ޤ����� -.It "ie%d: kernel configured irq %d doesn't match board configured irq %d" -�ǥХ����ץ����֤ϡ� -�ܡ��ɤγ��������꤬�����ͥ�����ե�����˻��ꤵ�줿����Ȱۤʤ뤳�Ȥ� -���Ф��ޤ����� -.It "ie%d: reset" -Intel i82586 �ϥɥ饤�Фˤ��ꥻ�åȤ����ɬ�פ�����ޤ����� -.It "ie%d: transceiver problem" -�ɥ饤�Фϡ����������ͥåȥȥ�󥷡��Ф�����ò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -����ϡ� -���դ��ȥ�󥷡��Ф���Ѥ��Ƥ���Ȥ��˥ȥ�󥷡��Х����֥뤬�ˤ�Ǥ��롢 -�⤷������»���Ƥ��뤳�Ȥ��̣���ޤ��� -�⤷��������ò¥«¡ï¿½ï¿½É¾ï¿½Î¥È¥ï¿½ó¥·¡ï¿½ï¿½Ð¤Ç·Ð¸ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ë¤Ï¡ï¿½ -�����ɤ����դ��ȥ�󥷡��Ф���Ѥ���褦�� -���äƥ��������ꤵ��Ƥ��뤫�⤷��ޤ��� -�ǰ��ξ�硢����ܡ��ɥȥ�󥷡��Фϲ���Ƥ��뤫�⤷��ޤ��� -.It "ie%d: TDR detected an open %d clocks away" -�ɥ饤�Фϡ� -���������ͥåȥ����֥�β�ϩ�������ץ�ˤʤäƤ��뤳�Ȥò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -Ʊ�������֥�Ƚ����ñ¹³¤ï¿½ï¿½Ç§ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.It "ie%d: TDR detected a short %d clocks away" -�ɥ饤�Фϡ� -���������ͥåȥ����֥뤬û�����Ƥ��뤳�Ȥò¸¡½Ð¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -Ʊ�������֥�Ƚ�ü�ñ¹³¤ï¿½ï¿½Ç§ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.It "ie%d: TDR returned unknown status %x" -�ɥ饤�Фϡ����������ͥåȥ����֥��������ʾ��֤����ޤ����� -.It "ie%d: multicast address setup command failed" -�����ɤϡ��ޥ�����㥹�ȥ⡼�ɤ�����ޤ���Ǥ����� -.It "ie%d: configure command failed" -�����ɤϡ������������˱������뤳�Ȥ���ݤ��ޤ����� -.It "ie%d: individual address setup command failed" -�������ͥåȤ� MAC ���ɥ쥹��ץ�����ह�뤳�Ȥ˼��Ԥ��ޤ����� -.El -.Sh �ٹ� -Racal Interlan NI5210 �ˤϡ� -��Í���꤬ 8K �Х��ȤΤ�Τ� 16K �Х��ȤΤ�ΤȤ�����ޤ��� -16K �Х��ȤΤ�Τ���Ѥ��뤳�Ȥò¶¯¤ï¿½ï¿½ä¾©ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -8K �Х��ȥ����ɤϡ��ɲä� RAM ���åפ�ä��뤳�Ȥˤ�ꡢ -16K �Х��Ȥˤ��뤳�Ȥ��Ǥ��ޤ��� -.Pp -.Sh ��Ϣ���� -.Xr arp 4 , -.Xr netintro 4 , -.Xr ifconfig 8 -.Sh ��� -.Nm -�ǥХ����ɥ饤�Фϡ� -.An William F. Jolitz -�ڤ� Lawrence Berkeley Laboratories �Υ����ɤ��� -.An Garrett A. Wollman -���������ޤ����� -.Tn 3C507 -���ݡ��Ȥ� -.An Charles M. Hannum -���������ޤ����� -���Υޥ˥奢��ڡ����� -.An Wilko C. Bulte -�����Ҥ��ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/io.4 b/ja_JP.eucJP/man/man4/man4.i386/io.4 deleted file mode 100644 index fabd384abc..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/io.4 +++ /dev/null @@ -1,72 +0,0 @@ -.\" -.\" Copyright (c) 1996 Joerg Wunsch -.\" -.\" All rights reserved. -.\" -.\" This program is free software. -.\" -.\" 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 DEVELOPERS ``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 DEVELOPERS 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. -.\" -.\" %Id: io.4,v 1.5 1997/03/21 20:13:45 mpp Exp % -.\" $FreeBSD$ -.\" -.Dd Jan 1, 1996 -.Dt IO 4 i386 -.Os -.Sh ̾�� -.Nm io -.Nd I/O �ø��ե����� -.Sh ���� -�ü�ե����� -.Pa /dev/io -�����沼�ˤ��륻�����ƥ��ۡ���ǡ� -.Pq �̾�ϥ����ͥ�����������ɤ�ͽ�󤵤줿 -I/O �ø������뤳�Ȥ�ץ������˵��Ĥ��ޤ��� -.Pa /dev/io -�ò³«¤ï¿½ï¿½ï¿½ï¿½Õ¥ï¿½ï¿½ï¿½ï¿½ëµï¿½Ò»Ò¤ï¿½ï¿½ï¿½Ã¤ï¿½ï¿½É¤ï¿½Ê¥×¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç¤â¡¢ -�ե饰�쥸�������åȤ���� -.Em IOPL -�ӥåȤ����뤳�Ȥ��Ǥ��ޤ��� -���ʤ����ľ�� I/O �����뤳�Ȥ�������ޤ��� -����ϡ��ϡ��ɥ�������ľ������ -�桼�����ɤΥץ�������ñ¤¯¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Î©ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -���������������� -.Pa /dev/io -�Υե����륢�������ѡ��ߥå����ˤ�äƴ�������Ƥ��ޤ��Τǡ� -���ΥǥХ������������ѡ��ߥå�����Ϳ����褦�� -���դ���ɬ�פ�����ޤ��� -�ɤ߹������ѤΥ��������Ǥ��������٤Ƥ� I/O �ø��� -Ϳ���Ƥ��ޤ����Ȥ����դ��Ƥ��������� -.Sh �ե����� -.Bl -tag -width Pa -compact -.It Pa /dev/io -.El -.Sh ��Ϣ���� -.Xr mem 4 -.Sh ��� -.Nm io -�ե������ -.Fx 1.0 -���о줷�ޤ����� - - - diff --git a/ja_JP.eucJP/man/man4/man4.i386/lnc.4 b/ja_JP.eucJP/man/man4/man4.i386/lnc.4 deleted file mode 100644 index d98101a2e5..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/lnc.4 +++ /dev/null @@ -1,124 +0,0 @@ -.\" -.\" Copyright (c) 1997 David E. O'Brien -.\" -.\" 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. -.\" 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 DEVELOPERS ``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 DEVELOPERS 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. -.\" -.\" %Id: lnc.4,v 1.6 1998/11/06 09:46:02 obrien Exp % -.\" $FreeBSD$ -.\" -.Dd January 19, 1997 -.Dt LNC 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm lnc -.Nd -AMD Lance/PCnet �������ͥåȥǥХ����ɥ饤�� -.Sh �� -.Cd "device lnc0 at isa? port 0x280 net irq 10 drq 0" -.Sh ���� -.Nm -�ɥ饤�Фϡ�Am7990 �� Am79C960 �ޤ� AMD �ե��ߥ�����Ѥ��Ƥ��� -Lance/PCnet Ethernet NIC �ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½ë¤¿ï¿½ï¿½ï¿½ï¿½Ñ°Õ¤ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Nm -���󥿥ե������ˤ�äƥ��ݡ��Ȥ���Ƥ��륤�����ͥåȥ����ɤϼ����̤�Ǥ�: -.Bl -tag -width -offset ident -compat -.It Novell NE2100 -.It Novell NE32-VL -.It Isolan BICC -.It Digital DEPCA -.It Hewlett Packard Vectra 486/66XM -.It Hewlett Packard Vectra XU -.El -.Sh ���� -.Bl -diag -.It "lnc%d: Framing error" -�ե졼�ߥ󥰥��顼��ȯ�����ޤ����� -����Ϥޤ���CRC ���顼��ȯ���������Ȥ��̣���Ƥ��ޤ��� -���η�̡� -�ɥ饤�Фϥե졼�ߥ󥰥��顼��ޤ�Ǥ���ѥ��åȤ���Ȥ��ޤ����� -.It "lnc%d: Receive CRC error" -���������������ͥåȥե졼��ϡ�CRC �����å�����˼��Ԥ��ޤ����� -���η�̡� -�ɥ饤�Ф������å�����˼��Ԥ����ѥ��åȤ���Ȥ��ޤ����� -.It "lnc%d: Packet dropped, no mbufs" -�ɥ饤�Ф� mbuf ��Ȥ��̤��Ƥ��ޤ��ޤ����� -�����餯�ñ¸»¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È»×¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It "lnc%d: Couldn't allocate memory for NIC" -��̿Ū���顼�Ǥ��� -���ξ������Ǥϡ������ɤ��Ф��ƥɥ饤�Фϥ����å�����ޤ��� -.It "lnc%d: Memory allocated above 16Mb limit" -ISA �� ESIA �����ɤϡ� -16MB �ʾ���ΰ�� DMA ž����Ԥ�����ˡ��Х��󥹥Хåե���ɬ�פȤʤ�ޤ��� -Am7990 �� Am79C960 �Υ��ɥ쥹�饤��� 24 �ܤ�������ޤ���Τǡ� -ʪ������Τ��������̤� 16MB �ˤ������������Ǥ��ޤ��� -.Nm -�ɥ饤�Фϡ����ʤ�������Ƥ���꤬���� 16MB ���ϰ���ˤ���Ȳ��ꤷ�Ƥ��ޤ��� -����Ϥ��ޤ������ʲ���ǤϤ���ޤ��󤬡� -����ʳ�����ˡ�Ϻ��ΤȤ�������Ǥ��ޤ��� -��Í��������Ѥ��� NIC �˴ؤ��Ƥϴط�����ޤ��� -.It "lnc%d: Device timeout -- Resetting" -�ǥХ����ϥͥåȥ���˱�������Τ���ߤ����������뤤�ϡ� -�ͥåȥ����³ (�����֥�) �˴ؤ������꤬ȯ�����ޤ����� -������Υͥåȥ����³�ȥ����ɤ����꤬Ʊ���ˤʤäƤ��뤫 -�ɤ�����ǧ���Ƥ��������� -.It "lnc%d: Transmit late collision -- Net error?" -.It "lnc%d: Loss of carrier during transmit -- Net error?" -.It "lnc%d: Transmit of packet failed after 16 attempts -- TDR = %d" -.It "lnc%d: Heartbeat error -- SQE test failed" -.It "lnc%d: Babble error - more than 1519 bytes transmitted" -.It "lnc%d: Missed packet -- no receive buffer" -.It "lnc%d: Memory error -- Resetting" -.It "lnc%d: Couldn't get mbuf for transmit packet -- Resetting" -.It "lnc%d: Receive buffer error" -.It "lnc%d: Receive overflow error" -.It "lnc%d: Receive interrupt with buffer still owned by controller -- Resetting" -.It "lnc%d: Receive interrupt but not start of packet -- Resetting" -.It "lnc%d: Start of packet found before end of previous in receive ring -- Resetting" -.It "lnc%d: End of received packet not found -- Resetting" -.It "lnc%d: Transmit interrupt with buffer still owned by controller -- Resetting" -.It "lnc%d: Transmit interrupt but not start of packet -- Resetting" -.It "lnc%d: Start of packet found before end of previous in transmit ring -- Resetting" -.It "lnc%d: End of transmitted packet not found -- Resetting" -.It "lnc%d: Transmit buffer error -- Resetting" -.It "lnc%d: Transmit underflow error -- Resetting" -.El -.Sh �Х� -���Υɥ饤�Фϡ� -�ɤΥ������ͥåȥɥ饤�Ф����Ĺ�˺���Ƥ����ǽ��������ޤ��� -.Sh ��Ϣ���� -.Xr arp 4 , -.Xr netintro 4 , -.Xr ifconfig 8 -.Sh ��� -.Nm -�ǥХ����ɥ饤�Ф� -.Fx 2.2 -�����о줷�ޤ����� -.Sh ��� -.Nm -�ǥХ����ɥ饤�Ф� -.An Paul Richards -���������ޤ����� -���Υޥ˥奢��ڡ����� -.An David E. O'Brien -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ diff --git a/ja_JP.eucJP/man/man4/man4.i386/mcd.4 b/ja_JP.eucJP/man/man4/man4.i386/mcd.4 deleted file mode 100644 index fb25731e30..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/mcd.4 +++ /dev/null @@ -1,151 +0,0 @@ -.\" -.\" Copyright (c) 1994 Keith E. Walker -.\" 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. -.\" 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. -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software withough specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: mcd.4,v 1.6 1998/10/22 14:12:55 bde Exp % -.\" $FreeBSD$ -.\" -.Dd December 8, 1994 -.Dt MCD 4 i386 -.Os FreeBSD 2.0 -.Sh ̾�� -.Nm mcd -.Nd Mitsumi CD-ROM �ɥ饤�� -.Sh �� -.Cd "device mcd0 at isa? port 0x300 bio irq 10" -.Sh ���� -.Nm mcd -�ɥ饤�Ф� Mitsumi �� CD-ROM �ץ쥤����Ф��ơ��ǡ����ȥ����ǥ����� -���󥿥ե��������󶡤��ޤ��� -CD-ROM �ץ쥤��ϡ�Mitsumi ���ѤΥ���ȥ����� -�ܡ��ɤ� 1 �Ĥ�Ф�ISA �Х�����³����Ƥ��뤳�Ȥ�ɬ�פǤ��� -���ݡ��Ȥ���Ƥ��륳��ȥ�����ܡ��ɤ� LU002S, LU005S, FX001, �����ư���Ū�� -FX001D �Ǥ��� -.Pp -.Nm mcd -�ɥ饤�Фϥǥ�������Í�� -.Fn ioctl -���ޥ�ɡ����ʤ�� -.Dv DIOCGDINFO , -.Dv DIOCGPART , -.Dv DIOCWDINFO , -.Dv DIOCSDINFO , -���ޥ�ɤ��Ф��Ʊ������ޤ��� -¾�Υǥ�������Í�� -.Fn ioctl -���ޥ�ɤˤϥ��顼���֤���Τ⤢��Ǥ��礦�� -.Pp -.Nm mcd -�ɥ饤�Фϡ����̤� CD-ROM -.Fn ioctl -���ޥ�ɤ��Ф��Ƥ�������ޤ��������Υ��ޥ�ɤϡ�CD-ROM �ץ쥤��� -�����ǥ�����ǽ�����椷�ޤ��� -���ޥ�ɤϼ����̤�Ǥ�: -.Pp -.Bl -tag -width CDIOCREADSUBCHANNEL -compact -offset indent -.It CDIOCREADSUBCHANNEL -�ǥ������������θ��ߤξ��֤ˤ����륵�֥���ͥ�ξ����������ޤ��� -.It CDIOCREADTOCHEADER -�ܼ��إå���������ޤ��� -.It CDIOCREADTOCENTRYS -���Ƥ��ܼ���������ޤ��� -.It CDIOCPLAYTRACKS -���ꤵ�줿���֤ˤ����ơ������ǥ���������Ϥ�ޤ��� -.It CDIOCPLAYBLOCKS -.Dv EINVAL -���顼�Ǽ��Ԥ��ޤ��� -.It CDIOCPLAYMSF -���ꤵ�줿���֤ˤ����ơ������ǥ���������Ϥ�ޤ��� -.It CDIOCRESUME -���餫��������ߤ����ǥ������κ�����쥸�塼�ष�ޤ��� -.It CDIOCPAUSE -�ǥ������κ���������ߤ��ޤ��� -.It CDIOCSTART -�ǥ�����������Ϥ�ޤ��� -.It CDIOCSTOP -���餫���������Υǥ���������ߤ��ޤ��� -.It CDIOCEJECT -�ǥ������ȥ졼�ò¥ª¡ï¿½ï¿½×¥ó¤·¤Þ¤ï¿½ -(�����������륳�ޥ�ɤϥ��ݡ��Ȥ���Ƥ��ޤ���)�� -.It CDIOCRESET -�������������ߤ���Mitsumi ����ȥ�����ܡ��ɤ�ꥻ�åȤ��ޤ��� -.It CDIOCSETDEBUG -�����ͥ�� -.Nm mcd -�ɥ饤�ФˤĤ��ƤΥǥХå���å������ò¥³¥ó¥½¡ï¿½ï¿½ï¿½Ë½ï¿½ï¿½Ï¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It CDIOCCLRDEBUG -�����ͥ�� -.Nm mcd -�ɥ饤�ФˤĤ��ƤΥǥХå���å������ν��Ϥ�λ���ޤ��� -.El -.Pp -�åµï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.Fn ioctl -���ޥ�ɤ� -.Nm mcd -�ɥ饤�Ф����ݡ��Ȥ��륳�ޥ�ɤ����Ǥ���( -.Dv CDIOCSETVOL -�� -.Dv CDIOCSETSTERIO -�Τ褦��) CD-ROM ��Ϣ -.Fn ioctl -���ޥ�ɤ�¸�ߤ��ޤ��������Τ褦�ʥ��ޥ�ɤ� -�ɥ饤�Фξ���ΥС������ǥ��ݡ��Ȥ���뤫���Τ�ޤ��� -.Sh ��Ϣ�ե����� -.Bl -tag -width /dev/(r)mcd0a -compact -.It Pa /dev/(r)mcd0a -�ǥ�������� BSD �ѡ��ƥ������˥����������ޤ����̾CD-ROM �ǥ����� -���¸�ߤ���ե����륷���ƥ��ñ��Ǥ��� -.It Pa /dev/(r)mcd0c -raw �ǥХ����˥����������ޤ��� -.El -.Sh �� -.Nm mcd -�ɥ饤�ФΥ���饯���⡼�ɥǥХ����ϡ� -�����ǥ�����ǽ�˸��ꤷ�ƥ����������뤿��˻Ȥ��٤��Ǥ��� -�ǡ�����ǽ�˥�����������ȡ���ǽ���Ҥɤ���������Ǥ��� -.Pp -�ɥ饤�Фθ��ߤΥС������ϡ��������줿������ IRQ ���Ф��Ƴ����� -�ϥ�ɥ���ݻ����Ƥ���ˤ⤫����餺�����󥿥ե������ܡ��ɤ� DMA �� -IRQ ��ǽ�Τɤ�����Ѥ��Ƥ��ޤ��� -�Ȥ⤫�� DMA ��ǽ�����ݡ��Ȥ����ޤǡ��ܡ��� -��������������ߤ����ϥɥ饤�Фˤ�äƥ��ݡ��Ȥ���ޤ��� -.Sh ��Ϣ���� -.Pa /usr/include/sys/cdio.h -.Sh ��� -�ɥ饤�Ф� -.An Holger Veit -(�ǡ�����ʬ) �ڤ� -.An Brian Moore -(�����ǥ�����ʬ) ���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ð¤ï¿½ï¿½ï¿½ï¿½Ñ¹ï¿½ï¿½ï¿½ -.An Gary Clark II , -.An Andrew A. Chernov , -.An Jordan K. Hubbard -�ˤ�ä��󶡤���ޤ����� -.Sh ��� -.Nm mcd -�ɥ饤�Ф� -.Fx 1.0 -�Ǻǽ���о줷�ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/npx.4 b/ja_JP.eucJP/man/man4/man4.i386/npx.4 deleted file mode 100644 index f44bbaabde..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/npx.4 +++ /dev/null @@ -1,79 +0,0 @@ -.\" -.\" Copyright (c) 1993 Christopher G. Demetriou -.\" 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. -.\" 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. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by Christopher G. Demetriou. -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software withough specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" from: npx.4,v 1.1 1993/08/06 10:58:03 cgd Exp -.\" %Id: npx.4,v 1.5 1998/10/22 14:22:13 bde Exp % -.\" $FreeBSD$ -.\" -.\" WORD: Numeric Processing Extension coprocessor ���ͱ黻���ץ����å� -.\" -.Dd August 28, 1993 -.Dt NPX 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm npx -.Nd ���ͱ黻���ץ����å��ȥ��ߥ�졼�� -.Sh �� -.Cd "options MATH_EMULATE" -.\" XXX this is awful hackery to get it to work right... -- cgd -.Cd "device npx0 at isa? port IO_NPX tty irq 13" -.Sh ���� -.Nm npx -�ɥ饤�Фϡ������ƥ�˿��ͱ黻���ץ����å�������С� -��������ѤǤ���褦�ˤ��ޤ��� -��ĥ���ͱ黻��ǽ (NPX) �ϡ� -.Sy 486DX -CPU ��Ȥä������ƥ�䡢 -.Sy 387 -�ޤ��� -.Sy 487SX -���ץ����å���Ȥä������ƥ��¸�ߤ��ޤ��� -.Nm npx -�ɥ饤�Ф� NPX ��¸�ߤ��뤫�ݤ��˴ؤ�餺�� -�����ƥब�����ư��뤿���ɬ�פǤ��� -.Pp -�⤷ NPX �������ƥ��¸�ߤ��ʤ����ˤϡ� -�����ͥ�����ե������ "MATH_EMULATE" ���ץ���� -���Ҥ���Ƥ��뤳�Ȥ�ɬ�פǤ��� -����ˤ�ꡢ�̾�� NPX �Ǽ¹Ԥ����̿�᤬���ݡ��Ȥ���ޤ��� -�����ƥ�� NPX ��¸�ߤ����������ͥ뤬���إ��ߥ�졼�������դ����� -���ۤ���Ƥ�����ˤϡ������ƥ�ϵ�ư���ޤ��� -.Sh �ٹ� -���ߥ�졼���� NPX ���ץ����å�����٤������٤��Ǥ��� -���Τ��ᡢ���ߥ�졼����Ȥ�ʤ���Фʤ�ʤ��Ȥ��ˤϡ� -��ư�������黻����ǽ�������ʤ�ޤ��� -.Sh �Х� -�������󤢤�ޤ����ä˰¤äݤ��ޥ����ܡ��ɾ�ǻȤä����ˤϤ����Ǥ��� -NPX ���� CPU �ؤγ����ߥ饤����������������Ƥ��ʤ� -�ޥ����ܡ��ɤ�����ޤ��� -�⤷���Τ褦�ʾ��ˡ������ƥब��������ư��ò¤¹¤ë¤³ï¿½È¤ï¿½Ë¾ï¿½ï¿½Ê¤ï¿½Ð¡ï¿½ -���ߥ�졼����Ȥ����Ȥ�ɬ�פǤ��� -.Pp -Ķ�۴ؿ�̿��Υ��ߥ�졼�����������ΤǤ��� -����ʳ���̿��Υ��ߥ�졼������������Ǥ��� diff --git a/ja_JP.eucJP/man/man4/man4.i386/pcf.4 b/ja_JP.eucJP/man/man4/man4.i386/pcf.4 deleted file mode 100644 index 7f14fc2530..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/pcf.4 +++ /dev/null @@ -1,65 +0,0 @@ -.\" Copyright (c) 1998, Nicolas Souchu -.\" 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. -.\" 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 AUTHOR 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 AUTHOR 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$ -.Dd August 6, 1998 -.Dt PCF 4 -.Os FreeBSD -.Sh ̾�� -.Nm pcf -.Nd -Philips I2C �Х�����ȥ����� -.Sh �� -.Cd "controller pcf0 at isa? port? irq 5" -.Pp -1 �İʾ�� iicbus ������ -.Cd "controller iicbus0" -.Sh ���� -.Em pcf -�ɥ饤�Ф� -.Xr iicbus 4 -�����ƥ��Ѥ� Philips PCF8584 I2C ����ȥ�����Υ��ݡ��Ȥ��󶡤��ޤ��� -.Pp -PCF8584 �� CMOS �ƥ��Υ������߷פ��줿���Ѳ�ϩ�Ǥ��ꡢ -�ۤȤ�ɤ�ɸ��Ū�ʥѥ���Х��ޥ���������ȥ�����/�ޥ������ץ����å��� -���ꥢ�� I2C �Х��Ȥδ֤Υ��󥿥ե��������󶡤��ޤ��� -PCF8584 �ϥޥ����ȥ��졼�֤�ξ���ε�ǽ���󶡤��ޤ��� -I2C �Х��Ȥ��̿��ϳ����ߤ��ݡ���󥰥ϥ�ɥ���������Ȥ��� -�Х��Ȥ���ܤȤ��Ƽ¹Ԥ���ޤ��� -�ޤ���I2C ����Í�Υ������󥹡��ץ��ȥ��롢Ĵ�䡢�����ߥ󥰤����Ƥ� -���椷�ޤ��� -PCF8584 �ϥѥ���Х������ƥ�� I2C �Х��Ȥ��������̿����ǽ�ˤ��Ƥ��ޤ��� -.Pp -.Sh ��Ϣ���� -.Xr iicbus 4 -.Sh ��� -.Nm -�ޥ˥奢��ڡ����� -.Fx 3.0 -���о줷�ޤ����� -.Sh ��� -���Υޥ˥奢��ڡ����� -.An Nicolas Souchu -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ diff --git a/ja_JP.eucJP/man/man4/man4.i386/perfmon.4 b/ja_JP.eucJP/man/man4/man4.i386/perfmon.4 deleted file mode 100644 index 16d20578b0..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/perfmon.4 +++ /dev/null @@ -1,225 +0,0 @@ -.\" -.\" Copyright 1996 Massachusetts Institute of Technology -.\" -.\" Permission to use, copy, modify, and distribute this software and -.\" its documentation for any purpose and without fee is hereby -.\" granted, provided that both the above copyright notice and this -.\" permission notice appear in all copies, that both the above -.\" copyright notice and this permission notice appear in all -.\" supporting documentation, and that the name of M.I.T. not be used -.\" in advertising or publicity pertaining to distribution of the -.\" software without specific, written prior permission. M.I.T. makes -.\" no representations about the suitability of this software for any -.\" purpose. It is provided "as is" without express or implied -.\" warranty. -.\" -.\" THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''. M.I.T. DISCLAIMS -.\" ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE, -.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT -.\" SHALL M.I.T. 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. -.\" -.\" %Id: perfmon.4,v 1.6 1998/03/12 07:30:36 charnier Exp % -.\" $FreeBSD$ -.Dd March 26, 1996 -.Dt PERFMON 4 i386 -.Os FreeBSD 2.2 -.Sh ̾�� -.Nm perfmon -.Nd CPU ����ǽ��˥���󥰤ò¤¹¤ë¥¤ï¿½ó¥¿¥Õ¥ï¿½ï¿½ï¿½ï¿½ï¿½ -.Sh �� -.Cd cpu \&"I586_CPU\&" -.Cd cpu \&"I686_CPU\&" -.Cd options PERFMON -.Sh ���� -.Nm perfmon -�ɥ饤�Фˤ�� -.Tn Intel -�� -.Tn Pentium -�� -.Tn "Pentium Pro" -�� -CPU ��������ǽ��˥���󥰵�ǽ�˥��������Ǥ��ޤ��� -�����Υץ����å��ˤ�¿�̤ʥ��٥�ȤˤĤ���ȯ������ޤ��� -(CPU ��������Ǥ�) ��³���֤Τɤ��餫��¬�ꤹ��褦������Ǥ��� -2 �Ĥ����������󥿤ȡ�Ʊ���������å��������������� -1 �ĤΥ������륫���󥿤���������Ƥ��ޤ��� -.Nm -�ɥ饤�ФǤϤ����ε�ǽ���Ф��ƥǥХ��������ˤ�륤�󥿥ե��������� -���ޤ��� -.Pp -��ǽ��˥���󥰤ò¤¹¤ë¥«ï¿½ï¿½ï¿½ó¥¿¤Ø¤ï¿½ï¿½ï¿½ï¿½Æ¤Î¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -�ǥХ������ü�ե������ -.Dq Pa /dev/perfmon -���޲�Ȥ��ƽ�������ޤ��� -���ΥǥХ������󶡤��� -.Xr ioctl 2 -�ꥯ�����Ȥ�¿������ -.Aq Pa machine/perfmon.h -�����������졢���Υե��������ˤ� -.Tn Pentium -�� -.Tn "Pentium Pro" -�ץ����å���ξ���ο����ʥ����󥿤�����⤢��ޤ��� -.Pp -.Sy ���ջ���: -���Ѳ�ǽ�ʥ��٥�Ȥν���ϥץ����å���˰ۤʤ�ޤ��� -���Ѥ���륤�٥�ȥ����ɤ�¬�ꤵ��� CPU �η������Ф��� -Ŭ���Ǥ��뤳�Ȥ��ǧ���뤳�Ȥϥץ�����ޤ���Ǥ�Ǥ��� -.Pp -�ʲ��� -.Xr ioctl 2 -�ꥯ�����Ȥ��������Ƥ��ޤ�: -.Bl -tag -width PMIOTSTAMP -.It Dv PMIOSETUP -.Pq Li "struct pmc" -��¤�Τ��������Ƥ���ѥ�᡼���ȥե饰�ǥ����󥿤����ꤷ�ޤ��� -�ʲ��Υե�����ɤ� -.Li struct pmc -���������Ƥ��ޤ�: -.Bl -tag -width "u_char pmc_eventx" -.It Li "int pmc_num" -���ꤹ�륫�����ֹ�Ǥ��� -.Dv NPMC -(���ߤ� 2) ��꾮�����ʤ���Фʤ�ޤ��� -.It Li "u_char pmc_event" -��˥����٤�����Υ��٥�ȥ����ɤǡ� -.Aq Pa machine/perfmon.h -���������Ƥ��ޤ��� -.It Li "u_char pmc_unit" -���٥�Ȥη����б��������֤Υޥ������ͤǤ� ( -.Tn Intel -��ʸ��ò»²¾ï¿½)�� -.It Li "u_char pmc_flags" -�����󥿤�Ư�����ѹ�����ե饰 (��������) �Ǥ��� -.It Li "u_char pmc_mask" -�����󥿤Υޥ������ͤǤ����Ĥޤꡢ���衢�����ͤϻ��ꤵ�줿���Υ����å� -�ʾ� (���ϰʲ�) �δַ�³���륤�٥�Ȥ˥�����Ȥ����¤���٤˻��Ѥ���뤷������ -�Ǥ��� -.El -.Pp -���Τ褦�� -.Li pmc_flags -���ͤ��������Ƥ��ޤ�: -.Bl -tag -compact -width PMCF_USRxx -.It Dv PMCF_USR -���٥�Ȥ�桼���⡼�ɤǥ�����Ȥ��ޤ��� -.It Dv PMCF_OS -���٥�Ȥò¥«¡ï¿½ï¿½Í¥ï¿½â¡¼ï¿½É¤Ç¥ï¿½ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Dv PMCF_E -���٥�Ȥ��³���֤ǤϤʤ����ο��ǥ�����Ȥ��ޤ��� -.It Dv PMCF_INV -�����󥿤Υޥ�������Ӥΰ�̣���ž���ޤ��� -.El -.It Dv PMIOGET -.Pq Li "struct pmc" -���ꤵ�줿�����󥿤θ��ߤ�������֤��ޤ��� -.It Dv PMIOSTART -.It Dv PMIOSTOP -.Pq Li int -���ꤷ�������󥿤�ư (���) ���ޤ����ϡ��ɥ������η�٤ˤ�ꡢ�ֹ��� -��ư����ߤò¤·¤Ê¤ï¿½ï¿½ï¿½Ð¤Ê¤ï¿½Þ¤ï¿½ï¿½ï¿½ -(¨���������� 0 ��ɬ���ޤ������� 1 ����ߤ��Ƥ�����ߤ��ʤ���Фʤ�ޤ���)�� -�ɥ饤�ФǤϤ�������� -.Sy �������Ƥ��ޤ��� -(�ȸ����Τâ¾ï¿½ï¿½ï¿½ CPU �ǤϤ�������Ϥʤ��ʤ뤫���Τ�ޤ���)�� -.It Dv PMIORESET -.Pq Li int -���ꤵ�줿�����󥿤� 0 �˥ꥻ�åȤ��ޤ��������󥿤ϥꥻ�åȤ������� -.Dv PMIOSTOP -�ˤ����ߤ���ʤ���Фʤ�ޤ������ƤΥ����󥿤ϼ�ưŪ�� -.Dv PMIOSETUP -�ˤ�äƥꥻ�åȤ���ޤ��� -.It Dv PMIOREAD -.Pq Li "struct pmc_data" -�����󥿤θ��ߤ��ͤ���Ф��ޤ��� -.Li pmc_data -��¤�Τˤϼ��Τ褦�� 2 �ĤΥե�����ɤ��������Ƥ��ޤ�: -.Pp -.Bl -tag -compact -width "quad_t pmcd_value" -.It Li "int pmcd_num" -�ɤ߽Ф������󥿤��ֹ档 -.It Li "int pmcd_value" -64 �ӥåȤ�����դ������Ǥν�λ�͡� -.El -.Pp -���衢 -.Tn "Pentium Pro" -�ץ����å����� -�����󥿤�ľ���ɤ߽Ф��٤� -.Li RDPMC -̿�����ѽ�����ͤˤʤ�Ǥ��礦�� -.It Dv PMIOTSTAMP -.Pq Li "struct pmc_tstamp" -�����ॹ����ץ����󥿤��ɤ߽Ф��ޤ��� -.Li pmc_tstamp -��¤�ΤǤ� 2 �ĤΥե�����ɤ��������Ƥ��ޤ�: -.Pp -.Bl -tag -compact -width "quad_t pmct_value" -.It Li "int pmct_rate" -�����󥿤� MHz �ǤΤ����褽��®�٤Ǥ��� -.It Li "quad_t pmct_value" -64 �ӥå������ǤΥ����󥿤θ��ߤ��ͤǤ��� -.El -.Pp -.Li pmct_rate -�ե�����ɤ�Ϳ�����륫���󥿤�®�٤ϡ� -����������ʻ��䥯���å��οʹԤ��Դ����ʰ٤ˡ� -�����ˤ������ΤǤϤʤ����Ȥ����դ���������ڤǤ��� -���Υե�����ɤˤĤ��Ƥ� -�����å������®�٤�ºݤ�ɽ�������ΤȤ������� -�꤬���꤫����Ŭ�����θ������餤�˹ͤ���٤��Ǥ��� -.El -.Sh ��Ϣ�ե����� -.Bl -tag -compact -width "/usr/include/machine/perfmon.h" -.It Pa /dev/perfmon -�����󥿤ؤ�ʸ�����ǥХ����Υ��󥿥ե����� -.It Pa /usr/include/machine/perfmon.h -��¤�Τȥ��٥�ȥ����ɤ�������Ƥ��륤�󥯥롼�ɥե����� -.It Pa /usr/share/examples/perfmon -���Ƥ� -.Fn ioctl -���ޥ�ɤλ��Ѥ����Ū���㼨��������ץ�Υ����������� -.El -.Sh ��Ϣ���� -.Xr ioctl 2 -.Rs -.%A Intel Corporation -.%B Pentium Pro Family Developer's Manual -.%D January 1996 -.%V vol. 3 -.%O Operating System Writer's Manual -.Re -.\"���������� -.Rs -.%A ����ƥ른��ѥ������� -.%B Pentium Pro �ե��ߥ꡼ �ǥ��٥��åѡ��� �ޥ˥奢�� -.%D January 1996 -.%V ���� -.%O ���ڥ졼�ƥ��� �����ƥ� �饤������ �ޥ˥奢�� -.Re -.\"���������� -.Sh ��� -The -.Nm -�ǥХ����� -.Fx 2.2 -�ǽ��Ƹ���ޤ����� -.Sh ��� -.Nm -�ɥ饤�Ф� -.An Garrett A. Wollman , -MIT Laboratory for Computer Science -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.\"Translated by Tetsuro Furuya <ht5t-fry@asahi-net.or.jp>, Dec. 1999. -.\"ML Checked by Tetsuya Isaki (���ů��) <isaki@net.ipc.hiroshima-u.ac.jp>, -.\" Satoru Koizumi (���� �� )<koizumi@cms.phys.s.u-tokyo.ac.jp> -.\"Final Checked by diff --git a/ja_JP.eucJP/man/man4/man4.i386/pnp.4 b/ja_JP.eucJP/man/man4/man4.i386/pnp.4 deleted file mode 100644 index ea64430402..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/pnp.4 +++ /dev/null @@ -1,221 +0,0 @@ -.\" pnp(4) - manual page for the scanner device driver `asc' -.\" -.\" -.\" Copyright (c) 1997 Luigi Rizzo -.\" -.\" 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. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgements: -.\" This product includes software developed by Luigi Rizzo. -.\" 4. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: pnp.4,v 1.2 1998/03/12 07:30:36 charnier Exp % -.\" -.\" Based on Japanese translation by Yasuhito FUTATSUKI <futatuki@fureai.or.jp> -.\" [man-jp 1426] -.\" $FreeBSD$ -.\" -.Dd September 7, 1997 -.Dt PNP 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm pnp -.Nd PnP �ǥХ����Υ��ݡ��� -.Sh �� -.Cd controller pnp0 -.Sh ���� -.Fx -�� PnP �ǥХ������ݡ��Ȥˤ�äơ��桼���� PnP �����ɤ������ -�������ꤹ�뤳�Ȥ���ǽ�ˤʤ�ޤ����ޤ����ǥХ����ɥ饤�Ф� PnP �����ɤ� -�ѥ�᡼����������ѹ����뤳�Ȥ���ǽ�ˤʤ�ޤ��� -.Pp -��ư�Ƕ������ꤹ�뵡ǽ���Ѥ��뤿��ˤϡ������ͥ�� -.Cd options USERCONFIG -�դ��ǥ���ѥ��뤹��ɬ�פ�����ޤ��� -���ΤȤ������ͥ�ϡ�PnP �ǥХ����������Ͽ���뤿��� -������ç¤ï¿½ï¿½ï¿½Î¥Æ¡ï¿½ï¿½Ö¥ï¿½ (�ǥե���Ȥ� 20 ����ȥ�) ����ݤ��ޤ��� -PnP ������ 1 �Ĥ�ʣ������Ω�����ǥХ������鹽������Ƥ��� -���Ȥ⤢��ޤ� (5 �� 6 �Ĥ⤢��Ȥ������Ȥϰ۾�ǤϤ���ޤ���)�� -.Pp -�����ͥ�� -.Dq Fl c -�ե饰�դ��ǥ֡��Ȥ��뤳�Ȥǡ� -PnP �����ɤ������ѹ��Υ��ޥ�ɤ���ѤǤ��ޤ������ޥ�ɤ� -.Dl pnp CSN LDN -�Ȥ����������󥹤���Ϥޤ�ޤ��������ǡ�CSN �ʤ�Ӥ� LDN �� -���줾�졢�ǥХ����˿����Ƥ��륫���������ֹ� -.Pq Card Select Number -����������ǥХ����ֹ� -.Pq Logiacal Device Number -�Ǥ��� -���Υ������󥹤�³���ơ��ʲ��Υ��ޥ�ɤ�Ǥ�դ��Ȥ߹�碌���Ȥ��ޤ��� - -.Bl -tag -width "mmmmmmmmmm"" -.It Dv irqN Ar line -�����ɾ�γ����� 0 �ޤ��� 1 -.Pq ����: N �ǻ��� -�˻��Ѥ��� IRQ �������ꤷ�ޤ��� -.Ar line -�� 0 ����ꤹ�뤳�Ȥϡ�IRQ ������Ѥ��ʤ����Ȥ��̣���ޤ��� -.It Dv drqN Ar n -�����ɾ�� DMA 0 �ޤ��� 1 -.Pq ����: N �ǻ��� -�˻��Ѥ��� DRQ ����ͥ�����ꤷ�ޤ��� -����ͥ�� 4 ����ꤹ�뤳�Ȥϡ�����ͥ����Ѥ��ʤ����Ȥ��̣���ޤ��� -.It Dv portN Ar address -N ���ܤΥݡ����ΰ� -.Pq port's range -�δ��쥢�ɥ쥹 -.Pq base address -�����ꤷ�ޤ� (N=0..7)�� -.Ar address -�� 0 ����ꤹ�뤳�Ȥϡ��ݡ��Ȥ���Ѥ��ʤ����Ȥ��̣���ޤ��� -.It Dv memN Ar address -N ���ܤΥ����ΰ� -.Pq memory's range -�δ��쥢�ɥ쥹 -.Pq base address -�����ꤷ�ޤ� (N=0..3)�� -.Ar address -�� 0 ����ꤹ�뤳�Ȥϡ������ΰ����Ѥ��ʤ����Ȥ��̣���ޤ��� -.It Dv bios -PnP �ǥХ���������Ȥ��ơ�BIOS �����ꤷ����Τ���Ѥ��ޤ��� -����ϥǥե���ȤǤ��ꡢ -BIOS �� PnP �ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½Ë¤ï¿½ï¿½Ì¾ï¿½Ï¤ï¿½ï¿½ï¿½Ç¤è¤¤ï¿½Ç¤ï¿½ï¿½ç¤¦ï¿½ï¿½ -BIOS �������Ѥ�����ˤ� -.Dq Dv flags -�ʳ��Υѥ�᡼����̵�뤵��ޤ��� -.It Dv os -PnP �ǥХ���������ˡ����Υ���ȥ�ǻ��ꤷ����Τ���Ѥ��ޤ��� -.It Dv enable -PnP �ǥХ�����Í���ˤ��ޤ��� -.It Dv disable -PnP �ǥХ�����̵���ˤ��ޤ��� -.It Dv delete -�ǥХ����˻��Ѥ���Ƥ��륨��ȥ���������̤� CSN/LDN ���Ȥ���� -¾�ΥǥХ����ǻ��ѤǤ���褦�ˤ��ޤ��� -.It Dv flags -�ǥХ����ɥ饤�Ф��Ϥ� 32 �ӥåȤ� flags ����ȥ���ͤ����ꤷ�ޤ��� -flags �ϡ����̤�ư��⡼�ɤ���ꤹ��Τ˻Ȥ��뤳�Ȥ�����ޤ��� -(�㤨�С������Υ�����ɥ����ɤ� SB �� WSS �Υ��ߥ�졼������ -�ڤ��ؤ��롢�ʤ�) -.El -.Pp -���ߤΥơ��֥���������ͤϡ�userconfig �� -.Ic ls -���ޥ�ɤ�ɽ������ޤ��� -���Υơ��֥�ϡ��桼�����Ԥʤä��ѹ��˲ä��� -PnP �ǥХ����ɥ饤�Ф����������������٤Ƥ������ǥХ����Υ���ȥ�� -�ݻ����ޤ��� -.Pp -�ơ��֥���ѹ���̤ϡ� -.Xr dset 8 -���ޥ�ɤˤ�äƥե����륷���ƥ��Υ֡��ȥ��᡼������¸����ޤ��� -.Pq ����: �����ͥ�� ELF ���ˤ�� dset ���ޥ�ɤ��ѻߤ���ޤ��� -.Pp -.Sh PnP �ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½ï¿½Ç¥Ð¥ï¿½ï¿½ï¿½ï¿½É¥é¥¤ï¿½ï¿½ -�����ͥ�� PnP �ǥХ�����ưŪ��ǧ���������ꤷ�ޤ��� -PnP �ǥХ����ϰʲ��Υǡ�����¤�Ǽ��̤��ޤ��� -.Bd -literal -struct pnp_device { - char *pd_name; - char *(*pd_probe ) (u_long csn, u_long vendor_id); - void (*pd_attach ) (u_long csn, u_long vend_id, char * name, - struct isa_device *dev); - u_long *pd_count; - u_int *imask; - struct isa_device dev; -}; -.Ed -.Pp -�ץ����� (probe) �롼����ϡ��Ϥ���� vendor_id ����ʬ�� -ǧ�������ΤǤ��뤫�� -���������ɬ�פʥǥХ�����Í���ˤʤäƤ��뤫������å����� -������� -���Ԥ������ˤ� NULL �ͤ������������ˤ� NULL �Ǥʤ��� -(���̤˥ǥХ���̾��ؤ��ݥ���) ���֤��ޤ��� -�ץ����֥롼������ˤ����ơ������ǥХ�����Í���Ǥ��뤫�ɤ����� -�����å��ˤϡ� -.Fn read_pnp_parms -����ѤǤ��ޤ��� -.Pp -�����å� (attach) �롼����ϡ� -PnP �����ɤ� ISA ����������ǽ�ˤ��롢 -�����������롢�ǥХ����� ISA �ɥ饤�Ф�Ƥ֡� -�Ȥ��ä�ɬ�פʽ�����ò¤¹¤Ù¤Æ¹Ô¤ï¿½ï¿½ï¿½ï¿½È¤ï¿½É¬ï¿½×¤Ç¤ï¿½ï¿½ï¿½ -.Pp -���Υ롼����ȥǡ�����¤�����ѤǤ��ޤ��� -.Bl -tag -width "xxxxxxxxxx" -.It Dv struct pnp_cinfo -���Υǡ�����¤ -.Po -.Pa /usr/i386/isa/pnp.h -���������Ƥ��� -.Pc -�ϡ� -PnP �����ǥХ����˴�Ϣ���뤹�٤Ƥξ����ޤ�Ǥ��ޤ��� -.It Fn read_pnp_parms "struct pnp_cinfo *d" "int ldn" -���δؿ����׵ᤵ�줿�����ǥХ�����������֤��ޤ��� -���δؿ��ϥץ����֤���ӥ����å��� -�롼���󤫤�ƤФ�뤳�Ȥ��������ꤷ�Ƥ��뤿�ᡢ -CSN ����ꤹ�뤳�ȤϤǤ��ޤ��� -.It Fn write_pnp_parms "struct pnp_cinfo *d" "int ldn" -���δؿ����׵ᤵ�줿�����ǥХ����Υѥ�᡼�������ꤷ�ޤ��� -Ʊ���ˡ������ͥ�ζ��������ѥơ��֥�Υ���ȥ�ò¹¹¿ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -BIOS �� (userconfig ����Ѥ���) �桼���������� -�ɤ��ѥ�᡼�������ꤹ�٤�����褯�ΤäƤ���Ϥ��ʤΤǡ� -�ǥХ����ɥ饤�Ф��̾�ǥХ�����������ѹ����٤��Ǥ� -.Em ����ޤ��� -�äˡ� -userconfig �ˤ�붯������ᥫ�˥������þ�����Ƥ��ޤ����ᡢ -̵���ˤʤäƤ��������ǥХ����� -.Em Í���ˤ��ƤϤʤ�ޤ��� -�ǥХ����ɥ饤�Ф������ǥХ�����ݡ����ΰ�ʤɤ�̵���ˤ��Ƥ� -���ޤ��ޤ��󤬡�����ϡ� -����ΥǥХ�����ѥ�᡼��������òµ¯¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½ï¤«ï¿½Ã¤Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -�¤�٤��Ǥ��� -.It Fn enable_pnp_card void -���δؿ��ϥ����å��롼���������� -.Em �Τߡ� -�����ɤ� ISA �ݡ���/����Υ��ɥ쥹�ΰ�˥��������������� -.Em �ƤФʤ���Фʤ�ޤ��� -.El -.Pp -.Sh ��Ϣ���� -.Xr dset 8 -.Pq ����: �ѻߤ���ޤ��� -.Sh �Х� -�ӥ��奢�륳��ե�����졼�����ˤϡ�PnP �ǥХ�������Υ��ݡ��Ȥ� -����ޤ��� -userconfig �Υ��ޥ�ɤ� PnP �ǥХ����������������뤳�Ȥ��Ǥ���� -�����餷�����ȤǤ��礦�� -.Sh ��� -PnP ���ݡ��Ȥ� -.An Sujal Patel -�����˼�ݤ�����Τò¸µ¤Ë¡ï¿½ -.An Luigi Rizzo -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.Sh ��� -.Nm -�� -.Fx 2.2.5 -�˽����о줷�ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/scd.4 b/ja_JP.eucJP/man/man4/man4.i386/scd.4 deleted file mode 100644 index e730f7b6e8..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/scd.4 +++ /dev/null @@ -1,65 +0,0 @@ -.\" -.\" Copyright (c) 1995 Jordan K. Hubbard -.\" 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. -.\" 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. -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software withough specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: scd.4,v 1.6 1998/03/12 07:30:37 charnier Exp % -.\" $FreeBSD$ -.\" -.Dd January 1, 1995 -.Dt SCD 4 i386 -.Os FreeBSD 2.0.5 -.Sh ̾�� -.Nm scd -.Nd Sony CDU31/33 CD-ROM �ɥ饤�� -.Sh �� -.Cd "device scd0 at isa? port 0x230 bio" -.Sh ���� -.Nm scd -�ɥ饤�Ф� Sony CDU31 �ڤ� CDU33A CD-ROM �ɥ饤�֤��Ф��� -�ǡ������󥿥ե��������󶡤��ޤ��� -�ɥ饤�֤ϡ� -Sony ��Í�Υ��󥿥ե����������ɤ��ߴ������ɤ���³����ɬ�פ�����ޤ��� -.Sh ��Ϣ�ե����� -.Bl -tag -width /dev/[r]scd0a -compact -.It Pa /dev/[r]scd0a -�ǥ�������� BSD �ѡ��ƥ������˥����������ޤ����̾CDROM �ǥ����� -��ˤ�ñ��Υե����륷���ƥ�Τ�¸�ߤ��ޤ��� -.It Pa /dev/[r]scd0c -raw �ǥХ����˥����������ޤ��� -.Sh ��Ϣ���� -.Pa /sys/i386/isa/scd.c -.Sh ��� -�ܥɥ饤�Фϡ� -.An Holger Veit -�� -.An Brian Moore -����£���������ɤ��Ѥ��ơ� -.An Mikael Hybsch -���ñ¤¤Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ -.Sh ��� -.Nm scd -�ɥ饤�Ф� -.Fx 2.0.5 -�Ǻǽ���о줷�ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/spkr.4 b/ja_JP.eucJP/man/man4/man4.i386/spkr.4 deleted file mode 100644 index 0e702a1c9d..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/spkr.4 +++ /dev/null @@ -1,234 +0,0 @@ -.\" -.\" %Id: spkr.4,v 1.10 1998/03/12 07:30:38 charnier Exp % -.\" $FreeBSD$ -.\" -.Dd November 7, 1993 -.Dt SPKR 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm speaker , -.Nm spkr -.Nd ���󥽡��륹�ԡ����ΥǥХ����ɥ饤�� -.Sh �� -.Cd pseudo-device speaker -.Fd #include <machine/speaker.h> -.Sh ���� -���ԡ����ǥХ����ɥ饤�Фϡ� -.Tn FreeBSD -�����äƤ��� -.Tn IBM-PC -�ߴ� PC ��ǡ� -���ץꥱ������󤬥��󥽡��륹�ԡ���������Ǥ���褦�ˤ��ޤ��� -.Pp -�����ʤ�Ȥ��Ǥ⡢���ΥǥХ����ò¥ª¡ï¿½ï¿½×¥ï¿½Ç¤ï¿½ï¿½ï¿½Î¤ï¿½ -���� 1 �ĤΥץ����������Ǥ��� -���Τ��ᡢ���ΥǥХ����Υ��å��Ȳ����ˤϡ� -.Xr open 2 -�� -.Xr close 2 -����Ѥ��ޤ��� -¾�Υץ��������ǥХ��������ꤷ�Ƥ�����˥����ץ󤷤褦�Ȥ���ȡ� -.Er EBUSY -���顼�ò¼¨¤ï¿½ï¿½ï¿½ -1 ���֤��ޤ��� -�ǥХ����ؤνñ¤¹ï¿½ï¿½ß¤Ï¡ï¿½ ASCII ʸ����ñ��˥���ǥ���ɽ������ -����ʸ���� (`play string') �Ȥ��Ʋ�ᤵ��ޤ��� -.Xr ioctl 2 -�ꥯ�����Ȥˤ��Ǥ�դμ��ȿ���ȯ���⥵�ݡ��Ȥ���Ƥ��ޤ��� -.Pp -ȯ�����뤳�Ȥǥץ����å������ꤹ�뤳�ȤϤ���ޤ��� -�ºݤˤϡ��ɥ饤�Ф� PC �ϡ��ɥ�����������ȯ���Ƥ���֤� -�ۤȤ�ɤλ��֤ò¥¹¥ê¡¼ï¿½×¤ï¿½ï¿½ï¿½ï¿½Ô¤Ã¤Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -¾�Υץ������ϥɥ饤�Ф����äƤ���֤˥ӡ��פ��Ĥ餹���Ȥ��Ǥ��ޤ��� -.Pp -���ץꥱ�������ϡ����ԡ����Υե����ëµï¿½Ò»Ò¤ï¿½ï¿½Ð¤ï¿½ï¿½ï¿½ -.Xr ioctl 2 -�ƤӽФ��ò¤¹¤ë¤³ï¿½È¤Ë¤ï¿½ê¡¢ï¿½ï¿½ï¿½Ô¡ï¿½ï¿½ï¿½ï¿½É¥é¥¤ï¿½Ð¤ï¿½Ä¾ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ç½ï¿½Ç¤ï¿½ï¿½ï¿½ -.Xr ioctl 2 -���󥿥ե������ˤĤ��Ƥ������ -.Pa /usr/include/machine/speaker.h -�ˤ���ޤ��� -�����θƤӽФ��˻Ȥ��� -.Li tone_t -��¤�Τˤϡ� -���ȿ� (�إ��) �Ȼ�³���� (1/100 ��ñ�̤�) ����ꤹ�� -2 �ĤΥե�����ɤ�����ޤ��� -���ȿ� 0 �ϡ�����Ȳ�ᤵ��ޤ��� -.Pp -���ߤ��Τ褦�� -.Xr ioctl 2 -�ƤӽФ��� 2 �Ĥ���ޤ��� -.Dv SPKRTONE -�ϡ��� 3 ������� tone ��¤�ΤؤΥݥ��� 1 �Ĥ������ꡢ -�������դ��ޤ��� -.Dv SPKRTUNE -�ϡ�ñ��� tone ��¤���������Ƭ�ؤΥݥ��� 1 �Ĥ������ꡢ -��������֤˱��դ��ޤ��� -�����������������³���� 0 �Υ��Фǽ��äƤ��뤳�Ȥ�ɬ�פǤ��� -.Pp -����ʸ����θ�ˡ�� -.Tn IBM -Advanced BASIC 2.0 �� PLAY ʸ�ν��������路�Ƥ��ޤ��� -PLAY ʸ�� -.Li MB , -.Li MF , -.Li X -���Ǥϻ�ʬ��Ķ��Ǥ����Ω���ʤ����������ޤ��� -`�����������ɽ�' ��ǽ�ȥ��顼����Ͽ������ɲä��줿��ΤǤ��� -.Pp - 7 ���������� 84 �������Ѳ�ǽ�� 1-84 ���ֹ椬�Ĥ��Ƥ��ޤ��� -.\" ��ʸ�Ǥ� 1-83 �ȤʤäƤ��롣 send-pr �Ѥߡ� -���줾��Υ��������֤� C ���� B �ޤ�³���Ƥ��� 0-6 ���ֹ椬�Ĥ��Ƥ��ޤ��� -������ A440 �˹�碌��ĴΧ����Ƥ��ơ����������� 3 �Ͽ���� C ����Ϥޤ�ޤ��� -�ǥե���ȤǤϱ��յ�ǽ��Ⱦ�äβ����ȯ���������Τ����Ǹ�� 1/16 �äϵ٤ߤޤ��� -.Pp -����ʸ����Ϻ����鱦�ؤȡ����ե��ޥ�ɥ��롼�פ�Ϣ³�Ȥ��Ʋ�ᤵ��ޤ��� -��ʸ����ʸ���϶��̤���ޤ��󡣱��ե��ޥ�ɥ��롼�פϼ����̤�Ǥ�: -.Bl -tag -width CDEFGABxx -.It Li CDEFGAB -A ���� G �ޤǤ�ʸ�����б����벻�ò¸½ºß¤Î¥ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ö¤ï¿½ï¿½Ä¤é¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -����ʸ���ˤϥ��ץ����ǡ� # + - �Τ��������줫�ҤȤĤ� -.Dq Em "�׻�����" -��³���뤳�Ȥ��Ǥ��ޤ������Τ����ǽ�� 2 �Ĥϲ���Ⱦ���⤯���� -�Ǹ�Τ�Τϲ���Ⱦ���㤯���ޤ��� -�ޤ�����ʸ���θ�ˤϲ�Ĺ��ɽ���������������� (���) ��Ĥ��뤳�Ȥ�Ǥ��ޤ��� -��Ĺ�ϼ��� L ���ޥ�ɤξ���Ʊ�ͤ˲�ᤵ��ޤ��� -.It Ns Li O Sy n -�⤷ -.Sy n -�������ʤ顢�ʸ�Υ��������֤����ꤷ�ޤ��� -.Sy n -�� -.Li L -�ޤ��� -.Li N -�Τ����줫����ꤹ�뤳�Ȥˤ�ꡢ -�����������ɽ���Í���ޤ���̵���ˤ��뤳�Ȥ��Ǥ��ޤ� -(�ǥե���ȤǤ�̵���Ǥ�)�� -�����������ɽ���Í���ˤʤäƤ�����ϡ�1 �Ȥβ�����᤹��ȡ� -����֤Ǥβ����κ����Ǿ��ˤʤ�褦��ɬ�פ˱����ƥ��������֤��Ѳ����ޤ��� -�������äơ� ``olbc'' �� ``olb>c'' �Τ褦�ˡ� -``olcb'' �� ``olc<b'' �Τ褦�˱��դ���ޤ��� -�����������ɽ��ϡ�> �� < �� O[0123456] ��³����1 ����ˤĤ��Ƥ�̵���Ǥ��� -(�����������ɽ���ǽ�� -.Tn IBM -BASIC �Ǥϥ��ݡ��Ȥ���Ƥ��ޤ���) -.It Li > -���ߤΥ��������֤� 1 �ľ夲�ޤ��� -.It Li < -���ߤΥ��������֤� 1 �IJ����ޤ��� -.It Ns Li N Sy n -���� -.Sy n -����դ��ޤ��� -.Sy n -�� 1 ���� 84 �������ߤβ�Ĺ�ε���Ȥ��� 0 �Ǥ��� -���������³���뤳�Ȥ�Ǥ��ޤ��� -.It Ns Li L Sy n -����β�Ĺ�����ꤷ�ޤ����ǥե���Ȥ� -.Li L4 -�ǡ���ʬ����Ǥ��� -�����ͤ� 1 ���� 64 �ޤǤ�ǧ����ޤ��� -.Li L1 -��������ˡ� -.Li L2 -����ʬ����ˡ� -.Li L4 -�ϻ�ʬ����ˡ��ʤɤ����ꤵ��ޤ��� -.It Ns Li P Sy n -.Sy n -�� -.Ns Li L Sy n -��Ʊ�ͤ˲�ᤷ������Ǥ������������Ĥ��뤳�Ȥ�Ǥ��ޤ��� -.Li ~ -�Ƚñ¤¯¤ï¿½ï¿½È¤ï¿½Ç¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Ns Li T Sy n -1 ʬ������λ�ʬ����ο������ꤷ�ޤ����ǥե���Ȥ� 120 �Ǥ��� -�褯����ƥ�ݤβ���̾: - -.Bd -literal -offset indent - �ƥ�� ʬ��������� -�ȤƤ��٤� Larghissimo - Largo 40-60 - Larghetto 60-66 - Grave - Lento - Adagio 66-76 -�٤� Adagietto - Andante 76-108 -�椯�餤 Andantino - Moderato 108-120 -®�� Allegretto - Allegro 120-168 - Vivace - Veloce - Presto 168-208 -�ȤƤ�®�� Prestissimo -.Ed -.It Li M[LNS] -Ĵ�������ꤷ�ޤ��� -.Li MN -.Ns No ( Li N -������ (normal) �ò¼¨¤ï¿½ï¿½Þ¤ï¿½) ���ǥե���Ȥǡ�����κǸ� 1/8 ��٤ߤޤ��� -�쥬���� (�٤ߤʤ�) �ˤ���ˤ� -.Li ML -�ò¡¢¥ï¿½ï¿½ï¿½ï¿½Ã¥ï¿½ï¿½ï¿½ï¿½ï¿½ (1/4 �٤�) �ˤ���ˤ� -.Li MS -������Ǥ��ޤ��� -.El -.Pp -���� (�Ĥޤ� -.Li CDEFGAB -�ޤ��� -.Li N -���ޥ��ʸ�����롼��) �ˤ��������� (.) ��³���뤳�Ȥ��Ǥ��ޤ��� -.\" dot �Ȥ� . �Ǥ��뤬���ܸ�Ǥ��������ʤ��Ȥ狼��ʤ� -���줾������������ 1 �ĤˤĤ�������β�Ĺ�� 1.5 �ܤˤ��ޤ��� -�������äơ��������椬 1 �ĤĤ�������ϤĤ��Ƥ��ʤ���Τ� 3/2 �β�Ĺ�ˡ� -2 �ĤĤ�������� 9/4 �β�Ĺ�ˡ� -3 �ĤĤ�������� 27/8 �β�Ĺ�ˤʤ�ޤ��� -.Pp -�������������ˤϥ��顼���� (_) ��³���뤳�Ȥ��Ǥ��ޤ��� -����ˤ�äƲ���θ�����ʤ��뾮���ʵ٤ߤ������ơ� -����ò¼¡¤Î²ï¿½ï¿½ï¿½Ë¥ï¿½ï¿½é¡¼ï¿½Ç¤Ä¤Ê¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½(���顼��ǽ�� -.Tn IBM -BASIC �Ǥϥ��ݡ��Ȥ���Ƥ��ޤ���) -.Pp -����ʸ������ζ����ñ�����Ф����Τǡ� -�����ʬ����Τ˻Ȥ����Ȥ��Ǥ��ޤ��� -.Sh �Х� -�����ơ��֥�δݤ�䡢ȯ���ϡ��ɥ������䥿���ޥϡ��ɥ������� -���ܤ� (�ɤ�������٤��θ���Ƥ��ʤ�) �Τ��ᡢ -���������Τ��䥿���ߥ󥰤Ͽ���Ū�˸�̩�ǤϤ���ޤ��� -����Ĵ��Ϥ���ޤ��� -.Pp -2 �İʾ�����������ư���ɸ��Ū�ʲ��ڵ����ȿ�Ǥ��Ƥ��ޤ��� -ɸ��Ū�ˤϡ����줾����������������������Ⱦʬ������Ĺ��Ĺ������ΤǤ��ꡢ -�����ˤ�äƽ������줿�����Ⱦʬ�ǤϤ���ޤ��� -�Ĥޤꡢ�������椬 1 �ĤĤ�������ϤĤ��Ƥ��ʤ���Τ� 3/2 �β�Ĺ�ˡ� -2 �ĤĤ�������� 7/4 �β�Ĺ�ˡ� -3 �ĤĤ�������� 15/8 �β�Ĺ�ˤʤ�ޤ��� -����Ǥ⡢3/2 �ܤˤ������ -.Tn IBM -BASIC �ޥ˥奢��˵�����Ƥ��뤿�ᡢ -�ߴ����Τ���ˤ��Τޤޤˤ��Ƥ��ޤ��� -.Pp -������ (�����ƥ��ʪ�� I/O �֥��å�����Ĺ��) ����ʸ����Ǥϡ� -�֥��å�������ޤ����뤿��ˡ� -����ν�������ͤ������ְ�äƲ�ᤵ��뤳�Ȥ�����ޤ��� -.Sh ��Ϣ�ե����� -.Bl -tag -width /dev/speakerxx -.It Pa /dev/speaker -���ԡ����ǥХ����ե����� -.El -.Sh ��Ϣ���� -.Xr spkrtest 8 -.Sh ��� -.An Eric S. Raymond Aq esr@snark.thyrsus.com -1990 ǯ 6 �� -.Sh �ܿ��� -.An Andrew A. Chernov Aq ache@astral.msk.su -.Sh ��� -.Nm -�ǥХ����� -.Fx 1.0 -�˽����о줷�ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/sr.4 b/ja_JP.eucJP/man/man4/man4.i386/sr.4 deleted file mode 100644 index 04ca6393ff..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/sr.4 +++ /dev/null @@ -1,119 +0,0 @@ -.\" -.\" Copyright (c) 1996 John Hay. 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. -.\" 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. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by John Hay. -.\" 4. Neither the name of the author nor the names of any co-contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY John Hay ``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 John Hay 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. -.\" -.\" %Id: sr.4,v 1.10 1998/10/22 14:12:55 bde Exp % -.\" -.\" $FreeBSD$ -.Dd July 4, 1996 -.Dt SR 4 i386 -.Os -.Sh ̾�� -.Nm sr -.Nd Ʊ�� RISCom/N2 / WANic 400/405 �ǥХ����ɥ饤�� -.Sh �� -.Cd "device sr0 at isa? port 0x300 net irq 10 iomem 0xd0000" -.Cd "device sr1 at isa? port 0x310 net irq 11 flags 0x1 iomem 0xd0000" -.Pp -.Cd "pseudo-device sppp" -.Sh ���� -.Nm sr -�ɥ饤�Фϡ�HD64570 ���åפ���Ѥ����� -RISCom/N2 ISA �����ɤ� WANic 400/405 PCI �����ɤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -��󥯥�٥���ؤˡ�ɸ��� -.Tn FreeBSD -sppp �����ɤ���Ѥ��ޤ��� -�ǥե���ȤΥץ��ȥ���� PPP �Ǥ��� -Cisco HDLC �ץ��ȥ���� -.Xr ifconfig 8 -�� -.Em link2 -���ɲä��뤳�Ȥˤ�äƻ��ѤǤ��ޤ��� -.Pp -.Em flags -�ե�����ɤϾ�ά��ǽ�Ǥ�����ά������硢�ɥ饤�Фϼ��Τ褦�˲��ꤷ�ޤ�: -.Pp -.Bl -hang -offset indent -.It "�����ɤˤ� 2 �ݡ��Ȥ���ޤ���" -.It "���ꥢ��ݡ��ȤΥ����å��ϳ����Τ�Τ���Ѥ��Ƥ��ꡢ" -�����ȼ����Υ����å���Ʊ���Ǥ��� -.El -.Pp -.Em flags -�ϥӥåȥե�����ɤǤ��ꡢ�ǥե���Ȱʳ���ư��ò¤µ¤ï¿½ï¿½ë¤¿ï¿½ï¿½Ë»ï¿½ï¿½Ñ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -.Bl -hang -offset indent -.It Em 0x01 -�����ɤˤ� 1 �ݡ��Ȥ�������ޤ��� -.It Em 0x10 -�ݡ��� 0 �ǡ������ȼ������̡��γ��������å�����Ѥ��ޤ��� -.It Em 0x40 -�ݡ��� 1 �ǡ������ȼ������̡��γ��������å�����Ѥ��ޤ��� -.El -.Pp -.Sh �ֹ� -�����ͥ�����ե�����Ǥϡ���������� 1 �ԤΤߤ�ɬ�פǤ��� -�ǽ�Υ����ɤΥݡ��Ȥ� sr0 ���鿶���ޤ��� -���Υ����ɤ��ֹ�ϡ��ǽ�Υ����ɤν��ä��꤫��³�����ޤ��� -�Ĥޤꡢ�⤷�ǽ�Υ����ɤ� 2 �ݡ��ȤΥ����ɤʤ顢���Υ����ɤ� sr0 �� sr1 -��Ȥ��ޤ��������Ƽ��Υ����ɤ� sr2 ����Ϥޤ�ޤ��� -.Pp -�����ɤ� IRQ 3, 4, 5, 7, 10, 11, 12, 15 �Τߤò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -iomem �ΰ�ϡ�16Kb �֥��å��Ǥ��ꡢ16Kb ��������Ϥޤ�ɬ�פ�����ޤ��� -.Pp -.Sh ���� -.Bl -diag -.It "sr%d: Warning illegal interrupt %d." -�����ɤ����ꤵ�줿�����ߤ���ѤǤ��ޤ���¾�γ����ߤ�����Ǥ��������� -.El -.Sh ��Ϣ�ե����� -.Bl -tag -width /sys/i386/isa/ic/hd64570.h -compact -.It Pa /sys/i386/isa/ic/hd64570.h -.It Pa /sys/i386/isa/if_srregs.h -.It Pa /sys/i386/isa/if_sr.c -.It Pa /sys/pci/if_sr_p.c -.El -.Sh �Х� -�������� X.21 ���󥿥ե��������������Ƥ��ޤ��� -¾�Τ�ΤǤϡ������å����ò¥³¡ï¿½ï¿½É¤ï¿½ï¿½ï¿½Ä´ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½É¬ï¿½×¤ï¿½ï¿½ï¿½ï¿½ï¿½Ç¤ï¿½ï¿½ç¤¦ï¿½ï¿½ -.Pp -���Υ����ɤˤϡ������餯��Ŭ����;�Ϥ�����ޤ��� -.Sh ��Ϣ���� -.Xr ar 4 , -.Xr cx 4 , -.Xr netintro 4 , -.Xr ifconfig 8 , -.Xr lsdev 8 -.Sh ��� -.Nm sr -�ǥХ����ɥ饤�Ф� -.An John Hay Aq jhay@FreeBSD.org -���������ޤ����� diff --git a/ja_JP.eucJP/man/man4/man4.i386/vx.4 b/ja_JP.eucJP/man/man4/man4.i386/vx.4 deleted file mode 100644 index 149c73366d..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/vx.4 +++ /dev/null @@ -1,102 +0,0 @@ -.\" -.\" Copyright (c) 1996, Fred Gray -.\" 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. -.\" 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. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by David Greenman. -.\" 4. The name of the author may not be used to endorse or promote products -.\" derived from this software without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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. -.\" -.\" %Id: vx.4,v 1.7 1998/03/12 07:30:39 charnier Exp % -.\" $FreeBSD$ -.\" -.Dd January 15, 1996 -.Dt VX 4 i386 -.Os -.Sh ̾�� -.Nm vx -.Nd -PCI �������ͥåȥǥХ����ɥ饤�� -.Sh �� -.Cd "device vx0" -.Sh ���� -.Nm vx -�ɥ饤�Фϡ� -3Com �� 3c590 �� 3c595�����ʤ�� EtherLink III �� Fast EtherLink III �� -PCI �������ͥåȥ����ɤ�10 Mbps �⡼�ɤǥ��ݡ��Ȥ��ޤ��� -���� -.Xr ifconfig 8 -���ޥ�ɤؤ� link �ե饰�ˤ�äơ����Τ������ǽ�Ǥ��� -.Pp -.Bl -tag -width LINK0X -compact -.It Em link0 -AUI �ݡ��Ȥ���Ѥ��ޤ��� -.It Em link1 -BNC �ݡ��Ȥ���Ѥ��ޤ��� -.It Em link2 -UTP �ݡ��Ȥ���Ѥ��ޤ��� -.El -.Sh ���� -.Bl -diag -.It "vx%d: not configured; kernel is built for only %d devices." -�����ƥ�ˤ��륢���ץ������Ф��ơ������ͥ�����ե�������� -�ǥХ���������ʬ�ǤϤ���ޤ��� -����ե�����˥ǥХ������ɲä��� -�����ͥ��ƹ��ۤ��ƥ�֡��Ȥ��Ʋ������� -.Pp -¾�Τ��٤Ƥο��Ǥϥϡ��ɥ����������꤫�ɥ饤�ФΥХ��ò¼¨¤ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Sh �ٹ� -����Τ����Ĥ��� 3c590 �����ɤˤ����꤬���ꡢ -�������դ���ﳲ������ޤ��� -���η�̤Ȥ��ơ��ѥ��å�»��������������ޤ��� -��Ԥϡ�3 Com �����󶡤���������ˡ� -���Τ褦�ʥ�ӥ����θ�����������褦�Ȥ��ޤ����� -�������������ν��Ϥ�����ʬ�ϵ��路���ٹ�ˤ����ޤ��� -.Pp -�����ɤΥХ��ޥ�����󥰵�ǽ����Ѥ��� -�ݡ���󥰥⡼�ɤ� I/O �Τߤ���Ѥ��뤳�Ȥ��顢 -���Υɥ饤�Ф���ǽ�Ϥ����餫���¤���ޤ��� -.Sh �Х� -.Nm vx -�ɥ饤�ФϤ����Ĥ��Υ����ƥ��ǥ��֡��Ȥθ塢�����ץ��������� -�ꥻ�åȤ��ʤ����Ȥ��Τ��Ƥ��ޤ��� -.Pp -.Nm vx -�ɥ饤�Фϡ����ݡ��Ȥ��Ƥ���Ȥ���륫���ɤΤ��٤ƤΥ�ǥ�� -Ű��Ū�˥ƥ��Ȥ�ԤʤäƤ���櫓�ǤϤ���ޤ��� -.Sh ��� -.Nm vx -�ǥХ����ɥ饤�Ф� -.Fx 2.1 -�Ǻǽ���о줷�ޤ����� -����� -.Nm ep -�ɥ饤�Ф�ͳ�褷�Ƥ��ơ�¿�������¤�Ѿ����Ƥ��ޤ��� -.Sh ��� -.Nm vx -�ǥХ����ɥ饤�ФȤ��Υޥ˥奢��ڡ����ϡ� -.An Herb Peyerl -�κ�ȤȤ���¾��¿���οͤα������ -.An Fred Gray Aq fgray@rice.edu -�ˤ�äƽñ¤«¤ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ diff --git a/ja_JP.eucJP/man/man4/man4.i386/wd.4 b/ja_JP.eucJP/man/man4/man4.i386/wd.4 deleted file mode 100644 index d1a7de23c8..0000000000 --- a/ja_JP.eucJP/man/man4/man4.i386/wd.4 +++ /dev/null @@ -1,106 +0,0 @@ -.\" -.\" Copyright (c) 1994 Wilko Bulte -.\" 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. -.\" 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. -.\" 3. The name of the author may not be used to endorse or promote products -.\" derived from this software withough specific prior written permission -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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. -.\" -.\" %Id: wd.4,v 1.10 1998/10/22 14:12:55 bde Exp % -.\" $FreeBSD$ -.\" -.Dd August 31, 1994 -.Dt WD 4 i386 -.Os FreeBSD -.Sh ̾�� -.Nm wd -.Nd -����Ū�� WD100x/IDE �ǥ���������ȥ������ѥɥ饤�� -.Sh �� -.Cd "controller wdc0 at isa? port" \&"IO_WD1\&" bio irq 14 -.Cd "disk wd0 at wdc0 drive 0 -.Cd "disk wd1 at wdc0 drive 1 -.Pp -CMD640b IDE ����ȥ�������: -.Cd "options" \&"CMD640\&" -.Sh ���� -���Υɥ饤�Фǡ�Western Digital WD100x ���꡼���ò¥¨¥ß¥ï¿½ì¡¼ï¿½È¤ï¿½ï¿½ï¿½ -����ȥ��������³���줿�ǥ������˥��������Ǥ���褦�ˤʤ�ޤ��� -����ˤϡ�WD1003 ST412 ����ȥ����顢WD1007 ESDI ����ȥ����顢 -�����ƤۤȤ�ɤΥޥ����ܡ��ɤˤ������Ū�� IDE ����ȥ������ޤߤޤ��� -.Pp -WD100x ���꡼���Ȥθߴ����ˤĤ��Ƥϡ��̾����ȥ�����λ���������������ޤ��� -.Pp -.Ar flags -�ѥ�᡼����Ȥäơ��ɥ饤�Ф˥ҥ�Ȥ����������뤳�Ȥ��Ǥ��ޤ��� -.Pp -16 �ӥå������Υե饰���ɥ饤����ˤ��ꡢ -���줾��� 4 (����: �ºݤˤ� 6) �ĤΥӥåȥե�����ɤ�����ޤ�: -.\" By mzaki@e-mail.ne.jp (Mar 1 1999) -.Bl -tag -width 0x0000 -offset 1c -.It 0x8000 -�ɥ饤�֤� 32 �ӥå�ž����ǽ���Ȥ���лȤ��ޤ��� -.It 0x4000 -�ɥ饤�֤����꡼�ץ⡼�ɤ���æ���Ƥ���Ȥ����Ǥ���褦�ʤ�С� -���𤷤Ƥ���Ȥߤʤ��ƺƽ�������ޤ��� -.It 0x2000 -�Ƕ�� PCI ���åץ��åȤˤ���Х��ޥ��� DMA ��ǽ�����뤫Ĵ�٤����Ѥ��ޤ��� -.It 0x1000 -�ǥե���Ȥ� CHS ���ɥ�å��󥰤ǤϤʤ���LBA ���ɥ�å��󥰤�Ȥ��ޤ��� -.It 0x0f00 -�إåɤο��� ((flags & 0xf00)>>8) �ȸ��ʤ��ơ� -����˹礦�褦�˥���������׻���ľ���ޤ��� -.It 0x00ff -�ɥ饤�֤Υޥ��������ž���⡼�ɤ��Ȥ���лȤ��ޤ��� -����� (flags & 0x00ff) ��������ž�����ߤޤ��� -.El -.Pp -���Υե饰�� drive �Ԥ� 16 �ӥå������ǻ��ꤹ�뤫�� -���뤤�� controller �Ԥ� 32 �ӥå������ǻ��ꤷ�ޤ��� -���ξ�硢��� 16 �ӥåȤ��ֹ���ç¤ï¿½Ê¥É¥é¥¤ï¿½Ö¤ï¿½Å¬ï¿½Ñ¤ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -.Dq Dv CMD640 -���ץ����ˤ�äơ�CMD640b IDE ����ȥ�����η�٤��н褹��褦�ˤʤ�ޤ��� -���Υ��ץ���󤬻��ꤵ��Ƥ��ơ� -���� PCI ���֥����ƥब���Υ��åפò¸¡½Ð¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ë¤Ï¡ï¿½ -�ץ饤�ޥ�ȥ��������Υ���ȥ������Ʊ���ˤϻȤ��ޤ��� -.Sh ��Ϣ�ե����� -.Bl -tag -width Pa -compact -.It Pa /dev/wd* -�ǥ������Υ֥��å��ǥХ����Ρ��� -.It Pa /dev/rwd* -�ǥ������Υ���饯���ǥХ����Ρ��� -.It Pa /sys/i386/conf/GENERIC -.\" ��ʸ -.\" sample generic kernel config file for (a.o.) wd based systems -.\" �� a.o. �äƤʤ�Ǥ��礦�� -wd �ˤ�륷���ƥ�Τ���Υ����ͥ�å������ͥ������ե�����Υ���ץ� -.It Pa /sys/i386/isa/wd.c -�ɥ饤�ФΥ����� -.El -.Sh ��Ϣ���� -.Xr bad144 8 -.Sh ���� -���Υ���ȥ�����ȥǥ��������ȹ�碌�ϡ� -��ưŪ�˥Хåɥ֥��å�������ò¤¹¤ë¤¿ï¿½ï¿½Îµï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -�Хåɥ֥��å���Ĵ�٤�ˤ� -.Xr bad144 8 -��¹Ԥ���ɬ�פ�����ޤ��� diff --git a/ja_JP.eucJP/man/man8/man8.i386/apm.8 b/ja_JP.eucJP/man/man8/man8.i386/apm.8 deleted file mode 100644 index be42ba0858..0000000000 --- a/ja_JP.eucJP/man/man8/man8.i386/apm.8 +++ /dev/null @@ -1,157 +0,0 @@ -.\" LP (Laptop Package) -.\" -.\" Copyright (c) 1994 by Tatsumi Hosokawa <hosokawa@jp.FreeBSD.org> -.\" -.\" This software may be used, modified, copied, and distributed, in -.\" both source and binary form provided that the above copyright and -.\" these terms are retained. Under no circumstances is the author -.\" responsible for the proper functioning of this software, nor does -.\" the author assume any responsibility for damages incurred with its -.\" -.\" %FreeBSD: src/usr.sbin/apm/apm.8,v 1.16.2.4 2001/08/16 15:55:38 ru Exp % -.\" -.\" use. -.\" -.\" $FreeBSD: doc/ja_JP.eucJP/man/man8/apm.8,v 1.11 2001/07/29 05:15:27 horikawa Exp $ -.Dd November 1, 1994 -.Dt APM 8 -.Os -.Sh ̾�� -.Nm apm , zzz -.Nd APM BIOS �������Ԥ������ξ����ɽ������ -.Sh �� -.Nm -.Op Fl ablstzZ -.Op Fl d Ar enable -.Op Fl e Ar enable -.Op Fl h Ar enable -.Op Fl r Ar delta -.Pp -.Nm zzz -.Sh ���� -.Nm -�ϡ� Intel / Microsoft APM (Advanced Power Management) BIOS �����椷�� -��åץȥå� PC ��� APM �θ��ߤξ��֤�ɽ�����ޤ��� -.Nm zzz -�ϡ� APM ����ˤ�äơ������ƥ�ò¥µ¥ï¿½ï¿½Ú¥ï¿½É¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -�ʲ��Υ��ץ���� -.Nm -�����Ѳ�ǽ�Ǥ� -( -.Nm zzz -�ˤϡ����ץ����Ϥ���ޤ���)�� -���ץ����Ϳ�����ʤ��ä����ϡ� -.Nm -�ϡ����ߤ� APM �ξ��֤������Ĺ�⡼�ɤ�ɽ�����ޤ��� -ʣ����ɽ�����ץ���󤬻��ꤵ�줿��硢 -�����˼������֤��ͤ� 1 �Ԥ� 1 �Ĥ���ɽ�����ޤ��� -.Bl -tag -width indent -.It Fl a -���ߤ� AC �Ÿ��ξ��֤������ͤ�ɽ�����ޤ��� -0, 1�����줾�� -.Dq ����Ƥ��� (off-line) -���֤� -.Dq �Ĥʤ��äƤ��� (on-line) -���֤ò¤¢¤ï¿½ï¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl b -�����ͤǡ����ߤΥХåƥ���֤�ɽ�����ޤ��� -0, 1, 2, 3�Ȥ����ͤϤ��줾�졢 -.Dq �ɹ� (high) -���֡� -.Dq ��Хåƥ� (low) -���֡� -.Dq ���� (critical) -���֡� -.Dq ���� (charging) -���֤ò¤¢¤ï¿½ï¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl d Ar enable -�̾�Υ����ڥ�ɤȥǥ����ץ쥤�Υ����ڥ�ɤ��̤˰���ʤ�/�̤˰����� -�֡����� -.Ar enable -�����椷�ޤ��� -������� Libretto 30CT �� 50CT ��ޤ� -¿��Υ�åץȥåפ�ư��ʤ��褦�Ǥ��� -.It Fl e Ar enable -�֡����Ͱ��� -.Ar enable -�˰�¸���ơ�����ԥ塼���� APM ��ǽ��Í��/̵�����ڤ��ؤ��ޤ��� -.It Fl h Ar enable -�֡����Ͱ��� -.Ar enable -�˰�¸���ơ� -�����ͥ륳��ƥ����ȥ����å��롼������� HLT ̿���Í��/̵�����ڤ��ؤ��ޤ��� -�����Υ��ץ����ϡ��ۤȤ�����Ƥ� APM �μ����ˤ����Ƥ����פǤ����� -.Dq Pa Idle CPU -�ƤӽФ��� CPU �����å��θ�®�� HLT ̿���Ʊ���˼¹Ԥ�����ϡ� -���Υԡ�����ǽ�θ������饷���ƥ��ޤ�뤿��� -.Fl t -���ץ����ɬ�פǤ��� -�ܺ٤ˤĤ��Ƥϡ� -.Xr apm 4 -�ò»²¾È¤ï¿½ï¿½Æ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ -.It Fl l -���ߤΥХåƥ�λĤ����ɽ�����ޤ��� -�⤷�����ʤ��Υ�åץȥåפ����ε�ǽ���󶡤��Ƥ��ʤ����ˤϡ� -255 ��ɽ������ޤ��� -.It Fl r Ar delta -��åץȥåפ����ݡ��Ȥ��Ƥ����硢 -�쥸�塼�०���������åץ����ޤ�Í���ˤ��ޤ��� -����ˤ���åץȥåפ������ڥ�ɤ����櫓�ǤϤ���ޤ��󤬡� -��åץȥåפ������ڥ�ɤ��� -�����ڥ�ɤ���Υ쥸�塼�ब���ݡ��Ȥ���Ƥ����硢 -.Ar delta -�ø�˥�åץȥåפ��쥸�塼�ष�ޤ� -(�����ڥ�ɤ�����������Ȥ���ΤǤϤʤ��� -�ܥ��ޥ�ɤ�¹Ԥ������֤����Ȥ��ޤ�)�� -.It Fl s -APM ���ݡ��Ⱦ��֤������ͤ�ɽ�����ޤ���0, 1 �Ȥ����ͤϤ��줾�졢 -.Dq �����Բ� (disabled) -���� -.Dq ���Ѳ�ǽ (enabled) -���� -�ò¤¢¤ï¿½ï¤·ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl t -�Ĥ�ΥХåƥ���֤�ͽ¬���ơ���ñ�̤�ɽ�����ޤ��� -ʬ����ʤ����ˤ� -1 ��ɽ�����ޤ��� -.It Fl Z -������Х��⡼�ɤ˰ܹԤ��ޤ��� -�ܥ⡼�ɤǤϥե�ѥ�⡼��̤���������ڥ�ɥ⡼�ɰʾ�����Ͼ���Ȥʤ�ޤ��� -�����ޤ⤷���ϥ�󥰥��󥸥��������٥�Ȥˤ�ꡢ -���ξ��֤���쥸�塼�ह�뵡ǽ�ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½ï¿½ï¿½Ã¥×¥È¥Ã¥×¤ï¿½ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -apm �ν��Ϥˤ�ꡢ��åץȥåפ����ò¥µ¥Ý¡ï¿½ï¿½È¤ï¿½ï¿½ï¿½È¼ï¿½Ä¥ï¿½ï¿½ï¿½Æ¤ï¿½ï¿½ë¤«ï¿½ï¿½Ê¬ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.It Fl z -�����ƥ�ò¥µ¥ï¿½ï¿½Ú¥ï¿½É¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ï¡ï¿½ -.Nm zzz -�������Ǥ��� -.El -.Sh �Х� -�����Ĥ��� APM �����Ǥϡ� -.Nm -��ɬ�פȤ���ѥ�᡼�����󶡤���Ƥ��ޤ��� -���Τ褦�ʥ����ƥ�˱����Ƥϡ� -.Nm -�ϡ��������Τ�ʤ���ɽ�����ޤ��� -.Pp -�����Ĥ��� APM �����Ǥϡ��Ÿ������å��ò²¡¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½È¤ä¥«ï¿½Ð¡ï¿½ï¿½ï¿½ -�Ĥ��줿���ȤʤɤΥ��٥�Ȥò°·¤ï¿½ï¿½ï¿½ï¿½È¤ï¿½ï¿½Ç¤ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -���Τ褦�ʼ����˱����Ƥϡ� -�����ƥ�� -.Nm -�� -.Nm zzz -.Ar ������ -�Ĥ��äƥ����ڥ�ɤ��� -.Ar �٤� -�Ǥ��� -.Sh �� -.Xr apmconf 8 -�� -.Xr apm 8 -�˥ޡ������졢 -.Xr apm 8 -������ǽ���֤������ޤ����� -.Sh ��Ϣ���� -.Xr apm 4 -.Sh ��� -.An Tatsumi Hosokawa Aq hosokawa@jp.FreeBSD.org diff --git a/ja_JP.eucJP/man/man8/man8.i386/apmd.8 b/ja_JP.eucJP/man/man8/man8.i386/apmd.8 deleted file mode 100644 index 1b53302484..0000000000 --- a/ja_JP.eucJP/man/man8/man8.i386/apmd.8 +++ /dev/null @@ -1,293 +0,0 @@ -.\" Copyright (c) 1999 Mitsuru IWASAKI <iwasaki@FreeBSD.org> -.\" Copyright (c) 1999 KOIE Hidetaka <koie@suri.co.jp> -.\" Copyright (c) 1999 Yoshihiko SARUMARU Aq <mistral@imasy.or.jp> -.\" Copyright (c) 1999 Norihiro Kumagai <kuma@nk.rim.or.jp> -.\" 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. -.\" 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 REGENTS 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 REGENTS 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. -.\" -.\" @(#)apmd.8 1.1 (FreeBSD) 6/28/99 -.\" %FreeBSD: src/usr.sbin/apmd/apmd.8,v 1.7.2.5 2001/08/16 15:55:38 ru Exp % -.\" -.\" $FreeBSD: doc/ja_JP.eucJP/man/man8/apmd.8,v 1.12 2001/08/18 23:50:44 horikawa Exp $ -.\" -.Dd June 28, 1999 -.Dt APMD 8 -.Os -.Sh ̾�� -.Nm apmd -.Nd Advanced Power Management �ƻ�ǡ���� -.Sh �� -.Nm -.Op Fl d -.Op Fl f file -.Op Fl v -.Sh ���� -.Nm -�ϡ����ꤷ�� Advanced Power Management -.Pq Tn APM -���٥�Ȥ�ƻ뤷�� -�����줫�Υ��٥�Ȥ�ȯ��������硢 -�б����륳�ޥ�ɥ������󥹤�¹Ԥ��ޤ��� -����ե�����ǻ��ꤵ�줿���٥�ȤΤߤ� -.Nm -�����Τ��졢����ʳ��Υ��٥�Ȥ�̵�뤵��ޤ��� -APM BIOS �ˤ�ä�ȯ�Ԥ��줿 -���٥�Ȥ��Ф��ơ� -.Nm -������ե�����ǻ��ꤵ�줿���ޥ�ɥ������󥹤�¹Ԥ��ޤ��� -.Nm -�ò¥µ¥ï¿½ï¿½Ú¥ï¿½ï¿½/������Х���ƻ뤹��褦�ˤ��Ƶ�ư����ȡ� -�����ͥ�Ϥ������׵ᥤ�٥�Ȥ��Ф��� -������Ԥ��ޤ��󡣤��Τ��᤽���Υ��٥��ȯ������ -�����ò¤µ¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ï¡ï¿½Å¬ï¿½Ú¤Ê¥ï¿½ï¿½Þ¥ï¿½É¤Þ¤ï¿½ï¿½ï¿½ï¿½È¤ß¹ï¿½ï¿½ß´Ø¿ï¿½ï¿½ï¿½ -����Ū������ե�����˻��ꤹ��ɬ�פ�����ޤ��� -.Pp -.Nm -�ϰʲ��μ¹Ի����ץ��������ò¤·¤Þ¤ï¿½ï¿½ï¿½ -.Bl -tag -width -f_file -.It Fl d -�ǥХå��⡼�ɤǵ�ư���ޤ��� -�ǡ����⡼�ɤǤϤʤ��ե������饦��ɤ�ư��ޤ��� -.It Fl f Ar file -�ǥե���Ȥ�����ե����� -.Pa /etc/apmd.conf -�����˻��Ѥ��롢�̤�����ե����� -.Ar file -����ꤷ�ޤ��� -.It Fl v -��Ĺ�⡼�ɤ�ư��ޤ��� -.El -.Pp -.Nm -�ϵ�ư��������ե����� -(�ǥե���Ȥ� -.Pa /etc/apmd.conf ) -���ɤ߹��ߡ� -�ƻ뤹�٤����٥�Ȥ� APM �ǥХ����ɥ饤�Ф����Τ��ޤ��� -��λ���ˤ� APM �ǥХ����ɥ饤�Фϥ��٥�Ȥδƻ��ưŪ�˲�����ޤ��� -.Pp -.Nm -�ץ������������ʥ� SIGHUP ���������ȡ�����ե�������ɤ߹���ľ���ơ� -������ѹ����Ƥ� APM �ǥХ����ɥ饤�Ф����Τ��ޤ��� -.Pp -.Nm -�ϡ��ǥХ����ե����� -.Pa /dev/apmctl -���ͳ���ơ����٥�Ȥμ������� APM �����ƥ������Ѥ� -.Xr ioctl 2 -�׵��ȯ�Ԥ��ޤ������ΥǥХ����ե��������¾���椵��ƥ����ץ󤵤�뤿�ᡢ -.Nm -�ץ�������Ʊ���� 1 �ĤΤߵ�ư��ǽ�Ǥ��� -.Pp -.Nm -�� APM ���٥�Ȥ�������ȡ�����ե�����ǻ��ꤵ�줿 -���٥�Ȥ��б����륳�ޥ�ɥꥹ�Ȥ�¹Ԥ��뤿��� -�ҥץ����������������Ƥ� APM ���٥�Ȥ��Ԥ����֤ˤʤ�ޤ��� -�������줿�ҥץ������ϡ� -���ꤵ�줿���ޥ�ɤ� 1 �Ĥ�����󤵤줿���֤˼¹Ԥ��ޤ��� -.Pp -.Nm -�� SUSPEND/STANDBY �׵���Ф��륳�ޥ�ɥꥹ�Ȥ�������Ƥ���֡� -�����ͥ���� APM �ǥХ����ɥ饤�Фϡ�APM BIOS ������ -���� 1 ��ʾ����Τ�ȯ�Ԥ�³���ޤ��� -����ˤ�ä� BIOS �ϡ����ޥ�ɽ�����Ǥ����׵᤬ -�ޤ����뤷�Ƥ��ʤ����Ȥ�ǧ�����ޤ��� -.Pp -.Nm -�ǡ����ϥե����� -.Pa /var/run/apmd.pid -����������ץ����� ID ��Ͽ���ޤ�������� -.Nm -�� kill �䡢����ե�������ɤ߹��ޤ��뤿��˻Ȥ��ޤ��� -.Sh ����ե����� -.Nm -������ե�����ι�¤�����˥���ץ�Ǥ����㤨�м��Τ褦�ˤʤ�ޤ��� -.Pp -.Bd -literal -apm_event SUSPENDREQ { - exec "sync && sync && sync"; - exec "sleep 1"; - exec "zzz"; -} -.Ed -.Pp -������Ǥϡ�APM ���٥�� -.Ql SUSPENDREQ -(�ǥ����ץ쥤���Ĥ������ʤɤ�ȯ�����ޤ�) �� -.Nm -���������ȡ� -.Ql sync -���ޥ�ɤ� 3 ��¹Ԥ��������Ԥä����Ȥ� -.Nm zzz ( Ns Nm apm Fl z ) -��¹Ԥ��ƥ����ƥ�ò¥µ¥ï¿½ï¿½Ú¥ï¿½É¤ï¿½ï¿½ï¿½ï¿½Þ¤ï¿½ï¿½ï¿½ -.Pp -.Bl -bullet -.It -apm_event ������� -.Bd -ragged -offset indent -.Ql apm_event -�ϥ�����ɤǤ��ꡢ���٥�Ȥ��Ȥ�����γ��Ϥ�ؼ����ޤ��� -.Ed -.It -APM ���٥�� -.Bd -ragged -offset indent -ʣ���Υ��٥�Ȥ��Ф���Ʊ��������¹Ԥ��������ϡ������Υ��٥��̾�� -����ޤǶ��ڤäƻ��ꤷ�ޤ���Í���ʥ��٥��̾�ϼ����̤�Ǥ��� -.Bl -item -.It -- -.Nm -����ư����Ƥ���ȥ����ͥ�Ǥν�����Ԥ�ʤ��ʤ륤�٥��: -.Pp -.Bl -tag -width USERSUSPENDREQ -compact -offset indent -.It STANDBYREQ -.It USERSTANDBYREQ -.It SUSPENDREQ -���ޥ�ɥꥹ�Ȥ� sync ��ޤ�뤳�Ȥò¤ª¤ï¿½ï¿½ï¿½ï¿½á¤·ï¿½Þ¤ï¿½ -.It USERSUSPENDREQ -���ޥ�ɥꥹ�Ȥ� sync ��ޤ�뤳�Ȥò¤ª¤ï¿½ï¿½ï¿½ï¿½á¤·ï¿½Þ¤ï¿½ -.It BATTERYLOW -���ޥ�ɥꥹ�Ȥ� zzz �Τߤò¤ª¤ï¿½ï¿½ï¿½ï¿½á¤·ï¿½Þ¤ï¿½ -.El -.It -- �����ͥ�ν�����λ��� -.Nm -�����Τ���륤�٥��: -.Pp -.Bl -tag -width USERSUSPENDREQ -compact -offset indent -.It NORMRESUME -.It CRITRESUME -.It STANDBYRESUME -.It POWERSTATECHANGE -.It UPDATETIME -.It CAPABILITIESCHANGE -.El -.Pp -�åµï¿½Ê³ï¿½ï¿½Î¥ï¿½ï¿½Ù¥ï¿½È¤ï¿½ -.Nm -�����Τ���ޤ��� -.El -.Ed -.It -���ޥ�ɥ饤��ʸˡ -.Bd -ragged -offset indent -���Ҥ���Ǥϡ� -.Ql exec -����Ϥޤ� 3 �Ԥϥ��٥�Ȥ��Ф��륳�ޥ�ɤǤ��� -���줾��ιԤϥ��ߥ�����ǽ�λ���Ƥ���ɬ�פ�����ޤ��� -���٥�Ȥ��Ф��륳�ޥ�ɥꥹ�Ȥ� -.Ql { -�� -.Ql } -�ǰϤߤޤ��� -.Nm -�ϥ��֥륯�����ơ������ǰϤޤ줿���ޥ�ɤμ¹Ԥ� -.Xr system 3 -��Ʊ�ͤ� -.Pa /bin/sh -����Ѥ��ޤ����ƥ��ޥ�ɤϥ��ޥ�ɥꥹ�ȤκǸ����ã���뤫 0 �ʳ��� -��λ�����ɤǽ����ޤǽ��֤˼¹Ԥ���ޤ��� -.Nm -�ϡ����Ԥ������ޥ�ɤν�λ�����ɤ� -.Xr syslog 3 -��ͳ����𤷤ޤ��� -��� APM BIOS ������׵ᥤ�٥�Ȥ���ä��ޤ��� -.Ed -.It -�Ȥ߹��ߴؿ� -.Bd -ragged -offset indent -���ޥ�ɹԤ����� -.Nm -���Ȥ߹��ߴؿ������Ǥ��ޤ����Ȥ߹��ߴؿ��ϥ��ޥ�ɹԤ�Ʊ�ͤ� -���ߥ�����ǽ�λ���ޤ��������Ȥ߹��ߴؿ������ߥ��ݡ��Ȥ���Ƥ��ޤ��� -.Bl -item -.It -- reject: -.Bd -ragged -offset indent -APM BIOS �����ľ�����׵����ݤ��ޤ����ǥ����ץ쥤���Ĥ�������ȯ���� -�� SUSPEND �׵����ݤ��ơ����� STANDBY ���֤ˤ��������ʤɤ˻��Ѥ� -�ޤ��� -.Ed -.El -.Ed -.El -.Sh ������ -����ե�����Υ���ץ�ˤϡ��ʲ��Τ�Τ��ޤޤ�Ƥ��ޤ��� -.Bd -literal -apm_event SUSPENDREQ { - exec "/etc/rc.suspend"; -} - -apm_event USERSUSPENDREQ { - exec "sync && sync && sync"; - exec "sleep 1"; - exec "apm -z"; -} - -apm_event NORMRESUME, STANDBYRESUME { - exec "/etc/rc.resume"; -} - -# resume event configuration for serial mouse users by -# reinitializing a moused(8) connected to a serial port. -# -#apm_event NORMRESUME { -# exec "kill -HUP `cat /var/run/moused.pid`"; -#} - -# suspend request event configuration for ATA HDD users: -# execute standby instead of suspend. -# -#apm_event SUSPENDREQ { -# reject; -# exec "sync && sync && sync"; -# exec "sleep 1"; -# exec "apm -Z"; -#} -.Ed -.Sh ��Ϣ�ե����� -.Bl -tag -width /etc/apmd.conf -compact -.It Pa /etc/apmd.conf -.It Pa /dev/apmctl -.It Pa /var/run/apmd.pid -.El -.Sh ��Ϣ���� -.Xr apm 4 , -.Xr apm 8 -.Sh ��� -.An Mitsuru IWASAKI Aq iwasaki@FreeBSD.org -.An KOIE Hidetaka Aq koie@suri.co.jp -.Pp -�ޤ��� -.An Warner Losh Aq imp@FreeBSD.org , -.An Hiroshi Yamashita Aq bluemoon@msj.biglobe.ne.jp , -.An Yoshihiko SARUMARU Aq mistral@imasy.or.jp , -.An Norihiro Kumagai Aq kuma@nk.rim.or.jp , -.An NAKAGAWA Yoshihisa Aq nakagawa@jp.FreeBSD.org , -.An Nick Hilliard Aq nick@foobar.org -�ˤ��׸�������ޤ����� -.Sh ��� -.Nm -���ޥ�ɤ� -.Fx 3.3 -�����о줷�ޤ����� diff --git a/ja_JP.eucJP/share/sgml/authors.ent b/ja_JP.eucJP/share/sgml/authors.ent deleted file mode 100644 index 456a74676d..0000000000 --- a/ja_JP.eucJP/share/sgml/authors.ent +++ /dev/null @@ -1,660 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD Japanese Documentation Project - - Original revision: 1.174 - - $FreeBSD: doc/ja_JP.eucJP/books/handbook/authors.ent,v 1.65 2001/07/18 19:29:08 hrs Exp $ - - Names and email address of contributing authors and CVS committers. - Entity names for committers should be the same as their login names on - freefall.FreeBSD.org. - - Use these entities when referencing people. - - Please keep this list in alphabetical order by entity names. - - IMPORTANT: If you delete names from this file you *must* ensure that - all references to them have been removed from the handbook's - translations. If they haven't then you *will* break the - builds for the other languages, and we will poke fun of you - in public. ---> - -<!ENTITY a.abial "Andrzej Bialecki <email>abial@FreeBSD.org</email>"> - -<!ENTITY a.ache "Andrey A. Chernov <email>ache@FreeBSD.org</email>"> - -<!ENTITY a.adam "Adam David <email>adam@FreeBSD.org</email>"> - -<!ENTITY a.ade "Ade Lovett <email>ade@FreeBSD.org</email>"> - -<!ENTITY a.adrian "Adrian Chadd <email>adrian@FreeBSD.org</email>"> - -<!ENTITY a.akiyama "���� ���� <email>akiyama@FreeBSD.org</email>"> - -<!ENTITY a.alc "Alan L. Cox <email>alc@FreeBSD.org</email>"> - -<!ENTITY a.alex "Alexander Langer <email>alex@FreeBSD.org</email>"> - -<!ENTITY a.alfred "Alfred Perlstein <email>alfred@FreeBSD.org</email>"> - -<!ENTITY a.amurai "¼�� �� <email>amurai@FreeBSD.org</email>"> - -<!ENTITY a.andreas "Andreas Klemm <email>andreas@FreeBSD.org</email>"> - -<!ENTITY a.andy "Andrey Zakhvatov <email>andy@FreeBSD.org</email>"> - -<!ENTITY a.archie "Archie Cobbs <email>archie@FreeBSD.org</email>"> - -<!ENTITY a.asami "���� �� <email>asami@FreeBSD.org</email>"> - -<!ENTITY a.asmodai "Jeroen Ruigrok/Asmodai <email>asmodai@FreeBSD.org</email>"> - -<!ENTITY a.assar "Assar Westerlund <email>assar@FreeBSD.org</email>"> - -<!ENTITY a.ats "Andreas Schulz <email>ats@FreeBSD.org</email>"> - -<!ENTITY a.awebster "Andrew Webster <email>awebster@pubnix.net</email>"> - -<!ENTITY a.babkin "Sergey Babkin <email>babkin@FreeBSD.org</email>"> - -<!ENTITY a.bbraun "Rob Braun <email>bbraun@FreeBSD.org</email>"> - -<!ENTITY a.bde "Bruce Evans <email>bde@FreeBSD.org</email>"> - -<!ENTITY a.ben "Ben Smithurst <email>ben@FreeBSD.org</email>"> - -<!ENTITY a.bean "Rebecca Visger <email>bean@FreeBSD.org</email>"> - -<!ENTITY a.benno "Benno Rice <email>benno@FreeBSD.org</email>"> - -<!ENTITY a.billf "Bill Fumerola <email>billf@FreeBSD.org</email>"> - -<!ENTITY a.bmah "Bruce A. Mah <email>bmah@FreeBSD.org</email>"> - -<!ENTITY a.bmilekic "Bosko Milekic <email>bmilekic@FreeBSD.org</email>"> - -<!ENTITY a.bp "Boris Popov <email>bp@FreeBSD.org</email>"> - -<!ENTITY a.brandon "Brandon Gillespie <email>brandon@FreeBSD.org</email>"> - -<!ENTITY a.brian "Brian Somers <email>brian@FreeBSD.org</email>"> - -<!ENTITY a.brooks "Brooks Davis <email>brooks@FreeBSD.org</email>"> - -<!ENTITY a.bsd "Brian S. Dean <email>bsd@FreeBSD.org</email>"> - -<!ENTITY a.cawimm "Charles A. Wimmer <email>cawimm@FreeBSD.org</email>"> - -<!ENTITY a.cg "Cameron Grant <email>cg@FreeBSD.org</email>"> - -<!ENTITY a.charnier "Philippe Charnier <email>charnier@FreeBSD.org</email>"> - -<!ENTITY a.chern "Chern Lee <email>chern@FreeBSD.org</email>"> - -<!ENTITY a.chm "Christoph Herrmann <email>chm@FreeBSD.org</email>"> - -<!ENTITY a.chris "Chris Costello <email>chris@FreeBSD.org</email>"> - -<!ENTITY a.chuck "Chuck Robey <email>chuckr@glue.umd.edu</email>"> - -<!ENTITY a.chuckr "Chuck Robey <email>chuckr@FreeBSD.org</email>"> - -<!ENTITY a.cjc "Crist J. Clark <email>cjc@FreeBSD.org</email>"> - -<!ENTITY a.cjh "Junho CHOI <email>cjh@FreeBSD.org</email>"> - -<!ENTITY a.clive "Clive Lin <email>clive@FreeBSD.org</email>"> - -<!ENTITY a.cp "Chuck Paterson <email>cp@FreeBSD.org</email>"> - -<!ENTITY a.cokane "Coleman Kane <email>cokane@FreeBSD.org</email>"> - -<!ENTITY a.cpiazza "Chris Piazza <email>cpiazza@FreeBSD.org</email>"> - -<!ENTITY a.cracauer "Martin Cracauer <email>cracauer@FreeBSD.org</email>"> - -<!ENTITY a.csgr "Geoff Rehmet <email>csgr@FreeBSD.org</email>"> - -<!ENTITY a.cshumway "Christopher Shumway <email>cshumway@FreeBSD.org</email>"> - -<!ENTITY a.cwt "Chris Timmons <email>cwt@FreeBSD.org</email>"> - -<!ENTITY a.dan "Dan Moschuk <email>dan@FreeBSD.org</email>"> - -<!ENTITY a.danny "Daniel O'Callaghan <email>danny@FreeBSD.org</email>"> - -<!ENTITY a.dannyboy "Daniel Harris <email>dannyboy@FreeBSD.org</email>"> - -<!ENTITY a.darrenr "Darren Reed <email>darrenr@FreeBSD.org</email>"> - -<!ENTITY a.davidn "David Nugent <email>davidn@blaze.net.au</email>"> - -<!ENTITY a.dbaker "Daniel Baker <email>dbaker@FreeBSD.org</email>"> - -<!ENTITY a.dburr "Donald Burr <email>dburr@FreeBSD.org</email>"> - -<!ENTITY a.dcs "Daniel C. Sobral <email>dcs@FreeBSD.org</email>"> - -<!ENTITY a.dd "Dima Dorfman <email>dd@FreeBSD.org</email>"> - -<!ENTITY a.dec "David E. Cross <email>dec@FreeBSD.org</email>"> - -<!ENTITY a.demon "Dmitry Sivachenko <email>demon@FreeBSD.org</email>"> - -<!ENTITY a.deischen "Daniel Eischen <email>deischen@FreeBSD.org</email>"> - -<!ENTITY a.des "Dag-Erling C. Smørgrav <email>des@FreeBSD.org</email>"> - -<!ENTITY a.dfr "Doug Rabson <email>dfr@FreeBSD.org</email>"> - -<!ENTITY a.dg "David Greenman <email>dg@FreeBSD.org</email>"> - -<!ENTITY a.dick "Richard Seaman Jr. <email>dick@FreeBSD.org</email>"> - -<!ENTITY a.dillon "Matthew Dillon <email>dillon@FreeBSD.org</email>"> - -<!ENTITY a.dima "Dima Ruban <email>dima@FreeBSD.org</email>"> - -<!ENTITY a.dinoex "Dirk Meyer <email>dinoex@FreeBSD.org</email>"> - -<!ENTITY a.dirk "Dirk Frömberg <email>dirk@FreeBSD.org</email>"> - -<!ENTITY a.dirkvangulik "Dirk-Willem van Gulik <email>Dirk.vanGulik@jrc.it</email>"> - -<!ENTITY a.dmlb "Duncan Barclay <email>dmlb@FreeBSD.org</email>"> - -<!ENTITY a.dougb "Doug Barton <email>DougB@FreeBSD.org</email>"> - -<!ENTITY a.dt "Dmitrij Tejblum <email>dt@FreeBSD.org</email>"> - -<!ENTITY a.dufault "Peter Dufault <email>dufault@FreeBSD.org</email>"> - -<!ENTITY a.dwcjr "David W. Chapman Jr. <email>dwcjr@FreeBSD.org</email>"> - -<!ENTITY a.dwhite "Doug White <email>dwhite@FreeBSD.org</email>"> - -<!ENTITY a.dwmalone "David Malone <email>dwmalone@FreeBSD.org</email>"> - -<!ENTITY a.dyson "John Dyson <email>dyson@FreeBSD.org</email>"> - -<!ENTITY a.eivind "Eivind Eklund <email>eivind@FreeBSD.org</email>"> - -<!ENTITY a.ejc "Eric J. Chet <email>ejc@FreeBSD.org</email>"> - -<!ENTITY a.eric "Eric Melville <email>eric@FreeBSD.org</email>"> - -<!ENTITY a.erich "Eric L. Hernes <email>erich@FreeBSD.org</email>"> - -<!ENTITY a.faq "FAQ �ݼ�ô���� <email>faq@FreeBSD.org</email>"> - -<!ENTITY a.fenner "Bill Fenner <email>fenner@FreeBSD.org</email>"> - -<!ENTITY a.flathill "ʿ�� ����ϯ <email>flathill@FreeBSD.org</email>"> - -<!ENTITY a.foxfair "Howard F. Hu <email>foxfair@FreeBSD.org</email>"> - -<!ENTITY a.fsmp "Steve Passe <email>fsmp@FreeBSD.org</email>"> - -<!ENTITY a.furuta "���� �� <email>furuta@FreeBSD.org</email>"> - -<!ENTITY a.gad "Garance A Drosehn <email>gad@FreeBSD.org</email>"> - -<!ENTITY a.gallatin "Andrew Gallatin <email>gallatin@FreeBSD.org</email>"> - -<!ENTITY a.gclarkii "Gary Clark II <email>gclarkii@FreeBSD.org</email>"> - -<!ENTITY a.gena "Gennady B. Sorokopud <email>gena@NetVision.net.il</email>"> - -<!ENTITY a.ghelmer "Guy Helmer <email>ghelmer@cs.iastate.edu</email>"> - -<!ENTITY a.gibbs "Justin T. Gibbs <email>gibbs@FreeBSD.org</email>"> - -<!ENTITY a.gioria "Sebastien Gioria <email>gioria@FreeBSD.org</email>"> - -<!ENTITY a.gj "Gary Jennejohn <email>gj@FreeBSD.org</email>"> - -<!ENTITY a.gpalmer "Gary Palmer <email>gpalmer@FreeBSD.org</email>"> - -<!ENTITY a.graichen "Thomas Graichen <email>graichen@FreeBSD.org</email>"> - -<!ENTITY a.green "Brian F. Feldman <email>green@FreeBSD.org</email>"> - -<!ENTITY a.greid "George C. A. Reid <email>greid@FreeBSD.org</email>"> - -<!ENTITY a.grog "Greg Lehey <email>grog@FreeBSD.org</email>"> - -<!ENTITY a.groudier "Gerard Roudier <email>groudier@club-internet.fr</email>"> - -<!ENTITY a.gryphon "Coranth Gryphon <email>gryphon@healer.com</email>"> - -<!ENTITY a.gshapiro "Gregory Neil Shapiro <email>gshapiro@FreeBSD.org</email>"> - -<!ENTITY a.gsutter "Gregory Sutter <email>gsutter@FreeBSD.org</email>"> - -<!ENTITY a.guido "Guido van Rooij <email>guido@FreeBSD.org</email>"> - -<!ENTITY a.hanai "�ְ� ��Ƿ <email>hanai@FreeBSD.org</email>"> - -<!ENTITY a.handy "Brian N. Handy <email>handy@sxt4.physics.montana.edu</email>"> - -<!ENTITY a.hrs "��ƣ ���� <email>hrs@FreeBSD.org</email>"> - -<!ENTITY a.roger "Roger Hardiman <email>roger@freebsd.org</email>"> - -<!ENTITY a.helbig "Wolfgang Helbig <email>helbig@FreeBSD.org</email>"> - -<!ENTITY a.hm "Hellmuth Michaelis <email>hm@FreeBSD.org</email>"> - -<!ENTITY a.hoek "Tim Vanderhoek <email>hoek@FreeBSD.org</email>"> - -<!ENTITY a.horikawa "���� ��ͺ <email>horikawa@FreeBSD.org</email>"> - -<!ENTITY a.hosokawa "���� � <email>hosokawa@FreeBSD.org</email>"> - -<!ENTITY a.hsu "Jeffrey Hsu <email>hsu@FreeBSD.org</email>"> - -<!ENTITY a.iedowse "Ian Dowse <email>iedowse@FreeBSD.org</email>"> - -<!ENTITY a.ijliao "Ying-Chieh Liao <email>ijliao@FreeBSD.org</email>"> - -<!ENTITY a.imp "Warner Losh <email>imp@FreeBSD.org</email>"> - -<!ENTITY a.imura "R. Imura <email>imura@FreeBSD.org</email>"> - -<!ENTITY a.issei "���� ���� <email>issei@FreeBSD.org</email>"> - -<!ENTITY a.itojun "���� (itojun) ���Ϻ <email>itojun@itojun.org</email>"> - -<!ENTITY a.iwasaki "��� �� <email>iwasaki@FreeBSD.org</email>"> - -<!ENTITY a.jake "Jake Burkholder <email>jake@FreeBSD.org</email>"> - -<!ENTITY a.jasone "Jason Evans <email>jasone@FreeBSD.org</email>"> - -<!ENTITY a.jayanth "Jayanth Vijayaraghavan <email>jayanth@FreeBSD.org</email>"> - -<!ENTITY a.jb "John Birrell <email>jb@cimlogic.com.au</email>"> - -<!ENTITY a.jdp "John Polstra <email>jdp@FreeBSD.org</email>"> - -<!ENTITY a.jedgar "Chris D. Faulhaber <email>jedgar@FreeBSD.org</email>"> - -<!ENTITY a.jeh "James Housley <email>jeh@FreeBSD.org</email>"> - -<!ENTITY a.jehamby "Jake Hamby <email>jehamby@lightside.com</email>"> - -<!ENTITY a.jesper "Jesper Skriver <email>jesper@FreeBSD.org</email>"> - -<!ENTITY a.jesusr "Jesus Rodriguez <email>jesusr@FreeBSD.org</email>"> - -<!ENTITY a.jfieber "John Fieber <email>jfieber@FreeBSD.org</email>"> - -<!ENTITY a.jfitz "James FitzGibbon <email>jfitz@FreeBSD.org</email>"> - -<!ENTITY a.jgreco "Joe Greco <email>jgreco@FreeBSD.org</email>"> - -<!ENTITY a.jhay "John Hay <email>jhay@FreeBSD.org</email>"> - -<!ENTITY a.jhb "John Baldwin <email>jhb@FreeBSD.org</email>"> - -<!ENTITY a.jhs "Julian Stacey <email>jhs@FreeBSD.org</email>"> - -<!ENTITY a.jim "Jim Mock <email>jim@FreeBSD.org</email>"> - -<!ENTITY a.jkh "Jordan K. Hubbard <email>jkh@FreeBSD.org</email>"> - -<!ENTITY a.jkoshy "Joseph Koshy <email>jkoshy@FreeBSD.org</email>"> - -<!ENTITY a.jlemon "Jonathan Lemon <email>jlemon@FreeBSD.org</email>"> - -<!ENTITY a.jlind "John Lind <email>john@starfire.MN.ORG</email>"> - -<!ENTITY a.jlrobin "James L. Robinson <email>jlrobin@FreeBSD.org</email>"> - -<!ENTITY a.jmacd "Joshua Peck Macdonald <email>jmacd@FreeBSD.org</email>"> - -<!ENTITY a.jmas "Jose M. Alcaide <email>jmas@FreeBSD.org</email>"> - -<!ENTITY a.jmb "Jonathan M. Bresler <email>jmb@FreeBSD.org</email>"> - -<!ENTITY a.jmg "John-Mark Gurney <email>jmg@FreeBSD.org</email>"> - -<!ENTITY a.jmz "Jean-Marc Zucconi <email>jmz@FreeBSD.org</email>"> - -<!ENTITY a.joe "Josef Karthauser <email>joe@FreeBSD.org</email>"> - -<!ENTITY a.keichii "Michael C. Wu <email>keichii@FreeBSD.org</email>"> - -<!ENTITY a.joerg "Jörg Wunsch <email>joerg@FreeBSD.org</email>"> - -<!ENTITY a.jon "Jonathan Chen <email>jon@FreeBSD.org</email>"> - -<!ENTITY a.john "John Cavanaugh <email>john@FreeBSD.org</email>"> - -<!ENTITY a.jraynard "James Raynard <email>jraynard@FreeBSD.org</email>"> - -<!ENTITY a.jseger "Justin Seger <email>jseger@FreeBSD.org</email>"> - -<!ENTITY a.julian "Julian Elischer <email>julian@FreeBSD.org</email>"> - -<!ENTITY a.jwd "John W. DeBoskey <email>jwd@FreeBSD.org</email>"> - -<!ENTITY a.jvh "Johannes Helander <email>jvh@FreeBSD.org</email>"> - -<!ENTITY a.karl "Karl Strickland <email>karl@FreeBSD.org</email>"> - -<!ENTITY a.kato "��ƣ ��ŵ <email>kato@FreeBSD.org</email>"> - -<!ENTITY a.kbyanc "Kelly Yancey <email>kbyanc@FreeBSD.org</email>"> - -<!ENTITY a.keith "Jing-Tang Keith Jang <email>keith@FreeBSD.org</email>"> - -<!ENTITY a.kelly "Sean Kelly <email>kelly@ad1440.net</email>"> - -<!ENTITY a.ken "Kenneth D. Merry <email>ken@FreeBSD.org</email>"> - -<!ENTITY a.kevlo "Kevin Lo <email>kevlo@FreeBSD.org</email>"> - -<!ENTITY a.kiri "�ͻ� ��ɧ <email>kiri@FreeBSD.org</email>"> - -<!ENTITY a.kjc "Ĺ ����ϯ <email>kjc@FreeBSD.org</email>"> - -<!ENTITY a.knu "��� ���� <email>knu@FreeBSD.org</email>"> - -<!ENTITY a.kris "Kris Kennaway <email>kris@FreeBSD.org</email>"> - -<!ENTITY a.kuriyama "���� �� <email>kuriyama@FreeBSD.org</email>"> - -<!ENTITY a.lars "Lars Fredriksen <email>lars@FreeBSD.org</email>"> - -<!ENTITY a.lile "Larry Lile <email>lile@FreeBSD.org</email>"> - -<!ENTITY a.lioux "Mário Sérgio Fujikawa Ferreira<email>lioux@FreeBSD.org</email>"> - -<!ENTITY a.ljo "L Jonas Olsson <email>ljo@FreeBSD.org</email>"> - -<!ENTITY a.lkoeller "Lars Koeller <email>lkoeller@FreeBSD.org</email>"> - -<!ENTITY a.logo "Valentino Vaschetto <email>logo@blackened.com</email>"> - -<!ENTITY a.luigi "Luigi Rizzo <email>luigi@FreeBSD.org</email>"> - -<!ENTITY a.luoqi "Luoqi Chen <email>luoqi@FreeBSD.org</email>"> - -<!ENTITY a.marcel "Marcel Moolenaar <email>marcel@FreeBSD.org</email>"> - -<!ENTITY a.markm "Mark Murray <email>markm@FreeBSD.org</email>"> - -<!ENTITY a.marko "Mark Ovens <email>marko@FreeBSD.org</email>"> - -<!ENTITY a.markp "Mark Pulford <email>markp@FreeBSD.org</email>"> - -<!ENTITY a.martin "Martin Renters <email>martin@FreeBSD.org</email>"> - -<!ENTITY a.max "�溬 ��ʸ <email>max@FreeBSD.org</email>"> - -<!ENTITY a.mayo "Mark Mayo <email>mark@vmunix.com</email>"> - -<!ENTITY a.mb "Maxim Bolotin <email>mb@FreeBSD.org</email>"> - -<!ENTITY a.mbarkah "Ade Barkah <email>mbarkah@FreeBSD.org</email>"> - -<!ENTITY a.mckay "Stephen McKay <email>mckay@FreeBSD.org</email>"> - -<!ENTITY a.mckusick "Kirk McKusick <email>mckusick@FreeBSD.org</email>"> - -<!ENTITY a.md "Mark Dapoz <email>md@bsc.no</email>"> - -<!ENTITY a.mdodd "Matthew N. Dodd <email>winter@jurai.net</email>"> - -<!ENTITY a.mharo "Michael Haro <email>mharo@FreeBSD.org</email>"> - -<!ENTITY a.mi "Mikhail Teterin <email>mi@FreeBSD.org</email>"> - -<!ENTITY a.mike "Mike Barcroft <email>mike@FreeBSD.org</email>"> - -<!ENTITY a.mikeh "Mike Heffner <email>mikeh@FreeBSD.org</email>"> - -<!ENTITY a.mita "���� ��Ϻ <email>mita@FreeBSD.org</email>"> - -<!ENTITY a.mjacob "Matthew Jacob <email>mjacob@FreeBSD.org</email>"> - -<!ENTITY a.mks "Mike Spengler <email>mks@FreeBSD.org</email>"> - -<!ENTITY a.motoyuki "���� ��Ƿ <email>motoyuki@FreeBSD.org</email>"> - -<!ENTITY a.mp "Mark Peek <email>mp@FreeBSD.org</email>"> - -<!ENTITY a.mph "Matthew Hunt <email>mph@FreeBSD.org</email>"> - -<!ENTITY a.mpp "Mike Pritchard <email>mpp@FreeBSD.org</email>"> - -<!ENTITY a.msmith "Michael Smith <email>msmith@FreeBSD.org</email>"> - -<!ENTITY a.mtaylor "Mark J. Taylor <email>mtaylor@FreeBSD.org</email>"> - -<!ENTITY a.murray "Murray Stokely <email>murray@FreeBSD.org</email>"> - -<!ENTITY a.nakai "��� ���� <email>nakai@FreeBSD.org</email>"> - -<!ENTITY a.nate "Nate Williams <email>nate@FreeBSD.org</email>"> - -<!ENTITY a.nbm "Neil Blakey-Milner <email>nbm@FreeBSD.org</email>"> - -<!ENTITY a.nectar "Jacques Vidrine <email>nectar@FreeBSD.org</email>"> - -<!ENTITY a.newton "Mark Newton <email>newton@FreeBSD.org</email>"> - -<!ENTITY a.nhibma "Nick Hibma <email>n_hibma@FreeBSD.org</email>"> - -<!ENTITY a.nik "Nik Clayton <email>nik@FreeBSD.org</email>"> - -<!ENTITY a.non "���� ˡ�� <email>non@FreeBSD.org</email>"> - -<!ENTITY a.nsayer "Nick Sayer <email>nsayer@FreeBSD.org</email>"> - -<!ENTITY a.nsj "Nate Johnson <email>nsj@FreeBSD.org</email>"> - -<!ENTITY a.nsouch "Nicolas Souchu <email>nsouch@FreeBSD.org</email>"> - -<!ENTITY a.nyan "�ⶶ ���� <email>nyan@FreeBSD.org</email>"> - -<!ENTITY a.obrien "David O'Brien <email>obrien@FreeBSD.org</email>"> - -<!ENTITY a.okazaki "���� ůϯ <email>okazaki@FreeBSD.org</email>"> - -<!ENTITY a.olah "Andras Olah <email>olah@FreeBSD.org</email>"> - -<!ENTITY a.olgeni "Jimmy Olgeni <email>olgeni@FreeBSD.org</email>"> - -<!ENTITY a.onoe "���� �� <email>onoe@FreeBSD.org</email>"> - -<!ENTITY a.opsys "Chris Watson <email>opsys@open-systems.net</email>"> - -<!ENTITY a.orion "Orion Hodson <email>orion@FreeBSD.org</email>"> - -<!ENTITY a.patrick "Patrick S. Gardella <email>patrick@FreeBSD.org</email>"> - -<!ENTITY a.paul "Paul Richards <email>paul@FreeBSD.org</email>"> - -<!ENTITY a.pb "Pierre Beyssac <email>pb@fasterix.freenix.org</email>"> - -<!ENTITY a.pds "Peter da Silva <email>pds@FreeBSD.org</email>"> - -<!ENTITY a.peter "Peter Wemm <email>peter@FreeBSD.org</email>"> - -<!ENTITY a.phantom "Alexey Zelkin <email>phantom@FreeBSD.org</email>"> - -<!ENTITY a.phk "Poul-Henning Kamp <email>phk@FreeBSD.org</email>"> - -<!ENTITY a.pho "Peter Holm <email>pho@FreeBSD.org</email>"> - -<!ENTITY a.piero "Piero Serini <email>piero@strider.inet.it</email>"> - -<!ENTITY a.pirzyk "Jim Pirzyk <email>pirzyk@FreeBSD.org</email>"> - -<!ENTITY a.pjc "Peter Childs <email>pjchilds@imforei.apana.org.au</email>"> - -<!ENTITY a.proven "Chris Provenzano <email>proven@FreeBSD.org</email>"> - -<!ENTITY a.ps "Paul Saab <email>ps@FreeBSD.org</email>"> - -<!ENTITY a.pst "Paul Traina <email>pst@FreeBSD.org</email>"> - -<!ENTITY a.reg "Jeremy Lea <email>reg@FreeBSD.org</email>"> - -<!ENTITY a.rgrimes "Rodney Grimes <email>rgrimes@FreeBSD.org</email>"> - -<!ENTITY a.rhuff "Robert Huff <email>rhuff@cybercom.net</email>"> - -<!ENTITY a.ricardag "Ricardo AG <email>ricardag@ag.com.br</email>"> - -<!ENTITY a.rich "Rich Murphey <email>rich@FreeBSD.org</email>"> - -<!ENTITY a.rnordier "Robert Nordier <email>rnordier@FreeBSD.org</email>"> - -<!ENTITY a.roam "Peter Pentchev <email>roam@FreeBSD.org</email>"> - -<!ENTITY a.roberto "Ollivier Robert <email>roberto@FreeBSD.org</email>"> - -<!ENTITY a.rse "Ralf S. Engelschall <email>rse@FreeBSD.org</email>"> - -<!ENTITY a.ru "Ruslan Ermilov <email>ru@FreeBSD.org</email>"> - -<!ENTITY a.rv "Rajesh Vaidheeswarran <email>rv@FreeBSD.org</email>"> - -<!ENTITY a.rvb "Robert V. Baron <email>rvb@FreeBSD.org</email>"> - -<!ENTITY a.rwatson "Robert Watson <email>rwatson@FreeBSD.org</email>"> - -<!ENTITY a.sada "���� ���� <email>sada@FreeBSD.org</email>"> - -<!ENTITY a.sanpei "��ʿ ��Ϻ <email>sanpei@FreeBSD.org</email>"> - -<!ENTITY a.schweikh "Jens Schweikhardt <email>schweikh@FreeBSD.org</email>"> - -<!ENTITY a.scottl "Scott Long <email>scottl@FreeBSD.org</email>"> - -<!ENTITY a.scrappy "Marc G. Fournier <email>scrappy@FreeBSD.org</email>"> - -<!ENTITY a.se "Stefan Esser <email>se@FreeBSD.org</email>"> - -<!ENTITY a.sef "Sean Eric Fagan <email>sef@FreeBSD.org</email>"> - -<!ENTITY a.semenu "Ustimenko Semen <email>semenu@FreeBSD.org</email>"> - -<!ENTITY a.sethk "Seth Kingsley <email>seth.kingsley@windriver.com</email>"> - -<!ENTITY a.sf "FUJISHIMA Satsuki <email>sf@FreeBSD.org</email>"> - -<!ENTITY a.shafeeq "Shafeeq Sinnamohideen <email>shafeeq@FreeBSD.org</email>"> - -<!ENTITY a.sheldonh "Sheldon Hearn <email>sheldonh@FreeBSD.org</email>"> - -<!ENTITY a.shiba "Takeshi Shibagaki <email>shiba@FreeBSD.org</email>"> - -<!ENTITY a.shige "ʡ�� ��Ƿ <email>shige@FreeBSD.org</email>"> - -<!ENTITY a.shin "��� �ɿ� <email>shin@FreeBSD.org</email>"> - -<!ENTITY a.silby "Mike Silbersack <email>silby@FreeBSD.org</email>"> - -<!ENTITY a.simokawa "���� ���� <email>simokawa@FreeBSD.org</email>"> - -<!ENTITY a.smace "Scott Mace <email>smace@FreeBSD.org</email>"> - -<!ENTITY a.smpatel "Sujal Patel <email>smpatel@FreeBSD.org</email>"> - -<!ENTITY a.sobomax "Maxim Sobolev <email>sobomax@FreeBSD.org</email>"> - -<!ENTITY a.sos "Søren Schmidt <email>sos@FreeBSD.org</email>"> - -<!ENTITY a.stanislav "G. Adam Stanislav. <email>adam@whizkidtech.net</email>"> - -<!ENTITY a.stark "Gene Stark <email>stark@FreeBSD.org</email>"> - -<!ENTITY a.stb "Stefan Bethke <email>stb@FreeBSD.org</email>"> - -<!ENTITY a.steve "Steve Price <email>steve@FreeBSD.org</email>"> - -<!ENTITY a.sumikawa "���� ���� <email>sumikawa@FreeBSD.org</email>"> - -<!ENTITY a.swallace "Steven Wallace <email>swallace@FreeBSD.org</email>"> - -<!ENTITY a.tanimura "ë¼ ���� <email>tanimura@FreeBSD.org</email>"> - -<!ENTITY a.taoka "�IJ� �һ� <email>taoka@FreeBSD.org</email>"> - -<!ENTITY a.takawata "���� º�� <email>takawata@FreeBSD.org</email>"> - -<!ENTITY a.tedm "Ted Mittelstaedt <email>tedm@FreeBSD.org</email>"> - -<!ENTITY a.tegge "Tor Egge <email>tegge@FreeBSD.org</email>"> - -<!ENTITY a.tg "Thomas Gellekum <email>tg@FreeBSD.org</email>"> - -<!ENTITY a.thepish "Peter Hawkins <email>thepish@FreeBSD.org</email>"> - -<!ENTITY a.tmm "Thomas Möstl <email>tmm@FreeBSD.org</email>"> - -<!ENTITY a.tobez "Anton Berezin <email>tobez@FreeBSD.org</email>"> - -<!ENTITY a.tom "Tom Hukins <email>tom@FreeBSD.org</email>"> - -<!ENTITY a.tomsoft "Thomas-Henning von Kamptz <email>tomsoft@FreeBSD.org</email>"> - -<!ENTITY a.torstenb "Torsten Blum <email>torstenb@FreeBSD.org</email>"> - -<!ENTITY a.toshi "���� ��ɧ <email>toshi@FreeBSD.org</email>"> - -<!ENTITY a.trevor "Trevor Johnson <email>trevor@FreeBSD.org</email>"> - -<!ENTITY a.truckman "Don “Truck” Lewis <email>truckman@FreeBSD.org</email>"> - -<!ENTITY a.tshiozak "���� ���� <email>tshiozak@FreeBSD.org</email>"> - -<!ENTITY a.uch "UCHIYAMA Yasushi <email>uch@FreeBSD.org</email>"> - -<!ENTITY a.ue "Udo Erdelhoff <email>ue@FreeBSD.org</email>"> - -<!ENTITY a.ugen "Ugen J.S.Antsilevich <email>ugen@FreeBSD.org</email>"> - -<!ENTITY a.uhclem "Frank Durda IV <email>uhclem@FreeBSD.org</email>"> - -<!ENTITY a.ulf "Ulf Zimmermann <email>ulf@FreeBSD.org</email>"> - -<!ENTITY a.ume "���� È¥ <email>ume@FreeBSD.org</email>"> - -<!ENTITY a.unfurl "Bill Swingle <email>unfurl@FreeBSD.org</email>"> - -<!ENTITY a.vanilla "Vanilla I. Shu <email>vanilla@FreeBSD.org</email>"> - -<!ENTITY a.wes "Wes Peters <email>wes@FreeBSD.org</email>"> - -<!ENTITY a.whiteside "Don Whiteside <email>whiteside@acm.org</email>"> - -<!ENTITY a.wilko "Wilko Bulte <email>wilko@FreeBSD.org</email>"> - -<!ENTITY a.will "Will Andrews <email>will@FreeBSD.org</email>"> - -<!ENTITY a.wjv "Johann Visagie <email>wjv@FreeBSD.org</email>"> - -<!ENTITY a.wlloyd "Bill Lloyd <email>wlloyd@mpd.ca</email>"> - -<!ENTITY a.wollman "Garrett Wollman <email>wollman@FreeBSD.org</email>"> - -<!ENTITY a.wosch "Wolfram Schneider <email>wosch@FreeBSD.org</email>"> - -<!ENTITY a.wpaul "Bill Paul <email>wpaul@FreeBSD.org</email>"> - -<!ENTITY a.wsanchez "Wilfredo Sánchez <email>wsanchez@FreeBSD.org</email>"> - -<!ENTITY a.wylie "Wylie Stilwell <email>wylie@osd.bsdi.com</email>"> - -<!ENTITY a.yar "Yar Tikhiy <email>yar@FreeBSD.org</email>"> - -<!ENTITY a.yokota "���� ��δ <email>yokota@FreeBSD.org</email>"> - -<!ENTITY a.zarzycki "Dave Zarzycki <email>zarzycki@FreeBSD.org</email>"> diff --git a/ja_JP.eucJP/share/sgml/jauthors.ent b/ja_JP.eucJP/share/sgml/jauthors.ent deleted file mode 100644 index 143921ae08..0000000000 --- a/ja_JP.eucJP/share/sgml/jauthors.ent +++ /dev/null @@ -1,91 +0,0 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD Japanese Documentation Project - - Original revision: - $FreeBSD: doc/ja_JP.eucJP/books/handbook/jauthors.ent,v 1.7 2000/07/20 00:20:57 hrs Exp $ - - Names and email address of Japanese local contributing authors and - castle.jp.freebsd.org CVS committers. - Entity names for committers on castle should be the same as their login - names on castle.jp.FreeBSD.ORG. - - Use these entities when referencing people. - - Please keep this list in alphabetical order by entity names. ---> - -<!ENTITY a.jp.arimura "ͼ ���� <email>arimura@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.candy "���� �ҹ� <email>candy@fct.kgc.co.jp</email>"> - -<!ENTITY a.jp.condle "�� ľǷ <email>mori@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.g92k0323 "���� ���� <email>g92k0323@cfi.waseda.ac.jp</email>"> - -<!ENTITY a.jp.graphite "���� ���� <email>graphite@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.hino "���� ���� <email>hino@ccm.cl.nec.co.jp</email>"> - -<!ENTITY a.jp.ikuo "���� ���� <email>ikuo@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.iwasaki "��� �� <email>iwasaki@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.katsu "������ �� <email>katsu@baum.kiyose.tokyo.jp</email>"> - -<!ENTITY a.jp.kimura "��¼ ��ȼ <email>kimura@netlab.is.tsukuba.ac.jp</email>"> - -<!ENTITY a.jp.kiroh "�Ϥ�� ������ <email>kiroh@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.kmiyakoda "���ġ���Ϻ <email>kmiyakoda@ctn.co.jp</email>"> - -<!ENTITY a.jp.masaki "���� ���� <email>masaki@po.iijnet.or.jp</email>"> - -<!ENTITY a.jp.mihoko "���� ����� <email>Mihoko_Tanaka@yokogawa.co.jp</email>"> - -<!ENTITY a.jp.mita "���� ��Ϻ <email>mita@jp.FreeBSD.ORG</email>"> - -<!ENTITY a.jp.miyasita "�ܲ� ���� <email>miyasita@hashilab.ee.ous.ac.jp</email>"> - -<!-- -<!ENTITY a.jp.motoyuki "���� ��Ƿ <email>motoyuki@jp.FreeBSD.org</email>"> -authors.sgml �����äƤ���Τǥ����ȥ����� ---> - -<!ENTITY a.jp.mrt "��餿���夦�������� <email>mrt@mickey.ai.kyutech.ac.jp</email>"> - -<!ENTITY a.jp.nakai "��� ���� <email>nakai@mlab.t.u-tokyo.ac.jp</email>"> - -<!ENTITY a.jp.nao "���� ľ�� <email>nao@tom-yam.or.jp</email>"> - -<!ENTITY a.jp.saeki "���� � <email>saeki@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.shou "���� ���� <email>shou@kt.rim.or.jp</email>"> - -<!ENTITY a.jp.simokawa "���� ���� <email>simokawa@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.sugimura "��¼ ���� <email>sugimura@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.tmaruya "�ݻ� ��� <email>tmaruya@nnc.or.jp</email>"> - -<!ENTITY a.jp.tomo "���� ��ͺ <email>tomo@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.ts "���� ���� <email>ts@icu.ac.jp</email>"> - -<!ENTITY a.jp.y-koga "�����褦�������� <email>y-koga@ccs.mt.nec.co.jp</email>"> - -<!ENTITY a.jp.yasu "���� ���� <email>yasu@hike.te.chiba-u.ac.jp</email>"> - -<!ENTITY a.jp.yoshiaki "���� ��� <email>yoshiaki@kt.rim.or.jp</email>"> - -<!ENTITY a.jp.yuki "���� ���� <email>yuki@jp.FreeBSD.org</email>"> - -<!-- - Names of FreeBSD mailing list in Japan. If we refer many mailing - lists in Japan, create jmailing-lists.ent file and store them in - it. ---> - -<!ENTITY a.jp.doc-jp "���ܸ�ɥ�����ơ������ץ��������� <email>doc-jp@jp.FreeBSD.org</email>"> - -<!ENTITY a.jp.users-jp "FreeBSD users-jp �᡼��󥰥ꥹ�� <email>FreeBSD-users-jp@jp.FreeBSD.org</email>"> diff --git a/share/sgml/catalog b/share/sgml/catalog index 888831394e..f060f3b90d 100644 --- a/share/sgml/catalog +++ b/share/sgml/catalog @@ -1,7 +1,7 @@ -- ...................................................................... -- -- FreeBSD SGML Public Identifiers ...................................... -- - -- $FreeBSD: doc/share/sgml/catalog,v 1.18 2001/08/05 19:40:38 jesusr Exp $ + -- $FreeBSD: doc/share/sgml/catalog,v 1.19 2001/08/25 22:02:08 dd Exp $ -- -- ...................................................................... -- @@ -46,6 +46,9 @@ PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities//EN" PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN" "../../en_US.ISO8859-1/share/sgml/authors.ent" +PUBLIC "-//FreeBSD//ENTITIES DocBook Newsgroup Entities//EN" + "../../en_US.ISO8859-1/share/sgml/newsgroups.ent" + -- ...................................................................... -- -- French specific ...................................................... -- diff --git a/zh/FAQ/FAQ.sgml b/zh/FAQ/FAQ.sgml deleted file mode 100644 index 9bf088483a..0000000000 --- a/zh/FAQ/FAQ.sgml +++ /dev/null @@ -1,70 +0,0 @@ -<!-- $Id: FAQ.sgml,v 1.8 1999-11-12 08:34:11 vanilla Exp $ --> -<!-- The FreeBSD Documentation Project --> -<!-- Translate into Chinese by ijliao@dragon2.net --> -<!-- English Version: 1.103 --> - -<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [ -<!ENTITY % includes SYSTEM "includes.sgml"> %includes; -<!ENTITY preface SYSTEM "preface.sgml"> -<!ENTITY install SYSTEM "install.sgml"> -<!ENTITY hardware SYSTEM "hardware.sgml"> -<!ENTITY troubleshoot SYSTEM "troubleshoot.sgml"> -<!ENTITY commercial SYSTEM "commercial.sgml"> -<!ENTITY applications SYSTEM "applications.sgml"> -<!ENTITY kernelconfig SYSTEM "kernelconfig.sgml"> -<!ENTITY admin SYSTEM "admin.sgml"> -<!ENTITY x SYSTEM "x.sgml"> -<!ENTITY network SYSTEM "network.sgml"> -<!ENTITY serial SYSTEM "serial.sgml"> -<!ENTITY misc SYSTEM "misc.sgml"> -<!ENTITY hackers SYSTEM "hackers.sgml"> -<!ENTITY acknowledgments SYSTEM "acknowledgments.sgml"> -]> - -<article> - - <title>FreeBSD 2.X �`���ݵ���</title> - <author> - <name>FreeBSD ���p�e</name> - </author> - - <date>$Date: 1999-11-12 08:34:11 $</date> - - <abstract> - �o�����O FreeBSD 2.X ���`���ݵ����C���D���S�O�[���A�_�h�o�DZ��س��A - �Ω� FreeBSD 2.0.5 �ΥH�᪺�����C�p�G���ؤ��e���� <XXX> �h�O�|�� - �����������C�p�G�z���U���p�e���i�榳���쪺�ܡA�бH�@�ʹq�l�l��� - FreeBSD ���p�e�� mailing list <htmlurl - url="mailto:freebsd-doc@FreeBSD.org" name="<freebsd-doc@FreeBSD.org>">�C - �z�i�H�q <url url="http://www.FreeBSD.org/" - name="FreeBSD World Wide Web server"> ����o����󪺳̷s�����C�z�]�i�H - �Q�� HTTP �ӤU������� <url url="FAQ.latin1" name="�¤�r��">�A - <url url="FAQ.ps" name="postscript ��">�A - <url url="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/FAQ.pdf" name="PDF ��">�A - �άO <url url="FAQ-html.tar.gz" name="HTML ��">�A�άO�g�� - <url url="ftp://ftp.FreeBSD.org/pub/FreeBSD/docs" name="FreeBSD FTP ��"> - �ӤU�� gzip'd �������C�z�γ\�]�Q - <url url="http://www.FreeBSD.org/search/search.html" - name="�b�`���ݵ������j�M���">�C - - </abstract> - - <toc> - -&preface; -&install; -&hardware; -&troubleshoot; -&commercial; -&applications; -&kernelconfig; -&admin; -&x; -&network; -&serial; -&misc; -&hackers; -&acknowledgments; - -</article> - |