From 8d9c59f591713bc555e97852462a15a8a1080a99 Mon Sep 17 00:00:00 2001 From: Doc Manager Date: Sun, 30 Mar 2003 20:25:46 +0000 Subject: Create tag '4.8.0'. --- .../books/handbook/multimedia/chapter.sgml | 661 -- en/handbook/contrib/chapter.sgml | 5796 --------------- en_US.ISO8859-1/books/arch-handbook/Makefile | 55 - en_US.ISO8859-1/books/arch-handbook/book.sgml | 301 - .../books/arch-handbook/boot/chapter.sgml | 1023 --- en_US.ISO8859-1/books/arch-handbook/chapters.ent | 48 - .../books/arch-handbook/driverbasics/chapter.sgml | 392 - .../books/arch-handbook/isa/chapter.sgml | 2487 ------- .../books/arch-handbook/jail/chapter.sgml | 611 -- .../books/arch-handbook/kobj/chapter.sgml | 298 - .../books/arch-handbook/locking/chapter.sgml | 313 - en_US.ISO8859-1/books/arch-handbook/mac.ent | 122 - .../books/arch-handbook/mac/chapter.sgml | 7483 -------------------- .../books/arch-handbook/newbus/chapter.sgml | 360 - .../books/arch-handbook/pci/chapter.sgml | 369 - .../books/arch-handbook/scsi/chapter.sgml | 1983 ------ .../books/arch-handbook/smp/chapter.sgml | 957 --- .../books/arch-handbook/sound/chapter.sgml | 687 -- .../books/arch-handbook/sysinit/chapter.sgml | 161 - .../books/arch-handbook/usb/chapter.sgml | 623 -- .../books/arch-handbook/vm/chapter.sgml | 260 - .../books/handbook/basics/disk-layout.kil | Bin 1450 -> 0 bytes .../books/handbook/basics/example-dir1.dot | 7 - .../books/handbook/basics/example-dir2.dot | 8 - .../books/handbook/basics/example-dir3.dot | 8 - .../books/handbook/basics/example-dir4.dot | 9 - .../books/handbook/basics/example-dir5.dot | 9 - .../books/handbook/mirrors/chapter.sgml | 60 +- en_US.ISO8859-1/books/porters-handbook/book.sgml | 10 + ja_JP.eucJP/books/handbook/multimedia/Makefile | 16 - ja_JP.eucJP/books/handbook/multimedia/chapter.sgml | 397 -- ja_JP.eucJP/man/man1/gtar.1 | 597 -- ja_JP.eucJP/man/man4/man4.i386/aic.4 | 51 - ja_JP.eucJP/man/man4/man4.i386/apm.4 | 160 - ja_JP.eucJP/man/man4/man4.i386/ar.4 | 108 - ja_JP.eucJP/man/man4/man4.i386/cs.4 | 105 - ja_JP.eucJP/man/man4/man4.i386/cx.4 | 289 - ja_JP.eucJP/man/man4/man4.i386/el.4 | 58 - ja_JP.eucJP/man/man4/man4.i386/ep.4 | 121 - ja_JP.eucJP/man/man4/man4.i386/ex.4 | 84 - ja_JP.eucJP/man/man4/man4.i386/fe.4 | 284 - ja_JP.eucJP/man/man4/man4.i386/ie.4 | 96 - ja_JP.eucJP/man/man4/man4.i386/io.4 | 72 - ja_JP.eucJP/man/man4/man4.i386/lnc.4 | 124 - ja_JP.eucJP/man/man4/man4.i386/mcd.4 | 151 - ja_JP.eucJP/man/man4/man4.i386/npx.4 | 79 - ja_JP.eucJP/man/man4/man4.i386/pcf.4 | 65 - ja_JP.eucJP/man/man4/man4.i386/perfmon.4 | 225 - ja_JP.eucJP/man/man4/man4.i386/pnp.4 | 221 - ja_JP.eucJP/man/man4/man4.i386/scd.4 | 65 - ja_JP.eucJP/man/man4/man4.i386/spkr.4 | 234 - ja_JP.eucJP/man/man4/man4.i386/sr.4 | 119 - ja_JP.eucJP/man/man4/man4.i386/vx.4 | 102 - ja_JP.eucJP/man/man4/man4.i386/wd.4 | 106 - ja_JP.eucJP/man/man8/man8.i386/apm.8 | 159 - ja_JP.eucJP/man/man8/man8.i386/apmd.8 | 294 - share/sgml/freebsd.ent | 6 +- zh/FAQ/FAQ.sgml | 70 - 58 files changed, 61 insertions(+), 29498 deletions(-) delete mode 100644 de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml delete mode 100644 en/handbook/contrib/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/Makefile delete mode 100644 en_US.ISO8859-1/books/arch-handbook/book.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/chapters.ent delete mode 100644 en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/mac.ent delete mode 100644 en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/pci/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/usb/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml delete mode 100644 en_US.ISO8859-1/books/handbook/basics/disk-layout.kil delete mode 100644 en_US.ISO8859-1/books/handbook/basics/example-dir1.dot delete mode 100644 en_US.ISO8859-1/books/handbook/basics/example-dir2.dot delete mode 100644 en_US.ISO8859-1/books/handbook/basics/example-dir3.dot delete mode 100644 en_US.ISO8859-1/books/handbook/basics/example-dir4.dot delete mode 100644 en_US.ISO8859-1/books/handbook/basics/example-dir5.dot delete mode 100644 ja_JP.eucJP/books/handbook/multimedia/Makefile delete mode 100644 ja_JP.eucJP/books/handbook/multimedia/chapter.sgml delete mode 100644 ja_JP.eucJP/man/man1/gtar.1 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/aic.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/apm.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/ar.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/cs.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/cx.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/el.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/ep.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/ex.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/fe.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/ie.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/io.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/lnc.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/mcd.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/npx.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/pcf.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/perfmon.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/pnp.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/scd.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/spkr.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/sr.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/vx.4 delete mode 100644 ja_JP.eucJP/man/man4/man4.i386/wd.4 delete mode 100644 ja_JP.eucJP/man/man8/man8.i386/apm.8 delete mode 100644 ja_JP.eucJP/man/man8/man8.i386/apmd.8 delete mode 100644 zh/FAQ/FAQ.sgml diff --git a/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml b/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml deleted file mode 100644 index 319c00579d..0000000000 --- a/de_DE.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ /dev/null @@ -1,661 +0,0 @@ - - - - - - - Moses - Moore - Von - - - - - - Benedikt - Köhler - Übersetzt von - - - Uwe - Pierau - - - - - Sound - - - Zusammenfassung - - FreeBSD unterstützt viele unterschiedliche Soundkarten, - die Ihnen den Genuss von Highfidelity-Klängen auf Ihrem - Computer ermöglichen. Dazu gehört unter anderem die - Möglichkeit, Tonquellen in den Formaten MPEG Audio Layer 3 - (MP3), WAV, Ogg Vorbis und vielen weiteren Formaten aufzunehmen - und wiederzugeben. Darüber hinaus enthält die FreeBSD - Ports-Sammlung Anwendungen, die Ihnen das Bearbeiten Ihrer - aufgenommenen Tonspuren, das Hinzufügen von Klangeffekten - und die Kontrolle der angeschlossenen MIDI-Geräte - erlauben. - - Nach dem Lesen dieses Kapitels werden Sie wissen: - - Wie Sie Ihre Soundkarte - bestimmen. - Wie Sie Ihr System so einstellen, dass die - Soundkarte richtig erkannt wird. - Einige Methoden und Beispielanwendungen, mit - denen Sie das korrekte Funktionieren Ihrer Soundkarte - überprüfen können. - Wie Sie Fehler in Ihren - Soundkarten-Einstellungen finden. - Wie Sie MP3s wiedergeben und - erzeugen. - Wie Sie CD-Tonspuren in Dateien - rippen. - - - Bevor Sie dieses Kapitel leben, sollten Sie: - - - Wissen, wie Sie einen neuen Kernel - konfigurieren und installieren (). - - - - - Bestimmen des korrekten Geräts - - PCI - ISA - Soundkarten - Zunächst sollten Sie in Erfahrung bringen, welches - Modell Ihrer Soundkarte Sie haben, welchen Chip sie benutzt und - ob es sich um eine PCI- oder ISA-Karte handelt. FreeBSD - unterstützt eine ganze Reihe sowohl von PCI- als auch von - ISA-Karten. Wenn Ihre Soundkarte in der folgenden Liste nicht - auftaucht, konsultieren Sie die &man.pcm.4; Manualpage. Diese - Liste ist zwar nicht vollständig, deckt jedoch einige der - verbreitetsten Karten ab. - - - - Crystal 4237, 4236, 4232, 4231 - - - - Yamaha OPL-SAx - - - - OPTi931 - - - - Ensoniq AudioPCI 1370/1371 - - - - ESS Solo-1/1E - - - - NeoMagic 256AV/ZX - - - - Sound Blaster Pro, 16, 32, AWE64, AWE128, Live - - - - Creative ViBRA16 - - - - Advanced Asound 100, 110, and Logic ALS120 - - - - ES 1868, 1869, 1879, 1888 - - - - Gravis UltraSound - - - - Aureal Vortex 1 or 2 - - - - - Kernel - Konfiguration - - - Um Ihre Soundkarte benutzen zu können, müssen Sie - den richtigen Gerätetreiber laden. Dafür gibt es mehrere - Möglichkeiten: Am einfachsten ist es, mit &man.kldload.8; das - entsprechende Kernel-Modul für Ihre Soundkarte zu laden. Sie - können aber auch die Unterstützung Ihrer Soundkarte - statisch in den Kernel hineinkompilieren. Der folgende Abschnitt - erklärt diese Methode. Weitere Informationen über das - Kompilieren eines Kernels erhalten sie in dem Kapitel Kernelkonfiguration. - - - Creative, Advance und ESS Soundkarten - - Für jede dieser Karten fügen Sie die folgende Zeile - zu Ihrer Kernelkonfiguration hinzu: - - device pcm - - ISA-Karten benötigen zusätzlich noch die - Zeile: - - device sbc - - Nicht-PnP fähige ISA-Karten benötigen die Zeilen: - - device pcm -device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 - - Dies sind die - Voreinstellungen. Sie werden unter Umständen den IRQ oder - andere Einstellungen anpassen müssen. In der &man.sbc.4; - Manualpage finden Sie weitere Informationen dazu. - - - Die Karte Sound Blaster Live wird unter FreeBSD 4.0 - nicht unterstützt. Dazu benötigen Sie einen Patch, - der in diesem Dokument nicht behandelt wird. Es ist deshalb - empfehlenswert, dass Sie in diesem Fall Ihr System auf den - neuesten -STABLE Stand aktualisieren, bevor Sie diese Karte - benutzen können. - - - - - Gravis UltraSound Karten - - Eine PnP ISA-Karte benötigt die folgenden Zeilen in der - Kernelkonfiguration: - - device pcm -device gusc - - Wenn Sie eine nicht-PnP fähige ISA-Karte besitzen, - fügen Sie die folgenden Zeilen ein: - - device pcm -device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13 - - Es kann sein, dass Sie den - IRQ oder andere Einstellungen Ihrer Karte anpassen - müssen. Lesen Sie dazu die &man.gusc.4; Manualpage - für weitere Informationen. - - - - Crystal Soundkarten - - In der Kernelkonfiguration geben Sie für Crystal Karten - die beiden folgenden Zeilen an: - - device pcm -device csa - - - - Allgemeine Unterstützung - - Für PnP ISA- oder PCI-Karten fügen Sie die folgende - Zeile zu Ihrer Kernelkonfiguration hinzu: - - device pcm - - Wenn Sie eine nicht-PnP ISA-Karte besitzen, die keinen - Bridge-Treiber hat, geben Sie zusätzlich die folgende Zeile - an: - - device pcm0 at isa? irq 10 drq 1 flags 0x0 - - Ändern Sie den IRQ oder - andere Einstellungen so, dass sie Ihrer Soundkarte - entsprechen. - - - - Onboard Sound - - Einige Systeme besitzen direkt auf dem Motherboard - eingebaute Soundgeräte. Diese benötigen die folgende - Angabe in Ihrer Kernelkonfiguration: - - options PNPBIOS - - - - - Erstellen und Testen der Device Nodes - - Device Node - Gerätedatei - Nach einem Neustart loggen Sie sich ein und geben - dmesg | grep pcm ein. Sie sollten etwas wie das - folgende sehen: - - &prompt.root; dmesg | grep pcm -pcm0: <SB16 DSP 4.11> on sbc0 - - Die Ausgabe Ihres Systems kann anders aussehen. Erscheinen - keine pcm Geräte, dann ist zuvor - ein Fehler aufgetreten. Wenn das passiert, schauen Sie sich Ihre - Kernelkonfiguration noch einmal an und vergewissern Sie sich, - dass Sie den richtigen Treiber gewählt haben. Weitere - Hinweise zur Fehlersuche gibt . - - Ergab der vorige Befehl pcm0 als - Ausgabe, dann müssen Sie folgendes als root - ausführen: - - &prompt.root; cd /dev -&prompt.root; sh MAKEDEV snd0 - - Wenn auf den vorigen Befehl pcm1 - als Ausgabe erschienen ist, dann müssen Sie dieselben - Befehle ausführen, nur dass Sie - snd0 durch - snd1 ersetzen. - - - Die obigen Kommandos legen kein - /dev/snd Device an. - - - Der Befehl MAKEDEV erzeugt eine Gruppe - von Device Nodes, darunter: - - - - - - Device - Beschreibung - - - - - - /dev/audio - SPARC-compatible audio device - - - - /dev/dsp - Digitized voice device - - - - /dev/dspW - /dev/dsp-ähnliches - Device mit 16 bits pro Sample - - - - /dev/midi - Raw midi access device - - - - /dev/mixer - Control port mixer device - - - - /dev/music - Level 2 sequencer interface - - - - /dev/sequencer - Sequencer device - - - - /dev/pss - Programmable device interface - - - - - - Wenn alles geklappt hat, haben Sie jetzt eine - funktionierende Soundkarte. Nun können Sie eine Anwendung - wie audio/mpg123 installieren, - um Audiodateien anhören zu können. - - - Häufige Probleme - - - - - - Fehler - Lösung - - - Device Node - Gerätedatei - - - - unsupported subdevice XX - Ein oder mehrere Device Nodes wurden nicht - korrekt angelegt. Wiederholen Sie die oben angegebenen - Schritte. - - - I/O port - - sb_dspwr(XX) timed out - Der I/O Port ist nicht korrekt angegeben. - - - IRQ - - bad irq XX - Der IRQ ist falsch angegeben. Stellen Sie - sicher, dass der angegebene IRQ mit dem Sound IRQ - übereinstimmt. - - - - xxx: gus pcm not attached, out of - memory - Es ist nicht genug Speicher verfügbar, - um das Gerät betreiben zu können. - - - DSP - - xxx: can't open /dev/dsp! - Überprüfen Sie mit fstat | - grep dsp ob eine andere Anwendung das - Gerät geöffnet hat. Häufige - Störenfriede sind esound - oder die Sound-Unterstützung von - KDE. - - - - - - - - - - - - Chern - Lee - Ein Beitrag von - - - - - - Benedikt - Köhler - Übersetzt von - - - - - MP3 Audio - - MP3 (MPEG Layer 3 Audio) ermöglicht eine - Klangwiedergabe in CD-ähnlicher Qualität, was Sie sich - auf Ihrem FreeBSD Rechner nicht entgehen lassen sollten. - - - MP3-Player - - XMMS (X Multimedia System) ist - bei weitem der beliebteste XFree86 MP3-Player. - WinAmp-Skins können auch mit - XMMS genutzt werden, da die - Benutzerschnittstelle fast identisch mit der von Nullsofts - WinAmp ist. Daneben - unterstützt XMMS auch eigene - Plugins. - - XMMS kann als - audio/xmms Port oder Package installiert - werden. - - Die Benutzerschnittstelle von - XMMS ist leicht zu erlernen und - beinhaltet eine Playlist, einen graphischen Equalizer und - vieles mehr. Diejenigen, die mit WinAmp vertraut sind, werden - XMMS sehr leicht zu benutzen - finden. - - Der Port audio/mpg123 ist - ein alternativer, kommandozeilenorientierter MP3-Player. - - mpg123 kann ausgeführt - werden, in dem man das zu benutzende Sound Device und die - abzuspielende MP3-Datei in der Kommandozeile wie unten - angibt: - - &prompt.root; mpg123 -a /dev/dsp1.0 Foobar-GreatestHits.mp3 -High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. -Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. -Uses code from various people. See 'README' for more! -THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! - - - - - -Playing MPEG stream from BT - Foobar-GreastHits.mp3 ... -MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo - - - /dev/dsp1.0 sollten Sie dabei mit dem - dsp-Device Ihres Systems ersetzen. - - - - CD-Audio Tracks rippen - - Bevor man eine ganze CD oder einen CD-Track in das - MP3-Format umwandeln kann, müssen die Audiodaten von der - CD auf die Festplatte gerippt werden. Dabei werden die CDDA - (CD Digital Audio) Rohdaten in WAV-Dateien kopiert. - - Die Anwendung cdda2wav die in dem - sysutils/cdrtools Paket enthalten - ist, kann zum Rippen der Audiodaten und anderen Informationen von CDs - genutzt werden. - - Wenn die Audio CD in dem Laufwerk liegt, können Sie - mit folgendem Befehl (als root) eine - ganze CD in einzelne WAV-Dateien (eine Datei für jeden - Track) rippen: - - &prompt.root; cdda2wav -D 0,1,0 -B - - Der Schalter bezieht sich auf - das SCSI Device 0,1,0, dass sich aus - dem Ergebnis des Befehls cdrecord -scanbus - ergibt. - - Um einzelne Tracks zu rippen, benutzen Sie den - Schalter wie folgt: - - &prompt.root; cdda2wav -D 0,1,0 -t 7 - - Dieses Beispiel rippt den siebten Track der Audio - CD-ROM. Um mehrere Tracks zu rippen, zum Beispiel die Tracks - eins bis sieben, können Sie wie folgt einen Bereich - angeben: - - &prompt.root; cdda2wav -D 0,1,0 -t 1+7 - - cdda2wav unterstützt auch ATAPI - (IDE) CD-ROM Laufwerke. Wenn Sie ein IDE Laufwerk benutzen, geben - Sie beim Aufruf von cdda2wav den - Gerätenamen anstelle der SCSI Gerätenummern an. Um den - siebten Track eines IDE Laufwerkes zu rippen, benutzen Sie das - folgende Kommando: - - &prompt.root; cdda2wav -D /dev/acd0a -t 7 - - - - MP3-Dateien kodieren - - Gegenwärtig ist Lame der - meistbenutzte MP3-Encoder. Lame - finden Sie unter audio/lame im - Ports-Verzeichnis. - - Benutzen Sie die WAV-Dateien, die sie von CD gerippt - haben, und wandeln sie mit dem folgenden Befehl die Datei - audio01.wav in - audio01.mp3 um: - - &prompt.root; lame -h -b 128 \ ---tt "Foo Liedtitel" \ ---ta "FooBar Künstler" \ ---tl "FooBar Album" \ ---ty "2001" \ ---tc "Geripped und kodiert von Foo" \ ---tg "Musikrichtung" \ -audio01.wav audio01.mp3 - - 128 kbits ist die gewöhnliche MP3 Bitrate. Viele - bevorzugen mit 160 oder 192 kbits eine höhere Qualität. Je - höher die Bitrate ist, desto mehr Speicherplatz - benötigt die resultierende MP3-Datei, allerdings wird die - Qualität dadurch auch besser. Der Schalter - verwendet den higher quality but a - little slower (höhere Qualität, aber etwas - langsamer) Modus. Die Schalter, die mit - beginnen, sind ID3-Tags, die in der Regel - Informationen über das Lied enthalten und in die - MP3-Datei eingebettet sind. Weitere Optionen können in - der Manualpage von Lame nachgelesen - werden. - - - - MP3-Dateien dekodieren - - Um aus MP3-Dateien eine Audio CD zu erstellen, müssen - diese in ein nicht komprimiertes WAV-Format umgewandelt - werden. Sowohl XMMS als auch - mpg123 unterstützen die Ausgabe - der MP3-Dateien in unkomprimierte Dateiformate. - - Dekodieren mit XMMS: - - - - Starten Sie XMMS. - - - - Klicken Sie mit der rechten Maustaste, um das - XMMS-Menu zu öffnen. - - - - Wählen Sie Preference im - Untermenü Options. - - - - Ändern Sie das Output-Plugin in Disk - Writer Plugin. - - - - Drücken Sie Configure. - - - - Geben Sie ein Verzeichnis ein (oder wählen Sie - browse), in das Sie die unkomprimierte Datei schreiben - wollen. - - - - Laden Sie die MP3-Datei wie gewohnt in - XMMS mit einer Lautstärke - von 100% und einem abgeschalteten EQ. - - - - Drücken Sie Play und es wird - so aussehen, als spiele XMMS - die MP3-Datei ab, aber keine Musik ist zu hören. Der - Player überspielt die MP3-Datei in eine Datei. - - - - Vergessen Sie nicht, das Output Plugin wieder in den - Ausgangszustand zurückzusetzen um wieder MP3-Dateien - anhören zu können. - - - - Mit mpg123 nach stdout schreiben: - - - - Geben Sie mpg123 -s - audio01.mp3 > audio01.pcm - ein - - - - XMMS schreibt die Datei in dem - WAV-Formal während mpg123 die - MP3-Datei in rohe PCM Audiodaten umwandelt. Beide Formate - können von cdrecord oder - burncd verwendet werden, um Audio - CDs zu schreiben. - - Lesen Sie in diesem Handbuch, - um mehr Informationen zur Benutzung von CD-Brennern mit FreeBSD zu - erhalten. - - - - - - 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 @@ - - - - Contributing to FreeBSD - - Contributed by &a.jkh;. - - 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 - relies 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! - - 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. - - 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 TODO 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! - - 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. - - - What Is Needed - - The following list of tasks and sub-projects represents something of - an amalgam of the various core team TODO 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? - - - High priority tasks - - The following tasks are considered to be urgent, usually because - they represent something that is badly broken or sorely needed: - - - - 3-stage boot issues. Overall coordination: &a.hackers; - - - - Do WinNT compatible drive tagging so that the 3rd stage - can provide an accurate mapping of BIOS geometries for - disks. - - - - - - Filesystem problems. Overall coordination: &a.fs; - - - - Fix the MSDOS file system. - - - - Clean up and document the nullfs filesystem code. - Coordinator: &a.eivind; - - - - Fix the union file system. Coordinator: &a.dg; - - - - - - Implement Int13 vm86 disk driver. Coordinator: - &a.hackers; - - - - New bus architecture. Coordinator: &a.newbus; - - - - Port existing ISA drivers to new architecture. - - - - Move all interrupt-management code to appropriate parts of - the bus drivers. - - - - Port PCI subsystem to new architecture. Coordinator: - &a.dfr; - - - - 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. - - - - Resolve the probe/attach priority issue once and for - all. - - - - Move any remaining buses over to the new - architecture. - - - - - - Kernel issues. Overall coordination: &a.hackers; - - - - Add more pro-active security infrastructure. Overall - coordination: &a.security; - - - - 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; - - - - Make the entire kernel use suser() - instead of comparing to 0. It is presently using about half - of each. Coordinator: &a.eivind; - - - - 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; - - - - 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. - - - - 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; - - - - Add authorization infrastructure to the kernel, to allow - different authorization policies. Part of this could be done - by modifying suser(). Coordinator: - &a.eivind; - - - - Add code to the NFS layer so that you cannot - chdir("..") out of an NFS partition. E.g., - /usr is a UFS partition with - /usr/src NFS exported. Now it is - possible to use the NFS filehandle for - /usr/src to get access to - /usr. - - - - - - - - Medium priority tasks - - The following tasks need to be done, but not with any particular - urgency: - - - - Full KLD based driver support/Configuration Manager. - - - - 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. - - - - - - PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk; - - - - Documentation! - - - - Reliable operation of the pcic driver (needs - testing). - - - - Recognizer and handler for sio.c - (mostly done). - - - - Recognizer and handler for ed.c - (mostly done). - - - - Recognizer and handler for ep.c - (mostly done). - - - - User-mode recognizer and handler (partially done). - - - - - - Advanced Power Management. Coordinators: &a.msmith; and - &a.phk; - - - - APM sub-driver (mostly done). - - - - IDE/ATA disk sub-driver (partially done). - - - - syscons/pcvt sub-driver. - - - - Integration with the PCMCIA/PCCARD drivers - (suspend/resume). - - - - - - - - Low priority tasks - - 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: - - The first N items are from Terry Lambert - terry@lambert.org - - - - 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. - - - - An "upgrade system" option that works on Linux boxes instead - of just previous rev FreeBSD boxes. - - - - Symmetric Multiprocessing with kernel preemption (requires - kernel preemption). - - - - 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). - - - - - - Smaller tasks - - 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. - - - - If you run FreeBSD-current and have a good Internet - connection, there is a machine current.FreeBSD.org 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. - - - - 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. - - - - 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). - - - - 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. - - - - 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. - - - - 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. - - - - Move contributed software to src/contrib - in the source tree. - - - - Make sure code in src/contrib is up to - date. - - - - Look for year 2000 bugs (and fix any you find!) - - - - Build the source tree (or just part of it) with extra warnings - enabled and clean up the warnings. - - - - Fix warnings for ports which do deprecated things like using - gets() or including malloc.h. - - - - 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) - - - - Suggest further tasks for this list! - - - - - - Work through the PR database - - The FreeBSD PR - list 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. - - 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. - - - - - How to Contribute - - Contributions to the system generally fall into one or more of the - following 6 categories: - - - Bug reports and general commentary - - An idea or suggestion of general technical - interest should be mailed to the &a.hackers;. Likewise, people with - an interest in such things (and a tolerance for a - high volume of mail!) may subscribe to the - hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information - about this and other mailing lists. - - If you find a bug or are submitting a specific change, please - report it using the &man.send-pr.1; program or its WEB-based - equivalent. Try to fill-in each field of the bug report. - Unless they exceed 65KB, include any patches directly in the report. - When including patches, do not 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 ftp.FreeBSD.org:/pub/FreeBSD/incoming/. - - 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 - bug-followup@FreeBSD.org. Use the number as the - message subject, e.g. "Re: kern/3377". Additional - information for any bug report should be submitted this way. - - 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;. - - - - Changes to the documentation - - Changes to the documentation are overseen by the &a.doc;. Send - submissions and changes (even small ones are welcome!) using - send-pr as described in Bug Reports and General - Commentary. - - - - Changes to existing source code - - 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 Staying current with FreeBSD for more - information about getting and using FreeBSD-current. - - 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. - - 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: - - - &prompt.user; diff -c oldfile newfile - - or - - &prompt.user; diff -c -r olddir newdir - - 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. - - 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 Bug Reports and General Commentary. - Do not 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. - - If you feel it appropriate (e.g. you have added, deleted, or - renamed files), bundle your changes into a tar file - and run the &man.uuencode.1; program on it. Shar archives are also - welcome. - - 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 very busy and so you - should only send mail to them where it is truly necessary. - - Please refer to man 9 intro and man 9 - style for some information on coding style. We would - appreciate it if you were at least aware of this information before - submitting code. - - - - New code or major value-added packages - - 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 ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming. - - When working with large amounts of code, the touchy subject of - copyrights also invariably comes up. Acceptable copyrights for code - included in FreeBSD are: - - - - 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. - - - - 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 - /sys/gnu or - /usr/src/gnu, and is therefore easily - identifiable to anyone for whom the GPL presents a problem. - - - - 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. - - 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 %% - with the appropriate information. - - -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$ - - For your convenience, a copy of this text can be found in - /usr/share/examples/etc/bsd-style-copyright. - - - - Money, Hardware or Internet access - - 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. - - - <anchor id="donations">Donating funds - - 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. - - 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. - - Please make any checks payable to FreeBSD, Inc., sent in care of - the following address: - -
- FreeBSD, Inc. - c/o Jordan Hubbard - 4041 Pike Lane, Suite F - Concord - CA, 94520 -
- - (currently using the Walnut Creek CDROM address until a PO box - can be opened) - - Wire transfers may also be sent directly to: - -
- Bank Of America - Concord Main Office - P.O. Box 37176 - San Francisco - CA, 94137-5176 - - Routing #: 121-000-358 - Account #: 01411-07441 (FreeBSD, Inc.) -
- - Any correspondence related to donations should be sent to &a.jkh, - either via email or to the FreeBSD, Inc. postal address given above. - - - If you do not wish to be listed in our donors section, please specify this when - making your donation. Thanks! - - - - Donating hardware - - Donations of hardware in any of the 3 following categories are - also gladly accepted by the FreeBSD Project: - - - - General purpose hardware such as disk drives, memory or - complete systems should be sent to the FreeBSD, Inc. address - listed in the donating funds - section. - - - - 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. - - - - 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. - - - - - - Donating Internet access - - We can always use new mirror sites for FTP, WWW or - cvsup. If you would like to be such a mirror, - please contact the FreeBSD project administrators - admin@FreeBSD.org for more information. - - - - - - Donors Gallery - - The FreeBSD Project is indebted to the following donors and would - like to publically thank them here! - - - - Contributors to the central server - project: - - The following individuals and businesses made it possible for - the FreeBSD Project to build a new central server machine to - eventually replace freefall.FreeBSD.org - by donating the following items: - - - - &a.mbarkah and his employer, - Hemisphere Online, donated a Pentium Pro - (P6) 200Mhz CPU - - - - ASA - Computers donated a Tyan 1662 - motherboard. - - - - Joe McGuckin joe@via.net of ViaNet Communications donated - a Kingston ethernet controller. - - - - Jack O'Neill jack@diamond.xtalwind.net - donated an NCR 53C875 SCSI controller - card. - - - - Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated - 128MB of memory, a 4 Gb disk - drive and the case. - - - - - - Direct funding: - - The following individuals and businesses have generously - contributed direct funding to the project: - - - - Annelise Anderson - ANDRSN@HOOVER.STANFORD.EDU - - - - &a.dillon - - - - Epilogue Technology - Corporation - - - - &a.sef - - - - Don Scott Wilde - - - - Gianmarco Giovannelli - gmarco@masternet.it - - - - Josef C. Grosch joeg@truenorth.org - - - - Robert T. Morris - - - - &a.chuckr - - - - Kenneth P. Stox ken@stox.sa.enteract.com of - Imaginary Landscape, - LLC. - - - - Dmitry S. Kohmanyuk dk@dog.farm.org - - - - Laser5 of Japan - (a portion of the profits from sales of their various FreeBSD - CD-ROMs. - - - - Fuki Shuppan - Publishing Co. donated a portion of their profits from - Hajimete no FreeBSD (FreeBSD, Getting - started) to the FreeBSD and XFree86 projects. - - - - ASCII Corp. - donated a portion of their profits from several FreeBSD-related - books to the FreeBSD project. - - - - Yokogawa Electric - Corp has generously donated significant funding to the - FreeBSD project. - - - - BuffNET - - - - Pacific - Solutions - - - - Siemens AG - via Andre - Albsmeier - - - - Chris Silva - - - - - - - - Hardware contributors: - - The following individuals and businesses have generously - contributed hardware for testing and device driver - development/support: - - - - 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. - - - - TRW Financial Systems, Inc. provided 130 PCs, three 68 GB - fileservers, twelve Ethernets, two routers and an ATM switch for - debugging the diskless code. - - - - Dermot McDonnell donated the Toshiba XM3401B CDROM drive - currently used in freefall. - - - - &a.chuck; contributed his floppy tape streamer for - experimental work. - - - - Larry Altneu larry@ALR.COM, and &a.wilko;, - provided Wangtek and Archive QIC-02 tape drives in order to - improve the wt driver. - - - - Ernst Winter ewinter@lobo.muc.de contributed - a 2.88 MB floppy drive to the project. This will hopefully - increase the pressure for rewriting the floppy disk driver. - ;-) - - - - Tekram - Technologies 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 ftp://ftp.tekram.com/scsi/FreeBSD. - - - - Larry M. Augustin 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! - - - - Christoph Kukulies kuku@FreeBSD.org donated - an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver - development. - - - - - - Special contributors: - - - - Walnut Creek CDROM - has donated almost more than we can say (see the history document for more details). - In particular, we would like to thank them for the original - hardware used for freefall.FreeBSD.org, our primary - development machine, and for thud.FreeBSD.org, 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. - - - - The interface - business GmbH, Dresden 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... - - - - Berkeley Software Design, - Inc. has contributed their DOS emulator code to the - remaining BSD world, which is used in the - doscmd command. - - - - - - - - Core Team Alumni - - 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. - - In rough chronological order: - - - - &a.guido (1995 - 1999) - - - - &a.dyson (1993 - 1998) - - - - &a.nate (1992 - 1996) - - - - &a.rgrimes (1992 - 1995) - - - - Andreas Schulz (1992 - 1995) - - - - &a.csgr (1993 - 1995) - - - - &a.paul (1992 - 1995) - - - - &a.smace (1993 - 1994) - - - - Andrew Moore (1993 - 1994) - - - - Christoph Robitschko (1993 - 1994) - - - - J. T. Conklin (1992 - 1993) - - - - - - Derived Software Contributors - - 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. - - 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. - - - - Additional FreeBSD Contributors - - (in alphabetical order by first name): - - - - ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp - - - - AMAGAI Yoshiji amagai@nue.org - - - - Aaron Bornstein aaronb@j51.com - - - - Aaron Smith aaron@mutex.org - - - - Achim Patzner ap@noses.com - - - - Ada T Lim ada@bsd.org - - - - Adam Baran badam@mw.mil.pl - - - - Adam Glass glass@postgres.berkeley.edu - - - - Adam McDougall mcdouga9@egr.msu.edu - - - - Adrian Colley aecolley@ois.ie - - - - Adrian Hall adrian@ibmpcug.co.uk - - - - Adrian Mariano adrian@cam.cornell.edu - - - - Adrian Steinmann ast@marabu.ch - - - - Adam Strohl troll@digitalspark.net - - - - Adrian T. Filipi-Martin - atf3r@agate.cs.virginia.edu - - - - Ajit Thyagarajan unknown - - - - Akio Morita - amorita@meadow.scphys.kyoto-u.ac.jp - - - - Akira SAWADA unknown - - - - Akira Watanabe - akira@myaw.ei.meisei-u.ac.jp - - - - Akito Fujita fujita@zoo.ncl.omron.co.jp - - - - Alain Kalker - A.C.P.M.Kalker@student.utwente.nl - - - - Alan Bawden alan@curry.epilogue.com - - - - Alec Wolman wolman@cs.washington.edu - - - - Aled Morris aledm@routers.co.uk - - - - Alex garbanzo@hooked.net - - - - Alex D. Chen - dhchen@Canvas.dorm7.nccu.edu.tw - - - - Alex G. Bulushev bag@demos.su - - - - Alex Le Heux alexlh@funk.org - - - - Alex Perel veers@disturbed.net - - - - Alexander B. Povolotsky tarkhil@mgt.msk.ru - - - - Alexander Leidinger - netchild@wurzelausix.CS.Uni-SB.DE - - - - Alexander Langer alex@cichlids.com - - - - Alexandre Snarskii snar@paranoia.ru - - - - Alistair G. Crooks agc@uts.amdahl.com - - - - Allan Saddi asaddi@philosophysw.com - - - - Allen Campbell allenc@verinet.com - - - - Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp - - - - Amancio Hasty hasty@star-gate.com - - - - Amir Farah amir@comtrol.com - - - - Amy Baron amee@beer.org - - - - Anatoly A. Orehovsky tolik@mpeks.tomsk.su - - - - Anatoly Vorobey mellon@pobox.com - - - - Anders Nordby nickerne@nome.no - - - - Anders Thulin Anders.X.Thulin@telia.se - - - - Andras Olah olah@cs.utwente.nl - - - - Andre Albsmeier - Andre.Albsmeier@mchp.siemens.de - - - - Andre Oppermann andre@pipeline.ch - - - - Andreas Haakh ah@alman.robin.de - - - - Andreas Kohout shanee@rabbit.augusta.de - - - - Andreas Lohr andreas@marvin.RoBIN.de - - - - Andreas Schulz unknown - - - - Andreas Wetzel mickey@deadline.snafu.de - - - - Andreas Wrede andreas@planix.com - - - - Andres Vega Garcia unknown - - - - Andrew Atrens atreand@statcan.ca - - - - Andrew Boothman andrew@cream.org - - - - Andrew Gillham gillham@andrews.edu - - - - Andrew Gordon andrew.gordon@net-tel.co.uk - - - - Andrew Herbert andrew@werple.apana.org.au - - - - Andrew J. Korty ajk@purdue.edu - - - - Andrew L. Moore alm@mclink.com - - - - Andrew McRae amcrae@cisco.com - - - - Andrew Stevenson andrew@ugh.net.au - - - - Andrew Timonin tim@pool1.convey.ru - - - - Andrew V. Stesin stesin@elvisti.kiev.ua - - - - Andrew Webster awebster@dataradio.com - - - - Andrey Zakhvatov andy@icc.surw.chel.su - - - - Andy Farkas andyf@speednet.com.au - - - - Andy Valencia ajv@csd.mot.com - - - - Andy Whitcroft andy@sarc.city.ac.uk - - - - Angelo Turetta ATuretta@stylo.it - - - - Anthony C. Chavez magus@xmission.com - - - - Anthony Yee-Hang Chan yeehang@netcom.com - - - - Anton Berezin tobez@plab.ku.dk - - - - Antti Kaipila anttik@iki.fi - - - - Are Bryne are.bryne@communique.no - - - - Ari Suutari ari@suutari.iki.fi - - - - Arjan de Vet devet@IAEhv.nl - - - - Arne Henrik Juul arnej@Lise.Unit.NO - - - - Assar Westerlund assar@sics.se - - - - Atsushi Furuta furuta@sra.co.jp - - - - Atsushi Murai amurai@spec.co.jp - - - - Bakul Shah bvs@bitblocks.com - - - - Barry Bierbauch pivrnec@vszbr.cz - - - - Barry Lustig barry@ictv.com - - - - Ben Hutchinson benhutch@xfiles.org.uk - - - - Ben Jackson unknown - - - - Ben Smithurst ben@scientia.demon.co.uk - - - - Ben Walter bwalter@itachi.swcp.com - - - - Benjamin Lewis bhlewis@gte.net - - - - Bernd Rosauer br@schiele-ct.de - - - - Bill Kish kish@osf.org - - - - Bill Trost trost@cloud.rain.com - - - - Blaz Zupan blaz@amis.net - - - - Bob Van Valzah Bob@whitebarn.com - - - - Bob Willcox bob@luke.pmr.com - - - - Boris Staeblow balu@dva.in-berlin.de - - - - Boyd R. Faulkner faulkner@asgard.bga.com - - - - Brad Karp karp@eecs.harvard.edu - - - - Bradley Dunn bradley@dunn.org - - - - Brandon Fosdick bfoz@glue.umd.edu - - - - Brandon Gillespie brandon@roguetrader.com - - - - &a.wlloyd - - - - Bob Wilcox bob@obiwan.uucp - - - - Boyd Faulkner faulkner@mpd.tandem.com - - - - Brent J. Nordquist bjn@visi.com - - - - Brett Lymn blymn@mulga.awadi.com.AU - - - - Brett Taylor - brett@peloton.physics.montana.edu - - - - Brian Campbell brianc@pobox.com - - - - Brian Clapper bmc@willscreek.com - - - - Brian Cully shmit@kublai.com - - - - Brian Handy - handy@lambic.space.lockheed.com - - - - Brian Litzinger brian@MediaCity.com - - - - Brian McGovern bmcgover@cisco.com - - - - Brian Moore ziff@houdini.eecs.umich.edu - - - - Brian R. Haug haug@conterra.com - - - - Brian Tao taob@risc.org - - - - Brion Moss brion@queeg.com - - - - Bruce A. Mah bmah@ca.sandia.gov - - - - Bruce Albrecht bruce@zuhause.mn.org - - - - Bruce Gingery bgingery@gtcs.com - - - - Bruce J. Keeler loodvrij@gridpoint.com - - - - Bruce Murphy packrat@iinet.net.au - - - - Bruce Walter walter@fortean.com - - - - Carey Jones mcj@acquiesce.org - - - - Carl Fongheiser cmf@netins.net - - - - Carl Mascott cmascott@world.std.com - - - - Casper casper@acc.am - - - - Castor Fu castor@geocast.com - - - - Cejka Rudolf cejkar@dcse.fee.vutbr.cz - - - - Chain Lee chain@110.net - - - - Charles Hannum mycroft@ai.mit.edu - - - - Charles Henrich henrich@msu.edu - - - - Charles Mott cmott@srv.net - - - - Charles Owens owensc@enc.edu - - - - Chet Ramey chet@odin.INS.CWRU.Edu - - - - Chia-liang Kao clkao@CirX.ORG - - - - Chiharu Shibata chi@bd.mbn.or.jp - - - - Chip Norkus unknown - - - - Choi Jun Ho junker@jazz.snu.ac.kr - - - - Chris Csanady cc@tarsier.ca.sandia.gov - - - - Chris Dabrowski chris@vader.org - - - - Chris Dillon cdillon@wolves.k12.mo.us - - - - Chris Shenton - cshenton@angst.it.hq.nasa.gov - - - - Chris Stenton jacs@gnome.co.uk - - - - Chris Timmons skynyrd@opus.cts.cwu.edu - - - - Chris Torek torek@ee.lbl.gov - - - - Christian Gusenbauer - cg@fimp01.fim.uni-linz.ac.at - - - - Christian Haury Christian.Haury@sagem.fr - - - - Christian Weisgerber - naddy@bigeye.rhein-neckar.de - - - - Christoph P. Kukulies kuku@FreeBSD.org - - - - Christoph Robitschko - chmr@edvz.tu-graz.ac.at - - - - Christoph Weber-Fahr - wefa@callcenter.systemhaus.net - - - - Christopher G. Demetriou - cgd@postgres.berkeley.edu - - - - Christopher T. Johnson - cjohnson@neunacht.netgsi.com - - - - Chrisy Luke chrisy@flix.net - - - - Chuck Hein chein@cisco.com - - - - Clive Lin clive@CiRX.ORG - - - - Colman Reilly careilly@tcd.ie - - - - Conrad Sabatier conrads@neosoft.com - - - - Coranth Gryphon gryphon@healer.com - - - - Cornelis van der Laan - nils@guru.ims.uni-stuttgart.de - - - - Cove Schneider cove@brazil.nbn.com - - - - Craig Leres leres@ee.lbl.gov - - - - Craig Loomis unknown - - - - Craig Metz cmetz@inner.net - - - - Craig Spannring cts@internetcds.com - - - - Craig Struble cstruble@vt.edu - - - - Cristian Ferretti cfs@riemann.mat.puc.cl - - - - Curt Mayer curt@toad.com - - - - Cy Schubert cschuber@uumail.gov.bc.ca - - - - DI. Christian Gusenbauer - cg@scotty.edvz.uni-linz.ac.at - - - - Dai Ishijima ishijima@tri.pref.osaka.jp - - - - Damian Hamill damian@cablenet.net - - - - Dan Cross tenser@spitfire.ecsel.psu.edu - - - - Dan Lukes dan@obluda.cz - - - - Dan Nelson dnelson@emsphone.com - - - - Dan Walters hannibal@cyberstation.net - - - - Daniel M. Eischen - deischen@iworks.InterWorks.org - - - - Daniel O'Connor doconnor@gsoft.com.au - - - - Daniel Poirot poirot@aio.jsc.nasa.gov - - - - Daniel Rock rock@cs.uni-sb.de - - - - Danny Egen unknown - - - - Danny J. Zerkel dzerkel@phofarm.com - - - - Darren Reed avalon@coombs.anu.edu.au - - - - Dave Adkins adkin003@tc.umn.edu - - - - Dave Andersen angio@aros.net - - - - Dave Blizzard dblizzar@sprynet.com - - - - Dave Bodenstab imdave@synet.net - - - - Dave Burgess burgess@hrd769.brooks.af.mil - - - - Dave Chapeskie dchapes@ddm.on.ca - - - - Dave Cornejo dave@dogwood.com - - - - Dave Edmondson davided@sco.com - - - - Dave Glowacki dglo@ssec.wisc.edu - - - - Dave Marquardt marquard@austin.ibm.com - - - - Dave Tweten tweten@FreeBSD.org - - - - David A. Adkins adkin003@tc.umn.edu - - - - David A. Bader dbader@umiacs.umd.edu - - - - David Borman dab@bsdi.com - - - - David Dawes dawes@XFree86.org - - - - David Filo filo@yahoo.com - - - - David Holland dholland@eecs.harvard.edu - - - - David Holloway daveh@gwythaint.tamis.com - - - - David Horwitt dhorwitt@ucsd.edu - - - - David Hovemeyer daveho@infocom.com - - - - David Jones dej@qpoint.torfree.net - - - - David Kelly dkelly@tomcat1.tbe.com - - - - David Kulp dkulp@neomorphic.com - - - - David L. Nugent davidn@blaze.net.au - - - - David Leonard d@scry.dstc.edu.au - - - - David Malone dwmalone@maths.tcd.ie - - - - David Muir Sharnoff muir@idiom.com - - - - David S. Miller davem@jenolan.rutgers.edu - - - - David Wolfskill dhw@whistle.com - - - - Dean Gaudet dgaudet@arctic.org - - - - Dean Huxley dean@fsa.ca - - - - Denis Fortin unknown - - - - Dennis Glatting - dennis.glatting@software-munitions.com - - - - Denton Gentry denny1@home.com - - - - Derek Inksetter derek@saidev.com - - - - Dima Sivachenko dima@Chg.RU - - - - Dirk Keunecke dk@panda.rhein-main.de - - - - Dirk Nehrling nerle@pdv.de - - - - Dmitry Khrustalev dima@xyzzy.machaon.ru - - - - Dmitry Kohmanyuk dk@farm.org - - - - Dom Mitchell dom@myrddin.demon.co.uk - - - - Dominik Brettnacher domi@saargate.de - - - - Don Croyle croyle@gelemna.ft-wayne.in.us - - - - &a.whiteside; - - - - Don Morrison dmorrisn@u.washington.edu - - - - Don Yuniskis dgy@rtd.com - - - - Donald Maddox dmaddox@conterra.com - - - - Doug Barton studded@dal.net - - - - Douglas Ambrisko ambrisko@whistle.com - - - - Douglas Carmichael dcarmich@mcs.com - - - - Douglas Crosher dtc@scrooge.ee.swin.oz.au - - - - Drew Derbyshire ahd@kew.com - - - - Duncan Barclay dmlb@ragnet.demon.co.uk - - - - Dustin Sallings dustin@spy.net - - - - Eckart "Isegrim" Hofmann - Isegrim@Wunder-Nett.org - - - - Ed Gold - vegold01@starbase.spd.louisville.edu - - - - Ed Hudson elh@p5.spnet.com - - - - Edward Wang edward@edcom.com - - - - Edwin Groothus edwin@nwm.wan.philips.com - - - - Eiji-usagi-MATSUmoto usagi@clave.gr.jp - - - - ELISA Font Project - - - - Elmar Bartel - bartel@informatik.tu-muenchen.de - - - - Eric A. Griff eagriff@global2000.net - - - - Eric Blood eblood@cs.unr.edu - - - - Eric J. Haug ejh@slustl.slu.edu - - - - Eric J. Schwertfeger eric@cybernut.com - - - - Eric L. Hernes erich@lodgenet.com - - - - Eric P. Scott eps@sirius.com - - - - Eric Sprinkle eric@ennovatenetworks.com - - - - Erich Stefan Boleyn erich@uruk.org - - - - Erik E. Rantapaa rantapaa@math.umn.edu - - - - Erik H. Moe ehm@cris.com - - - - Ernst Winter ewinter@lobo.muc.de - - - - Espen Skoglund espensk@stud.cs.uit.no> - - - - Eugene M. Kim astralblue@usa.net - - - - Eugene Radchenko genie@qsar.chem.msu.su - - - - Evan Champion evanc@synapse.net - - - - Faried Nawaz fn@Hungry.COM - - - - Flemming Jacobsen fj@tfs.com - - - - Fong-Ching Liaw fong@juniper.net - - - - Francis M J Hsieh mjshieh@life.nthu.edu.tw - - - - Frank Bartels knarf@camelot.de - - - - Frank Chen Hsiung Chan - frankch@waru.life.nthu.edu.tw - - - - Frank Durda IV uhclem@nemesis.lonestar.org - - - - Frank MacLachlan fpm@n2.net - - - - Frank Mayhar frank@exit.com - - - - Frank Nobis fn@Radio-do.de - - - - Frank Volf volf@oasis.IAEhv.nl - - - - Frank ten Wolde franky@pinewood.nl - - - - Frank van der Linden frank@fwi.uva.nl - - - - Fred Cawthorne fcawth@jjarray.umn.edu - - - - Fred Gilham gilham@csl.sri.com - - - - Fred Templin templin@erg.sri.com - - - - Frederick Earl Gray fgray@rice.edu - - - - FUJIMOTO Kensaku - fujimoto@oscar.elec.waseda.ac.jp - - - - FUJISHIMA Satsuki k5@respo.or.jp - - - - FURUSAWA Kazuhisa - furusawa@com.cs.osakafu-u.ac.jp - - - - Gabor Kincses gabor@acm.org - - - - Gabor Zahemszky zgabor@CoDe.hu - - - - G. Adam Stanislavadam@whizkidtech.net - - - - Garance A Drosehn gad@eclipse.its.rpi.edu - - - - Gareth McCaughan gjm11@dpmms.cam.ac.uk - - - - Gary A. Browning gab10@griffcd.amdahl.com - - - - Gary Howland gary@hotlava.com - - - - Gary J. garyj@rks32.pcs.dec.com - - - - Gary Kline kline@thought.org - - - - Gaspar Chilingarov nightmar@lemming.acc.am - - - - Gea-Suan Lin gsl@tpts4.seed.net.tw - - - - Geoff Rehmet csgr@alpha.ru.ac.za - - - - Georg Wagner georg.wagner@ubs.com - - - - Gerard Roudier groudier@club-internet.fr - - - - Gianmarco Giovannelli - gmarco@giovannelli.it - - - - Gil Kloepfer Jr. gil@limbic.ssdl.com - - - - Gilad Rom rom_glsa@ein-hashofet.co.il - - - - Ginga Kawaguti - ginga@amalthea.phys.s.u-tokyo.ac.jp - - - - Giles Lean giles@nemeton.com.au - - - - Glen Foster gfoster@gfoster.com - - - - Glenn Johnson gljohns@bellsouth.net - - - - Godmar Back gback@facility.cs.utah.edu - - - - Goran Hammarback goran@astro.uu.se - - - - Gord Matzigkeit gord@enci.ucalgary.ca - - - - Gordon Greeff gvg@uunet.co.za - - - - Graham Wheeler gram@cdsec.com - - - - Greg A. Woods woods@zeus.leitch.com - - - - Greg Ansley gja@ansley.com - - - - Greg Troxel gdt@ir.bbn.com - - - - Greg Ungerer gerg@stallion.oz.au - - - - Gregory Bond gnb@itga.com.au - - - - Gregory D. Moncreaff - moncrg@bt340707.res.ray.com - - - - Guy Harris guy@netapp.com - - - - Guy Helmer ghelmer@cs.iastate.edu - - - - HAMADA Naoki hamada@astec.co.jp - - - - HONDA Yasuhiro - honda@kashio.info.mie-u.ac.jp - - - - HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp - - - - Hannu Savolainen hannu@voxware.pp.fi - - - - Hans Huebner hans@artcom.de - - - - Hans Petter Bieker zerium@webindex.no - - - - Hans Zuidam hans@brandinnovators.com - - - - Harlan Stenn Harlan.Stenn@pfcs.com - - - - Harold Barker hbarker@dsms.com - - - - Havard Eidnes - Havard.Eidnes@runit.sintef.no - - - - Heikki Suonsivu hsu@cs.hut.fi - - - - Heiko W. Rupp unknown - - - - Helmut F. Wirth hfwirth@ping.at - - - - Henrik Vestergaard Draboel - hvd@terry.ping.dk - - - - Herb Peyerl hpeyerl@NetBSD.org - - - - Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp - - - - Hidekazu Kuroki hidekazu@cs.titech.ac.jp - - - - Hideki Yamamoto hyama@acm.org - - - - Hideyuki Suzuki - hideyuki@sat.t.u-tokyo.ac.jp - - - - Hirayama Issei iss@mail.wbs.ne.jp - - - - Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp - - - - Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp - - - - Hironori Ikura hikura@kaisei.org - - - - Hiroshi Nishikawa nis@pluto.dti.ne.jp - - - - Hiroya Tsubakimoto unknown - - - - Holger Veit Holger.Veit@gmd.de - - - - Holm Tiffe holm@geophysik.tu-freiberg.de - - - - Horance Chou - horance@freedom.ie.cycu.edu.tw - - - - Horihiro Kumagai kuma@jp.FreeBSD.org - - - - HOTARU-YA hotaru@tail.net - - - - Hr.Ladavac lada@ws2301.gud.siemens.co.at - - - - Hubert Feyrer hubertf@NetBSD.ORG - - - - Hugh F. Mahon hugh@nsmdserv.cnd.hp.com - - - - Hugh Mahon h_mahon@fc.hp.com - - - - Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw - - - - IMAI Takeshi take-i@ceres.dti.ne.jp - - - - IMAMURA Tomoaki - tomoak-i@is.aist-nara.ac.jp - - - - Ian Dowse iedowse@maths.tcd.ie - - - - Ian Holland ianh@tortuga.com.au - - - - Ian Struble ian@broken.net - - - - Ian Vaudrey i.vaudrey@bigfoot.com - - - - Igor Khasilev igor@jabber.paco.odessa.ua - - - - Igor Roshchin str@giganda.komkon.org - - - - Igor Sviridov siac@ua.net - - - - Igor Vinokurov igor@zynaps.ru - - - - Ikuo Nakagawa ikuo@isl.intec.co.jp - - - - Ilya V. Komarov mur@lynx.ru - - - - Issei Suzuki issei@jp.FreeBSD.org - - - - Itsuro Saito saito@miv.t.u-tokyo.ac.jp - - - - J. Bryant jbryant@argus.flash.net - - - - J. David Lowe lowe@saturn5.com - - - - J. Han hjh@best.com - - - - J. Hawk jhawk@MIT.EDU - - - - J.T. Conklin jtc@cygnus.com - - - - J.T. Jang keith@email.gcn.net.tw - - - - Jack jack@zeus.xtalwind.net - - - - Jacob Bohn Lorensen jacob@jblhome.ping.mk - - - - Jagane D Sundar jagane@netcom.com - - - - Jake Burkholder jake@checker.org - - - - Jake Hamby jehamby@lightside.com - - - - James Clark jjc@jclark.com - - - - James D. Stewart jds@c4systm.com - - - - James Jegers jimj@miller.cs.uwm.edu - - - - James Raynard - fhackers@jraynard.demon.co.uk - - - - James T. Liu jtliu@phlebas.rockefeller.edu - - - - James da Silva jds@cs.umd.edu - - - - Jan Conard - charly@fachschaften.tu-muenchen.de - - - - Jan Koum jkb@FreeBSD.org - - - - Janick Taillandier - Janick.Taillandier@ratp.fr - - - - Janusz Kokot janek@gaja.ipan.lublin.pl - - - - Jarle Greipsland jarle@idt.unit.no - - - - Jason Garman init@risen.org - - - - Jason Thorpe thorpej@NetBSD.org - - - - Jason Wright jason@OpenBSD.org - - - - Jason Young - doogie@forbidden-donut.anet-stl.com - - - - Javier Martin Rueda jmrueda@diatel.upm.es - - - - Jay Fenlason hack@datacube.com - - - - Jaye Mathisen mrcpu@cdsnet.net - - - - Jeff Bartig jeffb@doit.wisc.edu - - - - Jeff Forys jeff@forys.cranbury.nj.us - - - - Jeff Kletsky Jeff@Wagsky.com - - - - Jeffrey Evans evans@scnc.k12.mi.us - - - - Jeffrey Wheat jeff@cetlink.net - - - - Jens Schweikhardt schweikh@noc.dfn.d - - - - Jeremy Allison jallison@whistle.com - - - - Jeremy Chatfield jdc@xinside.com - - - - Jeremy Lea reg@shale.csir.co.za - - - - Jeremy Prior unknown - - - - Jeroen Ruigrok/Asmodai asmodai@wxs.nl - - - - Jesse Rosenstock jmr@ugcs.caltech.edu - - - - Jian-Da Li jdli@csie.nctu.edu.tw - - - - Jim Babb babb@FreeBSD.org - - - - Jim Binkley jrb@cs.pdx.edu - - - - Jim Carroll jim@carroll.com - - - - Jim Flowers jflowers@ezo.net - - - - Jim Leppek jleppek@harris.com - - - - Jim Lowe james@cs.uwm.edu - - - - Jim Mattson jmattson@sonic.net - - - - Jim Mercer jim@komodo.reptiles.org - - - - Jim Wilson wilson@moria.cygnus.com - - - - Jimbo Bahooli - griffin@blackhole.iceworld.org - - - - Jin Guojun jin@george.lbl.gov - - - - Joachim Kuebart unknown - - - - Joao Carlos Mendes Luis jonny@jonny.eng.br - - - - Jochen Pohl jpo.drs@sni.de - - - - Joe "Marcus" Clarke marcus@miami.edu - - - - Joe Abley jabley@clear.co.nz - - - - Joe Jih-Shian Lu jslu@dns.ntu.edu.tw - - - - Joe Orthoefer j_orthoefer@tia.net - - - - Joe Traister traister@mojozone.org - - - - Joel Faedi Joel.Faedi@esial.u-nancy.fr - - - - Joel Ray Holveck joelh@gnu.org - - - - Joel Sutton sutton@aardvark.apana.org.au - - - - Johan Granlund johan@granlund.nu - - - - Johan Karlsson k@numeri.campus.luth.se - - - - Johan Larsson johan@moon.campus.luth.se - - - - Johann Tonsing jtonsing@mikom.csir.co.za - - - - Johannes Helander unknown - - - - Johannes Stille unknown - - - - John Baldwin jobaldwi@vt.edu - - - - John Beckett jbeckett@southern.edu - - - - John Beukema jbeukema@hk.super.net - - - - John Brezak unknown - - - - John Capo jc@irbs.com - - - - John F. Woods jfw@jfwhome.funhouse.com - - - - John Goerzen - jgoerzen@alexanderwohl.complete.org - - - - John Hay jhay@mikom.csir.co.za - - - - John Heidemann johnh@isi.edu - - - - John Hood cgull@owl.org - - - - John Kohl unknown - - - - John Lind john@starfire.mn.org - - - - John Mackin john@physiol.su.oz.au - - - - John P johnp@lodgenet.com - - - - John Perry perry@vishnu.alias.net - - - - John Preisler john@vapornet.com - - - - John Rochester jr@cs.mun.ca - - - - John Sadler john_sadler@alum.mit.edu - - - - John Saunders john@pacer.nlc.net.au - - - - John W. DeBoskey jwd@unx.sas.com - - - - John Wehle john@feith.com - - - - John Woods jfw@eddie.mit.edu - - - - Jon Morgan morgan@terminus.trailblazer.com - - - - Jonathan H N Chin jc254@newton.cam.ac.uk - - - - Jonathan Hanna - jh@pc-21490.bc.rogers.wave.ca - - - - Jorge Goncalves j@bug.fe.up.pt - - - - Jorge M. Goncalves ee96199@tom.fe.up.pt - - - - Jos Backus jbackus@plex.nl - - - - Jose M. Alcaide jose@we.lc.ehu.es - - - - Jose Marques jose@nobody.org - - - - Josef Grosch - jgrosch@superior.mooseriver.com - - - - Josef Karthauser joe@uk.FreeBSD.org - - - - Joseph Stein joes@wstein.com - - - - Josh Gilliam josh@quick.net - - - - Josh Tiefenbach josh@ican.net - - - - Juergen Lock nox@jelal.hb.north.de - - - - Juha Inkari inkari@cc.hut.fi - - - - Jukka A. Ukkonen jua@iki.fi - - - - Julian Assange proff@suburbia.net - - - - Julian Coleman j.d.coleman@ncl.ac.uk - - - - &a.jhs - - - - Julian Jenkins kaveman@magna.com.au - - - - Junichi Satoh junichi@jp.FreeBSD.org - - - - Junji SAKAI sakai@jp.FreeBSD.org - - - - Junya WATANABE junya-w@remus.dti.ne.jp - - - - K.Higashino a00303@cc.hc.keio.ac.jp - - - - KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp - - - - Kai Vorma vode@snakemail.hut.fi - - - - Kaleb S. Keithley kaleb@ics.com - - - - Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp - - - - Kapil Chowksey kchowksey@hss.hns.com - - - - Karl Denninger karl@mcs.com - - - - Karl Dietz Karl.Dietz@triplan.com - - - - Karl Lehenbauer karl@NeoSoft.com - - - - Kato Takenori - kato@eclogite.eps.nagoya-u.ac.jp - - - - Kawanobe Koh kawanobe@st.rim.or.jp - - - - Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp - - - - Kazuo Horikawa horikawa@jp.FreeBSD.org - - - - Kees Jan Koster kjk1@ukc.ac.uk - - - - Keith Bostic bostic@bostic.com - - - - Keith E. Walker unknown - - - - Keith Moore unknown - - - - Keith Sklower unknown - - - - Kelly Yancey kbyanc@posi.net - - - - Ken Hornstein unknown - - - - Ken Key key@cs.utk.edu - - - - Ken Mayer kmayer@freegate.com - - - - Kenji Saito marukun@mx2.nisiq.net - - - - Kenji Tomita tommyk@da2.so-net.or.jp - - - - Kenneth Furge kenneth.furge@us.endress.com - - - - Kenneth Monville desmo@bandwidth.org - - - - Kenneth R. Westerback krw@tcn.net - - - - Kenneth Stailey kstailey@gnu.ai.mit.edu - - - - Kent Talarico kent@shipwreck.tsoft.net - - - - Kent Vander Velden graphix@iastate.edu - - - - Kentaro Inagaki JBD01226@niftyserve.ne.jp - - - - Kevin Bracey kbracey@art.acorn.co.uk - - - - Kevin Day toasty@dragondata.com - - - - Kevin Lahey kml@nas.nasa.gov - - - - Kevin Lokevlo@hello.com.tw - - - - Kevin Street street@iname.com - - - - Kevin Van Maren vanmaren@fast.cs.utah.edu - - - - Kiroh HARADA kiroh@kh.rim.or.jp - - - - Klaus Klein kleink@layla.inka.de - - - - Klaus-J. Wolf Yanestra@t-online.de - - - - Koichi Sato copan@ppp.fastnet.or.jp - - - - Kostya Lukin lukin@okbmei.msk.su - - - - Kouichi Hirabayashi kh@mogami-wire.co.jp - - - - Kurt D. Zeilenga Kurt@Boolean.NET - - - - Kurt Olsen kurto@tiny.mcs.usu.edu - - - - L. Jonas Olsson - ljo@ljo-slip.DIALIN.CWRU.Edu - - - - Lars Köller - Lars.Koeller@Uni-Bielefeld.DE - - - - Larry Altneu larry@ALR.COM - - - - Laurence Lopez lopez@mv.mv.com - - - - Lee Cremeans lcremean@tidalwave.net - - - - Liang Tai-hwa - avatar@www.mmlab.cse.yzu.edu.tw - - - - Lon Willett lon%softt.uucp@math.utah.edu - - - - Louis A. Mamakos louie@TransSys.COM - - - - Louis Mamakos loiue@TransSys.com - - - - Lucas James Lucas.James@ldjpc.apana.org.au - - - - Lyndon Nerenberg lyndon@orthanc.com - - - - M.C. Wong unknown - - - - MANTANI Nobutaka nobutaka@nobutaka.com - - - - MIHIRA Sanpei Yoshiro sanpei@sanpei.org - - - - MITA Yoshio mita@jp.FreeBSD.org - - - - MITSUNAGA Noriaki - mitchy@er.ams.eng.osaka-u.ac.jp - - - - MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp - - - - Magnus Enbom dot@tinto.campus.luth.se - - - - Mahesh Neelakanta mahesh@gcomm.com - - - - Makoto MATSUSHITA matusita@jp.FreeBSD.org - - - - Makoto WATANABE - watanabe@zlab.phys.nagoya-u.ac.jp - - - - Malte Lance malte.lance@gmx.net - - - - Manu Iyengar - iyengar@grunthos.pscwa.psca.com - - - - Marc Frajola marc@dev.com - - - - Marc Ramirez mrami@mramirez.sy.yale.edu - - - - Marc Slemko marcs@znep.com - - - - Marc van Kempen wmbfmk@urc.tue.nl - - - - Marc van Woerkom van.woerkom@netcologne.de - - - - Marcel Moolenaar marcel@scc.nl - - - - Mario Sergio Fujikawa Ferreira - lioux@gns.com.br - - - - Mark Andrews unknown - - - - Mark Cammidge mark@gmtunx.ee.uct.ac.za - - - - Mark Diekhans markd@grizzly.com - - - - Mark Huizer xaa@stack.nl - - - - Mark J. Taylor mtaylor@cybernet.com - - - - Mark Krentel krentel@rice.edu - - - - Mark Mayo markm@vmunix.com - - - - Mark Thompson thompson@tgsoft.com - - - - Mark Tinguely tinguely@plains.nodak.edu - - - - Mark Treacy unknown - - - - Mark Valentine mark@linus.demon.co.uk - - - - Martin Birgmeier - - - - Martin Ibert mib@ppe.bb-data.de - - - - Martin Kammerhofer dada@sbox.tu-graz.ac.at - - - - Martin Renters martin@tdc.on.ca - - - - Martti Kuparinen - martti.kuparinen@ericsson.com - - - - Masachika ISHIZUKA - ishizuka@isis.min.ntt.jp - - - - Mas.TAKEMURA unknown - - - - Masafumi NAKANE max@wide.ad.jp - - - - Masahiro Sekiguchi - seki@sysrap.cs.fujitsu.co.jp - - - - Masanobu Saitoh msaitoh@spa.is.uec.ac.jp - - - - Masanori Kanaoka kana@saijo.mke.mei.co.jp - - - - Masanori Kiriake seiken@ARGV.AC - - - - Masatoshi TAMURA - tamrin@shinzan.kuee.kyoto-u.ac.jp - - - - Mats Lofkvist mal@algonet.se - - - - Matt Bartley mbartley@lear35.cytex.com - - - - Matt Thomas matt@3am-software.com - - - - Matt White mwhite+@CMU.EDU - - - - Matthew C. Mead mmead@Glock.COM - - - - Matthew Cashdollar mattc@rfcnet.com - - - - Matthew Flatt mflatt@cs.rice.edu - - - - Matthew Fuller fullermd@futuresouth.com - - - - Matthew Stein matt@bdd.net - - - - Matthias Pfaller leo@dachau.marco.de - - - - Matthias Scheler tron@netbsd.org - - - - Mattias Gronlund - Mattias.Gronlund@sa.erisoft.se - - - - Mattias Pantzare pantzer@ludd.luth.se - - - - Maurice Castro - maurice@planet.serc.rmit.edu.au - - - - Max Euston meuston@jmrodgers.com - - - - Max Khon fjoe@husky.iclub.nsu.ru - - - - Maxim Bolotin max@rsu.ru - - - - Maxim V. Sobolev sobomax@altavista.net - - - - Micha Class - michael_class@hpbbse.bbn.hp.com - - - - Michael Butler imb@scgt.oz.au - - - - Michael Butschky butsch@computi.erols.com - - - - Michael Clay mclay@weareb.org - - - - Michael Elbel me@FreeBSD.org - - - - Michael Galassi nerd@percival.rain.com - - - - Michael Hancock michaelh@cet.co.jp - - - - Michael Hohmuth hohmuth@inf.tu-dresden.de - - - - Michael Perlman canuck@caam.rice.edu - - - - Michael Petry petry@netwolf.NetMasters.com - - - - Michael Reifenberger root@totum.plaut.de - - - - Michael Sardo jaeger16@yahoo.com - - - - Michael Searle searle@longacre.demon.co.uk - - - - Michal Listos mcl@Amnesiac.123.org - - - - Michio Karl Jinbo - karl@marcer.nagaokaut.ac.jp - - - - Miguel Angel Sagreras - msagre@cactus.fi.uba.ar - - - - Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp - - - - Mika Nystrom mika@cs.caltech.edu - - - - Mikael Hybsch micke@dynas.se - - - - Mikael Karpberg - karpen@ocean.campus.luth.se - - - - Mike Del repenting@hotmail.com - - - - Mike Durian durian@plutotech.com - - - - Mike Durkin mdurkin@tsoft.sf-bay.org - - - - Mike E. Matsnev mike@azog.cs.msu.su - - - - Mike Evans mevans@candle.com - - - - Mike Grupenhoff kashmir@umiacs.umd.edu - - - - Mike Hibler mike@marker.cs.utah.edu - - - - Mike Karels unknown - - - - Mike McGaughey mmcg@cs.monash.edu.au - - - - Mike Meyer mwm@shiva.the-park.com - - - - Mike Mitchell mitchell@ref.tfs.com - - - - Mike Murphy mrm@alpharel.com - - - - Mike Peck mike@binghamton.edu - - - - Mike Spengler mks@msc.edu - - - - Mikhail A. Sokolov mishania@demos.su - - - - Mikhail Teterin mi@aldan.ziplink.net - - - - Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW - - - - Mitsuru IWASAKI iwasaki@pc.jaring.my - - - - Mitsuru Yoshida mitsuru@riken.go.jp - - - - Monte Mitzelfelt monte@gonefishing.org - - - - Morgan Davis root@io.cts.com - - - - Mostyn Lewis mostyn@mrl.com - - - - Motomichi Matsuzaki mzaki@e-mail.ne.jp - - - - Motoyuki Kasahara m-kasahr@sra.co.jp - - - - Motoyuki Konno motoyuki@snipe.rim.or.jp - - - - Murray Stokely murray@cdrom.com - - - - N.G.Smith ngs@sesame.hensa.ac.uk - - - - NAGAO Tadaaki nagao@cs.titech.ac.jp - - - - NAKAJI Hiroyuki - nakaji@tutrp.tut.ac.jp - - - - NAKAMURA Kazushi nkazushi@highway.or.jp - - - - NAKAMURA Motonori - motonori@econ.kyoto-u.ac.jp - - - - NIIMI Satoshi sa2c@and.or.jp - - - - NOKUBI Hirotaka h-nokubi@yyy.or.jp - - - - Nadav Eiron nadav@barcode.co.il - - - - Nanbor Wang nw1@cs.wustl.edu - - - - Naofumi Honda - honda@Kururu.math.sci.hokudai.ac.jp - - - - Naoki Hamada nao@tom-yam.or.jp - - - - Narvi narvi@haldjas.folklore.ee - - - - Nathan Ahlstrom nrahlstr@winternet.com - - - - Nathan Dorfman nathan@rtfm.net - - - - Neal Fachan kneel@ishiboo.com - - - - Neil Blakey-Milner nbm@rucus.ru.ac.za - - - - Niall Smart rotel@indigo.ie - - - - Nick Barnes Nick.Barnes@pobox.com - - - - Nick Handel nhandel@NeoSoft.com - - - - Nick Hilliard nick@foobar.org - - - - &a.nsayer; - - - - Nick Williams njw@cs.city.ac.uk - - - - Nickolay N. Dudorov nnd@itfs.nsk.su - - - - Niklas Hallqvist niklas@filippa.appli.se - - - - Nisha Talagala nisha@cs.berkeley.edu - - - - No Name ZW6T-KND@j.asahi-net.or.jp - - - - No Name adrian@virginia.edu - - - - No Name alex@elvisti.kiev.ua - - - - No Name anto@netscape.net - - - - No Name bobson@egg.ics.nitch.ac.jp - - - - No Name bovynf@awe.be - - - - No Name burg@is.ge.com - - - - No Name chris@gnome.co.uk - - - - No Name colsen@usa.net - - - - No Name coredump@nervosa.com - - - - No Name dannyman@arh0300.urh.uiuc.edu - - - - No Name davids@SECNET.COM - - - - No Name derek@free.org - - - - No Name devet@adv.IAEhv.nl - - - - No Name djv@bedford.net - - - - No Name dvv@sprint.net - - - - No Name enami@ba2.so-net.or.jp - - - - No Name flash@eru.tubank.msk.su - - - - No Name flash@hway.ru - - - - No Name fn@pain.csrv.uidaho.edu - - - - No Name gclarkii@netport.neosoft.com - - - - No Name gordon@sheaky.lonestar.org - - - - No Name graaf@iae.nl - - - - No Name greg@greg.rim.or.jp - - - - No Name grossman@cygnus.com - - - - No Name gusw@fub46.zedat.fu-berlin.de - - - - No Name hfir@math.rochester.edu - - - - No Name hnokubi@yyy.or.jp - - - - No Name iaint@css.tuu.utas.edu.au - - - - No Name invis@visi.com - - - - No Name ishisone@sra.co.jp - - - - No Name iverson@lionheart.com - - - - No Name jpt@magic.net - - - - No Name junker@jazz.snu.ac.kr - - - - No Name k-sugyou@ccs.mt.nec.co.jp - - - - No Name kenji@reseau.toyonaka.osaka.jp - - - - No Name kfurge@worldnet.att.net - - - - No Name lh@aus.org - - - - No Name lhecking@nmrc.ucc.ie - - - - No Name mrgreen@mame.mu.oz.au - - - - No Name nakagawa@jp.FreeBSD.org - - - - No Name ohki@gssm.otsuka.tsukuba.ac.jp - - - - No Name owaki@st.rim.or.jp - - - - No Name pechter@shell.monmouth.com - - - - No Name pete@pelican.pelican.com - - - - No Name pritc003@maroon.tc.umn.edu - - - - No Name risner@stdio.com - - - - No Name roman@rpd.univ.kiev.ua - - - - No Name root@ns2.redline.ru - - - - No Name root@uglabgw.ug.cs.sunysb.edu - - - - No Name stephen.ma@jtec.com.au - - - - No Name sumii@is.s.u-tokyo.ac.jp - - - - No Name takas-su@is.aist-nara.ac.jp - - - - No Name tamone@eig.unige.ch - - - - No Name tjevans@raleigh.ibm.com - - - - No Name tony-o@iij.ad.jp amurai@spec.co.jp - - - - No Name torii@tcd.hitachi.co.jp - - - - No Name uenami@imasy.or.jp - - - - No Name uhlar@netlab.sk - - - - No Name vode@hut.fi - - - - No Name wlloyd@mpd.ca - - - - No Name wlr@furball.wellsfargo.com - - - - No Name wmbfmk@urc.tue.nl - - - - No Name yamagata@nwgpc.kek.jp - - - - No Name ziggy@ryan.org - - - - Nobuhiro Yasutomi nobu@psrc.isac.co.jp - - - - Nobuyuki Koganemaru - kogane@koganemaru.co.jp - - - - Norio Suzuki nosuzuki@e-mail.ne.jp - - - - Noritaka Ishizumi graphite@jp.FreeBSD.org - - - - Noriyuki Soda soda@sra.co.jp - - - - Oh Junseon hollywar@mail.holywar.net - - - - Olaf Wagner wagner@luthien.in-berlin.de - - - - Oleg Sharoiko os@rsu.ru - - - - Oleg V. Volkov rover@lglobus.ru - - - - Oliver Breuninger ob@seicom.NET - - - - Oliver Friedrichs oliver@secnet.com - - - - Oliver Fromme - oliver.fromme@heim3.tu-clausthal.de - - - - Oliver Laumann - net@informatik.uni-bremen.de - - - - Oliver Oberdorf oly@world.std.com - - - - Olof Johansson offe@ludd.luth.se - - - - Osokin Sergey aka oZZ ozz@FreeBSD.org.ru - - - - Pace Willisson pace@blitz.com - - - - Paco Rosich rosich@modico.eleinf.uv.es - - - - Palle Girgensohn girgen@partitur.se - - - - Parag Patel parag@cgt.com - - - - Pascal Pederiva pascal@zuo.dec.com - - - - Pasvorn Boonmark boonmark@juniper.net - - - - Patrick Gardella patrick@cre8tivegroup.com - - - - Patrick Hausen unknown - - - - Paul Antonov apg@demos.su - - - - Paul F. Werkowski unknown - - - - Paul Fox pgf@foxharp.boston.ma.us - - - - Paul Koch koch@thehub.com.au - - - - Paul Kranenburg pk@NetBSD.org - - - - Paul Mackerras paulus@cs.anu.edu.au - - - - Paul Popelka paulp@uts.amdahl.com - - - - Paul S. LaFollette, Jr. unknown - - - - Paul Saab paul@mu.org - - - - Paul Sandys myj@nyct.net - - - - Paul T. Root proot@horton.iaces.com - - - - Paul Vixie paul@vix.com - - - - Paulo Menezes paulo@isr.uc.pt - - - - Paulo Menezes pm@dee.uc.pt - - - - Pedro A M Vazquez vazquez@IQM.Unicamp.BR - - - - Pedro Giffuni giffunip@asme.org - - - - Pete Bentley pete@demon.net - - - - Peter Childs pjchilds@imforei.apana.org.au - - - - Peter Cornelius pc@inr.fzk.de - - - - Peter Haight peterh@prognet.com - - - - Peter Jeremy perer.jeremy@alcatel.com.au - - - - Peter M. Chen pmchen@eecs.umich.edu - - - - Peter Much peter@citylink.dinoex.sub.org - - - - Peter Olsson unknown - - - - Peter Philipp pjp@bsd-daemon.net - - - - Peter Stubbs PETERS@staidan.qld.edu.au - - - - Phil Maker pjm@cs.ntu.edu.au - - - - Phil Sutherland - philsuth@mycroft.dialix.oz.au - - - - Phil Taylor phil@zipmail.co.uk - - - - Philip Musumeci philip@rmit.edu.au - - - - Pierre Y. Dampure pierre.dampure@k2c.co.uk - - - - Pius Fischer pius@ienet.com - - - - Pomegranate daver@flag.blackened.net - - - - Powerdog Industries - kevin.ruddy@powerdog.com - - - - R. Kym Horsell - - - - Rajesh Vaidheeswarran rv@fore.com - - - - Ralf Friedl friedl@informatik.uni-kl.de - - - - Randal S. Masutani randal@comtest.com - - - - Randall Hopper rhh@ct.picker.com - - - - Randall W. Dean rwd@osf.org - - - - Randy Bush rbush@bainbridge.verio.net - - - - Reinier Bezuidenhout - rbezuide@mikom.csir.co.za - - - - Remy Card Remy.Card@masi.ibp.fr - - - - Ricardas Cepas rch@richard.eu.org - - - - Riccardo Veraldi veraldi@cs.unibo.it - - - - Richard Henderson richard@atheist.tamu.edu - - - - Richard Hwang rhwang@bigpanda.com - - - - Richard Kiss richard@homemail.com - - - - Richard J Kuhns rjk@watson.grauel.com - - - - Richard M. Neswold - rneswold@drmemory.fnal.gov - - - - Richard Seaman, Jr. dick@tar.com - - - - Richard Stallman rms@gnu.ai.mit.edu - - - - Richard Straka straka@user1.inficad.com - - - - Richard Tobin richard@cogsci.ed.ac.uk - - - - Richard Wackerbarth rkw@Dataplex.NET - - - - Richard Winkel rich@math.missouri.edu - - - - Richard Wiwatowski rjwiwat@adelaide.on.net - - - - Rick Macklem rick@snowhite.cis.uoguelph.ca - - - - Rick Macklin unknown - - - - Rob Austein sra@epilogue.com - - - - Rob Mallory rmallory@qualcomm.com - - - - Rob Snow rsnow@txdirect.net - - - - Robert Crowe bob@speakez.com - - - - Robert D. Thrush rd@phoenix.aii.com - - - - Robert Eckardt - roberte@MEP.Ruhr-Uni-Bochum.de - - - - Robert Sanders rsanders@mindspring.com - - - - Robert Sexton robert@kudra.com - - - - Robert Shady rls@id.net - - - - Robert Swindells swindellsr@genrad.co.uk - - - - Robert Watson robert@cyrus.watson.org - - - - Robert Withrow witr@rwwa.com - - - - Robert Yoder unknown - - - - Robin Carey - robin@mailgate.dtc.rankxerox.co.uk - - - - Roger Hardiman roger@cs.strath.ac.uk - - - - Roland Jesse jesse@cs.uni-magdeburg.de - - - - Ron Bickers rbickers@intercenter.net - - - - Ron Lenk rlenk@widget.xmission.com - - - - Ronald Kuehn kuehn@rz.tu-clausthal.de - - - - Rudolf Cejka unknown - - - - Ruslan Belkin rus@home2.UA.net - - - - Ruslan Ermilov ru@ucb.crimea.ua - - - - Ruslan Shevchenko rssh@cam.grad.kiev.ua - - - - Russell L. Carter rcarter@pinyon.org - - - - Russell Vincent rv@groa.uct.ac.za - - - - Ryan Younce ryany@pobox.com - - - - Ryuichiro IMURA imura@cs.titech.ac.jp - - - - SANETO Takanori sanewo@strg.sony.co.jp - - - - SAWADA Mizuki miz@qb3.so-net.ne.jp - - - - SUGIMURA Takashi sugimura@jp.FreeBSD.org - - - - SURANYI Peter - suranyip@jks.is.tsukuba.ac.jp - - - - Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp - - - - Sakari Jalovaara sja@tekla.fi - - - - Sam Hartman hartmans@mit.edu - - - - Samuel Lam skl@ScalableNetwork.com - - - - Samuele Zannoli zannoli@cs.unibo.it - - - - Sander Vesik sander@haldjas.folklore.ee - - - - Sandro Sigala ssigala@globalnet.it - - - - Sascha Blank blank@fox.uni-trier.de - - - - Sascha Wildner swildner@channelz.GUN.de - - - - Satoh Junichi junichi@astec.co.jp - - - - Scot Elliott scot@poptart.org - - - - Scot W. Hetzel hetzels@westbend.net - - - - Scott A. Kenney saken@rmta.ml.org - - - - Scott Blachowicz - scott.blachowicz@seaslug.org - - - - Scott Burris scott@pita.cns.ucla.edu - - - - Scott Hazen Mueller scott@zorch.sf-bay.org - - - - Scott Michel scottm@cs.ucla.edu - - - - Scott Mitchel scott@uk.FreeBSD.org - - - - Scott Reynolds scott@clmqt.marquette.mi.us - - - - Sebastian Strollo seb@erix.ericsson.se - - - - Serge A. Babkin babkin@hq.icb.chel.su - - - - Serge V. Vakulenko vak@zebub.msk.su - - - - Sergei Chechetkin - csl@whale.sunbay.crimea.ua - - - - Sergei S. Laskavy laskavy@pc759.cs.msu.su - - - - Sergey Gershtein sg@mplik.ru - - - - Sergey Kosyakov ks@itp.ac.ru - - - - Sergey Potapov sp@alkor.ru - - - - Sergey Shkonda serg@bcs.zp.ua - - - - Sergey V.Dorokhov svd@kbtelecom.nalnet.ru - - - - Sergio Lenzi lenzi@bsi.com.br - - - - Shaun Courtney shaun@emma.eng.uct.ac.za - - - - Shawn M. Carey smcarey@mailbox.syr.edu - - - - Shigio Yamaguchi shigio@tamacom.com - - - - Shinya Esu esu@yk.rim.or.jp - - - - Shuichi Tanaka stanaka@bb.mbn.or.jp - - - - Shunsuke Akiyama akiyama@jp.FreeBSD.org - - - - Simon simon@masi.ibp.fr - - - - Simon Burge simonb@telstra.com.au - - - - Simon J Gerraty sjg@melb.bull.oz.au - - - - Simon Marlow simonm@dcs.gla.ac.uk - - - - Simon Shapiro shimon@simon-shapiro.org - - - - Sin'ichiro MIYATANI siu@phaseone.co.jp - - - - Slaven Rezic eserte@cs.tu-berlin.de - - - - Soochon Radee slr@mitre.org - - - - Soren Dayton csdayton@midway.uchicago.edu - - - - Soren Dossing sauber@netcom.com - - - - Soren S. Jorvang soren@dt.dk - - - - Stefan Bethke stb@hanse.de - - - - Stefan Eggers seggers@semyam.dinoco.de - - - - Stefan Moeding s.moeding@ndh.net - - - - Stefan Petri unknown - - - - Stefan `Sec` Zehl sec@42.org - - - - Steinar Haug sthaug@nethelp.no - - - - Stephane E. Potvin sepotvin@videotron.ca - - - - Stephane Legrand stephane@lituus.fr - - - - Stephen Clawson - sclawson@marker.cs.utah.edu - - - - Stephen F. Combs combssf@salem.ge.com - - - - Stephen Farrell stephen@farrell.org - - - - Stephen Hocking sysseh@devetir.qld.gov.au - - - - Stephen J. Roznowski sjr@home.net - - - - Stephen McKay syssgm@devetir.qld.gov.au - - - - Stephen Melvin melvin@zytek.com - - - - Steve Bauer sbauer@rock.sdsmt.edu - - - - Steve Coltrin spcoltri@io.com - - - - Steve Deering unknown - - - - Steve Gerakines steve2@genesis.tiac.net - - - - Steve Gericke steveg@comtrol.com - - - - Steve Piette steve@simon.chi.il.US - - - - Steve Schwarz schwarz@alpharel.com - - - - Steven G. Kargl - kargl@troutmask.apl.washington.edu - - - - Steven H. Samorodin samorodi@NUXI.com - - - - Steven McCanne mccanne@cs.berkeley.edu - - - - Steven Plite splite@purdue.edu - - - - Steven Wallace unknown - - - - Stuart Henderson - stuart@internationalschool.co.uk - - - - Sue Blake sue@welearn.com.au - - - - Sugimoto Sadahiro ixtl@komaba.utmc.or.jp - - - - Sugiura Shiro ssugiura@duo.co.jp - - - - Sujal Patel smpatel@wam.umd.edu - - - - Sune Stjerneby stjerneby@usa.net - - - - Suzuki Yoshiaki - zensyo@ann.tama.kawasaki.jp - - - - Tadashi Kumano kumano@strl.nhk.or.jp - - - - Taguchi Takeshi taguchi@tohoku.iij.ad.jp - - - - Takahiro Yugawa yugawa@orleans.rim.or.jp - - - - Takanori Watanabe - takawata@shidahara1.planet.sci.kobe-u.ac.jp - - - - Takashi Mega mega@minz.org - - - - Takashi Uozu j1594016@ed.kagu.sut.ac.jp - - - - Takayuki Ariga a00821@cc.hc.keio.ac.jp - - - - Takeru NAIKI naiki@bfd.es.hokudai.ac.jp - - - - Takeshi Amaike amaike@iri.co.jp - - - - Takeshi MUTOH mutoh@info.nara-k.ac.jp - - - - Takeshi Ohashi - ohashi@mickey.ai.kyutech.ac.jp - - - - Takeshi WATANABE - watanabe@crayon.earth.s.kobe-u.ac.jp - - - - Takuya SHIOZAKI - tshiozak@makino.ise.chuo-u.ac.jp - - - - Tatoku Ogaito tacha@tera.fukui-med.ac.jp - - - - Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org - - - - Ted Buswell tbuswell@mediaone.net - - - - Ted Faber faber@isi.edu - - - - Ted Lemon mellon@isc.org - - - - Terry Lambert terry@lambert.org - - - - Terry Lee terry@uivlsi.csl.uiuc.edu - - - - Tetsuya Furukawa tetsuya@secom-sis.co.jp - - - - Theo de Raadt deraadt@OpenBSD.org - - - - Thomas thomas@mathematik.uni-Bremen.de - - - - Thomas D. Dean tomdean@ix.netcom.com - - - - Thomas David Rivers rivers@dignus.com - - - - Thomas G. McWilliams tgm@netcom.com - - - - Thomas Gellekum - thomas@ghpc8.ihf.rwth-aachen.de - - - - Thomas Graichen - graichen@omega.physik.fu-berlin.de - - - - Thomas König - Thomas.Koenig@ciw.uni-karlsruhe.de - - - - Thomas Ptacek unknown - - - - Thomas A. Stephens tas@stephens.org - - - - Thomas Stromberg tstrombe@rtci.com - - - - Thomas Valentino Crimi - tcrimi+@andrew.cmu.edu - - - - Thomas Wintergerst thomas@lemur.nord.de - - - - Þórður Ívarsson - totii@est.is - - - - Tim Kientzle kientzle@netcom.com - - - - Tim Singletary - tsingle@sunland.gsfc.nasa.gov - - - - Tim Wilkinson tim@sarc.city.ac.uk - - - - Timo J. Rinne tri@iki.fi - - - - Todd Miller millert@openbsd.org - - - - Tom root@majestix.cmr.no - - - - Tom tom@sdf.com - - - - Tom Gray - DCA dcasba@rain.org - - - - Tom Jobbins tom@tom.tj - - - - Tom Pusateri pusateri@juniper.net - - - - Tom Rush tarush@mindspring.com - - - - Tom Samplonius tom@misery.sdf.com - - - - Tomohiko Kurahashi - kura@melchior.q.t.u-tokyo.ac.jp - - - - Tony Kimball alk@Think.COM - - - - Tony Li tli@jnx.com - - - - Tony Lynn wing@cc.nsysu.edu.tw - - - - Tony Maher tonym@angis.org.au - - - - Torbjorn Granlund tege@matematik.su.se - - - - Toshihiko ARAI toshi@tenchi.ne.jp - - - - Toshihiko SHIMOKAWA toshi@tea.forus.or.jp - - - - Toshihiro Kanda candy@kgc.co.jp - - - - Toshiomi Moriki - Toshiomi.Moriki@ma1.seikyou.ne.jp - - - - Trefor S. trefor@flevel.co.uk - - - - Trevor Blackwell tlb@viaweb.com - - - - URATA Shuichiro s-urata@nmit.tmg.nec.co.jp - - - - Udo Schweigert ust@cert.siemens.de - - - - Ugo Paternostro paterno@dsi.unifi.it - - - - Ulf Kieber kieber@sax.de - - - - Ulli Linzen ulli@perceval.camelot.de - - - - Ustimenko Semen semen@iclub.nsu.ru - - - - Uwe Arndt arndt@mailhost.uni-koblenz.de - - - - Vadim Chekan vadim@gc.lviv.ua - - - - Vadim Kolontsov vadim@tversu.ac.ru - - - - Vadim Mikhailov mvp@braz.ru - - - - Van Jacobson van@ee.lbl.gov - - - - Vasily V. Grechishnikov - bazilio@ns1.ied-vorstu.ac.ru - - - - Vasim Valejev vasim@uddias.diaspro.com - - - - Vernon J. Schryver vjs@mica.denver.sgi.com - - - - Vic Abell abe@cc.purdue.edu - - - - Ville Eerola ve@sci.fi - - - - Vincent Poy vince@venus.gaianet.net - - - - Vincenzo Capuano - VCAPUANO@vmprofs.esoc.esa.de - - - - Virgil Champlin champlin@pa.dec.com - - - - Vladimir A. Jakovenko - vovik@ntu-kpi.kiev.ua - - - - Vladimir Kushnir kushn@mail.kar.net - - - - Vsevolod Lobko seva@alex-ua.com - - - - W. Gerald Hicks wghicks@bellsouth.net - - - - W. Richard Stevens rstevens@noao.edu - - - - Walt Howard howard@ee.utah.edu - - - - Warren Toomey wkt@csadfa.cs.adfa.oz.au - - - - Wayne Scott wscott@ichips.intel.com - - - - Werner Griessl - werner@btp1da.phy.uni-bayreuth.de - - - - Wes Santee wsantee@wsantee.oz.net - - - - Wietse Venema wietse@wzv.win.tue.nl - - - - Wilfredo Sanchez wsanchez@apple.com - - - - Wiljo Heinen wiljo@freeside.ki.open.de - - - - Wilko Bulte wilko@yedi.iaf.nl - - - - Will Andrews andrews@technologist.com - - - - Willem Jan Withagen wjw@surf.IAE.nl - - - - William Jolitz withheld - - - - William Liao william@tale.net - - - - Wojtek Pilorz - wpilorz@celebris.bdk.lublin.pl - - - - Wolfgang Helbig helbig@ba-stuttgart.de - - - - Wolfgang Solfrank ws@tools.de - - - - Wolfgang Stanglmeier wolf@FreeBSD.org - - - - Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW - - - - Yarema yds@ingress.com - - - - Yaroslav Terletsky ts@polynet.lviv.ua - - - - Yasuhito FUTATSUKI futatuki@fureai.or.jp - - - - Yasuhiro Fukama yasuf@big.or.jp - - - - Yen-Shuo Su yssu@CCCA.NCTU.edu.tw - - - - Ying-Chieh Liao ijliao@csie.NCTU.edu.tw - - - - Yixin Jin yjin@rain.cs.ucla.edu - - - - Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp - - - - Yoshihiko OHTA yohta@bres.tsukuba.ac.jp - - - - Yoshihisa NAKAGAWA - y-nakaga@ccs.mt.nec.co.jp - - - - Yoshikazu Goto gotoh@ae.anritsu.co.jp - - - - Yoshimasa Ohnishi - ohnishi@isc.kyutech.ac.jp - - - - Yoshishige Arai ryo2@on.rim.or.jp - - - - Yuichi MATSUTAKA matutaka@osa.att.ne.jp - - - - Yujiro MIYATA - miyata@bioele.nuee.nagoya-u.ac.jp - - - - Yukihiro Nakai nacai@iname.com - - - - Yusuke Nawano azuki@azkey.org - - - - Yuu Yashiki s974123@cc.matsuyama-u.ac.jp - - - - Yuval Yarom yval@cs.huji.ac.il - - - - Yves Fonk yves@cpcoup5.tn.tudelft.nl - - - - Yves Fonk yves@dutncp8.tn.tudelft.nl - - - - Zach Heilig zach@gaffaneys.com - - - - Zahemszhky Gabor zgabor@code.hu - - - - Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw - - - - arci vega@sophia.inria.fr - - - - der Mouse mouse@Collatz.McRCIM.McGill.EDU - - - - frf frf@xocolatl.com - - - - Ege Rekk aagero@aage.priv.no - - - - - - 386BSD Patch Kit Patch Contributors - - (in alphabetical order by first name): - - - - Adam Glass glass@postgres.berkeley.edu - - - - Adrian Hall adrian@ibmpcug.co.uk - - - - Andrey A. Chernov ache@astral.msk.su - - - - Andrew Herbert andrew@werple.apana.org.au - - - - Andrew Moore alm@netcom.com - - - - Andy Valencia ajv@csd.mot.com - jtk@netcom.com - - - - Arne Henrik Juul arnej@Lise.Unit.NO - - - - Bakul Shah bvs@bitblocks.com - - - - Barry Lustig barry@ictv.com - - - - Bob Wilcox bob@obiwan.uucp - - - - Branko Lankester - - - - Brett Lymn blymn@mulga.awadi.com.AU - - - - Charles Hannum mycroft@ai.mit.edu - - - - Chris G. Demetriou - cgd@postgres.berkeley.edu - - - - Chris Torek torek@ee.lbl.gov - - - - Christoph Robitschko - chmr@edvz.tu-graz.ac.at - - - - Daniel Poirot poirot@aio.jsc.nasa.gov - - - - Dave Burgess burgess@hrd769.brooks.af.mil - - - - Dave Rivers rivers@ponds.uucp - - - - David Dawes dawes@physics.su.OZ.AU - - - - David Greenman dg@Root.COM - - - - Eric J. Haug ejh@slustl.slu.edu - - - - Felix Gaehtgens - felix@escape.vsse.in-berlin.de - - - - Frank Maclachlan fpm@crash.cts.com - - - - Gary A. Browning gab10@griffcd.amdahl.com - - - - Gary Howland gary@hotlava.com - - - - Geoff Rehmet csgr@alpha.ru.ac.za - - - - Goran Hammarback goran@astro.uu.se - - - - Guido van Rooij guido@gvr.org - - - - Guy Harris guy@auspex.com - - - - Havard Eidnes - Havard.Eidnes@runit.sintef.no - - - - Herb Peyerl hpeyerl@novatel.cuc.ab.ca - - - - Holger Veit Holger.Veit@gmd.de - - - - Ishii Masahiro, R. Kym Horsell - - - - J.T. Conklin jtc@cygnus.com - - - - Jagane D Sundar jagane@netcom.com - - - - James Clark jjc@jclark.com - - - - James Jegers jimj@miller.cs.uwm.edu - - - - James W. Dolter - - - - James da Silva jds@cs.umd.edu et al - - - - Jay Fenlason hack@datacube.com - - - - Jim Wilson wilson@moria.cygnus.com - - - - Jörg Lohse - lohse@tech7.informatik.uni-hamburg.de - - - - Jörg Wunsch - joerg_wunsch@uriah.heep.sax.de - - - - John Dyson - - - - John Woods jfw@eddie.mit.edu - - - - Jordan K. Hubbard jkh@whisker.hubbard.ie - - - - Julian Elischer julian@dialix.oz.au - - - - Julian Stacey jhs@FreeBSD.org - - - - Karl Dietz Karl.Dietz@triplan.com - - - - Karl Lehenbauer karl@NeoSoft.com - karl@one.neosoft.com - - - - Keith Bostic bostic@toe.CS.Berkeley.EDU - - - - Ken Hughes - - - - Kent Talarico kent@shipwreck.tsoft.net - - - - Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu - kml@mosquito.cis.ufl.edu - - - - Marc Frajola marc@dev.com - - - - Mark Tinguely tinguely@plains.nodak.edu - tinguely@hookie.cs.ndsu.NoDak.edu - - - - Martin Renters martin@tdc.on.ca - - - - Michael Clay mclay@weareb.org - - - - Michael Galassi nerd@percival.rain.com - - - - Mike Durkin mdurkin@tsoft.sf-bay.org - - - - Naoki Hamada nao@tom-yam.or.jp - - - - Nate Williams nate@bsd.coe.montana.edu - - - - Nick Handel nhandel@NeoSoft.com - nick@madhouse.neosoft.com - - - - Pace Willisson pace@blitz.com - - - - Paul Kranenburg pk@cs.few.eur.nl - - - - Paul Mackerras paulus@cs.anu.edu.au - - - - Paul Popelka paulp@uts.amdahl.com - - - - Peter da Silva peter@NeoSoft.com - - - - Phil Sutherland - philsuth@mycroft.dialix.oz.au - - - - Poul-Henning Kampphk@FreeBSD.org - - - - Ralf Friedl friedl@informatik.uni-kl.de - - - - Rick Macklem root@snowhite.cis.uoguelph.ca - - - - Robert D. Thrush rd@phoenix.aii.com - - - - Rodney W. Grimes rgrimes@cdrom.com - - - - Sascha Wildner swildner@channelz.GUN.de - - - - Scott Burris scott@pita.cns.ucla.edu - - - - Scott Reynolds scott@clmqt.marquette.mi.us - - - - Sean Eric Fagan sef@kithrup.com - - - - Simon J Gerraty sjg@melb.bull.oz.au - sjg@zen.void.oz.au - - - - Stephen McKay syssgm@devetir.qld.gov.au - - - - Terry Lambert terry@icarus.weber.edu - - - - Terry Lee terry@uivlsi.csl.uiuc.edu - - - - Tor Egge Tor.Egge@idi.ntnu.no - - - - Warren Toomey wkt@csadfa.cs.adfa.oz.au - - - - Wiljo Heinen wiljo@freeside.ki.open.de - - - - William Jolitz withheld - - - - Wolfgang Solfrank ws@tools.de - - - - Wolfgang Stanglmeier wolf@dentaro.GUN.de - - - - Yuval Yarom yval@cs.huji.ac.il - - - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/Makefile b/en_US.ISO8859-1/books/arch-handbook/Makefile deleted file mode 100644 index f0390ebe65..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/Makefile +++ /dev/null @@ -1,55 +0,0 @@ -# -# $FreeBSD$ -# -# Build the FreeBSD Developers' Handbook. -# - -MAINTAINER=murray@FreeBSD.org - -DOC?= book - -FORMATS?= html-split - -HAS_INDEX= true - -INSTALL_COMPRESSED?= gz -INSTALL_ONLY_COMPRESSED?= - -# Images -IMAGES= sockets/layers.eps sockets/sain.eps sockets/sainfill.eps sockets/sainlsb.eps sockets/sainmsb.eps sockets/sainserv.eps sockets/serv.eps sockets/serv2.eps sockets/slayers.eps - -# -# SRCS lists the individual SGML files that make up the document. Changes -# to any of these files will force a rebuild -# - -# SGML content -SRCS= book.sgml -SRCS+= boot/chapter.sgml -SRCS+= dma/chapter.sgml -SRCS+= driverbasics/chapter.sgml -SRCS+= introduction/chapter.sgml -SRCS+= ipv6/chapter.sgml -SRCS+= isa/chapter.sgml -SRCS+= jail/chapter.sgml -SRCS+= kerneldebug/chapter.sgml -SRCS+= kobj/chapter.sgml -SRCS+= l10n/chapter.sgml -SRCS+= locking/chapter.sgml -SRCS+= mac/chapter.sgml -SRCS+= pci/chapter.sgml -SRCS+= policies/chapter.sgml -SRCS+= scsi/chapter.sgml -SRCS+= secure/chapter.sgml -SRCS+= sockets/chapter.sgml -SRCS+= sound/chapter.sgml -SRCS+= sysinit/chapter.sgml -SRCS+= tools/chapter.sgml -SRCS+= usb/chapter.sgml -SRCS+= vm/chapter.sgml -SRCS+= x86/chapter.sgml - -# Entities - -DOC_PREFIX?= ${.CURDIR}/../../.. -.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/en_US.ISO8859-1/books/arch-handbook/book.sgml b/en_US.ISO8859-1/books/arch-handbook/book.sgml deleted file mode 100644 index e27a42d8a5..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/book.sgml +++ /dev/null @@ -1,301 +0,0 @@ - - - -%bookinfo; - -%man; - -%freebsd; - %chapters; - %mac-entities; - %authors - %mailing-lists; - -]> - - - - FreeBSD Developers' Handbook - - The FreeBSD Documentation Project - - August 2000 - - - 2000 - 2001 - 2002 - 2003 - The FreeBSD Documentation Project - - - &bookinfo.legalnotice; - - - Welcome to the Developers' Handbook. This manual is a - work in progress 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;. - - The latest version of this document is always available - from the FreeBSD World - Wide Web server. It may also be downloaded in a - variety of formats and compression options from the FreeBSD FTP - server or one of the numerous mirror - sites. - - - - - Basics - - &chap.introduction; - &chap.tools; - &chap.secure; - &chap.l10n; - &chap.policies; - - - - - Interprocess Communication - - - * Signals - - Signals, pipes, semaphores, message queues, shared memory, - ports, sockets, doors - - - - &chap.sockets; - &chap.ipv6; - - - - - Kernel - - &chap.boot; - &chap.locking; - &chap.kobj; - &chap.jail; - &chap.sysinit; - &chap.mac; - &chap.vm; - &chap.dma; - &chap.kerneldebug; - - - * UFS - - UFS, FFS, Ext2FS, JFS, inodes, buffer cache, labeling, - locking, metadata, soft-updates, LFS, portalfs, procfs, - vnodes, memory sharing, memory objects, TLBs, caching - - - - - * AFS - - AFS, NFS, SANs, etc. - - - - - * Syscons - - Syscons, tty, PCVT, serial console, screen savers, - etc. - - - - - * Compatibility Layers - - - * Linux - - Linux, SVR4, etc. - - - - - - - Device Drivers - - &chap.driverbasics; - &chap.isa; - &chap.pci; - &chap.scsi; - &chap.usb; - &chap.newbus; - - &chap.snd; - - - - - Architectures - - &chap.x86; - - - * Alpha - - Talk about the architectural specifics of - FreeBSD/alpha. - - Explanation of alignment errors, how to fix, how to - ignore. - - Example assembly language code for FreeBSD/alpha. - - - - * IA-64 - - Talk about the architectural specifics of - FreeBSD/ia64. - - - - - - Appendices - - - - - - - Dave - A - Patterson - - - John - L - Hennessy - - - 1998Morgan Kaufmann Publishers, - Inc. - 1-55860-428-6 - - Morgan Kaufmann Publishers, Inc. - - Computer Organization and Design - The Hardware / Software Interface - 1-2 - - - - - - W. - Richard - Stevens - - - 1993Addison Wesley Longman, - Inc. - 0-201-56317-7 - - Addison Wesley Longman, Inc. - - Advanced Programming in the Unix Environment - 1-2 - - - - - - Marshall - Kirk - McKusick - - - Keith - Bostic - - - Michael - J - Karels - - - John - S - Quarterman - - - 1996Addison-Wesley Publishing Company, - Inc. - 0-201-54979-4 - - Addison-Wesley Publishing Company, Inc. - - The Design and Implementation of the 4.4 BSD Operating System - 1-2 - - - - - - Aleph - One - - - Phrack 49; "Smashing the Stack for Fun and Profit" - - - - - - Chrispin - Cowan - - - Calton - Pu - - - Dave - Maier - - - StackGuard; Automatic Adaptive Detection and Prevention of - Buffer-Overflow Attacks - - - - - - Todd - Miller - - - Theo - de Raadt - - - strlcpy and strlcat -- consistent, safe string copy and - concatenation. - - - - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml deleted file mode 100644 index dba9d73a39..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/boot/chapter.sgml +++ /dev/null @@ -1,1023 +0,0 @@ - - - - - - - Sergey - Lyubka - Contributed by - - - - Bootstrapping and kernel initialization - - - Synopsis - - This chapter is an overview of the boot and system - initialization process, starting from the BIOS (firmware) POST, - to the first user process creation. Since the initial steps of - system startup are very architecture dependent, the IA-32 - architecture is used as an example. - - - - Overview - - A computer running FreeBSD can boot by several methods, - although the most common method, booting from a harddisk where - the OS is installed, will be discussed here. The boot process - is divided into several steps: - - - BIOS POST - boot0 stage - boot2 stage - loader stage - kernel initialization - - - The boot0 and boot2 - stages are also referred to as bootstrap stages 1 and - 2 in &man.boot.8; as the first steps in FreeBSD's - 3-stage bootstrapping procedure. Various information is printed - on the screen at each stage, so you may visually recognize them - using the table that follows. Please note that the actual data - may differ from machine to machine: - - - - - - may vary - - BIOS (firmware) messages - - - - -F1 FreeBSD -F2 BSD -F5 Disk 2 - - - boot0 - - - - ->>FreeBSD/i386 BOOT -Default: 1:ad(1,a)/boot/loader -boot: - - - boot2This - prompt will appear if the user presses a key just after - selecting an OS to boot at the boot0 - stage. - - - - -BTX loader 1.0 BTX version is 1.01 -BIOS drive A: is disk0 -BIOS drive C: is disk1 -BIOS 639kB/64512kB available memory -FreeBSD/i386 bootstrap loader, Revision 0.8 -Console internal video/keyboard -(jkh@bento.freebsd.org, Mon Nov 20 11:41:23 GMT 2000) -/kernel text=0x1234 data=0x2345 syms=[0x4+0x3456] -Hit [Enter] to boot immediately, or any other key for command prompt -Booting [kernel] in 9 seconds..._ - - - loader - - - - - Copyright (c) 1992-2002 The FreeBSD Project. -Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 - The Regents of the University of California. All rights reserved. -FreeBSD 4.6-RC #0: Sat May 4 22:49:02 GMT 2002 - devnull@kukas:/usr/obj/usr/src/sys/DEVNULL -Timecounter "i8254" frequency 1193182 Hz - - kernel - - - - - - - - BIOS POST - - When the PC powers on, the processor's registers are set - to some predefined values. One of the registers is the - instruction pointer register, and its value - after a power on is well defined: it is a 32-bit value of - 0xfffffff0. The instruction pointer register points to code to - be executed by the processor. One of the registers is the - cr1 32-bit control register, and its value - just after the reboot is 0. One of the cr1's bits, the bit PE - (Protected Enabled) indicates whether the processor is running - in protected or real mode. Since at boot time this bit is - cleared, the processor boots in real mode. Real mode means, - among other things, that linear and physical addresses are - identical. - - The value of 0xfffffff0 is slightly less then 4Gb, so unless - the machine has 4Gb physical memory, it cannot point to a valid - memory address. The computer's hardware translates this address - so that it points to a BIOS memory block. - - BIOS stands for Basic Input Output - System, and it is a chip on the motherboard that has - a relatively small amount of read-only memory (ROM). This - memory contains various low-level routines that are specific to - the hardware supplied with the motherboard. So, the processor - will first jump to the address 0xfffffff0, which really resides - in the BIOS's memory. Usually this address contains a jump - instruction to the BIOS's POST routines. - - POST stands for Power On Self Test. - This is a set of routines including the memory check, system bus - check and other low-level stuff so that the CPU can initialize - the computer properly. The important step on this stage is - determining the boot device. All modern BIOS's allow the boot - device to be set manually, so you can boot from a floppy, - CD-ROM, harddisk etc. - - The very last thing in the POST is the INT - 0x19 instruction. That instruction reads 512 bytes - from the first sector of boot device into the memory at address - 0x7c00. The term first sector originates - from harddrive architecture, where the magnetic plate is divided - to a number of cylindrical tracks. Tracks are numbered, and - every track is divided by a number (usually 64) sectors. Track - number 0 is the outermost on the magnetic plate, and sector 1, - the first sector (tracks, or, cylinders, are numbered starting - from 0, but sectors - starting from 1), has a special meaning. - It is also called Master Boot Record, or MBR. The remaining - sectors on the first track are never used Some - utilities such as &man.disklabel.8; may store the information in - this area, mostly in the second - sector.. - - - - <literal>boot0</literal> stage - - Take a look at the file /boot/boot0. - This is a small 512-byte file, and it is exactly what FreeBSD's - installation procedure wrote to your harddisk's MBR if you chose - the bootmanager option at installation time. - - As mentioned previously, the INT 0x19 - instruction loads an MBR, i.e. the boot0 - content, into the memory at address 0x7c00. Taking a look at - the file sys/boot/i386/boot0/boot0.s can - give a guess at what is happening there - this is the boot - manager, which is an awesome piece of code written by Robert - Nordier. - - The MBR, or, boot0, has a special - structure starting from offset 0x1be, called the - partition table. It has 4 records of 16 - bytes each, called partition records, which - represent how the harddisk(s) are partitioned, or, in FreeBSD's - terminology, sliced. One byte of those 16 says whether a - partition (slice) is bootable or not. Exactly one record must - have that flag set, otherwise boot0's code - will refuse to proceed. - - A partition record has the following fields: - - - - the 1-byte filesystem type - - - - the 1-byte bootable flag - - - - the 6 byte descriptor in CHS format - - - - the 8 byte descriptor in LBA format - - - - A partition record descriptor has the information about - where exactly the partition resides on the drive. Both - descriptors, LBA and CHS, describe the same information, but in - different ways: LBA (Logical Block Addressing) has the starting - sector for the partition and the partition's length, while CHS - (Cylinder Head Sector) has coordinates for the first and last - sectors of the partition. - - The boot manager scans the partition table and prints the - menu on the screen so the user can select what disk and what - slice to boot. By pressing an appropriate key, - boot0 performs the following - actions: - - - - modifies the bootable flag for the selected partition to - make it bootable, and clears the previous - - - - saves itself to disk to remember what partition (slice) - has been selected so to use it as the default on the next - boot - - - - loads the first sector of the selected partition (slice) - into memory and jumps there - - - - What kind of data should reside on the very first sector of - a bootable partition (slice), in our case, a FreeBSD slice? As - you may have already guessed, it is - boot2. - - - - <literal>boot2</literal> stage - - You might wonder, why boot2 comes after - boot0, and not boot1. Actually, there is a - 512-byte file called boot1 in the directory - /boot as well. It is used for booting from - a floppy. When booting from a floppy, - boot1 plays the same role as - boot0 for a harddisk: it locates - boot2 and runs it. - - You may have realized that a file - /boot/mbr exists as well. It is a - simplified version of boot0. The code in - mbr does not provide a menu for the user, - it just blindly boots the partition marked active. - - The code implementing boot2 resides in - sys/boot/i386/boot2/, and the executable - itself is in /boot. The files - boot0 and boot2 that - are in /boot are not used by the bootstrap, - but by utilities such as boot0cfg. - The actual position for boot0 is in the - MBR. For boot2 it is the beginning of a - bootable FreeBSD slice. These locations are not under the - filesystem's control, so they are invisible to commands like - ls. - - The main task for boot2 is to load the - file /boot/loader, which is the third stage - in the bootstrapping procedure. The code in - boot2 cannot use any services like - open() and read(), - since the kernel is not yet loaded. It must scan the harddisk, - knowing about the filesystem structure, find the file - /boot/loader, read it into memory using a - BIOS service, and then pass the execution to the loader's entry - point. - - Besides that, boot2 prompts for user - input so the loader can be booted from different disk, unit, - slice and partition. - - The boot2 binary is created in special - way: - - sys/boot/i386/boot2/Makefile -boot2: boot2.ldr boot2.bin ${BTX}/btx/btx - btxld -v -E ${ORG2} -f bin -b ${BTX}/btx/btx -l boot2.ldr \ - -o boot2.ld -P 1 boot2.bin - - This Makefile snippet shows that &man.btxld.8; is used to - link the binary. BTX, which stands for BooT eXtender, is a - piece of code that provides a protected mode environment for the - program, called the client, that it is linked with. So - boot2 is a BTX client, i.e. it uses the - service provided by BTX. - - The btxld utility is the linker. - It links two binaries together. The difference between - &man.btxld.8; and &man.ld.1; is that - ld usually links object files into a - shared object or executable, while - btxld links an object file with the - BTX, producing the binary file suitable to be put on the - beginning of the partition for the system boot. - - boot0 passes the execution to BTX's entry - point. BTX then switches the processor to protected mode, and - prepares a simple environment before calling the client. This - includes: - - - virtual v86 mode. That means, the BTX is a v86 - monitor. Real mode instructions like posh, popf, cli, sti, if - called by the client, will work. - - Interrupt Descriptor Table (IDT) is set up so - all hardware interrupts are routed to the default BIOS's - handlers, and interrupt 0x30 is set up to be the syscall - gate. - - Two system calls: exec and - exit, are defined: - - sys/boot/i386/btx/lib/btxsys.s: - .set INT_SYS,0x30 # Interrupt number -# -# System call: exit -# -__exit: xorl %eax,%eax # BTX system - int $INT_SYS # call 0x0 -# -# System call: exec -# -__exec: movl $0x1,%eax # BTX system - int $INT_SYS # call 0x1 - - - BTX creates a Global Descriptor Table (GDT): - - sys/boot/i386/btx/btx/btx.s: -gdt: .word 0x0,0x0,0x0,0x0 # Null entry - .word 0xffff,0x0,0x9a00,0xcf # SEL_SCODE - .word 0xffff,0x0,0x9200,0xcf # SEL_SDATA - .word 0xffff,0x0,0x9a00,0x0 # SEL_RCODE - .word 0xffff,0x0,0x9200,0x0 # SEL_RDATA - .word 0xffff,MEM_USR,0xfa00,0xcf# SEL_UCODE - .word 0xffff,MEM_USR,0xf200,0xcf# SEL_UDATA - .word _TSSLM,MEM_TSS,0x8900,0x0 # SEL_TSS - - The client's code and data start from address MEM_USR - (0xa000), and a selector (SEL_UCODE) points to the client's code - segment. The SEL_UCODE descriptor has Descriptor Privilege - Level (DPL) 3, which is the lowest privilege level. But the - INT 0x30 instruction handler resides in a - segment pointed to by the SEL_SCODE (supervisor code) selector, - as shown from the code that creates an IDT: - - mov $SEL_SCODE,%dh # Segment selector -init.2: shr %bx # Handle this int? - jnc init.3 # No - mov %ax,(%di) # Set handler offset - mov %dh,0x2(%di) # and selector - mov %dl,0x5(%di) # Set P:DPL:type - add $0x4,%ax # Next handler - - So, when the client calls __exec(), the - code will be executed with the highest privileges. This allows - the kernel to change the protected mode data structures, such as - page tables, GDT, IDT, etc later, if needed. - - boot2 defines an important structure, - struct bootinfo. This structure is - initialized by boot2 and passed to the - loader, and then further to the kernel. Some nodes of this - structures are set by boot2, the rest by the - loader. This structure, among other information, contains the - kernel filename, BIOS harddisk geometry, BIOS drive number for - boot device, physical memory available, envp - pointer etc. The definition for it is: - - /usr/include/machine/bootinfo.h -struct bootinfo { - u_int32_t bi_version; - u_int32_t bi_kernelname; /* represents a char * */ - u_int32_t bi_nfs_diskless; /* struct nfs_diskless * */ - /* End of fields that are always present. */ -#define bi_endcommon bi_n_bios_used - u_int32_t bi_n_bios_used; - u_int32_t bi_bios_geom[N_BIOS_GEOM]; - u_int32_t bi_size; - u_int8_t bi_memsizes_valid; - u_int8_t bi_bios_dev; /* bootdev BIOS unit number */ - u_int8_t bi_pad[2]; - u_int32_t bi_basemem; - u_int32_t bi_extmem; - u_int32_t bi_symtab; /* struct symtab * */ - u_int32_t bi_esymtab; /* struct symtab * */ - /* Items below only from advanced bootloader */ - u_int32_t bi_kernend; /* end of kernel space */ - u_int32_t bi_envp; /* environment */ - u_int32_t bi_modulep; /* preloaded modules */ -}; - - boot2 enters into an infinite loop waiting - for user input, then calls load(). If the - user does not press anything, the loop brakes by a timeout, so - load() will load the default file - (/boot/loader). Functions ino_t - lookup(char *filename) and int xfsread(ino_t - inode, void *buf, size_t nbyte) are used to read the - content of a file into memory. /boot/loader - is an ELF binary, but where the ELF header is prepended with - a.out's struct exec structure. - load() scans the loader's ELF header, loading - the content of /boot/loader into memory, and - passing the execution to the loader's entry: - - sys/boot/i386/boot2/boot2.c: - __exec((caddr_t)addr, RB_BOOTINFO | (opts & RBX_MASK), - MAKEBOOTDEV(dev_maj[dsk.type], 0, dsk.slice, dsk.unit, dsk.part), - 0, 0, 0, VTOP(&bootinfo)); - - - - <application>loader</application> stage - - loader is a BTX client as well. - I will not describe it here in detail, there is a comprehensive - manpage written by Mike Smith, &man.loader.8;. The underlying - mechanisms and BTX were discussed above. - - The main task for the loader is to boot the kernel. When - the kernel is loaded into memory, it is being called by the - loader: - - sys/boot/common/boot.c: - /* Call the exec handler from the loader matching the kernel */ - module_formats[km->m_loader]->l_exec(km); - - - - Kernel initialization - - To where exactly is the execution passed by the loader, - i.e. what is the kernel's actual entry point. Let us take a - look at the command that links the kernel: - - sys/conf/Makefile.i386: -ld -elf -Bdynamic -T /usr/src/sys/conf/ldscript.i386 -export-dynamic \ --dynamic-linker /red/herring -o kernel -X locore.o \ -<lots of kernel .o files> - - A few interesting things can be seen in this line. First, - the kernel is an ELF dynamically linked binary, but the dynamic - linker for kernel is /red/herring, which is - definitely a bogus file. Second, taking a look at the file - sys/conf/ldscript.i386 gives an idea about - what ld options are used when - compiling a kernel. Reading through the first few lines, the - string - - sys/conf/ldscript.i386: -ENTRY(btext) - - says that a kernel's entry point is the symbol `btext'. - This symbol is defined in locore.s: - - sys/i386/i386/locore.s: - .text -/********************************************************************** - * - * This is where the bootblocks start us, set the ball rolling... - * - */ -NON_GPROF_ENTRY(btext) - - First what is done is the register EFLAGS is set to a - predefined value of 0x00000002, and then all the segment - registers are initialized: - - sys/i386/i386/locore.s -/* Don't trust what the BIOS gives for eflags. */ - pushl $PSL_KERNEL - popfl - -/* - * Don't trust what the BIOS gives for %fs and %gs. Trust the bootstrap - * to set %cs, %ds, %es and %ss. - */ - mov %ds, %ax - mov %ax, %fs - mov %ax, %gs - - btext calls the routines - recover_bootinfo(), - identify_cpu(), - create_pagetables(), which are also defined - in locore.s. Here is a description of what - they do: - - - - - - recover_bootinfo - - This routine parses the parameters to the kernel - passed from the bootstrap. The kernel may have been - booted in 3 ways: by the loader, described above, by the - old disk boot blocks, and by the old diskless boot - procedure. This function determines the booting method, - and stores the struct bootinfo - structure into the kernel memory. - - - - identify_cpu - - This functions tries to find out what CPU it is - running on, storing the value found in a variable - _cpu. - - - - create_pagetables - - This function allocates and fills out a Page Table - Directory at the top of the kernel memory area. - - - - - The next steps are enabling VME, if the CPU supports - it: - - testl $CPUID_VME, R(_cpu_feature) - jz 1f - movl %cr4, %eax - orl $CR4_VME, %eax - movl %eax, %cr4 - - Then, enabling paging: - /* Now enable paging */ - movl R(_IdlePTD), %eax - movl %eax,%cr3 /* load ptd addr into mmu */ - movl %cr0,%eax /* get control word */ - orl $CR0_PE|CR0_PG,%eax /* enable paging */ - movl %eax,%cr0 /* and let's page NOW! */ - - The next three lines of code are because the paging was set, - so the jump is needed to continue the execution in virtualized - address space: - - pushl $begin /* jump to high virtualized address */ - ret - -/* now running relocated at KERNBASE where the system is linked to run */ -begin: - - The function init386() is called, with - a pointer to the first free physical page, after that - mi_startup(). init386 - is an architecture dependent initialization function, and - mi_startup() is an architecture independent - one (the 'mi_' prefix stands for Machine Independent). The - kernel never returns from mi_startup(), and - by calling it, the kernel finishes booting: - - sys/i386/i386/locore.s: - movl physfree, %esi - pushl %esi /* value of first for init386(first) */ - call _init386 /* wire 386 chip for unix operation */ - call _mi_startup /* autoconfiguration, mountroot etc */ - hlt /* never returns to here */ - - - <function>init386()</function> - - init386() is defined in - sys/i386/i386/machdep.c and performs - low-level initialization, specific to the i386 chip. The - switch to protected mode was performed by the loader. The - loader has created the very first task, in which the kernel - continues to operate. Before running straight away to the - code, I will enumerate the tasks the processor must complete - to initialize protected mode execution: - - - - Initialize the kernel tunable parameters, passed from - the bootstrapping program. - - - - Prepare the GDT. - - - - Prepare the IDT. - - - - Initialize the system console. - - - - Initialize the DDB, if it is compiled into - kernel. - - - - Initialize the TSS. - - - - Prepare the LDT. - - - - Setup proc0's pcb. - - - - What init386() first does is - initialize the tunable parameters passed from bootstrap. This - is done by setting the environment pointer (envp) and calling - init_param1(). The envp pointer has been - passed from loader in the bootinfo - structure: - - sys/i386/i386/machdep.c: - kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; - - /* Init basic tunables, hz etc */ - init_param1(); - - init_param1() is defined in - sys/kern/subr_param.c. That file has a - number of sysctls, and two functions, - init_param1() and - init_param2(), that are called from - init386(): - - sys/kern/subr_param.c - hz = HZ; - TUNABLE_INT_FETCH("kern.hz", &hz); - - TUNABLE_<typename>_FETCH is used to fetch the value - from the environment: - - /usr/src/sys/sys/kernel.h -#define TUNABLE_INT_FETCH(path, var) getenv_int((path), (var)) - - - Sysctl kern.hz is the system clock tick. Along with - this, the following sysctls are set by - init_param1(): kern.maxswzone, - kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.dflssiz, - kern.maxssiz, kern.sgrowsiz. - - Then init386() prepares the Global - Descriptors Table (GDT). Every task on an x86 is running in - its own virtual address space, and this space is addressed by - a segment:offset pair. Say, for instance, the current - instruction to be executed by the processor lies at CS:EIP, - then the linear virtual address for that instruction would be - the virtual address of code segment CS + EIP. For - convenience, segments begin at virtual address 0 and end at a - 4Gb boundary. Therefore, the instruction's linear virtual - address for this example would just be the value of EIP. - Segment registers such as CS, DS etc are the selectors, - i.e. indexes, into GDT (to be more precise, an index is not a - selector itself, but the INDEX field of a selector). - FreeBSD's GDT holds descriptors for 15 selectors per - CPU: - - sys/i386/i386/machdep.c: -union descriptor gdt[NGDT * MAXCPU]; /* global descriptor table */ - -sys/i386/include/segments.h: -/* - * Entries in the Global Descriptor Table (GDT) - */ -#define GNULL_SEL 0 /* Null Descriptor */ -#define GCODE_SEL 1 /* Kernel Code Descriptor */ -#define GDATA_SEL 2 /* Kernel Data Descriptor */ -#define GPRIV_SEL 3 /* SMP Per-Processor Private Data */ -#define GPROC0_SEL 4 /* Task state process slot zero and up */ -#define GLDT_SEL 5 /* LDT - eventually one per process */ -#define GUSERLDT_SEL 6 /* User LDT */ -#define GTGATE_SEL 7 /* Process task switch gate */ -#define GBIOSLOWMEM_SEL 8 /* BIOS low memory access (must be entry 8) */ -#define GPANIC_SEL 9 /* Task state to consider panic from */ -#define GBIOSCODE32_SEL 10 /* BIOS interface (32bit Code) */ -#define GBIOSCODE16_SEL 11 /* BIOS interface (16bit Code) */ -#define GBIOSDATA_SEL 12 /* BIOS interface (Data) */ -#define GBIOSUTIL_SEL 13 /* BIOS interface (Utility) */ -#define GBIOSARGS_SEL 14 /* BIOS interface (Arguments) */ - - Note that those #defines are not selectors themselves, but - just a field INDEX of a selector, so they are exactly the - indices of the GDT. for example, an actual selector for the - kernel code (GCODE_SEL) has the value 0x08. - - The next step is to initialize the Interrupt Descriptor - Table (IDT). This table is to be referenced by the processor - when a software or hardware interrupt occurs. For example, to - make a system call, user application issues the INT - 0x80 instruction. This is a software interrupt, so - the processor's hardware looks up a record with index 0x80 in - the IDT. This record points to the routine that handles this - interrupt, in this particular case, this will be the kernel's - syscall gate. The IDT may have a maximum of 256 (0x100) - records. The kernel allocates NIDT records for the IDT, where - NIDT is the maximum (256): - - sys/i386/i386/machdep.c: -static struct gate_descriptor idt0[NIDT]; -struct gate_descriptor *idt = &idt0[0]; /* interrupt descriptor table */ - - - For each interrupt, an appropriate handler is set. The - syscall gate for INT 0x80 is set as - well: - - sys/i386/i386/machdep.c: - setidt(0x80, &IDTVEC(int0x80_syscall), - SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL)); - - So when a userland application issues the INT - 0x80 instruction, control will transfer to the - function _Xint0x80_syscall, which is in - the kernel code segment and will be executed with supervisor - privileges. - - Console and DDB are then initialized: - - sys/i386/i386/machdep.c: - cninit(); -/* skipped */ -#ifdef DDB - kdb_init(); - if (boothowto & RB_KDB) - Debugger("Boot flags requested debugger"); -#endif - - The Task State Segment is another x86 protected mode - structure, the TSS is used by the hardware to store task - information when a task switch occurs. - - The Local Descriptors Table is used to reference userland - code and data. Several selectors are defined to point to the - LDT, they are the system call gates and the user code and data - selectors: - - /usr/include/machine/segments.h -#define LSYS5CALLS_SEL 0 /* forced by intel BCS */ -#define LSYS5SIGR_SEL 1 -#define L43BSDCALLS_SEL 2 /* notyet */ -#define LUCODE_SEL 3 -#define LSOL26CALLS_SEL 4 /* Solaris >= 2.6 system call gate */ -#define LUDATA_SEL 5 -/* separate stack, es,fs,gs sels ? */ -/* #define LPOSIXCALLS_SEL 5*/ /* notyet */ -#define LBSDICALLS_SEL 16 /* BSDI system call gate */ -#define NLDT (LBSDICALLS_SEL + 1) - - - Next, proc0's Process Control Block (struct - pcb) structure is initialized. proc0 is a - struct proc structure that describes a kernel - process. It is always present while the kernel is running, - therefore it is declared as global: - - sys/kern/kern_init.c: - struct proc proc0; - - The structure struct pcb is a part of a - proc structure. It is defined in - /usr/include/machine/pcb.h and has a - process's information specific to the i386 architecture, such as - registers values. - - - - <function>mi_startup()</function> - - This function performs a bubble sort of all the system - initialization objects and then calls the entry of each object - one by one: - - sys/kern/init_main.c: - for (sipp = sysinit; *sipp; sipp++) { - - /* ... skipped ... */ - - /* Call function */ - (*((*sipp)->func))((*sipp)->udata); - /* ... skipped ... */ - } - - Although the sysinit framework is described in the - Developers' Handbook, I will discuss the internals of it. - - Every system initialization object (sysinit object) is - created by calling a SYSINIT() macro. Let us take as example an - announce sysinit object. This object prints - the copyright message: - - sys/kern/init_main.c: -static void -print_caddr_t(void *data __unused) -{ - printf("%s", (char *)data); -} -SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright) - - The subsystem ID for this object is SI_SUB_COPYRIGHT - (0x0800001), which comes right after the SI_SUB_CONSOLE - (0x0800000). So, the copyright message will be printed out - first, just after the console initialization. - - Let us take a look at what exactly the macro - SYSINIT() does. It expands to a - C_SYSINIT() macro. The - C_SYSINIT() macro then expands to a static - struct sysinit structure declaration with - another DATA_SET macro call: - /usr/include/sys/kernel.h: - #define C_SYSINIT(uniquifier, subsystem, order, func, ident) \ - static struct sysinit uniquifier ## _sys_init = { \ subsystem, \ - order, \ func, \ ident \ }; \ DATA_SET(sysinit_set,uniquifier ## - _sys_init); - -#define SYSINIT(uniquifier, subsystem, order, func, ident) \ - C_SYSINIT(uniquifier, subsystem, order, \ - (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)ident) - - The DATA_SET() macro expands to a - MAKE_SET(), and that macro is the point where - the all sysinit magic is hidden: - - /usr/include/linker_set.h -#define MAKE_SET(set, sym) \ - static void const * const __set_##set##_sym_##sym = &sym; \ - __asm(".section .set." #set ",\"aw\""); \ - __asm(".long " #sym); \ - __asm(".previous") -#endif -#define TEXT_SET(set, sym) MAKE_SET(set, sym) -#define DATA_SET(set, sym) MAKE_SET(set, sym) - - In our case, the following declaration will occur: - - static struct sysinit announce_sys_init = { - SI_SUB_COPYRIGHT, - SI_ORDER_FIRST, - (sysinit_cfunc_t)(sysinit_nfunc_t) print_caddr_t, - (void *) copyright -}; - -static void const *const __set_sysinit_set_sym_announce_sys_init = - &announce_sys_init; -__asm(".section .set.sysinit_set" ",\"aw\""); -__asm(".long " "announce_sys_init"); -__asm(".previous"); - - The first __asm instruction will create - an ELF section within the kernel's executable. This will happen - at kernel link time. The section will have the name - .set.sysinit_set. The content of this section is one 32-bit - value, the address of announce_sys_init structure, and that is - what the second __asm is. The third - __asm instruction marks the end of a section. - If a directive with the same section name occured before, the - content, i.e. the 32-bit value, will be appended to the existing - section, so forming an array of 32-bit pointers. - - Running objdump on a kernel - binary, you may notice the presence of such small - sections: - - &prompt.user; objdump -h /kernel - 7 .set.cons_set 00000014 c03164c0 c03164c0 002154c0 2**2 - CONTENTS, ALLOC, LOAD, DATA - 8 .set.kbddriver_set 00000010 c03164d4 c03164d4 002154d4 2**2 - CONTENTS, ALLOC, LOAD, DATA - 9 .set.scrndr_set 00000024 c03164e4 c03164e4 002154e4 2**2 - CONTENTS, ALLOC, LOAD, DATA - 10 .set.scterm_set 0000000c c0316508 c0316508 00215508 2**2 - CONTENTS, ALLOC, LOAD, DATA - 11 .set.sysctl_set 0000097c c0316514 c0316514 00215514 2**2 - CONTENTS, ALLOC, LOAD, DATA - 12 .set.sysinit_set 00000664 c0316e90 c0316e90 00215e90 2**2 - CONTENTS, ALLOC, LOAD, DATA - - This screen dump shows that the size of .set.sysinit_set - section is 0x664 bytes, so 0x664/sizeof(void - *) sysinit objects are compiled into the kernel. The - other sections such as .set.sysctl_set - represent other linker sets. - - By defining a variable of type struct - linker_set the content of - .set.sysinit_set section will be collected - into that variable: - sys/kern/init_main.c: - extern struct linker_set sysinit_set; /* XXX */ - - The struct linker_set is defined as - follows: - - /usr/include/linker_set.h: - struct linker_set { - int ls_length; - void *ls_items[1]; /* really ls_length of them, trailing NULL */ -}; - - The first node will be equal to the number of a sysinit - objects, and the second node will be a NULL-terminated array of - pointers to them. - - Returning to the mi_startup() - discussion, it is must be clear now, how the sysinit objects are - being organized. The mi_startup() function - sorts them and calls each. The very last object is the system - scheduler: - - /usr/include/sys/kernel.h: -enum sysinit_sub_id { - SI_SUB_DUMMY = 0x0000000, /* not executed; for linker*/ - SI_SUB_DONE = 0x0000001, /* processed*/ - SI_SUB_CONSOLE = 0x0800000, /* console*/ - SI_SUB_COPYRIGHT = 0x0800001, /* first use of console*/ -... - SI_SUB_RUN_SCHEDULER = 0xfffffff /* scheduler: no return*/ -}; - - The system scheduler sysinit object is defined in the file - sys/vm/vm_glue.c, and the entry point for - that object is scheduler(). That function - is actually an infinite loop, and it represents a process with - PID 0, the swapper process. The proc0 structure, mentioned - before, is used to describe it. - - The first user process, called init, is - created by the sysinit object init: - - sys/kern/init_main.c: -static void -create_init(const void *udata __unused) -{ - int error; - int s; - - s = splhigh(); - error = fork1(&proc0, RFFDG | RFPROC, &initproc); - if (error) - panic("cannot fork init: %d\n", error); - initproc->p_flag |= P_INMEM | P_SYSTEM; - cpu_set_fork_handler(initproc, start_init, NULL); - remrunqueue(initproc); - splx(s); -} -SYSINIT(init,SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL) - - The create_init() allocates a new process - by calling fork1(), but does not mark it - runnable. When this new process is scheduled for execution by the - scheduler, the start_init() will be called. - That function is defined in init_main.c. It - tries to load and exec the init binary, - probing /sbin/init first, then - /sbin/oinit, - /sbin/init.bak, and finally - /stand/sysinstall: - - sys/kern/init_main.c: -static char init_path[MAXPATHLEN] = -#ifdef INIT_PATH - __XSTRING(INIT_PATH); -#else - "/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall"; -#endif - - - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/chapters.ent b/en_US.ISO8859-1/books/arch-handbook/chapters.ent deleted file mode 100644 index 38db6f5f93..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/chapters.ent +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml deleted file mode 100644 index 61a425b8bd..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml +++ /dev/null @@ -1,392 +0,0 @@ - - - - Writing FreeBSD Device Drivers - - This chapter was written by &a.murray; with selections from a - variety of sources including the intro(4) manual page by - &a.joerg;. - - - Introduction - This chapter provides a brief introduction to writing device - drivers for FreeBSD. A device in this context is a term used - mostly for hardware-related stuff that belongs to the system, - like disks, printers, or a graphics display with its keyboard. - A device driver is the software component of the operating - system that controls a specific device. There are also - so-called pseudo-devices where a device driver emulates the - behavior of a device in software without any particular - underlying hardware. Device drivers can be compiled into the - system statically or loaded on demand through the dynamic kernel - linker facility `kld'. - - 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 - /dev in the filesystem hierarchy. - In releases of FreeBSD older than 5.0-RELEASE, where - &man.devfs.5; support is not integrated into FreeBSD, - each device node must be - created statically and independent of the existence of the - associated device driver. Most device nodes on the system are - created by running MAKEDEV. - - Device drivers can roughly be broken down into two - categories; character and network device drivers. - - - - - Dynamic Kernel Linker Facility - KLD - - 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. - - The kld interface is used through the following - privileged commands: - - - kldload - loads a new kernel - module - kldunload - unloads a kernel - module - kldstat - lists the currently loaded - modules - - - - Skeleton Layout of a kernel module - -/* - * 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); - - - - Makefile - - FreeBSD provides a makefile include that you can use to - quickly compile your kernel addition. - - SRCS=skeleton.c -KMOD=skeleton - -.include <bsd.kmod.mk> - - Simply running make with this makefile - will create a file skeleton.ko that can - be loaded into your system by typing: -&prompt.root; kldload -v ./skeleton.ko - - - - - - Accessing a device driver - - 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 /dev/MAKEDEV - 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 mknod. - - - - Creating static device nodes - - The mknod command requires four - arguments to create a device node. You must specify the name - of the device node, the type of device, the major number of - the device, and the minor number of the device. - - - - Dynamic device nodes - - The device filesystem, or devfs, provides access to the - kernel's device namespace in the global filesystem namespace. - This eliminates the problems of potentially having a device - driver without a static device node, or a device node without - an installed device driver. Devfs is still a work in - progress, but it is already working quite nicely. - - - - - - Character Devices - - 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. - - 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. - - /* - * 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(&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); - - To install this driver you will first need to make a node on - your filesystem with a command such as: - - &prompt.root; mknod /dev/echo c 33 0 - - With this driver loaded you should now be able to type - something like: - - &prompt.root; echo -n "Test Data" > /dev/echo -&prompt.root; cat /dev/echo -Test Data - - Real hardware devices in the next chapter.. - - Additional Resources - - Dynamic - Kernel Linker (KLD) Facility Programming Tutorial - - Daemonnews October 2000 - How - to Write Kernel Drivers with NEWBUS - Daemonnews July - 2000 - - - - - - Network Drivers - - 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). - - man ifnet(), loopback device, Bill Paul's drivers, - etc.. - - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml deleted file mode 100644 index 55469129ff..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/isa/chapter.sgml +++ /dev/null @@ -1,2487 +0,0 @@ - - - - ISA device drivers - - - - This chapter was written by &a.babkin; Modifications for the - handbook made by &a.murray;, &a.wylie;, and &a.logo;. - - - - - Synopsis - - 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. - - - - Basic information - - A typical ISA driver would need the following include - files: - -#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> - - They describe the things specific to the ISA and generic - bus subsystem. - - The bus subsystem is implemented in an object-oriented - fashion, its main structures are accessed by associated method - functions. - - 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: - - - - static void xxx_isa_identify (driver_t *, - device_t); 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. - - - - static int xxx_isa_probe (device_t - dev); 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. - - - - static int xxx_isa_attach (device_t - dev); Attach and initialize device. - - - - static int xxx_isa_detach (device_t - dev); Detach device before unloading the driver - module. - - - - static int xxx_isa_shutdown (device_t - dev); Execute shutdown of the device before - system shutdown. - - - - static int xxx_isa_suspend (device_t - dev); Suspend the device before the system goes - to the power-save state. May also abort transition to the - power-save state. - - - - static int xxx_isa_resume (device_t - dev); Resume the device activity after return - from power-save state. - - - - - xxx_isa_probe() and - xxx_isa_attach() are mandatory, the rest of - the routines are optional, depending on the device's - needs. - - The driver is linked to the system with the following set of - descriptions. - - /* 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); - - Here struct xxx_softc 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. - - If the driver is implemented as a loadable module then - load_function() is called to do - driver-specific initialization or clean-up when the driver is - loaded or unloaded and load_argument is passed as one of its - arguments. If the driver does not support dynamic loading (in - other words it must always be linked into the kernel) then these - values should be set to 0 and the last definition would look - like: - - DRIVER_MODULE(xxx, isa, xxx_isa_driver, - xxx_devclass, 0, 0); - - 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: - - 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 */ - }; - - If the driver does not support PnP devices it still needs - an empty PnP ID table, like: - - static struct isa_pnp_id xxx_pnp_ids[] = { - { 0, NULL }, /* end of table */ - }; - - - - - Device_t pointer - - Device_t 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: - - - - device_t - device_get_parent(dev) Get the parent bus of a - device. - - driver_t - device_get_driver(dev) Get pointer to its driver - structure. - - char - *device_get_name(dev) Get the driver name, such - as "xxx" for our example. - - int device_get_unit(dev) - Get the unit number (units are numbered from 0 for the - devices associated with each driver). - - char - *device_get_nameunit(dev) Get the device name - including the unit number, such as xxx0, xxx1 and so - on. - - char - *device_get_desc(dev) Get the device - description. Normally it describes the exact model of device - in human-readable form. - - device_set_desc(dev, - desc) Set the description. This makes the device - description point to the string desc which may not be - deallocated or changed after that. - - device_set_desc_copy(dev, - desc) Set the description. The description is - copied into an internal dynamically allocated buffer, so the - string desc may be changed afterwards without adverse - effects. - - void - *device_get_softc(dev) Get pointer to the device - descriptor (struct xxx_softc) - associated with this device. - - u_int32_t - device_get_flags(dev) Get the flags specified for - the device in the configuration file. - - - - A convenience function device_printf(dev, fmt, - ...) may be used to print the messages from the - device driver. It automatically prepends the unitname and - colon to the message. - - The device_t methods are implemented in the file - kern/bus_subr.c. - - - - - Configuration file and the order of identifying and probing - during auto-configuration - - The ISA devices are described in the kernel configuration file - like: - - device xxx0 at isa? port 0x300 irq 10 drq 5 - iomem 0xd0000 flags 0x1 sensitive - - The values of port, IRQ and so on are converted to the - resource values associated with the device. They are optional, - depending on the device's needs and abilities for - auto-configuration. For example, some devices do not need DRQ - at all and some allow the driver to read the IRQ setting from - the device configuration ports. If a machine has multiple ISA - buses the exact bus may be specified in the configuration - line, like isa0 or isa1, otherwise the device would be - searched for on all the ISA buses. - - 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. - - 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: - device xxx0 at isa? then only - one device will be configured. - - 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: - - device xxx at isa? - - If a driver supports both auto-identified and legacy - devices and both kinds are installed at once in one machine - then it is enough to describe in the config file the legacy - devices only. The auto-identified devices will be added - automatically. - - When an ISA bus is auto-configured the events happen as - follows: - - 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. - - The PnP devices are put to sleep using the PnP protocol to - prevent them from being probed as legacy devices. - - 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. - - The probe and attach routines of all non-PNP devices are - called likewise. - - 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. - - Then for each PnP device the probe routines of all the - present ISA drivers are called. The first one that claims the - device gets attached. It is possible that multiple drivers - would claim the device with different priority; in this case, the - highest-priority driver wins. The probe routines must call - ISA_PNP_PROBE() 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 ISA_PNP_PROBE(), at - least with an empty PnP ID table to return failure on unknown - PnP devices. - - The probe routine returns a positive value (the error - code) on error, zero or negative value on success. - - 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. - - 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. - - Because the PnP devices are disabled when probing the - legacy devices they will not be attached twice (once as legacy - and once as PnP). But in case of device-dependent identify - routines it is the responsibility of the driver to make sure - that the same device will not be attached by the driver twice: - once as legacy user-configured and once as - auto-identified. - - 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. - - Other unusual configurations may be accommodated by - accessing the configuration resources directly with functions - of families resource_query_*() and - resource_*_value(). Their implementations - are located in kern/subr_bus.c. 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. - - - - - Resources - - The information that a user enters into the kernel - configuration file is processed and passed to the kernel as - configuration resources. This information is parsed by the bus - configuration code and transformed into a value of structure - device_t and the bus resources associated with it. The drivers - may access the configuration resources directly using - functions resource_* for more complex cases of - configuration. However, generally this is neither needed nor recommended, - so this issue is not discussed further here. - - 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: - - - - SYS_RES_IRQ - interrupt - number - - - - SYS_RES_DRQ - ISA DMA channel - number - - - - SYS_RES_MEMORY - range of - device memory mapped into the system memory space - - - - - SYS_RES_IOPORT - range of - device I/O registers - - - - The enumeration within types starts from 0, so if a device - has two memory regions it would have resources of type - SYS_RES_MEMORY numbered 0 and 1. The resource type has - nothing to do with the C language type, all the resource - values have the C language type unsigned long and must be - cast as necessary. The resource numbers do not have to be - contiguous, although for ISA they normally would be. The - permitted resource numbers for ISA devices are: - - IRQ: 0-1 - DRQ: 0-1 - MEMORY: 0-3 - IOPORT: 0-7 - - All the resources are represented as ranges, with a start - value and count. For IRQ and DRQ resources the count would - normally be equal to 1. The values for memory refer to the - physical addresses. - - Three types of activities can be performed on - resources: - - - set/get - allocate/release - activate/deactivate - - - Setting sets the range used by the resource. Allocation - reserves the requested range that no other driver would be - able to reserve it (and checking that no other driver reserved - this range already). Activation makes the resource accessible - to the driver by doing whatever is necessary for that (for - example, for memory it would be mapping into the kernel - virtual address space). - - The functions to manipulate resources are: - - - - int bus_set_resource(device_t dev, int type, - int rid, u_long start, u_long count) - - Set a range for a resource. Returns 0 if successful, - error code otherwise. Normally, this function will - return an error only if one of type, - rid, start or - count has a value that falls out of the - permitted range. - - - - dev - driver's device - - - type - type of resource, SYS_RES_* - - - rid - resource number (ID) within type - - - start, count - resource range - - - - - - int bus_get_resource(device_t dev, int type, - int rid, u_long *startp, u_long *countp) - - Get the range of resource. Returns 0 if successful, - error code if the resource is not defined yet. - - - - 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) - - Convenience functions to get only the start or - count. Return 0 in case of error, so if the resource start - has 0 among the legitimate values it would be impossible - to tell if the value is 0 or an error occurred. Luckily, - no ISA resources for add-on drivers may have a start value - equal to 0. - - - - void bus_delete_resource(device_t dev, int - type, int rid) - Delete a resource, make it undefined. - - - - struct resource * - bus_alloc_resource(device_t dev, int type, int *rid, - u_long start, u_long end, u_long count, u_int - flags) - - Allocate a resource as a range of count values not - allocated by anyone else, somewhere between start and - end. Alas, alignment is not supported. If the resource - was not set yet it is automatically created. The special - values of start 0 and end ~0 (all ones) means that the - fixed values previously set by - bus_set_resource() must be used - instead: start and count as themselves and - end=(start+count), in this case if the resource was not - defined before then an error is returned. Although rid is - passed by reference it is not set anywhere by the resource - allocation code of the ISA bus. (The other buses may use a - different approach and modify it). - - - - Flags are a bitmap, the flags interesting for the caller - are: - - - - RF_ACTIVE - causes the resource - to be automatically activated after allocation. - - - - RF_SHAREABLE - resource may be - shared at the same time by multiple drivers. - - - - RF_TIMESHARE - 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. - - - - Returns 0 on error. The allocated values may be - obtained from the returned handle using methods - rhand_*(). - - - int bus_release_resource(device_t dev, int - type, int rid, struct resource *r) - - - - Release the resource, r is the handle returned by - bus_alloc_resource(). Returns 0 on - success, error code otherwise. - - - - int bus_activate_resource(device_t dev, int - type, int rid, struct resource *r) - int bus_deactivate_resource(device_t dev, int - type, int rid, struct resource *r) - - - - 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. - - - - int bus_setup_intr(device_t dev, struct - resource *r, int flags, driver_intr_t *handler, void *arg, - void **cookiep) int - bus_teardown_intr(device_t dev, struct resource *r, void - *cookie) - - - - Associate or de-associate the interrupt handler with a - device. Return 0 on success, error code otherwise. - - - - r - the activated resource handler describing the - IRQ - flags - the interrupt priority level, one of: - - - - INTR_TYPE_TTY - terminals and - other likewise character-type devices. To mask them - use spltty(). - - - (INTR_TYPE_TTY | - INTR_TYPE_FAST) - 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 spltty(). - - - INTR_TYPE_BIO - block-type - devices, except those on the CAM controllers. To mask - them use splbio(). - - - INTR_TYPE_CAM - CAM (Common - Access Method) bus controllers. To mask them use - splcam(). - - - INTR_TYPE_NET - network - interface controllers. To mask them use - splimp(). - - - INTR_TYPE_MISC - - miscellaneous devices. There is no other way to mask - them than by splhigh() which - masks all interrupts. - - - - - - 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. - - - - handler - pointer to the handler - function, the type driver_intr_t is defined as void - driver_intr_t(void *) - - - arg - 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. - - - cookie[p] - the value received - from setup() is used to identify the - handler when passed to - teardown() - - - - A number of methods are defined to operate on the resource - handlers (struct resource *). Those of interest to the device - driver writers are: - - - - u_long rman_get_start(r) u_long - rman_get_end(r) Get the start and end of - allocated resource range. - - - void *rman_get_virtual(r) Get - the virtual address of activated memory resource. - - - - - - - Bus memory mapping - - In many cases data is exchanged between the driver and the - device through the memory. Two variants are possible: - - (a) memory is located on the device card - (b) memory is the main memory of the computer - - In case (a) the driver always copies the data back and - forth between the on-card memory and the main memory as - necessary. To map the on-card memory into the kernel virtual - address space the physical address and length of the on-card - memory must be defined as a SYS_RES_MEMORY resource. That - resource can then be allocated and activated, and its virtual - address obtained using - rman_get_virtual(). The older drivers - used the function pmap_mapdev() for this - purpose, which should not be used directly any more. Now it is - one of the internal steps of resource activation. - - Most of the ISA cards will have their memory configured - for physical location somewhere in range 640KB-1MB. Some of - the ISA cards require larger memory ranges which should be - placed somewhere under 16MB (because of the 24-bit address - limitation on the ISA bus). In that case if the machine has - more memory than the start address of the device memory (in - other words, they overlap) a memory hole must be configured at - the address range used by devices. Many BIOSes allow - configuration of a memory hole of 1MB starting at 14MB or - 15MB. FreeBSD can handle the memory holes properly if the BIOS - reports them properly (this feature may be broken on old BIOSes). - - In case (b) just the address of the data is sent to - the device, and the device uses DMA to actually access the - data in the main memory. Two limitations are present: First, - ISA cards can only access memory below 16MB. Second, the - contiguous pages in virtual address space may not be - contiguous in physical address space, so the device may have - to do scatter/gather operations. The bus subsystem provides - ready solutions for some of these problems, the rest has to be - done by the drivers themselves. - - 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. - - Tags are organized into a tree-like hierarchy with - inheritance of the properties. A child tag inherits all the - requirements of its parent tag, and may make them more strict - but never more loose. - - 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. - - The tags can be used to create a map in two ways. - - First, a chunk of contiguous memory conformant with the - tag requirements may be allocated (and later may be - freed). This is normally used to allocate relatively - long-living areas of memory for communication with the - device. Loading of such memory into a map is trivial: it is - always considered as one chunk in the appropriate physical - memory range. - - Second, an arbitrary area of virtual memory may be loaded - into a map. Each page of this memory will be checked for - conformance to the map requirement. If it conforms then it is - left at its original location. If it is not then a fresh - conformant 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 a per-transfer - basis: buffer for each transfer would be loaded, transfer done - and buffer unloaded. - - The functions working on the DMA memory are: - - - - 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) - - Create a new tag. Returns 0 on success, the error code - otherwise. - - - - parent - parent tag, or NULL to - create a top-level tag. - - - - alignment - - 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 - bus_dmamem_alloc() but not - bus_dmamap_create() calls. - - - - boundary - physical address - boundary that must not be crossed when allocating the - memory. Use value 0 for no boundary. Applies only to - the future bus_dmamem_alloc() but - not bus_dmamap_create() 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. - - - - lowaddr, highaddr - the names - are slightly misleading; these values are used to limit - the permitted range of physical addresses used to - allocate the memory. The exact meaning varies depending - on the planned future use: - - - - For bus_dmamem_alloc() all - the addresses from 0 to lowaddr-1 are considered - permitted, the higher ones are forbidden. - - - - For bus_dmamap_create() 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. - - - - For the ISA devices the normal values (with no - filter function) are: - lowaddr = BUS_SPACE_MAXADDR_24BIT - highaddr = BUS_SPACE_MAXADDR - - - - - - - filter, filterarg - the filter - function and its argument. If NULL is passed for filter - then the whole range [lowaddr, highaddr] is considered - unaccessible when doing - bus_dmamap_create(). 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: int filterfunc(void *arg, - bus_addr_t paddr). It must return 0 if the - page is accessible, non-zero otherwise. - - - - maxsize - the maximal size of - memory (in bytes) that may be allocated through this - tag. In case it is difficult to estimate or could be - arbitrarily big, the value for ISA devices would be - BUS_SPACE_MAXSIZE_24BIT. - - - - nsegments - maximal number of - scatter-gather segments supported by the device. If - unrestricted then the value BUS_SPACE_UNRESTRICTED - should be used. This value is recommended for the parent - tags, the actual restrictions would then be specified - for the descendant tags. Tags with nsegments equal to - BUS_SPACE_UNRESTRICTED may not be used to actually load - maps, they may be used only as parent tags. The - practical limit for nsegments seems to be about 250-300, - higher values will cause kernel stack overflow (the hardware - can not normally support that many - scatter-gather buffers anyway). - - - - maxsegsz - maximal size of a - scatter-gather segment supported by the device. The - maximal value for ISA device would be - BUS_SPACE_MAXSIZE_24BIT. - - - - flags - a bitmap of flags. The - only interesting flags are: - - - - BUS_DMA_ALLOCNOW - requests - to allocate all the potentially needed bounce pages - when creating the tag. - - - - BUS_DMA_ISA - 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. - - - - - - dmat - pointer to the storage - for the new tag to be returned. - - - - - - - - int bus_dma_tag_destroy(bus_dma_tag_t - dmat) - - Destroy a tag. Returns 0 on success, the error code - otherwise. - - dmat - the tag to be destroyed. - - - - - int bus_dmamem_alloc(bus_dma_tag_t dmat, - void** vaddr, int flags, bus_dmamap_t - *mapp) - - 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 - bus_dmamap_load() before being used to get - the physical address of the memory. - - - - - - - dmat - the tag - - - - - vaddr - pointer to the storage - for the kernel virtual address of the allocated area - to be returned. - - - - - flags - a bitmap of flags. The only interesting flag is: - - - - - BUS_DMA_NOWAIT - if the - memory is not immediately available return the - error. If this flag is not set then the routine - is allowed to sleep until the memory - becomes available. - - - - - - - mapp - pointer to the storage - for the new map to be returned. - - - - - - - - void bus_dmamem_free(bus_dma_tag_t dmat, void - *vaddr, bus_dmamap_t map) - - - Free the memory allocated by - bus_dmamem_alloc(). At present, - freeing of the memory allocated with ISA restrictions is - not implemented. Because of this the recommended model - of use is to keep and re-use the allocated areas for as - long as possible. Do not lightly free some area and then - shortly allocate it again. That does not mean that - bus_dmamem_free() should not be - used at all: hopefully it will be properly implemented - soon. - - - - - dmat - the tag - - - - - vaddr - the kernel virtual - address of the memory - - - - - map - the map of the memory (as - returned from - bus_dmamem_alloc()) - - - - - - - - int bus_dmamap_create(bus_dma_tag_t dmat, int - flags, bus_dmamap_t *mapp) - - - Create a map for the tag, to be used in - bus_dmamap_load() later. Returns 0 - on success, the error code otherwise. - - - - - dmat - the tag - - - - - flags - theoretically, a bit map - of flags. But no flags are defined yet, so at present - it will be always 0. - - - - - mapp - pointer to the storage - for the new map to be returned - - - - - - - - int bus_dmamap_destroy(bus_dma_tag_t dmat, - bus_dmamap_t map) - - - Destroy a map. Returns 0 on success, the error code otherwise. - - - - - - dmat - the tag to which the map is associated - - - - - map - the map to be destroyed - - - - - - - - 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) - - - Load a buffer into the map (the map must be previously - created by bus_dmamap_create() or - bus_dmamem_alloc()). 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. - - - - - - dmat - the tag - - - - - map - the map - - - - - buf - kernel virtual address of - the buffer - - - - - buflen - length of the buffer - - - - - callback, - callback_arg - the callback function and - its argument - - - - - - The prototype of callback function is: - - - void callback(void *arg, bus_dma_segment_t - *seg, int nseg, int error) - - - - - - arg - the same as callback_arg - passed to bus_dmamap_load() - - - - - seg - array of the segment - descriptors - - - - - nseg - number of descriptors in - array - - - - - error - indication of the - segment number overflow: if it is set to EFBIG then - the buffer did not fit into the maximal number of - segments permitted by the tag. In this case only the - permitted number of descriptors will be in the - array. Handling of this situation is up to the - driver: depending on the desired semantics it can - either consider this an error or split the buffer in - two and handle the second part separately - - - - - - Each entry in the segments array contains the fields: - - - - - - - ds_addr - physical bus address - of the segment - - - - - ds_len - length of the segment - - - - - - - - - void bus_dmamap_unload(bus_dma_tag_t dmat, - bus_dmamap_t map) - - unload the map. - - - - - - dmat - tag - - - - - map - loaded map - - - - - - - - - void bus_dmamap_sync (bus_dma_tag_t dmat, - bus_dmamap_t map, bus_dmasync_op_t op) - - - 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. - - - - - - dmat - tag - - - - - map - loaded map - - - - - op - type of synchronization - operation to perform: - - - - - - - - BUS_DMASYNC_PREREAD - before - reading from device into buffer - - - - - BUS_DMASYNC_POSTREAD - after - reading from device into buffer - - - - - BUS_DMASYNC_PREWRITE - before - writing the buffer to device - - - - - BUS_DMASYNC_POSTWRITE - after - writing the buffer to device - - - - - - - - - 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 bus_dmamem_alloc(). - - - Before calling the callback function from - bus_dmamap_load() 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. - - - 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. - - - If the hardware does not support scatter-gather at all or - the driver wants to support some buffer size even if it is - heavily fragmented then the solution is to allocate a - contiguous buffer in the driver and use it as intermediate - storage if the original buffer does not fit. - - - 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. - - - For a buffer which stays practically fixed during all the - time between attachment and detachment of a device: - - bus_dmamem_alloc -> bus_dmamap_load -> ...use buffer... -> - -> bus_dmamap_unload -> bus_dmamem_free - - - For a buffer that changes frequently and is passed from - outside the driver: - - - 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 - - - - When loading a map created by - bus_dmamem_alloc() the passed address - and size of the buffer must be the same as used in - bus_dmamem_alloc(). 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. - - - A typical example would be: - - - 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); - - - Looks a bit long and complicated but that is the way to do - it. The practical consequence is: if multiple memory areas - are allocated always together it would be a really good idea - to combine them all into one structure and allocate as one - (if the alignment and boundary limitations permit). - - - When loading an arbitrary buffer into the map created by - bus_dmamap_create() special measures - must be taken to synchronize with the callback in case it - would be delayed. The code would look like: - - - { - 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); - } - - - Two possible approaches for the processing of requests are: - - - 1. If requests are completed by marking them explicitly as - done (such as the CAM requests) then it would be simpler to - put all the further processing into the callback driver - which would mark the request when it is done. Then not much - extra synchronization is needed. For the flow control - reasons it may be a good idea to freeze the request queue - until this request gets completed. - - - 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 tsleep() called. Later - when the callback gets called it will do its processing and - check this synchronization flag. If it is set then the - callback should issue a wakeup. In this approach the - callback function could either do all the needed processing - (just like the previous case) or simply save the segments - array in the buffer descriptor. Then after callback - completes the calling function could use this saved segments - array and do all the processing. - - - - - - - - DMA - - - The Direct Memory Access (DMA) is implemented in the ISA bus - through the DMA controller (actually, two of them but that is - an irrelevant detail). To make the early ISA devices simple - and cheap the logic of the bus control and address - generation was concentrated in the DMA controller. - Fortunately, FreeBSD provides a set of functions that mostly - hide the annoying details of the DMA controller from the - device drivers. - - - - 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: - - - - void isa_dmacascade(int channel_number) - - - - All the further activity is done by programming the - device. When detaching the driver no DMA-related functions - need to be called. - - - - For the simpler devices things get more complicated. The - functions used are: - - - - - - - int isa_dma_acquire(int chanel_number) - - - 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. - - - - - - int isa_dma_release(int chanel_number) - - - Release a previously reserved DMA channel. No - transfers must be in progress when the channel is - released (in addition the device must not try to - initiate transfer after the channel is released). - - - - - - void isa_dmainit(int chan, u_int - bouncebufsize) - - - Allocate a bounce buffer for use with the specified - channel. The requested size of the buffer can not exceed - 64KB. This bounce buffer will be automatically used - later if a transfer buffer happens to be not - physically contiguous or outside of the memory - accessible by the ISA bus or crossing the 64KB - boundary. If the transfers will be always done from - buffers which conform to these conditions (such as - those allocated by - bus_dmamem_alloc() with proper - limitations) then isa_dmainit() - does not have to be called. But it is quite convenient - to transfer arbitrary data using the DMA controller. - The bounce buffer will automatically care of the - scatter-gather issues. - - - - - - chan - channel number - - - - - bouncebufsize - size of the - bounce buffer in bytes - - - - - - - - - - void isa_dmastart(int flags, caddr_t addr, u_int - nbytes, int chan) - - - 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 - isa_dmainit() 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. - - - - flags - a bitmask determining the type of operation to - be done. The direction bits B_READ and B_WRITE are mutually - exclusive. - - - - - - B_READ - read from the ISA bus into memory - - - - - B_WRITE - write from the memory to the ISA bus - - - - - 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 - isa_dmastart() will have to be - called again before initiating the next - transfer. Using B_RAW makes sense only if the bounce - buffer is not used. - - - - - - - - addr - virtual address of the buffer - - - - - 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. - - - - - chan - channel number - - - - - - void isa_dmadone(int flags, caddr_t addr, int - nbytes, int chan) - - - 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 - isa_dmastart(). Flag B_RAW is - permitted but it does not affect - isa_dmadone() in any way. - - - - - - int isa_dmastatus(int channel_number) - - - Returns the number of bytes left in the current transfer - to be transferred. In case the flag B_READ was set in - isa_dmastart() the number returned - will never be equal to zero. At the end of transfer it - will be automatically reset back to the length of - buffer. The normal use is to check the number of bytes - left after the device signals that the transfer is - completed. If the number of bytes is not 0 then something - probably went wrong with that transfer. - - - - - - int isa_dmastop(int channel_number) - - - Aborts the current transfer and returns the number of - bytes left untransferred. - - - - - - - xxx_isa_probe - - - - 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. - - - - 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. - - - - 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). - - - - 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 xxx_isa_attach(). If a - driver returns a negative value it can not be sure that it - will have the highest priority and its attach routine will - be called. So in this case it also must release all the - resources before returning and if necessary allocate them - again in the attach routine. When - xxx_isa_probe() returns 0 releasing the - resources before returning is also a good idea and a - well-behaved driver should do so. But in cases where there is - some problem with releasing the resources the driver is - allowed to keep resources between returning 0 from the probe - routine and execution of the attach routine. - - - - A typical probe routine starts with getting the device - descriptor and unit: - - - 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; - - - 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. - - - - pnperror=ISA_PNP_PROBE(device_get_parent(dev), dev, - xxx_pnp_ids); if(pnperror == ENXIO) return ENXIO; - - - - 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 - device_set_desc(). - - - - If a driver supports only PnP devices then the condition - would look like: - - - if(pnperror != 0) - return pnperror; - - - No special treatment is required for the drivers which do not - support PnP because they pass an empty PnP ID table and will - always get ENXIO if called on a PnP card. - - - - 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. - - - - 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: - - - sc->port0 = bus_get_resource_start(dev, - SYS_RES_IOPORT, 0 /*rid*/); if(sc->port0 == 0) return ENXIO; - - - - The base port address is saved in the structure softc for - future use. If it will be used very often then calling the - resource function each time would be prohibitively slow. If - we do not get a port we just return an error. Some device - drivers can instead be clever and try to probe all the - possible ports, like this: - - - - /* 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; - - - Of course, normally the driver's - identify() routine should be used for - such things. But there may be one valid reason why it may be - better to be done in probe(): 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 the devices later. But the - identify() routines are called before - any probes, so they show no respect to the sensitive devices - and may upset them. - - - - 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. - - - - if(pnperror /* only for non-PnP devices */ - && bus_set_resource(dev, SYS_RES_IOPORT, 0, sc->port0, - XXX_PORT_COUNT)<0) - return ENXIO; - - - Finally allocate and activate a piece of port address space - (special values of start and end mean use those we set by - bus_set_resource()): - - - - 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; - - - 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. - - - - Normally drivers do not set up the interrupt handlers until - the attach routine. Instead they do probes in the polling - mode using the DELAY() function for - timeout. The probe routine must never hang forever, all the - waits for the device must be done with timeouts. If the - device does not respond within the time it is probably broken - or misconfigured and the driver must return error. When - determining the timeout interval give the device some extra - time to be on the safe side: although - DELAY() is supposed to delay for the - same amount of time on any machine it has some margin of - error, depending on the exact CPU. - - - - If the probe routine really wants to check that the - interrupts really work it may configure and probe the - interrupts too. But that is not recommended. - - - - /* implemented in some very device-specific way */ - if(error = xxx_probe_ports(sc)) - goto bad; /* will deallocate the resources before returning */ - - - - The function xxx_probe_ports() 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. - - - - if(pnperror) - device_set_desc(dev, "Our device model 1234"); - - - - 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. - - - - The memory address may be specified in the kernel - configuration file or on some devices it may be - pre-configured in non-volatile configuration registers. If - both sources are available and different, which one should - be used? Probably if the user bothered to set the address - explicitly in the kernel configuration file they know what - they are doing and this one should take precedence. An - example of implementation could be: - - - /* 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*/); - } - - - Resources for IRQ and DRQ are easy to check by analogy. - - - - If all went well then release all the resources and return success. - - - xxx_free_resources(sc); - return 0; - - - 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. - - - bad: - - xxx_free_resources(sc); - if(error) - return error; - else /* exact error is unknown */ - return ENXIO; - - - That would be all for the probe routine. Freeing of - resources is done from multiple places, so it is moved to a - function which may look like: - - -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; - } - } - - - - - xxx_isa_attach - - - 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. - - - The attach routine returns 0 if it completed successfully or - error code otherwise. - - - The attach routine starts just like the probe routine, - with getting some frequently used data into more accessible - variables. - - - struct xxx_softc *sc = device_get_softc(dev); - int unit = device_get_unit(dev); - int error = 0; - - 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). - - - 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); - - The DMA request channel (DRQ) is allocated likewise. To - initialize it use functions of the - isa_dma*() family. For example: - - - isa_dmacascade(sc->drq0); - - The interrupt request line (IRQ) is a bit - special. Besides allocation the driver's interrupt handler - should be associated with it. Historically in the old ISA - drivers the argument passed by the system to the interrupt - handler was the device unit number. But in modern drivers - the convention suggests passing the pointer to structure - softc. The important reason is that when the structures - softc are allocated dynamically then getting the unit number - from softc is easy while getting softc from the unit number is - difficult. Also this convention makes the drivers for - different buses look more uniform and allows them to share - the code: each bus gets its own probe, attach, detach and - other bus-specific routines while the bulk of the driver - code may be shared among them. - - - - 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; - - - - - If the device needs to make DMA to the main memory then - this memory should be allocated like described before: - - - 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); - - - After all the necessary resources are allocated the - device should be initialized. The initialization may include - testing that all the expected features are functional. - - if(xxx_initialize(sc) < 0) - goto bad; - - - 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: - - - device_printf(dev, "has on-card FIFO buffer of %d bytes\n", sc->fifosize); - - - If the initialization routine experiences any problems - then printing messages about them before returning error is - also recommended. - - 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. - - If all went well then return success. - - error = xxx_attach_subsystem(sc); - if(error) - goto bad; - - return 0; - - 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. - - bad: - - xxx_free_resources(sc); - if(error) - return error; - else /* exact error is unknown */ - return ENXIO; - - That would be all for the attach routine. - - - - - - xxx_isa_detach - - - If this function is present in the driver and the driver is - compiled as a loadable module then the driver gets the - ability to be unloaded. This is an important feature if the - hardware supports hot plug. But the ISA bus does not support - hot plug, so this feature is not particularly important for - the ISA devices. The ability to unload a driver may be - useful when debugging it, but in many cases installation of - the new version of the driver would be required only after - the old version somehow wedges the system and a reboot will be - needed anyway, so the efforts spent on writing the detach - routine may not be worth it. Another argument that - unloading would allow upgrading the drivers on a production - machine seems to be mostly theoretical. Installing a new - version of a driver is a dangerous operation which should - never be performed on a production machine (and which is not - permitted when the system is running in secure mode). Still, - the detach routine may be provided for the sake of - completeness. - - - - The detach routine returns 0 if the driver was successfully - detached or the error code otherwise. - - - - 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. - struct xxx_softc *sc = device_get_softc(dev); - int error; - - error = xxx_detach_subsystem(sc); - if(error) - return error; - - - Next the driver may want to reset the hardware to some - consistent state. That includes stopping any ongoing - transfers, disabling the DMA channels and interrupts to - avoid memory corruption by the device. For most of the - drivers this is exactly what the shutdown routine does, so - if it is included in the driver we can just call it. - - xxx_isa_shutdown(dev); - - - And finally release all the resources and return success. - xxx_free_resources(sc); - return 0; - - - - - - xxx_isa_shutdown - - - This routine is called when the system is about to be shut - down. It is expected to bring the hardware to some - consistent state. For most of the ISA devices no special - action is required, so the function is not really necessary - because the device will be re-initialized on reboot - anyway. But some devices have to be shut down with a special - procedure, to make sure that they will be properly detected - after soft reboot (this is especially true for many devices - with proprietary identification protocols). In any case - disabling DMA and interrupts in the device registers and - stopping any ongoing transfers is a good idea. The exact - action depends on the hardware, so we do not consider it here - in any detail. - - - - - xxx_intr - - - The interrupt handler is called when an interrupt is - received which may be from this particular device. The ISA - bus does not support interrupt sharing (except in some special - cases) so in practice if the interrupt handler is called - then the interrupt almost for sure came from its - device. Still, the interrupt handler must poll the device - registers and make sure that the interrupt was generated by - its device. If not it should just return. - - - - The old convention for the ISA drivers was getting the - device unit number as an argument. This is obsolete, and the - new drivers receive whatever argument was specified for them - in the attach routine when calling - bus_setup_intr(). By the new convention - it should be the pointer to the structure softc. So the - interrupt handler commonly starts as: - - - - static void - xxx_intr(struct xxx_softc *sc) - { - - - - - It runs at the interrupt priority level specified by the - interrupt type parameter of - bus_setup_intr(). That means that all - the other interrupts of the same type as well as all the - software interrupts are disabled. - - - - To avoid races it is commonly written as a loop: - - - - while(xxx_interrupt_pending(sc)) { - xxx_process_interrupt(sc); - xxx_acknowledge_interrupt(sc); - } - - - The interrupt handler has to acknowledge interrupt to the - device only but not to the interrupt controller, the system - takes care of the latter. - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml deleted file mode 100644 index 53af59a441..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/jail/chapter.sgml +++ /dev/null @@ -1,611 +0,0 @@ - - - - - Evan Sarmiento -
evms@cs.bu.edu
- - - - 2001 - Evan Sarmiento - - - The Jail Subsystem - - On most UNIX systems, root has omnipotent power. This promotes - insecurity. If an attacker were to gain root on a system, he would - have every function at his fingertips. In FreeBSD there are - sysctls which dilute the power of root, in order to minimize the - damage caused by an attacker. Specifically, one of these functions - is called secure levels. Similarly, another function which is - present from FreeBSD 4.0 and onward, is a utility called - &man.jail.8;. Jail chroots an - environment and sets certain restrictions on processes which are - forked from within. For example, a jailed process cannot affect - processes outside of the jail, utilize certain system calls, or - inflict any damage on the main computer. - - Jail is becoming the new security - model. People are running potentially vulnerable servers such as - Apache, BIND, and sendmail within jails, so that if an attacker - gains root within the Jail, it is only - an annoyance, and not a devastation. This article focuses on the - internals (source code) of Jail and - Jail NG. It will also suggest - improvements upon the jail code base which are already being - worked on. If you are looking for a how-to on setting up a - Jail, I suggest you look at my other - article in Sys Admin Magazine, May 2001, entitled "Securing - FreeBSD using Jail." - - - Architecture - - - Jail consists of two realms: the - user-space program, jail, and the code implemented within the - kernel: the jail() system call and associated - restrictions. I will be discussing the user-space program and - then how jail is implemented within the kernel. - - - Userland code - - The source for the user-land jail is located in - /usr/src/usr.sbin/jail, consisting of - one file, jail.c. The program takes these - arguments: the path of the jail, hostname, ip address, and the - command to be executed. - - - Data Structures - - In jail.c, the first thing I would - note is the declaration of an important structure - struct jail j; which was included from - /usr/include/sys/jail.h. - - The definition of the jail structure is: - -/usr/include/sys/jail.h: - -struct jail { - u_int32_t version; - char *path; - char *hostname; - u_int32_t ip_number; -}; - - As you can see, there is an entry for each of the - arguments passed to the jail program, and indeed, they are - set during it's execution. - - /usr/src/usr.sbin/jail.c -j.version = 0; -j.path = argv[1]; -j.hostname = argv[2]; - - - - - Networking - - One of the arguments passed to the Jail program is an IP - address with which the jail can be accessed over the - network. Jail translates the ip address given into network - byte order and then stores it in j (the jail structure). - - /usr/src/usr.sbin/jail/jail.c: -struct in.addr in; -... -i = inet.aton(argv[3], ); -... -j.ip_number = ntohl(in.s.addr); - - The - inet_aton3 - function "interprets the specified character string as an - Internet address, placing the address into the structure - provided." The ip number node in the jail structure is set - only when the ip address placed onto the in structure by - inet aton is translated into network byte order by - ntohl(). - - - - - Jailing The Process - - Finally, the userland program jails the process, and - executes the command specified. Jail now becomes an - imprisoned process itself and forks a child process which - then executes the command given using &man.execv.3; - - /usr/src/sys/usr.sbin/jail/jail.c -i = jail(); -... -i = execv(argv[4], argv + 4); - - As you can see, the jail function is being called, and - its argument is the jail structure which has been filled - with the arguments given to the program. Finally, the - program you specify is executed. I will now discuss how Jail - is implemented within the kernel. - - - - - Kernel Space - - We will now be looking at the file - /usr/src/sys/kern/kern_jail.c. This is - the file where the jail system call, appropriate sysctls, and - networking functions are defined. - - - sysctls - - In kern_jail.c, the following - sysctls are defined: - - /usr/src/sys/kern/kern_jail.c: - -int jail_set_hostname_allowed = 1; -SYSCTL_INT(_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW, - _set_hostname_allowed, 0, - "Processes in jail can set their hostnames"); - -int jail_socket_unixiproute_only = 1; -SYSCTL_INT(_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW, - _socket_unixiproute_only, 0, - "Processes in jail are limited to creating UNIX/IPv4/route sockets only -"); - -int jail_sysvipc_allowed = 0; -SYSCTL_INT(_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW, - _sysvipc_allowed, 0, - "Processes in jail can use System V IPC primitives"); - - Each of these sysctls can be accessed by the user - through the sysctl program. Throughout the kernel, these - specific sysctls are recognized by their name. For example, - the name of the first sysctl is - jail.set.hostname.allowed. - - - - &man.jail.2; system call - - Like all system calls, the &man.jail.2; system call takes - two arguments, struct proc *p and - struct jail_args - *uap. p is a pointer to a proc - structure which describes the calling process. In this - context, uap is a pointer to a structure which specifies the - arguments given to &man.jail.2; from the userland program - jail.c. When I described the userland - program before, you saw that the &man.jail.2; system call was - given a jail structure as its own argument. - - /usr/src/sys/kern/kern_jail.c: -int -jail(p, uap) - struct proc *p; - struct jail_args /* { - syscallarg(struct jail *) jail; - } */ *uap; - - Therefore, uap->jail would access the - jail structure which was passed to the system call. Next, - the system call copies the jail structure into kernel space - using the copyin() - function. copyin() takes three arguments: - the data which is to be copied into kernel space, - uap->jail, where to store it, - j and the size of the storage. The jail - structure uap->jail is copied into kernel - space and stored in another jail structure, - j. - - /usr/src/sys/kern/kern_jail.c: -error = copyin(uap->jail, , sizeof j); - - There is another important structure defined in - jail.h. It is the prison structure - (pr). The prison structure is used - exclusively within kernel space. The &man.jail.2; system call - copies everything from the jail structure onto the prison - structure. Here is the definition of the prison structure. - - /usr/include/sys/jail.h: -struct prison { - int pr_ref; - char pr_host[MAXHOSTNAMELEN]; - u_int32_t pr_ip; - void *pr_linux; -}; - - The jail() system call then allocates memory for a - pointer to a prison structure and copies data between the two - structures. - - /usr/src/sys/kern/kern_jail.c: - MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_WAITOK); - bzero((caddr_t)pr, sizeof *pr); - error = copyinstr(j.hostname, pr_host]]>, sizeof pr->pr_host, 0); - if (error) - goto bail; - - Finally, the jail system call chroots the path - specified. The chroot function is given two arguments. The - first is p, which represents the calling process, the second - is a pointer to the structure chroot args. The structure - chroot args contains the path which is to be chrooted. As - you can see, the path specified in the jail structure is - copied to the chroot args structure and used. - - /usr/src/sys/kern/kern_jail.c: -ca.path = j.path; -error = chroot(p, ); - - These next three lines in the source are very important, - as they specify how the kernel recognizes a process as - jailed. Each process on a Unix system is described by its - own proc structure. You can see the whole proc structure in - /usr/include/sys/proc.h. For example, - the p argument in any system call is actually a pointer to - that process' proc structure, as stated before. The proc - structure contains nodes which can describe the owner's - identity (p_cred), the process resource - limits (p_limit), and so on. In the - definition of the process structure, there is a pointer to a - prison structure. (p_prison). - - /usr/include/sys/proc.h: -struct proc { -... -struct prison *p_prison; -... -}; - - In kern_jail.c, the function then - copies the pr structure, which is filled with all the - information from the original jail structure, over to the - p->p_prison structure. It then does a - bitwise OR of p->p_flag with the constant - P_JAILED, meaning that the calling - process is now recognized as jailed. The parent process of - each process, forked within the jail, is the program jail - itself, as it calls the &man.jail.2; system call. When the - program is executed through execve, it inherits the - properties of its parents proc structure, therefore it has - the p->p_flag set, and the - p->p_prison structure is filled. - - /usr/src/sys/kern/kern_jail.c -p->p.prison = pr; -p->p.flag |= P.JAILED; - - When a process is forked from a parent process, the - &man.fork.2; system call deals differently with imprisoned - processes. In the fork system call, there are two pointers - to a proc structure p1 - and p2. p1 points to - the parent's proc structure and p2 points - to the child's unfilled proc - structure. After copying all relevant data between the - structures, &man.fork.2; checks if the structure - p->p_prison is filled on - p2. If it is, it increments the - pr.ref by one, and sets the - p_flag to one on the child process. - - /usr/src/sys/kern/kern_fork.c: -if (p2->p_prison) { - p2->p_prison->pr_ref++; - p2->p_flag |= P_JAILED; -} - - - - - - - Restrictions - - Throughout the kernel there are access restrictions relating - to jailed processes. Usually, these restrictions only check if - the process is jailed, and if so, returns an error. For - example: - - if (p->p_prison) - return EPERM; - - - SysV IPC - - System V IPC is based on messages. Processes can send each - other these messages which tell them how to act. The functions - which deal with messages are: msgsys, - msgctl, msgget, - msgsend and msgrcv. - Earlier, I mentioned that there were certain sysctls you could - turn on or off in order to affect the behavior of Jail. One of - these sysctls was jail_sysvipc_allowed. On - most systems, this sysctl is set to 0. If it were set to 1, it - would defeat the whole purpose of having a jail; privleged - users from within the jail would be able to affect processes - outside of the environment. The difference between a message - and a signal is that the message only consists of the signal - number. - - /usr/src/sys/kern/sysv_msg.c: - - - &man.msgget.3;: msgget returns (and possibly - creates) a message descriptor that designates a message queue - for use in other system calls. - - &man.msgctl.3;: Using this function, a process - can query the status of a message - descriptor. - - &man.msgsnd.3;: msgsnd sends a message to a - process. - - &man.msgrcv.3;: a process receives messages using - this function - - - - In each of these system calls, there is this - conditional: - - /usr/src/sys/kern/sysv msg.c: -if (!jail.sysvipc.allowed && p->p_prison != NULL) - return (ENOSYS); - - Semaphore system calls allow processes to synchronize - execution by doing a set of operations atomically on a set of - semaphores. Basically semaphores provide another way for - processes lock resources. However, process waiting on a - semaphore, that is being used, will sleep until the resources - are relinquished. The following semaphore system calls are - blocked inside a jail: semsys, - semget, semctl and - semop. - - /usr/src/sys/kern/sysv_sem.c: - - - - &man.semctl.2;(id, num, cmd, arg): - Semctl does the specified cmd on the semaphore queue - indicated by id. - - - &man.semget.2;(key, nsems, flag): - Semget creates an array of semaphores, corresponding to - key. - - Key and flag take on the same meaning as they - do in msgget. - - &man.semop.2;(id, ops, num): - Semop does the set of semaphore operations in the array of - structures ops, to the set of semaphores identified by - id. - - - System V IPC allows for processes to share - memory. Processes can communicate directly with each other by - sharing parts of their virtual address space and then reading - and writing data stored in the shared memory. These system - calls are blocked within a jailed environment: shmdt, - shmat, oshmctl, shmctl, shmget, and - shmsys. - - /usr/src/sys/kern/sysv shm.c: - - - &man.shmctl.2;(id, cmd, buf): - shmctl does various control operations on the shared memory - region identified by id. - - &man.shmget.2;(key, size, - flag): shmget accesses or creates a shared memory - region of size bytes. - - &man.shmat.2;(id, addr, flag): - shmat attaches a shared memory region identified by id to the - address space of a process. - - &man.shmdt.2;(addr): shmdt - detaches the shared memory region previously attached at - addr. - - - - - - Sockets - - Jail treats the &man.socket.2; system call and related - lower-level socket functions in a special manner. In order to - determine whether a certain socket is allowed to be created, - it first checks to see if the sysctl - jail.socket.unixiproute.only is set. If - set, sockets are only allowed to be created if the family - specified is either PF_LOCAL, - PF_INET or - PF_ROUTE. Otherwise, it returns an - error. - - /usr/src/sys/kern/uipc_socket.c: -int socreate(dom, aso, type, proto, p) -... -register struct protosw *prp; -... -{ - if (p->p_prison && jail_socket_unixiproute_only && - prp->pr_domain->dom_family != PR_LOCAL && prp->pr_domain->dom_family != PF_INET - && prp->pr_domain->dom_family != PF_ROUTE) - return (EPROTONOSUPPORT); -... -} - - - - - Berkeley Packet Filter - - The Berkeley Packet Filter provides a raw interface to - data link layers in a protocol independent fashion. The - function bpfopen() opens an Ethernet - device. There is a conditional which disallows any jailed - processes from accessing this function. - - /usr/src/sys/net/bpf.c: -static int bpfopen(dev, flags, fmt, p) -... -{ - if (p->p_prison) - return (EPERM); -... -} - - - - - Protocols - - There are certain protocols which are very common, such as - TCP, UDP, IP and ICMP. IP and ICMP are on the same level: the - network layer 2. There are certain precautions which are - taken in order to prevent a jailed process from binding a - protocol to a certain port only if the nam - parameter is set. nam is a pointer to a sockaddr structure, - which describes the address on which to bind the service. A - more exact definition is that sockaddr "may be used as a - template for reffering to the identifying tag and length of - each address"[2]. In the function in - pcbbind, sin is a - pointer to a sockaddr.in structure, which contains the port, - address, length and domain family of the socket which is to be - bound. Basically, this disallows any processes from jail to be - able to specify the domain family. - - /usr/src/sys/kern/netinet/in_pcb.c: -int in.pcbbind(int, nam, p) -... - struct sockaddr *nam; - struct proc *p; -{ - ... - struct sockaddr.in *sin; - ... - if (nam) { - sin = (struct sockaddr.in *)nam; - ... - if (sin->sin_addr.s_addr != INADDR_ANY) - if (prison.ip(p, 0, ->sin.addr.s_addr)) - return (EINVAL); - .... - } -... -} - - You might be wondering what function - prison_ip() does. prison.ip is given three - arguments, the current process (represented by - p), any flags, and an ip address. It - returns 1 if the ip address belongs to a jail or 0 if it does - not. As you can see from the code, if it is indeed an ip - address belonging to a jail, the protcol is not allowed to - bind to a certain port. - - /usr/src/sys/kern/kern_jail.c: -int prison_ip(struct proc *p, int flag, u_int32_t *ip) { - u_int32_t tmp; - - if (!p->p_prison) - return (0); - if (flag) - tmp = *ip; - else tmp = ntohl (*ip); - - if (tmp == INADDR_ANY) { - if (flag) - *ip = p->p_prison->pr_ip; - else *ip = htonl(p->p_prison->pr_ip); - return (0); - } - - if (p->p_prison->pr_ip != tmp) - return (1); - return (0); -} - - Jailed users are not allowed to bind services to an ip - which does not belong to the jail. The restriction is also - written within the function in_pcbbind: - - /usr/src/sys/net inet/in_pcb.c - if (nam) { - ... - lport = sin->sin.port; - ... if (lport) { - ... - if (p && p->p_prison) - prison = 1; - if (prison && - prison_ip(p, 0, ->sin_addr.s_addr)) - return (EADDRNOTAVAIL); - - - - - Filesystem - - Even root users within the jail are not allowed to set any - file flags, such as immutable, append, and no unlink flags, if - the securelevel is greater than 0. - - /usr/src/sys/ufs/ufs/ufs_vnops.c: -int ufs.setattr(ap) - ... -{ - if ((cred->cr.uid == 0) && (p->prison == NULL)) { - if ((ip->i_flags - & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) && - securelevel > 0) - return (EPERM); -} - - - - - - - Jail NG - - Jail NG is a "from-scratch re-implementation of Jail" by - Robert Watson, a FreeBSD committer. Some of the new features - include the ability to add processes to a jail, an improved - management tool, and per-jail sysctls. For example, you could - have sysvipc_permitted set on one jail while - another jail may be allowed to use System V IPC. You can - download the kernel patches and utilities for Jail NG from his - website at: - . - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml deleted file mode 100644 index b2ef1f689b..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/kobj/chapter.sgml +++ /dev/null @@ -1,298 +0,0 @@ - - - - Kernel Objects - - Kernel Objects, or Kobj 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. - - - Terminology - - - - Object - A set of data - data structure - data - allocation. - - - - Method - - An operation - function. - - - - Class - - One or more methods. - - - - Interface - - A standard set of one or more methods. - - - - - - - Kobj Operation - - 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. - - 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. - - These indirections can be visualized as the - following: - - object->cache<->class - - - - - Using Kobj - - - Structures - - struct kobj_method - - - - Functions - - 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); - - - - Macros - - KOBJ_CLASS_FIELDS -KOBJ_FIELDS -DEFINE_CLASS(name, methods, size) -KOBJMETHOD(NAME, FUNC) - - - - Headers - - <sys/param.h> -<sys/kobj.h> - - - - Creating an interface template - - The first step in using Kobj is to create an - Interface. Creating the interface involves creating a template - that the script - src/sys/kern/makeobjops.pl can use to - generate the header and code for the method declarations and - method lookup functions. - - Within this template the following keywords are used: - #include, INTERFACE, - CODE, METHOD, - STATICMETHOD, and - DEFAULT. - - The #include statement and what follows - it is copied verbatim to the head of the generated code - file. - - For example: - - #include <sys/foo.h> - - The INTERFACE keyword is used to define - the interface name. This name is concatenated with each method - name as [interface name]_[method name]. Its syntax is - INTERFACE [interface name];. - - For example: - - INTERFACE foo; - - The CODE keyword copies its arguments - verbatim into the code file. Its syntax is - CODE { [whatever] }; - - For example: - - CODE { - struct foo * foo_alloc_null(struct bar *) - { - return NULL; -} -}; - - The METHOD keyword describes a method. Its syntax is - METHOD [return type] [method name] { [object [, - arguments]] }; - - For example: - - METHOD int bar { - struct object *; - struct foo *; - struct bar; -}; - - The DEFAULT keyword may follow the - METHOD keyword. It extends the - METHOD key word to include the default - function for method. The extended syntax is - METHOD [return type] [method name] { - [object; [other arguments]] }DEFAULT [default - function]; - - For example: - - METHOD int bar { - struct object *; - struct foo *; - int bar; -} DEFAULT foo_hack; - - The STATICMETHOD keyword is used like - the METHOD keyword except the kobj data is not - at the head of the object structure so casting to kobj_t would - be incorrect. Instead STATICMETHOD relies on the Kobj data being - referenced as 'ops'. This is also useful for calling - methods directly out of a class's method table. - - Other complete examples: - - src/sys/kern/bus_if.m -src/sys/kern/device_if.m - - - - - Creating a Class - - 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 - DEFINE_CLASS(). 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 - KOBJMETHOD(). - - For example: - - DEFINE_CLASS(fooclass, foomethods, sizeof(struct foodata)); - -kobj_method_t foomethods[] = { - KOBJMETHOD(bar_doo, foo_doo), - KOBJMETHOD(bar_foo, foo_foo), - { NULL, NULL} -}; - - The class must be compiled. Depending on - the state of the system at the time that the class is to be - initialized a statically allocated cache, ops - table have to be used. This can be accomplished by - declaring a struct kobj_ops and using - kobj_class_compile_static(); otherwise, - kobj_class_compile() should be used. - - - - Creating an Object - - 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 - kobj_init() on the Kobj portion of it; - otherwise, you may use kobj_create() to - allocate and initialize the Kobj portion of the object - automatically. kobj_init() may also be - used to change the class that an object uses. - - To integrate Kobj into the object you should use the macro - KOBJ_FIELDS. - - For example - - struct foo_data { - KOBJ_FIELDS; - foo_foo; - foo_bar; -}; - - - - Calling Methods - - 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. - - For example, if the interface name was foo and the method - was bar then the call would be: - - [return value = ] FOO_BAR(object [, other parameters]); - - - - - Cleaning Up - - When an object allocated through - kobj_create() is no longer needed - kobj_delete() may be called on it, and - when a class is no longer being used - kobj_class_free() may be called on it. - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml deleted file mode 100644 index ed32ed61b5..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/locking/chapter.sgml +++ /dev/null @@ -1,313 +0,0 @@ - - - - Locking Notes - - This chapter is maintained by the FreeBSD SMP Next - Generation Project. Please direct any comments or suggestions - to its &a.smp;. - - - 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. - - - Mutexes - - 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. - - 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. - - Each mutex has several properties of interest: - - - - Variable Name - - The name of the struct mtx variable in - the kernel source. - - - - - Logical Name - - The name of the mutex assigned to it by - mtx_init. This name is displayed in - KTR trace messages and witness errors and warnings and is - used to distinguish mutexes in the witness code. - - - - - Type - - The type of the mutex in terms of the - MTX_* flags. The meaning for each - flag is related to its meaning as documented in - &man.mutex.9;. - - - - MTX_DEF - - A sleep mutex - - - - - MTX_SPIN - - A spin mutex - - - - - MTX_RECURSE - - This mutex is allowed to recurse. - - - - - - - - Protectees - - 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 - - - - - - Dependent Functions - - Functions that can only be called if this mutex is - held. - - - - - - Mutex List - - - - - Variable Name - Logical Name - Type - Protectees - Dependent Functions - - - - - - - sched_lock - sched lock - - MTX_SPIN | - MTX_RECURSE - - - _gmonparam, - cnt.v_swtch, - cp_time, - curpriority, - pscnt, - slpque, - itqueuebits, - itqueues, - rtqueuebits, - rtqueues, - queuebits, - queues, - idqueuebits, - idqueues, - switchtime, - switchticks - - - setrunqueue, - remrunqueue, - mi_switch, - chooseproc, - schedclock, - resetpriority, - updatepri, - maybe_resched, - cpu_switch, - cpu_throw, - need_resched, - resched_wanted, - clear_resched, - aston, - astoff, - astpending, - calcru, - proc_compare - - - - - - vm86pcb_lock - vm86pcb lock - - MTX_DEF - - - vm86pcb - - - vm86_bioscall - - - - - - Giant - Giant - - MTX_DEF | - MTX_RECURSE - - nearly everything - lots - - - - - callout_lock - callout lock - - MTX_SPIN | - MTX_RECURSE - - - callfree, - callwheel, - nextsoftcheck, - softticks, - ticks - - - - - - -
- - - - Shared Exclusive Locks - - These locks provide basic reader-writer type functionality - and may be held by a sleeping process. Currently they are - backed by &man.lockmgr.9;. - - - Shared Exclusive Lock List - - - - - Variable Name - Protectees - - - - - allproc_lock - - allproc - zombproc - pidhashtbl - nextpid - - proctree_lock - - - - - -
- - - - Atomically Protected Variables - - 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. - - - - - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/mac.ent b/en_US.ISO8859-1/books/arch-handbook/mac.ent deleted file mode 100644 index 6ead9b19ca..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/mac.ent +++ /dev/null @@ -1,122 +0,0 @@ - - - - - - - - - - Parameter - Description - Locking - - -'> - -struct label *label - char *element_name - char *element_data - size_t size - size_t *len - int *claimed -'> - - - - label - Label to be externalized - - - - element_name - Name of the policy whose label should be externalized - - - - element_data - Buffer; to be filled in with text representation of label - - - - size - Size of element_data - - - - len - To be filled in with the length of the string representing the - label data. - - - - claimed - Should be incremented when element_data - can be filled in. - - -'> - -Produce an externalized label based on the label structure passed. - An externalized label consists of a text representation of the label - contents that can be used with userland applications and read by the - user. Currently, all policies' externalize entry - points will be called, so the implementation should check the contents - of element_name before attempting to fill in - element_data. If - element_name does not match the name of your - policy, simply return 0. Only return nonzero - if an error occurs while externalizing the label data. Once the policy - fills in element_data, *claimed - should be incremented. -"> - -struct label *label - char *element_name - char *element_data - int *claimed -'> - - - - label - Label to be filled in - - - - element_name - Name of the policy whose label should be internalized - - - - element_data - Text data to be internalized - - - - claimed - Should be incremented when data can be successfully - internalized. - - -'> - -Produce an internal label structure based on externalized label data - in text format. Currently, all policies' internalize - entry points are called when internalization is requested, so the - implementation should compare the contents of - element_name to its own name in order to be sure - it should be internalizing the data in element_data. - Just as in the externalize entry points, the entry - point should return 0 if - element_name does not match its own name, or when - data can successfully be internalized, in which case - *claimed should be incremented. -"> diff --git a/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml deleted file mode 100644 index caee9e28a4..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml +++ /dev/null @@ -1,7483 +0,0 @@ - - - - - - - Chris - Costello - - - TrustedBSD Project -
chris@FreeBSD.org
- - - - - Robert - Watson - - - TrustedBSD Project -
rwatson@FreeBSD.org
- - - - - - The TrustedBSD MAC Framework - - - MAC Documentation Copyright - - This documentation was developed for the FreeBSD Project by - Chris Costello at Safeport Network Services and Network - Associates Laboratories, the Security Research Division of - Network Associates, Inc. under DARPA/SPAWAR contract - N66001-01-C-8035 (CBOSS), as part of the DARPA - CHATS research program. - - Redistribution and use in source (SGML DocBook) and - 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) - with or without modification, are permitted provided that the - following conditions are met: - - - - Redistributions of source code (SGML DocBook) must - retain the above copyright notice, this list of conditions - and the following disclaimer as the first lines of this file - unmodified. - - - - Redistributions in compiled form (transformed to other - DTDs, converted to PDF, PostScript, RTF and other formats) - must reproduce the above copyright notice, this list of - conditions and the following disclaimer in the documentation - and/or other materials provided with the - distribution. - - - - - THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS ASSOCIATES - TECHNOLOGY, INC "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, - INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - DISCLAIMED. IN NO EVENT SHALL NETWORKS ASSOCIATES TECHNOLOGY, - INC BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, - EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER - CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, - STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN - IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - - - - Synopsis - - MAC, or Mandatory Access Control, is a feature introduced by - the TrustedBSD Project to supplement the existing standard DAC - (Discretionary Access Control) policies of BSD Unix systems. - - This chapter introduces the MAC policy framework and - provides documentation for a sample MAC policy module. - - - - - Introduction - - The TrustedBSD MAC framework provides a mechanism to allow - the compile-time or run-time extension of the kernel access - control model. New system policies may be implemented as - kernel modules and linked to the kernel; if multiple policy - modules are present, their results will be composed. While the - framework is intended to support a variety of access control - models, its design was derived from the requirements of a set - of specific access control models required for the TrustedBSD - and CBOSS Projects. This includes support for fixed and - floating label Biba integrity policies, the MLS - confidentiality policy, the Type Enforcement rule-based access - control policy, and the ability to support layering of the NSA - FLASK framework above the TrustedBSD MAC framework. This - document describes the rough architecture of the framework, - with the understanding that this is a work-in-progress and may - change subtantially as requirements evolve. - - - - Kernel Architecture - - The TrustedBSD MAC framework provides the opportunity for - policy modules to be augment system access control decisions. - Policies are permitted the opportunity to restrict the set of - rights available for processes at a variety of relevant points - in the kernel. In addition, they are provided the opportunity - to tag processes and various kernel objects with labels storing - access control information. Policy modules may register - interest in a subset of the total available events or objects, - and are not required to implement events or objects that are not - relevant to the policy. Multiple modules may be loaded at once, - and the results of the modules are composed as necessary to - build an over-all system policy. Policy modules may be - implemented such that they can be loaded on-demand at run-time, - or such that they may only be loaded early in the boot process. - This permits policies requiring pervasive labeling of all - objects to prevent improper use. - - - - Userland Architecture - - ... - - - - Entry Point Framework - - Four classes of entry points are offered to policies - registered with the framework: entry points associated with - the registration and management of policies, entry points - denoting initialization, creation, destruction, and other life - cycle events for kernel objects, events assocated with access - control decisions that the policy module may influence, and - calls associated with the management of labels on objects. In - addition, a mac_syscall() entry point is - provided so that policies may extend the kernel interface - without registering new system calls. - - Policy module writers should be aware of the kernel - locking strategy, as well as what object locks are available - during which entry points. Writers should attempt to avoid - deadlock scenarios by avoiding grabbing non-leaf locks inside - of entry points, and also follow the locking protocol for - object access and modification. In particular, writers should - be aware that while necessary locks to access objects and - their labels are generally held, sufficient locks to modify an - object or its label may not be present for all entry points. - Locking information for arguments is documented in the MAC - framework entry point document. - - Policy entry points will pass a reference to the object - label along with the object itself. This permits labeled - policies to be unaware of the internals of the object yet - still make decisions based on the label. The exception to this - is the process credential, which is assumed to be understood - by policies as a first class security object in the kernel. - Policies that do not implement labels on kernel objects will - be passed NULL pointers for label arguments to entry - points. - - - General-Purpose Module Entry Points - - Modules may be declared using the - MAC_POLICY_SET() macro, which names the - policy, provides a reference to the MAC entry point vector, - provides load-time flags determining how the policy framework - should handle the policy, and optionally requests the - allocation of label state by the framework. - - static struct mac_policy_ops mac_policy_ops = -{ - .mpo_destroy = mac_policy_destroy, - .mpo_init = mac_policy_init, - .mpo_init_bpfdesc_label = mac_policy_init_bpfdesc_label, - .mpo_init_cred_label = mac_policy_init_label, -/* ... */ - .mpo_check_vnode_setutimes = mac_policy_check_vnode_setutimes, - .mpo_check_vnode_stat = mac_policy_check_vnode_stat, - .mpo_check_vnode_write = mac_policy_check_vnode_write, -}; - - The MAC policy entry point vector, - mac_policy_ops in this example, associates - functions defined in the module with specific entry points. A - complete listing of available entry points and their - prototypes may be found in the MAC entry point reference - section. Of specific interest during module registration are - the .mpo_destroy and .mpo_init - entry points. .mpo_init will be invoked once a - policy is successfully registered with the module framework - but prior to any other entry points becoming active. This - permits the policy to perform any policy-specific allocation - and initialization, such as initialization of any data or - locks. .mpo_destroy will be invoked when a - policy module is unloaded to permit releasing of any allocated - memory and destruction of locks. Currently, these two entry - points are invoked with the MAC policy list mutex held to - prevent any other entry points from being invoked: this will - be changed, but in the mean time, policies should be careful - about what kernel primitives they invoke so as to avoid lock - ordering or sleeping problems. - - The policy declaration's module name field exists so that - the module may be uniquely identified for the purposes of - module dependencies. An appropriate string should be selected. - The full string name of the policy is displayed to the user - via the kernel log during load and unload events, and also - exported when providing status information to userland - processes. - - The policy flags field permits the module to provide the - framework with information about its loader-related - capabilities. Currently, two flags are defined: - - - - MPC_LOADTIME_FLAG_UNLOADOK - - - This flag indicates that the policy module may be - unloaded. If this flag is not provided, then the policy - framework will reject requests to unload the module. - This flag might be used by modules that allocate label - state and are unable to free that state at - runtime. - - - - - MPC_LOADTIME_FLAG_NOTLATE - - This flag indicates that the policy module - must be loaded and initialized early in the boot - process. If the flag is specified, attempts to register - the module following boot will be rejected. The flag - may be used by policies that require pervasive labeling - of all system objects, and cannot handle objects that - have not been properly initialized by the policy. - - - - - - <function>&mac.mpo;_init</function - - - - void - &mac.mpo;_init - - struct mac_policy_conf - *conf - - - - - - &mac.thead; - - - - conf - MAC policy definition - - - - - - Policy load event. The policy list mutex is held, so - caution should be applied. - - - - <function>&mac.mpo;_destroy</function> - - - - void - &mac.mpo;_destroy - - struct mac_policy_conf - *conf - - - - - - &mac.thead; - - - - conf - MAC policy definition - - - - - - Policy load event. The policy list mutex is held, so - caution should be applied. - - - - <function>&mac.mpo;_syscall</function> - - - - int - &mac.mpo;_syscall - - struct thread - *td - int call - void *arg - - - - - - &mac.thead; - - - - td - Calling thread - - - - call - Syscall number - - - - arg - Pointer to syscall arguments - - - - - - This entry point provides a policy-multiplexed system - call so that policies may provide additional services to - user processes without registering specific system calls. - The policy name provided during registration is used to - demux calls from userland, and the arguments will be - forwarded to this entry point. When implementing new - services, security modules should be sure to invoke - appropriate access control checks from the MAC framework as - needed. For example, if a policy implements an augmented - signal functionality, it should call the necessary signal - access control checks to invoke the MAC framework and other - registered policies. - - Modules must currently perform the - copyin() of the syscall data on their - own. - - - - <function>&mac.mpo;_thread_userret</function> - - - - void - &mac.mpo;_thread_userret - - struct thread - *td - - - - - - &mac.thead; - - - - td - Returning thread - - - - - - - This entry point permits policy modules to perform - MAC-related events when a thread returns to user space. - This is required for policies that have floating process - labels, as it's not always possible to acquire the process - lock at arbitrary points in the stack during system call - processing; process labels might represent traditional - authentication data, process history information, or other - data. - - - - - Label Operations - - - <function>&mac.mpo;_init_bpfdesc_label</function> - - - - void - &mac.mpo;_init_bpfdesc_label - - struct bpf_d - *bpf_d - struct label - *label - - - - - - &mac.thead; - - - - bpf_d - Object; bpf descriptor - - - - label - New label to apply - - - - - - Initialize the label on a newly instantiated bpfdesc (BPF - descriptor) - - - - <function>&mac.mpo;_init_cred_label</function> - - - - void - &mac.mpo;_init_cred_label - - struct label - *label - - - - - - &mac.thead; - - - - label - New label to initialize - - - - - - Initialize the label for a newly instantiated - user credential. - - - - <function>&mac.mpo;_init_devfsdirent_label</function> - - - - void - &mac.mpo;_init_devfsdirent_label - - struct devfs_dirent - *devfs_dirent - struct label - *label - - - - - - &mac.thead; - - - - devfs_dirent - Object; devfs directory entry - - - - label - New label to apply - - - - - - Initialize the label on a newly instantiated devfs - entry. - - - - <function>&mac.mpo;_init_ifnet_label</function> - - - - void - &mac.mpo;_init_ifnet_label - - struct ifnet - *ifnet - struct label - *label - - - - - - &mac.thead; - - - - ifnet - Object; network interface - - - - label - New label to apply - - - - - - Initialize the label on a newly instantiated network - interface. - - - - <function>&mac.mpo;_init_ipq_label</function> - - - - void - &mac.mpo;_init_ipq_label - - struct ipq - *ipq - struct label - *label - - - - - - &mac.thead; - - - - ipq - Object; IP reassembly queue - - - - label - New label to apply - - - - - - Initialize the label on a newly instantiated IP fragment - reassembly queue. - - - - <function>&mac.mpo;_init_mbuf_label</function> - - - - void - &mac.mpo;_init_mbuf_label - - struct mbuf - *mbuf - int how - struct label - *label - - - - - - &mac.thead; - - - - mbuf - Object; mbuf - - - - how - Blocking/non-blocking &man.malloc.9;; see - below - - - - label - Policy label to initialize - - - - - Initialize the label on a newly instantiated mbuf packet - header (mbuf). The - how field may be one of - M_WAITOK and M_NOWAIT, and - should be employed to avoid performing a blocking - &man.malloc.9; during this initialization call. Mbuf - allocation frequently occurs in performance sensitive - environments, and the implementation should be careful to - avoid blocking or long-lived operations. This entry point - is permitted to fail resulting in the failure to allocate - the mbuf header. - - - - <function>&mac.mpo;_init_mount_label</function> - - - - void - &mac.mpo;_init_mount_label - - struct mount - *mount - struct label - *mntlabel - struct label - *fslabel - - - - - - - &mac.thead; - - - - mount - Object; file system mount point - - - - mntlabel - Policy label to be initialized for the mount - itself - - - - fslabel - Policy label to be initialized for the file - system - - - - - - Initialize the labels on a newly instantiated mount - point. - - - - <function>&mac.mpo;_init_mount_fs_label</function> - - - - void - &mac.mpo;_init_mount_fs_label - - struct label - *label - - - - - - &mac.thead; - - - - label - Label to be initialized - - - - - - Initialize the label on a newly mounted file - system. - - - - <function>&mac.mpo;_init_pipe_label</function> - - - - void - &mac.mpo;_init_pipe_label - - struct - label*label - - - - - - &mac.thead; - - - - label - Label to be filled in - - - - - Initialize a label for a newly instantiated pipe. - - - - <function>&mac.mpo;_init_socket_label</function> - - - - void - &mac.mpo;_init_socket_label - - struct label - *label - int flag - - - - - - &mac.thead; - - - - label - New label to initialize - - - - flag - &man.malloc.9; flags - - - - - - Initialize a label for a newly instantiated - socket. - - - - <function>&mac.mpo;_init_socket_peer_label</function> - - - - void - &mac.mpo;_init_socket_peer_label - - struct label - *label - int flag - - - - - - &mac.thead; - - - - label - New label to initialize - - - - flag - &man.malloc.9; flags - - - - - - Initialize the peer label for a newly instantiated - socket. - - - - <function>&mac.mpo;_init_proc_label</function> - - - - void - &mac.mpo;_init_proc_label - - struct label - *label - - - - - - &mac.thead; - - - - label - New label to initialize - - - - - - Initialize the label for a newly instantiated - process. - - - - - <function>&mac.mpo;_init_vnode_label</function> - - - - void - &mac.mpo;_init_vnode_label - - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - vp - Object; file system object - - - - label - New label to initialize - - - - - - Initialize the label on a newly instantiated vnode. - - - <function>&mac.mpo;_destroy_bpfdesc_label</function> - - - - void - &mac.mpo;_destroy_bpfdesc_label - - struct label - *label - - - - - - &mac.thead; - - - - label - bpfdesc label - - - - - - Destroy the label on a bpf descriptor. In this entry - point a policy should free any internal storage associated - with label so that it may be - destroyed. - - - - <function>&mac.mpo;_destroy_cred_label</function> - - - - void - &mac.mpo;_destroy_cred_label - - struct ucred - *cred - struct label - *label - - - - - - &mac.thead; - - - - cred - Subject; user credential - - - - label - Label being destroyed - - - - - - Destroy the label on a credential. In this entry point, - a policy module should free any internal storage associated - with label so that it may be - destroyed. - - - - - <function>&mac.mpo;_destroy_devfsdirent_label</function> - - - - void - &mac.mpo;_destroy_devfsdirent_label - - struct devfs_dirent - *devfs_dirent - struct label - *label - - - - - - &mac.thead; - - - - devfs_dirent - Object; devfs directory entry - - - - label - Label being destroyed - - - - - - Destroy the label on a devfs entry. In this entry - point, a policy module should free any internal storage - asociated with label so that it may - be destroyed. - - - - <function>&mac.mpo;_destroy_ifnet_label</function> - - - - void - &mac.mpo;_destroy_ifnet_label - - struct label - *label - - - - - - &mac.thead; - - - - label - Label being destroyed - - - - - - Destroy the label on a removed interface. In this entry - point, a policy module should free any internal storage - associated with label so that it may - be destroyed. - - - - <function>&mac.mpo;_destroy_ipq_label</function> - - - - void - &mac.mpo;_destroy_ipq_label - - struct label - *label - - - - - - &mac.thead; - - - - label - Label being destroyed - - - - - - Destroy the label on an IP fragment queue. In this - entry point, a policy module should free any internal - storage associated with label so that - it may be destroyed. - - - - <function>&mac.mpo;_destroy_mbuf_label</function> - - - - void - &mac.mpo;_destroy_mbuf_label - - struct label - *label - - - - - - &mac.thead; - - - - label - Label being destroyed - - - - - - Destroy the label on an mbuf header. In this entry - point, a policy module should free any internal storage - associated with label so that it may - be destroyed. - - - - <function>&mac.mpo;_destroy_mount_label</function> - - - - void - &mac.mpo;_destroy_mount_label - - struct label - *label - - - - - - &mac.thead; - - - - label - Mount point label being destroyed - - - - - - Destroy the labels on a mount point. In this entry - point, a policy module should free the internal storage - associated with mntlabel so that they - may be destroyed. - - - - <function>&mac.mpo;_destroy_mount_label</function> - - - - void - &mac.mpo;_destroy_mount_label - - struct mount - *mp - struct label - *mntlabel - struct label - *fslabel - - - - - - &mac.thead; - - - - mp - Object; file system mount point - - - - mntlabel - Mount point label being destroyed - - - - fslabel - File system label being destroyed> - - - - - - Destroy the labels on a mount point. In this entry - point, a policy module should free the internal storage - associated with mntlabel and - fslabel so that they may be - destroyed. - - - - <function>&mac.mpo;_destroy_socket_label</function> - - - - void - &mac.mpo;_destroy_socket_label - - struct label - *label - - - - - - - &mac.thead; - - - - label - Socket label being destroyed - - - - - - - Destroy the label on a socket. In this entry point, a - policy module should free any internal storage associated - with label so that it may be - destroyed. - - - - <function>&mac.mpo;_destroy_socket_peer_label</function> - - - - void - &mac.mpo;_destroy_socket_peer_label - - struct label - *peerlabel - - - - - - &mac.thead; - - - - peerlabel - Socket peer label being destroyed - - - - - - Destroy the peer label on a socket. In this entry - point, a policy module should free any internal storage - associated with label so that it may - be destroyed. - - - - <function>&mac.mpo;_destroy_pipe_label</function> - - - - void - &mac.mpo;_destroy_pipe_label - - struct label - *label - - - - - - &mac.thead; - - - - label - Pipe label - - - - - - Destroy the label on a pipe. In this entry point, a - policy module should free any internal storage associated - with label so that it may be - destroyed. - - - - <function>&mac.mpo;_destroy_proc_label</function> - - - - void - &mac.mpo;_destroy_proc_label - struct label - *label - - - - - - &mac.thead; - - - - label - Process label - - - - - - Destroy the label on a process. In this entry point, a - policy module should free any internal storage associated - with label so that it may be - destroyed. - - - - <function>&mac.mpo;_copy_pipe_label</function> - - - - void - &mac.mpo;_copy_pipe_label - - struct label - *src - struct label - *dest - - - - - - &mac.thead; - - - - src - Source label - - - - dest - Destination label - - - - - - Copy the label information in - src into - dest. - - - - <function>&mac.mpo;_copy_vnode_label</function> - - - - void - &mac.mpo;_copy_vnode_label - - struct label - *src - struct label - *dest - - - - - - &mac.thead; - - - - src - Source label - - - - dest - Destination label - - - - - - Copy the label information in - src into - dest. - - - - <function>&mac.mpo;_externalize_cred_label</function> - - - - int - &mac.mpo;_externalize_cred_label - - &mac.externalize.paramdefs; - - - - - - &mac.thead; - - &mac.externalize.tbody; - - - - &mac.externalize.para; - - - - <function>&mac.mpo;_externalize_ifnet_label</function> - - - - int - &mac.mpo;_externalize_ifnet_label - - &mac.externalize.paramdefs; - - - - - - &mac.thead; - - &mac.externalize.tbody; - - - - &mac.externalize.para; - - - - <function>&mac.mpo;_externalize_pipe_label</function> - - - - int - &mac.mpo;_externalize_pipe_label - - &mac.externalize.paramdefs; - - - - - - &mac.thead; - - &mac.externalize.tbody; - - - - &mac.externalize.para; - - - - <function>&mac.mpo;_externalize_socket_label</function> - - - - int - &mac.mpo;_externalize_socket_label - - &mac.externalize.paramdefs; - - - - - - &mac.thead; - - &mac.externalize.tbody; - - - - &mac.externalize.para; - - - - <function>&mac.mpo;_externalize_socket_peer_label</function> - - - - int - &mac.mpo;_externalize_socket_peer_label - - &mac.externalize.paramdefs; - - - - - - &mac.thead; - - &mac.externalize.tbody; - - - - &mac.externalize.para; - - - - <function>&mac.mpo;_externalize_vnode_label</function> - - - - int - &mac.mpo;_externalize_vnode_label - - &mac.externalize.paramdefs; - - - - - - &mac.thead; - - &mac.externalize.tbody; - - - - &mac.externalize.para; - - - - <function>&mac.mpo;_internalize_cred_label</function> - - - - int - &mac.mpo;_internalize_cred_label - - &mac.internalize.paramdefs; - - - - - - &mac.thead; - - &mac.internalize.tbody; - - - - &mac.internalize.para; - - - - <function>&mac.mpo;_internalize_ifnet_label</function> - - - - int - &mac.mpo;_internalize_ifnet_label - - &mac.internalize.paramdefs; - - - - - - &mac.thead; - - &mac.internalize.tbody; - - - - &mac.internalize.para; - - - - <function>&mac.mpo;_internalize_pipe_label</function> - - - - int - &mac.mpo;_internalize_pipe_label - - &mac.internalize.paramdefs; - - - - - - &mac.thead; - - &mac.internalize.tbody; - - - - &mac.internalize.para; - - - - <function>&mac.mpo;_internalize_socket_label</function> - - - - int - &mac.mpo;_internalize_socket_label - - &mac.internalize.paramdefs; - - - - - - &mac.thead; - - &mac.internalize.tbody; - - - - &mac.internalize.para; - - - - <function>&mac.mpo;_internalize_vnode_label</function> - - - - int - &mac.mpo;_internalize_vnode_label - - &mac.internalize.paramdefs; - - - - - - &mac.thead; - - &mac.internalize.tbody; - - - - &mac.internalize.para; - - - - - Label Events - - This class of entry points is used by the MAC framework to - permit policies to maintain label information on kernel - objects. For each labeled kernel object of interest to a MAC - policy, entry points may be registered for relevant life cycle - events. All objects implement initialization, creation, and - destruction hooks. Some objects will also implement - relabeling, allowing user processes to change the labels on - objects. Some objects will also implement object-specific - events, such as label events associated with IP reassembly. A - typical labeled object will have the following life cycle of - entry points: - - Label initialization o -(object-specific wait) \ -Label creation o - \ -Relabel events, o--<--. -Various object-specific, | | -Access control events ~-->--o - \ -Label destruction o - - Label initialization permits policies to allocate memory - and set initial values for labels without context for the use - of the object. The label slot allocated to a policy will be - zero'd by default, so some policies may not need to perform - initialization. - - Label creation occurs when the kernel structure is - associated with an actual kernel object. For example, mbufs - may be allocated and remain unused in a pool until they are - required. mbuf allocation causes label initialization on the - mbuf to take place, but mbuf creation occurs when the mbuf is - associated with a datagram. Typically, context will be - provided for a creation event, including the circumstances of - the creation, and labels of other relevant objects in the - creation process. For example, when an mbuf is created from a - socket, the socket and its label will be presented to - registered policies in addition to the new mbuf and its label. - Memory allocation in creation events is discouraged, as it may - occur in performance sensitive ports of the kernel; in - addition, creation calls are not permitted to fail so a - failure to allocate memory cannot be reported. - - Object specific events do not generally fall into the - other broad classes of label events, but will generally - provide an opportunity to modify or update the label on an - object based on additional context. For example, the label on - an IP fragment reassembly queue may be updated during the - MAC_UPDATE_IPQ entry point as a result of the - acceptance of an additional mbuf to that queue. - - Access control events are discussed in detail in the - following section. - - Label destruction permits policies to release storage or - state associated with a label during its association with an - object so that the kernel data structures supporting the - object may be reused or released. - - In addition to labels associated with specific kernel - objects, an additional class of labels exists: temporary - labels. These labels are used to store update information - submitted by user processes. These labels are initialized and - destroyed as with other label types, but the creation event is - MAC_INTERNALIZE, which accepts a user label - to be converted to an in-kernel representation. - - - File System Object Labeling Event Operations - - - <function>&mac.mpo;_associate_vnode_devfs</function> - - - - void - &mac.mpo;_associate_vnode_devfs - - struct mount - *mp - struct label - *fslabel - struct devfs_dirent - *de - struct label - *delabel - struct vnode - *vp - struct label - *vlabel - - - - - - &mac.thead; - - - - mp - Devfs mount point - - - - fslabel - Devfs file system label - (mp->mnt_fslabel) - - - - de - Devfs directory entry - - - - delabel - Policy label associated with - de - - - - vp - vnode associated with - de - - - - vlabel - Policy label associated with - vp - - - - - - Fill in the label (vlabel) for - a newly created devfs vnode based on the devfs directory - entry passed in de and its - label. - - - - <function>&mac.mpo;_associate_vnode_extattr</function> - - - - int - &mac.mpo;_associate_vnode_extattr - - struct mount - *mp - struct label - *fslabel - struct vnode - *vp - struct label - *vlabel - - - - - - &mac.thead; - - - - mp - File system mount point - - - - fslabel - File system label - - - - vp - Vnode to label - - - - vlabel - Policy label associated with - vp - - - - - - Attempt to retrieve the label for - vp from the file system extended - attributes. Upon success, the value 0 - is returned. Should extended attribute retrieval not be - supported, an accepted fallback is to copy - fslabel into - vlabel. In the event of an error, - an appropriate value for errno should - be returned. - - - - <function>&mac.mpo;_associate_vnode_singlelabel</function> - - - - void - &mac.mpo;_associate_vnode_singlelabel - - struct mount - *mp - struct label - *fslabel - struct vnode - *vp - struct label - *vlabel - - - - - - &mac.thead; - - - - mp - File system mount point - - - - fslabel - File system label - - - - vp - Vnode to label - - - - vlabel - Policy label associated with - vp - - - - - - On non-multilabel file systems, this entry point is - called to set the policy label for - vp based on the file system label, - fslabel. - - - - - <function>&mac.mpo;_create_devfs_device</function> - - - - void - &mac.mpo;_create_devfs_device - - dev_t dev - struct devfs_dirent - *devfs_dirent - struct label - *label - - - - - - &mac.thead; - - - - dev - Device corresponding with - devfs_dirent - - - - devfs_dirent - Devfs directory entry to be labeled. - - - - label - Label for devfs_dirent - to be filled in. - - - - - - Fill out the label on a devfs_dirent being created for - the passed device. This call will be made when the device - file system is mounted, regenerated, or a new device is made - available. - - - - <function>&mac.mpo;_create_devfs_directory</function> - - - - void - &mac.mpo;_create_devfs_directory - - char *dirname - int dirnamelen - struct devfs_dirent - *devfs_dirent - struct label - *label - - - - - - &mac.thead; - - - - dirname - Name of directory being created - - - - namelen - Length of string - dirname - - - - devfs_dirent - Devfs directory entry for directory being - created. - - - - - - Fill out the label on a devfs_dirent being created for - the passed directory. This call will be made when the device - file system is mounted, regenerated, or a new device - requiring a specific directory hierarchy is made - available. - - - - <function>&mac.mpo;_create_devfs_symlink</function> - - - - void - &mac.mpo;_create_devfs_symlink - - struct ucred - *cred - struct mount - *mp - struct devfs_dirent - *dd - struct label - *ddlabel - struct devfs_dirent - *de - struct label - *delabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - mp - Devfs mount point - - - - dd - Link destination - - - - ddlabel - Label associated with - dd - - - - de - Symlink entry - - - - delabel - Label associated with - de - - - - - - Fill in the label (delabel) for - a newly created &man.devfs.5; symbolic link entry. - - - - <function>&mac.mpo;_create_vnode_extattr</function> - - - - int - &mac.mpo;_create_vnode_extattr - - struct ucred - *cred - struct mount - *mp - struct label - *fslabel - struct vnode - *dvp - struct label - *dlabel - struct vnode - *vp - struct label - *vlabel - struct componentname - *cnp - - - - - - &mac.thead; - - - - cred - Subject credential - - - - mount - File system mount point - - - - label - File system label - - - - dvp - Parent directory vnode - - - - dlabel - Label associated with - dvp - - - - vp - Newly created vnode - - - - vlabel - Policy label associated with - vp - - - - cnp - Component name for - vp - - - - - - Write out the label for vp to - the appropriate extended attribute. If the write - succeeds, fill in vlabel with the - label, and return 0. Otherwise, - return an appropriate error. - - - - <function>&mac.mpo;_create_mount</function> - - - - void - &mac.mpo;_create_mount - - struct ucred - *cred - struct mount - *mp - struct label - *mnt - struct label - *fslabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - mp - Object; file system being mounted - - - - mntlabel - Policy label to be filled in for - mp - - - - fslabel - Policy label for the file system - mp mounts. - - - - - - Fill out the labels on the mount point being created by - the passed subject credential. This call will be made when - a new file system is mounted. - - - - <function>&mac.mpo;_create_root_mount</function> - - - - void - &mac.mpo;_create_root_mount - - struct ucred - *cred - struct mount - *mp - struct label - *mntlabel - struct label - *fslabel - - - - - - &mac.thead; - - - - See . - - - - - - Fill out the labels on the mount point being created by - the passed subject credential. This call will be made when - the root file system is mounted, after - &mac.mpo;_create_mount;. - - - - <function>&mac.mpo;_relabel_vnode</function> - - - - void - &mac.mpo;_relabel_vnode - - struct ucred - *cred - struct vnode - *vp - struct label - *vnodelabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - vnode to relabel - - - - vnodelabel - Existing policy label for - vp - - - - newlabel - New, possibly partial label to replace - vnodelabel - - - - - - Update the label on the passed vnode given the passed - update vnode label and the passed subject credential. - - - - <function>&mac.mpo;_setlabel_vnode_extattr</function> - - - - int - &mac.mpo;_setlabel_vnode_extattr - - struct ucred - *cred - struct vnode - *vp - struct label - *vlabel - struct label - *intlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Vnode for which the label is being - written - - - - vlabel - Policy label associated with - vp - - - - intlabel - Label to write out - - - - - - Write out the policy from - intlabel to an extended - attribute. This is called from - vop_stdcreatevnode_ea. - - - - <function>&mac.mpo;_update_devfsdirent</function> - - - void - &mac.mpo;_update_devfsdirent - - struct devfs_dirent - *devfs_dirent - struct label - *direntlabel - struct vnode - *vp - struct label - *vnodelabel - - - - - - &mac.thead; - - - - devfs_dirent - Object; devfs directory entry - - - - direntlabel - Policy label for - devfs_dirent to be - updated. - - - - vp - Parent vnode - Locked - - - - vnodelabel - Policy label for - vp - - - - - - Update the devfs_dirent label - from the passed devfs vnode label. This call will be made - when a devfs vnode has been successfully relabeled to commit - the label change such that it lasts even if the vnode is - recycled. It will also be made when when a symlink is - created in devfs, following a call to - mac_vnode_create_from_vnode to - initialize the vnode label. - - - - - IPC Object Labeling Event Operations - - - - <function>&mac.mpo;_create_mbuf_from_socket</function> - - - - void - &mac.mpo;_create_mbuf_from_socket - - struct socket - *so - struct label - *socketlabel - struct mbuf *m - struct label - *mbuflabel - - - - - - &mac.thead; - - - - socket - Socket - Socket locking WIP - - - - socketlabel - Policy label for - socket - - - - m - Object; mbuf - - - - mbuflabel - Policy label to fill in for - m - - - - - - Set the label on a newly created mbuf header from the - passed socket label. This call is made when a new datagram - or message is generated by the socket and stored in the - passed mbuf. - - - - <function>&mac.mpo;_create_pipe</function> - - - - void - &mac.mpo;_create_pipe - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Policy label associated with - pipe - - - - - - Set the label on a newly created pipe from the passed - subject credential. This call is made when a new pipe is - created. - - - - <function>&mac.mpo;_create_socket</function> - - - - void - &mac.mpo;_create_socket - - struct ucred - *cred - struct socket - *so - struct label - *socketlabel - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - so - Object; socket to label - - - - socketlabel - Label to fill in for - so - - - - - - Set the label on a newly created socket from the passed - subject credential. This call is made when a socket is - created. - - - - <function>&mac.mpo;_create_socket_from_socket</function> - - - - void - &mac.mpo;_create_socket_from_socket - - struct socket - *oldsocket - struct label - *oldsocketlabel - struct socket - *newsocket - struct label - *newsocketlabel - - - - - - &mac.thead; - - - - oldsocket - Listening socket - - - - oldsocketlabel - Policy label associated with - oldsocket - - - - newsocket - New socket - - - - newsocketlabel - Policy label associated with - newsocketlabel - - - - - - Label a socket, newsocket, - newly &man.accept.2;ed, based on the &man.listen.2; - socket, oldsocket. - - - - <function>&mac.mpo;_relabel_pipe</function> - - - - void - &mac.mpo;_relabel_pipe - - struct ucred - *cred - struct pipe - *pipe - struct label - *oldlabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - oldlabel - Current policy label associated with - pipe - - - - newlabel - Policy label update to apply to - pipe - - - - - - Apply a new label, newlabel, to - pipe. - - - - <function>&mac.mpo;_relabel_socket</function> - - - - void - &mac.mpo;_relabel_socket - - struct ucred - *cred - struct socket - *so - struct label - *oldlabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - so - Object; socket - - - - oldlabel - Current label for - so - - - - newlabel - Label update for - so - - - - - - Update the label on a socket from the passed socket - label update. - - - - <function>&mac.mpo;_set_socket_peer_from_mbuf</function> - - - - void - &mac.mpo;_set_socket_peer_from_mbuf - - struct mbuf - *mbuf - struct label - *mbuflabel - struct label - *oldlabel - struct label - *newlabel - - - - - - &mac.thead; - - - - mbuf - First datagram received over socket - - - - mbuflabel - Label for mbuf - - - - oldlabel - Current label for the socket - - - - newlabel - Policy label to be filled out for the - socket - - - - - - Set the peer label on a stream socket from the passed - mbuf label. This call will be made when the first datagram - is received by the stream socket, with the exception of Unix - domain sockets. - - - - <function>&mac.mpo;_set_socket_peer_from_socket</function> - - - - void - &mac.mpo;_set_socket_peer_from_socket - - struct socket - *oldsocket - struct label - *oldsocketlabel - struct socket - *newsocket - struct label - *newsocketpeerlabel - - - - - - &mac.thead; - - - - oldsocket - Local socket - - - - oldsocketlabel - Policy label for - oldsocket - - - - newsocket - Peer socket - - - - newsocketpeerlabel - Policy label to fill in for - newsocket - - - - - - - Set the peer label on a stream UNIX domain socket from - the passed remote socket endpoint. This call will be made - when the socket pair is connected, and will be made for both - endpoints. - - - - - Network Object Labeling Event Operations - - - <function>&mac.mpo;_create_bpfdesc</function> - - - - void - &mac.mpo;_create_bpfdesc - - struct ucred - *cred - struct bpf_d - *bpf_d - struct label - *bpflabel - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - bpf_d - Object; bpf descriptor - - - - bpf - Policy label to be filled in for - bpf_d - - - - - - Set the label on a newly created BPF descriptor from the - passed subject credential. This call will be made when a - BPF device node is opened by a process with the passed - subject credential. - - - - <function>&mac.mpo;_create_ifnet</function> - - - - void - &mac.mpo;_create_ifnet - - struct ifnet - *ifnet - struct label - *ifnetlabel - - - - - - &mac.thead; - - - - ifnet - Network interface - - - - ifnetlabel - Policy label to fill in for - ifnet - - - - - - Set the label on a newly created interface. This call - may be made when a new physical interface becomes available - to the system, or when a pseudo-interface is instantiated - during the boot or as a result of a user action. - - - - <function>&mac.mpo;_create_ipq</function> - - - - void - &mac.mpo;_create_ipq - - struct mbuf - *fragment - struct label - *fragmentlabel - struct ipq - *ipq - struct label - *ipqlabel - - - - - - &mac.thead; - - - - fragment - First received IP fragment - - - - fragmentlabel - Policy label for - fragment - - - - ipq - IP reassembly queue to be labeled - - - - ipqlabel - Policy label to be filled in for - ipq - - - - - - Set the label on a newly created IP fragment reassembly - queue from the mbuf header of the first received - fragment. - - - - <function>&mac.mpo;_create_datagram_from_ipq</function> - - - - void - &mac.mpo;_create_create_datagram_from_ipq - - struct ipq - *ipq - struct label - *ipqlabel - struct mbuf - *datagram - struct label - *datagramlabel - - - - - - &mac.thead; - - - - ipq - IP reassembly queue - - - - ipqlabel - Policy label for - ipq - - - - datagram - Datagram to be labeled - - - - datagramlabel - Policy label to be filled in for - datagramlabel - - - - - - Set the label on a newly reassembled IP datagram from - the IP fragment reassembly queue from which it was - generated. - - - - <function>&mac.mpo;_create_fragment</function> - - - - void - &mac.mpo;_create_fragment - - struct mbuf - *datagram - struct label - *datagramlabel - struct mbuf - *fragment - struct label - *fragmentlabel - - - - - - &mac.thead; - - - - datagram - Datagram - - - - datagramlabel - Policy label for - datagram - - - - fragment - Fragment to be labeled - - - - fragmentlabel - Policy label to be filled in for - datagram - - - - - - Set the label on the mbuf header of a newly created IP - fragment from the label on the mbuf header of the datagram - it was generate from. - - - - <function>&mac.mpo;_create_mbuf_from_mbuf</function> - - - - void - &mac.mpo;_create_mbuf_from_mbuf - - struct mbuf - *oldmbuf - struct label - *oldmbuflabel - struct mbuf - *newmbuf - struct label - *newmbuflabel - - - - - - &mac.thead; - - - - oldmbuf - Existing (source) mbuf - - - - oldmbuflabel - Policy label for - oldmbuf - - - - newmbuf - New mbuf to be labeled - - - - newmbuflabel - Policy label to be filled in for - newmbuf - - - - - - Set the label on the mbuf header of a newly created - datagram from the mbuf header of an existing datagram. This - call may be made in a number of situations, including when - an mbuf is re-allocated for alignment purposes. - - - - <function>&mac.mpo;_create_mbuf_linklayer</function> - - - - void - &mac.mpo;_create_mbuf_linklayer - - struct ifnet - *ifnet - struct label - *ifnetlabel - struct mbuf - *mbuf - struct label - *mbuflabel - - - - - - &mac.thead; - - - - ifnet - Network interface - - - - ifnetlabel - Policy label for - ifnet - - - - mbuf - mbuf header for new datagram - - - - mbuflabel - Policy label to be filled in for - mbuf - - - - - - Set the label on the mbuf header of a newly created - datagram generated for the purposes of a link layer response - for the passed interface. This call may be made in a number - of situations, including for ARP or ND6 responses in the - IPv4 and IPv6 stacks. - - - - <function>&mac.mpo;_create_mbuf_from_bpfdesc</function> - - - - void - &mac.mpo;_create_mbuf_from_bpfdesc - - struct bpf_d - *bpf_d - struct label - *bpflabel - struct mbuf - *mbuf - struct label - *mbuflabel - - - - - - &mac.thead; - - - - bpf_d - BPF descriptor - - - - bpflabel - Policy label for - bpflabel - - - - mbuf - New mbuf to be labeled - - - - mbuflabel - Policy label to fill in for - mbuf - - - - - - Set the label on the mbuf header of a newly created - datagram generated using the passed BPF descriptor. This - call is made when a write is performed to the BPF device - associated with the passed BPF descriptor. - - - - <function>&mac.mpo;_create_mbuf_from_ifnet</function> - - - - void - &mac.mpo;_create_mbuf_from_ifnet - - struct ifnet - *ifnet - struct label - *ifnetlabel - struct mbuf - *mbuf - struct label - *mbuflabel - - - - - - &mac.thead; - - - - ifnet - Network interface - - - - ifnetlabel - Policy label for - ifnetlabel - - - - mbuf - mbuf header for new datagram - - - - mbuflabel - Policy label to be filled in for - mbuf - - - - - - Set the label on the mbuf header of a newly created - datagram generated from the passed network interface. - - - - <function>&mac.mpo;_create_mbuf_multicast_encap</function> - - - - void - &mac.mpo;_create_mbuf_multicast_encap - - struct mbuf - *oldmbuf - struct label - *oldmbuflabel - struct ifnet - *ifnet - struct label - *ifnetlabel - struct mbuf - *newmbuf - struct label - *newmbuflabel - - - - - - &mac.thead; - - - - oldmbuf - mbuf header for existing datagram - - - - oldmbuflabel - Policy label for - oldmbuf - - - - ifnet - Network interface - - - - ifnetlabel - Policy label for - ifnet - - - - newmbuf - mbuf header to be labeled for new - datagram - - - - newmbuflabel - Policy label to be filled in for - newmbuf - - - - - - Set the label on the mbuf header of a newly created - datagram generated from the existing passed datagram when it - is processed by the passed multicast encapsulation - interface. This call is made when an mbuf is to be - delivered using the virtual interface. - - - - <function>&mac.mpo;_create_mbuf_netlayer</function> - - - - void - &mac.mpo;_create_mbuf_netlayer - - struct mbuf - *oldmbuf - struct label - *oldmbuflabel - struct mbuf - *newmbuf - struct label - *newmbuflabel - - - - - - &mac.thead; - - - - oldmbuf - Received datagram - - - - oldmbuflabel - Policy label for - oldmbuf - - - - newmbuf - Newly created datagram - - - - newmbuflabel - Policy label for - newmbuf - - - - - - Set the label on the mbuf header of a newly created - datagram generated by the IP stack in response to an - existing received datagram (oldmbuf). - This call may be made in a number of situations, including - when responding to ICMP request datagrams. - - - - <function>&mac.mpo;_fragment_match</function> - - - - int - &mac.mpo;_fragment_match - - struct mbuf - *fragment - struct label - *fragmentlabel - struct ipq - *ipq - struct label - *ipqlabel - - - - - - &mac.thead; - - - - fragment - IP datagram fragment - - - - fragmentlabel - Policy label for - fragment - - - - ipq - IP fragment reassembly queue - - - - ipqlabel - Policy label for - ipq - - - - - - Determine whether an mbuf header containing an IP - datagram (fragment) fragment matches - the label of the passed IP fragment reassembly queue - (ipq). Return - (1) for a successful match, or - (0) for no match. This call is - made when the IP stack attempts to find an existing fragment - reassembly queue for a newly received fragment; if this - fails, a new fragment reassembly queue may be instantiated - for the fragment. Policies may use this entry point to - prevent the reassembly of otherwise matching IP fragments if - policy does not permit them to be reassembled based on the - label or other information. - - - - <function>&mac.mpo;_relabel_ifnet</function> - - - - void - &mac.mpo;_relabel_ifnet - - struct ucred - *cred - struct ifnet - *ifnet - struct label - *ifnetlabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - ifnet - Object; Network interface - - - - ifnetlabel - Policy label for - ifnet - - - - newlabel - Label update to apply to - ifnet - - - - - - Update the label of network interface, - ifnet, based on the passed update - label, newlabel, and the passed - subject credential, cred. - - - - <function>&mac.mpo;_update_ipq</function> - - - - void - &mac.mpo;_update_ipq - - struct mbuf - *fragment - struct label - *fragmentlabel - struct ipq - *ipq - struct label - *ipqlabel - - - - - - &mac.thead; - - - - mbuf - IP fragment - - - - mbuflabel - Policy label for - mbuf - - - - ipq - IP fragment reassembly queue - - - - ipqlabel - Policy label to be updated for - ipq - - - - - - Update the label on an IP fragment reassembly queue - (ipq) based on the acceptance of the - passed IP fragment mbuf header - (mbuf). - - - - - Process Labeling Event Operations - - - <function>&mac.mpo;_create_cred</function> - - - - void - &mac.mpo;_create_cred - - struct ucred - *parent_cred - struct ucred - *child_cred - - - - - - &mac.thead; - - - - parent_cred - Parent subject credential - - - - child_cred - Child subject credential - - - - - - Set the label of a newly created subject credential from - the passed subject credential. This call will be made when - &man.crcopy.9; is invoked on a newly created struct - ucred. This call should not be confused with a - process forking or creation event. - - - - <function>&mac.mpo;_execve_transition</function> - - - - void - &mac.mpo;_execve_transition - - struct ucred - *old - struct ucred - *new - struct vnode - *vp - struct label - *vnodelabel - - - - - - &mac.thead; - - - - old - Existing subject credential - Immutable - - - - new - New subject credential to be labeled - - - - vp - File to execute - Locked - - - - vnodelabel - Policy label for - vp - - - - - - Update the label of a newly created subject credential - (new) from the passed existing - subject credential (old) based on a - label transition caused by executing the passed vnode - (vp). This call occurs when a - process executes the passed vnode and one of the policies - returns a success from the - mpo_execve_will_transition entry point. - Policies may choose to implement this call simply by - invoking mpo_create_cred and passing - the two subject credentials so as not to implement a - transitioning event. Policies should not leave this entry - point unimplemented if they implement - mpo_create_cred, even if they do not - implement - mpo_execve_will_transition. - - - - <function>&mac.mpo;_execve_will_transition</function> - - - - int - &mac.mpo;_execve_will_transition - - struct ucred - *old - struct vnode - *vp - struct label - *vnodelabel - - - - - - &mac.thead; - - - - old - Subject credential prior to - &man.execve.2; - Immutable - - - - vp - File to execute - - - - vnodelabel - Policy label for - vp - - - - - - Determine whether the policy will want to perform a - transition event as a result of the execution of the passed - vnode by the passed subject credential. Return - 1 if a transition is required, - 0 if not. Even if a policy - returns 0, it should behave - correctly in the presence of an unexpected invocation of - mpo_execve_transition, as that call may - happen as a result of another policy requesting a - transition. - - - - <function>&mac.mpo;_create_proc0</function> - - - - void - &mac.mpo;_create_proc0 - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential to be filled in - - - - - - Create the subject credential of process 0, the parent - of all kernel processes. - - - - <function>&mac.mpo;_create_proc1</function> - - - - void - &mac.mpo;_create_proc1 - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential to be filled in - - - - - - Create the subject credential of process 1, the parent - of all user processes. - - - - <function>&mac.mpo;_relabel_cred</function> - - - - void - &mac.mpo;_relabel_cred - - struct ucred - *cred - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - newlabel - Label update to apply to - cred - - - - - - Update the label on a subject credential from the passed - update label. - - - - - - - - - Access Control Checks - - Access control entry points permit policy modules to - influence access control decisions made by the kernel. - Generally, although not always, arguments to an access control - entry point will include one or more authorizing credentials, - information (possibly including a label) for any other objects - involved in the operation. An access control entry point may - return 0 to permit the operation, or an &man.errno.2; error - value. The results of invoking the entry point across various - registered policy modules will be composed as follows: if all - modules permit the operation to succeed, success will be - returned. If one or modules returns a failure, a failure will - be returned. If more than one module returns a failure, the - errno value to return to the user will be selected using the - following precedence, implemented by the - error_select() function in - kern_mac.c: - - - - - - Most precedence - EDEADLK - - - - EINVAL - - - - ESRCH - - - - EACCES - - - Least precedence - EPERM - - - - - - If none of the error values returned by all modules are - listed in the precedence chart then an arbitrarily selected - value from the set will be returned. In general, the rules - provide precedence to errors in the following order: kernel - failures, invalid arguments, object not present, access not - permitted, other. - - - <function>&mac.mpo;_check_bpfdesc_receive</function> - - - - int - &mac.mpo;_check_bpfdesc_receive - - struct bpf_d - *bpf_d - struct label - *bpflabel - struct ifnet - *ifnet - struct label - *ifnetlabel - - - - - - &mac.thead; - - - - bpf_d - Subject; BPF descriptor - - - - bpflabel - Policy label for - bpf_d - - - - ifnet - Object; network interface - - - - ifnetlabel - Policy label for - ifnet - - - - - - Determine whether the MAC framework should permit - datagrams from the passed interface to be delivered to the - buffers of the passed BPF descriptor. Return - (0) for success, or an - errno value for failure Suggested - failure: EACCES for label mismatches, - EPERM for lack of privilege. - - - - <function>&mac.mpo;_check_kenv_dump</function> - - - - int - &mac.mpo;_check_kenv_dump - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential - - - - - - Determine whether the subject should be allowed to - retrieve the kernel environment (see &man.kenv.2;). - - - - <function>&mac.mpo;_check_kenv_get</function> - - - - int - &mac.mpo;_check_kenv_get - - struct ucred - *cred - char *name - - - - - - &mac.thead; - - - - cred - Subject credential - - - - name - Kernel environment variable name - - - - - - Determine whether the subject should be allowed to - retrieve the value of the specified kernel environment - variable. - - - - <function>&mac.mpo;_check_kenv_set</function> - - - - int - &mac.mpo;_check_kenv_set - - struct ucred - *cred - char *name - - - - - - &mac.thead; - - - - cred - Subject credential - - - - name - Kernel environment variable name - - - - - - Determine whether the subject should be allowed to set - the specified kernel environment variable. - - - - <function>&mac.mpo;_check_kenv_unset</function> - - - - int - &mac.mpo;_check_kenv_unset - - struct ucred - *cred - char *name - - - - - - &mac.thead; - - - - cred - Subject credential - - - - name - Kernel environment variable name - - - - - - Determine whether the subject should be allowed to unset - the specified kernel environment variable. - - - - <function>&mac.mpo;_check_kld_load</function> - - - - int - &mac.mpo;_check_kld_load - - struct ucred - *cred - struct vnode - *vp - struct label - *vlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Kernel module vnode - - - - vlabel - Label associated with - vp - - - - - - Determine whether the subject should be allowed to load - the specified module file. - - - - <function>&mac.mpo;_check_kld_stat</function> - - - - int - &mac.mpo;_check_kld_stat - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential - - - - - - Determine whether the subject should be allowed to - retrieve a list of loaded kernel module files and associated - statistics. - - - - <function>&mac.mpo;_check_kld_unload</function> - - - - int - &mac.mpo;_check_kld_unload - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential - - - - - - Determine whether the subject should be allowed to - unload a kernel module. - - - - <function>&mac.mpo;_check_pipe_ioctl</function> - - - - int - &mac.mpo;_check_pipe_ioctl - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - unsigned long - cmd - void *data - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Policy label associated with - pipe - - - - cmd - &man.ioctl.2; command - - - - data - &man.ioctl.2; data - - - - - - Determine whether the subject should be allowed to make - the specified &man.ioctl.2; call. - - - - <function>&mac.mpo;_check_pipe_poll</function> - - - - int - &mac.mpo;_check_pipe_poll - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Policy label associated with - pipe - - - - - - Determine whether the subject should be allowed to poll - pipe. - - - - <function>&mac.mpo;_check_pipe_read</function> - - - - int - &mac.mpo;_check_pipe_read - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Policy label associated with - pipe - - - - - - Determine whether the subject should be allowed read - access to pipe. - - - - <function>&mac.mpo;_check_pipe_relabel</function> - - - - int - &mac.mpo;_check_pipe_relabel - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Current policy label associated with - pipe - - - - newlabel - Label update to - pipelabel - - - - - - Determine whether the subject should be allowed to - relabel pipe. - - - - <function>&mac.mpo;_check_pipe_stat</function> - - - - int - &mac.mpo;_check_pipe_stat - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Policy label associated with - pipe - - - - - - Determine whether the subject should be allowed to - retrieve statistics related to - pipe. - - - - <function>&mac.mpo;_check_pipe_write</function> - - - - int - &mac.mpo;_check_pipe_write - - struct ucred - *cred - struct pipe - *pipe - struct label - *pipelabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - pipe - Pipe - - - - pipelabel - Policy label associated with - pipe - - - - - - Determine whether the subject should be allowed to write - to pipe. - - - - <function>&mac.mpo;_check_socket_bind</function> - - - - int - &mac.mpo;_check_socket_bind - - struct ucred - *cred - struct socket - *socket - struct label - *socketlabel - struct sockaddr - *sockaddr - - - - - - &mac.thead; - - - - cred - Subject credential - - - - socket - Socket to be bound - - - - socketlabel - Policy label for - socket - - - - sockaddr - Address of - socket - - - - - - - - - - <function>&mac.mpo;_check_socket_connect</function> - - - - int - &mac.mpo;_check_socket_connect - - struct ucred - *cred - struct socket - *socket - struct label - *socketlabel - struct sockaddr - *sockaddr - - - - - - &mac.thead; - - - - cred - Subject credential - - - - socket - Socket to be connected - - - - socketlabel - Policy label for - socket - - - - sockaddr - Address of - socket - - - - - - Determine whether the subject credential - (cred) can connect the passed socket - (socket) to the passed socket address - (sockaddr). Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatches, - EPERM for lack of privilege. - - - - <function>&mac.mpo;_check_socket_receive</function> - - - - int - &mac.mpo;_check_socket_receive - - struct ucred - *cred - struct socket - *so - struct label - *socketlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - so - Socket - - - - socketlabel - Policy label associated with - so - - - - - - Determine whether the subject should be allowed to - receive information from the socket - so. - - - - <function>&mac.mpo;_check_socket_send</function> - - - - int - &mac.mpo;_check_socket_send - - struct ucred - *cred - struct socket - *so - struct label - *socketlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - so - Socket - - - - socketlabel - Policy label associated with - so - - - - - - Determine whether the subject should be allowed to send - information across the socket - so. - - - - <function>&mac.mpo;_check_cred_visible</function> - - - - int - &mac.mpo;_check_cred_visible - - struct ucred - *u1 - struct ucred - *u2 - - - - - - &mac.thead; - - - - u1 - Subject credential - - - - u2 - Object credential - - - - - - Determine whether the subject credential - u1 can see other - subjects with the passed subject credential - u2. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatches, - EPERM for lack of privilege, or - ESRCH to hide visibility. This call - may be made in a number of situations, including - inter-process status sysctls used by ps, - and in procfs lookups. - - - - <function>&mac.mpo;_check_socket_visible</function> - - - - int - &mac.mpo;_check_socket_visible - - struct ucred - *cred - struct socket - *socket - struct label - *socketlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - socket - Object; socket - - - - socketlabel - Policy label for - socket - - - - - - - - - <function>&mac.mpo;_check_ifnet_relabel</function> - - - - int - &mac.mpo;_check_ifnet_relabel - - struct ucred - *cred - struct ifnet - *ifnet - struct label - *ifnetlabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - ifnet - Object; network interface - - - - ifnetlabel - Existing policy label for - ifnet - - - - newlabel - Policy label update to later be applied to - ifnet - - - - - - Determine whether the subject credential can relabel the - passed network interface to the passed label update. - - - - <function>&mac.mpo;_check_socket_relabel</function> - - - - int - &mac.mpo;_check_socket_relabel - - struct ucred - *cred - struct socket - *socket - struct label - *socketlabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - socket - Object; socket - - - - socketlabel - Existing policy label for - socket - - - - newlabel - Label update to later be applied to - socketlabel - - - - - - Determine whether the subject credential can relabel the - passed socket to the passed label update. - - - - <function>&mac.mpo;_check_cred_relabel</function> - - - - int - &mac.mpo;_check_cred_relabel - - struct ucred - *cred - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - newlabel - Label update to later be applied to - cred - - - - - - Determine whether the subject credential can relabel - itself to the passed label update. - - - - - <function>&mac.mpo;_check_vnode_relabel</function> - - - - int - &mac.mpo;_check_vnode_relabel - - struct ucred - *cred - struct vnode - *vp - struct label - *vnodelabel - struct label - *newlabel - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - vp - Object; vnode - Locked - - - - vnodelabel - Existing policy label for - vp - - - - newlabel - Policy label update to later be applied to - vp - - - - - - Determine whether the subject credential can relabel the - passed vnode to the passed label update. - - - - <function>&mac.mpo;_check_mount_stat</function> - - - - int &mac.mpo;_check_mount_stat - - struct ucred - *cred - struct mount - *mp - struct label - *mountlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - mp - Object; file system mount - - - - mountlabel - Policy label for - mp - - - - - - - Determine whether the subject credential can see the - results of a statfs performed on the file system. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatches - or EPERM for lack of privilege. This - call may be made in a number of situations, including during - invocations of &man.statfs.2; and related calls, as well as to - determine what file systems to exclude from listings of file - systems, such as when &man.getfsstat.2; is invoked. - - - - <function>&mac.mpo;_check_proc_debug</function> - - - - int - &mac.mpo;_check_proc_debug - - struct ucred - *cred - struct proc - *proc - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - proc - Object; process - - - - - - Determine whether the subject credential can debug the - passed process. Return 0 for - success, or an errno value for failure. - Suggested failure: EACCES for label - mismatch, EPERM for lack of - privilege, or ESRCH to hide - visibility of the target. This call may be made in a number - of situations, including use of the &man.ptrace.2; and - &man.ktrace.2; APIs, as well as for some types of procfs - operations. - - - - <function>&mac.mpo;_check_vnode_access</function> - - - - int - &mac.mpo;_check_vnode_access - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int flags - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - flags - &man.access.2; flags - - - - - - Determine how invocations of &man.access.2; and related - calls by the subject credential should return when performed - on the passed vnode using the passed access flags. This - should generally be implemented using the same semantics - used in &mac.mpo;_check_vnode_open. - Return 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatches - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_chdir</function> - - - - int - &mac.mpo;_check_vnode_chdir - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Object; vnode to &man.chdir.2; into - - - - dlabel - Policy label for - dvp - - - - - - Determine whether the subject credential can change the - process working directory to the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_chroot</function> - - - - int - &mac.mpo;_check_vnode_chroot - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Directory vnode - - - - dlabel - Policy label associated with - dvp - - - - - - Determine whether the subject should be allowed to - &man.chroot.2; into the specified directory - (dvp). - - - - <function>&mac.mpo;_check_vnode_create</function> - - - - int - &mac.mpo;_check_vnode_create - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - struct componentname - *cnp - struct vattr - *vap - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Object; vnode - - - - dlabel - Policy label for - dvp - - - - cnp - Component name for - dvp - - - - vap - vnode attributes for vap - - - - - - Determine whether the subject credential can create a - vnode with the passed parent directory, passed name - information, and passed attribute information. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES. for label mismatch, - or EPERM for lack of privilege. - This call may be made in a number of situations, including - as a result of calls to &man.open.2; with - O_CREAT, &man.mknod.2;, &man.mkfifo.2;, and - others. - - - - <function>&mac.mpo;_check_vnode_delete</function> - - - - int - &mac.mpo;_check_vnode_delete - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - struct vnode - *vp - void *label - struct componentname - *cnp - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Parent directory vnode - - - - dlabel - Policy label for - dvp - - - - vp - Object; vnode to delete - - - - label - Policy label for - vp - - - - cnp - Component name for - vp - - - - - - Determine whether the subject credential can delete a - vnode from the passed parent directory and passed name - information. Return 0 for - success, or an errno value for failure. - Suggested failure: EACCES for label - mismatch, or EPERM for lack of - privilege. This call may be made in a number of situations, - including as a result of calls to &man.unlink.2; and - &man.rmdir.2;. Policies implementing this entry point - should also implement - mpo_check_rename_to to authorize - deletion of objects as a result of being the target of a - rename. - - - - <function>&mac.mpo;_check_vnode_deleteacl</function> - - - - int - &mac.mpo;_check_vnode_deleteacl - - struct ucred *cred - struct vnode *vp - struct label *label - acl_type_t type - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - vp - Object; vnode - Locked - - - - label - Policy label for - vp - - - - type - ACL type - - - - - - Determine whether the subject credential can delete the - ACL of passed type from the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_exec</function> - - - - int - &mac.mpo;_check_vnode_exec - - struct ucred - *cred - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode to execute - - - - label - Policy label for - vp - - - - - - Determine whether the subject credential can execute the - passed vnode. Determination of execute privilege is made - seperately from decisions about any transitioning event. - Return 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_getacl</function> - - - - int - &mac.mpo;_check_vnode_getacl - - struct ucred - *cred - struct vnode - *vp - struct label - *label - acl_type_t - type - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - type - ACL type - - - - - - Determine whether the subject credentical can retrieve - the ACL of passed type from the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_getextattr</function> - - - - int - &mac.mpo;_check_vnode_getextattr - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int - attrnamespace - const char - *name - struct uio - *uio - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - attrnamespace - Extended attribute namespace - - - - name - Extended attribute name - - - - uio - I/O structure pointer; see &man.uio.9; - - - - - - Determine whether the subject credential can retrieve - the extended attribute with the passed namespace and name - from the passed vnode. Policies implementing labeling using - extended attributes may be interested in special handling of - operations on those extended attributes. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_link</function> - - - - int - &mac.mpo;_check_vnode_link - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - struct vnode - *vp - struct label - *label - struct componentname - *cnp - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Directory vnode - - - - dlabel - Policy label associated with - dvp - - - - vp - Link destination vnode - - - - label - Policy label associated with - vp - - - - cnp - Component name for the link being created - - - - - - Determine whether the subject should be allowed to - create a link to the vnode vp with - the name specified by cnp. - - - - <function>&mac.mpo;_check_vnode_mmap</function> - - - - int - &mac.mpo;_check_vnode_mmap - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int prot - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Vnode to map - - - - label - Policy label associated with - vp - - - - prot - Mmap protections (see &man.mmap.2;) - - - - - - Determine whether the subject should be allowed to map - the vnode vp with the protections - specified in prot. - - - - <function>&mac.mpo;_check_vnode_mmap_downgrade</function> - - - - void - &mac.mpo;_check_vnode_mmap_downgrade - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int *prot - - - - - - &mac.thead; - - - - cred - See - . - - - - vp - - - - label - - - - prot - Mmap protections to be downgraded - - - - - - Downgrade the mmap protections based on the subject and - object labels. - - - - <function>&mac.mpo;_check_vnode_mprotect</function> - - - - int - &mac.mpo;_check_vnode_mprotect - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int prot - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Mapped vnode - - - - prot - Memory protections - - - - - - Determine whether the subject should be allowed to - set the specified memory protections on memory mapped from - the vnode vp. - - - - <function>&mac.mpo;_check_vnode_poll</function> - - - - int - &mac.mpo;_check_vnode_poll - - struct ucred - *active_cred - struct ucred - *file_cred - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - active_cred - Subject credential - - - - file_cred - Credential associated with the struct - file - - - - vp - Polled vnode - - - - label - Policy label associated with - vp - - - - - - Determine whether the subject should be allowed to poll - the vnode vp. - - - - <function>&mac.mpo;_check_vnode_rename_from</function> - - - - int - &mac.mpo;_vnode_rename_from - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - struct vnode - *vp - struct label - *label - struct componentname - *cnp - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Directory vnode - - - - dlabel - Policy label associated with - dvp - - - - vp - Vnode to be renamed - - - - label - Policy label asociated with - vp - - - - cnp - Component name for - vp - - - - - - Determine whether the subject should be allowed to - rename the vnode vp to something - else. - - - - <function>&mac.mpo;_check_vnode_rename_to</function> - - - - int - &mac.mpo;_check_vnode_rename_to - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - struct vnode - *vp - struct label - *label - int samedir - struct componentname - *cnp - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Directory vnode - - - - dlabel - Policy label associated with - dvp - - - - vp - Overwritten vnode - - - - label - Policy label associated with - vp - - - - samedir - Boolean; 1 if the source and - destination directories are the same - - - - cnp - Destination component name - - - - - - Determine whether the subject should be allowed to - rename to the vnode vp, into the - directory dvp, or to the name - represented by cnp. If there is no - existing file to overwrite, vp and - label will be NULL. - - - - <function>&mac.mpo;_check_socket_listen</function> - - - - int - &mac.mpo;_check_socket_listen - - struct ucred - *cred - struct socket - *socket - struct label - *socketlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - socket - Object; socket - - - - socketlabel - Policy label for - socket - - - - - - Determine whether the subject credential can listen on - the passed socket. Return 0 for - success, or an errno value for failure. - Suggested failure: EACCES for label - mismatch, or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_lookup</function> - - - - int - &mac.mpo;_check_vnode_lookup - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - struct componentname - *cnp - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Object; vnode - - - - dlabel - Policy label for - dvp - - - - cnp - Component name being looked up - - - - - - Determine whether the subject credential can perform a - lookup in the passed directory vnode for the passed name. - Return 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_open</function> - - - - int - &mac.mpo;_check_vnode_open - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int - acc_mode - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - acc_mode - &man.open.2; access mode - - - - - - Determine whether the subject credential can perform an - open operation on the passed vnode with the passed access - mode. Return 0 for success, or - an errno value for failure. Suggested failure: - EACCES for label mismatch, or - EPERM for lack of privilege. - - - - <function>&mac.mpo;_check_vnode_readdir</function> - - - - int - &mac.mpo;_check_vnode_readdir - - struct ucred - *cred - struct vnode - *dvp - struct label - *dlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - dvp - Object; directory vnode - - - - dlabel - Policy label for - dvp - - - - - - Determine whether the subject credential can perform a - readdir operation on the passed - directory vnode. Return 0 for - success, or an errno value for failure. - Suggested failure: EACCES for label - mismatch, or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_readlink</function> - - - - int - &mac.mpo;_check_vnode_readlink - - struct ucred - *cred - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - - - Determine whether the subject credential can perform a - readlink operation on the passed - symlink vnode. Return 0 for - success, or an errno value for failure. - Suggested failure: EACCES for label - mismatch, or EPERM for lack of - privilege. This call may be made in a number of situations, - including an explicit readlink call by - the user process, or as a result of an implicit - readlink during a name lookup by the - process. - - - - <function>&mac.mpo;_check_vnode_revoke</function> - - - - int - &mac.mpo;_check_vnode_revoke - - struct ucred - *cred - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - - - Determine whether the subject credential can revoke - access to the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_setacl</function> - - - - int - &mac.mpo;_check_vnode_setacl - - struct ucred - *cred - struct vnode - *vp - struct label - *label - acl_type_t - type - struct acl - *acl - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - type - ACL type - - - - acl - ACL - - - - - - Determine whether the subject credential can set the - passed ACL of passed type on the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_setextattr</function> - - - - int - &mac.mpo;_check_vnode_setextattr - - struct ucred - *cred - struct vnode - *vp - struct label - *label - int - attrnamespace - const char - *name - struct uio - *uio - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for vp - - - - attrnamespace - Extended attribute namespace - - - - name - Extended attribute name - - - - uio - I/O structure pointer; see &man.uio.9; - - - - - - Determine whether the subject credentical can set the - extended attribute of passed name and passed namespace on - the passed vnode. Policies implementing security labels - backed into extended attributes may want to provide - additional protections for those attributes. Additionally, - policies should avoid making decisions based on the data - referenced from uio, as there is a - potential race condition between this check and the actual - operation. The uio may also be - NULL if a delete operation is being - performed. Return 0 for success, - or an errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_setflags</function> - - - - int - &mac.mpo;_check_vnode_setflags - - struct ucred - *cred - struct vnode - *vp - struct label - *label - u_long flags - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - flags - File flags; see &man.chflags.2; - - - - - - Determine whether the subject credential can set the - passed flags on the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_setmode</function> - - - - int - &mac.mpo;_check_vnode_setmode - - struct ucred - *cred - struct vnode - *vp - struct label - *label - mode_t mode - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for vp - - - - mode - File mode; see &man.chmod.2; - - - - - - Determine whether the subject credential can set the - pased mode on the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_vnode_setowner</function> - - - - int - &mac.mpo;_check_vnode_setowner - - struct ucred - *cred - struct vnode - *vp - struct label - *label - uid_t uid - gid_t gid - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for vp - - - - uid - User ID - - - - gid - Group ID - - - - - - Determine whether the subject credential can set the - passed uid and passed gid as file uid and file gid on the - passed vnode. The IDs may be set to (-1) - to request no update. Return 0 - for success, or an errno value for - failure. Suggested failure: EACCES - for label mismatch, or EPERM for lack - of privilege. - - - - <function>&mac.mpo;_check_vnode_setutimes</function> - - - - int - &mac.mpo;_check_vnode_setutimes - - struct ucred - *cred - struct vnode - *vp - struct label - *label - struct timespec - atime - struct timespec - mtime - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vp - - - - label - Policy label for - vp - - - - atime - Access time; see &man.utimes.2; - - - - mtime - Modification time; see &man.utimes.2; - - - - - - Determine whether the subject credential can set the - passed access timestamps on the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_proc_sched</function> - - - - int - &mac.mpo;_check_proc_sched - - struct ucred - *ucred - struct proc - *proc - - - - - - &mac.thead; - - - - cred - Subject credential - - - - proc - Object; process - - - - - - Determine whether the subject credential can change the - scheduling parameters of the passed process. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - EPERM for lack of privilege, or - ESRCH to limit visibility. - - See &man.setpriority.2; for more information. - - - - <function>&mac.mpo;_check_proc_signal</function> - - - - int - &mac.mpo;_check_proc_signal - - struct ucred - *cred - struct proc - *proc - int signal - - - - - - &mac.thead; - - - - cred - Subject credential - - - - proc - Object; process - - - - signal - Signal; see &man.kill.2; - - - - - - Determine whether the subject credential can deliver the - passed signal to the passed process. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - EPERM for lack of privilege, or - ESRCH to limit visibility. - - - - <function>&mac.mpo;_check_vnode_stat</function> - - - - int - &mac.mpo;_check_vnode_stat - - struct ucred - *cred - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Object; vnode - - - - label - Policy label for - vp - - - - - - Determine whether the subject credential can - stat the passed vnode. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatch, - or EPERM for lack of - privilege. - - See &man.stat.2; for more information. - - - - <function>&mac.mpo;_check_ifnet_transmit</function> - - - - int - &mac.mpo;_check_ifnet_transmit - - struct ucred - *cred - struct ifnet - *ifnet - struct label - *ifnetlabel - struct mbuf - *mbuf - struct label - *mbuflabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - ifnet - Network interface - - - - ifnetlabel - Policy label for - ifnet - - - - mbuf - Object; mbuf to be sent - - - - mbuflabel - Policy label for - mbuf - - - - - - Determine whether the network interface can transmit the - passed mbuf. Return 0 for - success, or an errno value for failure. - Suggested failure: EACCES for label - mismatch, or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_socket_deliver</function> - - - - int - &mac.mpo;_check_socket_deliver - - struct ucred - *cred - struct ifnet - *ifnet - struct label - *ifnetlabel - struct mbuf - *mbuf - struct label - *mbuflabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - ifnet - Network interface - - - - ifnetlabel - Policy label for - ifnet - - - - mbuf - Object; mbuf to be delivered - - - - mbuflabel - Policy label for - mbuf - - - - - - Determine whether the socket may receive the datagram - stored in the passed mbuf header. Return - 0 for success, or an - errno value for failure. Suggested - failures: EACCES for label mismatch, - or EPERM for lack of - privilege. - - - - <function>&mac.mpo;_check_socket_visible</function> - - - - int - &mac.mpo;_check_socket_visible - - struct ucred - *cred - struct socket - *so - struct label - *socketlabel - - - - - - &mac.thead; - - - - cred - Subject credential - Immutable - - - - so - Object; socket - - - - socketlabel - Policy label for - so - - - - - - Determine whether the subject credential cred can "see" - the passed socket (socket) using - system monitoring functions, such as those employed by - &man.netstat.8; and &man.sockstat.1;. Return - 0 for success, or an - errno value for failure. Suggested - failure: EACCES for label mismatches, - EPERM for lack of privilege, or - ESRCH to hide visibility. - - - - <function>&mac.mpo;_check_system_acct</function> - - - - int - &mac.mpo;_check_system_acct - - struct ucred - *ucred - struct vnode - *vp - struct label - *vlabel - - - - - - &mac.thead; - - - - ucred - Subject credential - - - - vp - Accounting file; &man.acct.5; - - - - vlabel - Label associated with - vp - - - - - - Determine whether the subject should be allowed to - enable accounting, based on its label and the label of the - accounting log file. - - - - <function>&mac.mpo;_check_system_nfsd</function> - - - - int - &mac.mpo;_check_system_nfsd - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential - - - - - - Determine whether the subject should be allowed to call - &man.nfssvc.2;. - - - - <function>&mac.mpo;_check_system_reboot</function> - - - - int - &mac.mpo;_check_system_reboot - - struct ucred - *cred - int howto - - - - - - &mac.thead; - - - - cred - Subject credential - - - - howto - howto parameter from - &man.reboot.2; - - - - - - Determine whether the subject should be allowed to - reboot the system in the specified manner. - - - - <function>&mac.mpo;_check_system_settime</function> - - - - int - &mac.mpo;_check_system_settime - - struct ucred - *cred - - - - - - &mac.thead; - - - - cred - Subject credential - - - - - - Determine whether the user should be allowed to set the - system clock. - - - - <function>&mac.mpo;_check_system_swapon</function> - - - - int - &mac.mpo;_check_system_swapon - - struct ucred - *cred - struct vnode - *vp - struct label - *vlabel - - - - - - &mac.thead; - - - - cred - Subject credential - - - - vp - Swap device - - - - vlabel - Label associated with - vp - - - - - - Determine whether the subject should be allowed to add - vp as a swap device. - - - - <function>&mac.mpo;_check_system_sysctl</function> - - - - int - &mac.mpo;_check_system_sysctl - - struct ucred - *cred - int *name - u_int *namelen - void *old - size_t - *oldlenp - int inkernel - void *new - size_t newlen - - - - - - &mac.thead; - - - - cred - Subject credential - - - - name - See &man.sysctl.3; - - - - namelen - - - - old - - - - oldlenp - - - - inkernel - Boolean; 1 if called from - kernel - - - - new - See &man.sysctl.3; - - - - newlen - - - - - - Determine whether the subject should be allowed to make - the specified &man.sysctl.3; transaction. - - - - - Label Management Calls - - Relabel events occur when a user process has requested - that the label on an object be modified. A two-phase update - occurs: first, an access control check will be performed to - determine if the update is both valid and permitted, and then - the update itself is performed via a seperate entry point. - Relabel entry points typically accept the object, object label - reference, and an update label submitted by the process. - Memory allocation during relabel is discouraged, as relabel - calls are not permitted to fail (failure should be reported - earlier in the relabel check). - - - - - <function>&mac.mpo;_destroy_vnode_label</function> - - - - void - &mac.mpo;_destroy_vnode_label - - struct vnode - *vp - struct label - *label - - - - - - &mac.thead; - - - - vp - Object; file system object - - - - label - Label being destroyed - - - - - - Destroy the label on a vnode. In this entry point, a - policy module should free any internal storage associated - with label so that it may be - destroyed. - - - - - - Userland APIs - - The userland API is still under development. - - - - Sample Policy Modules - - The mac_none policy provides sample - prototypes and registration of all available policy entry - points. - - The mac_seeotheruids policy provides - a simple access control policy without the use of labeling, - relying only on information already present in the kernel - objects. - - The mac_biba policy provides a sample - information flow based labeled access control policy, - assigning labels to all kernel objects. - - - - Conclusion - - The TrustedBSD MAC framework permits kernel modules to - augment the system security policy in a highly integrated - manner. They may do this based on existing object properties, - or based on label data that is maintained with the assistance of - the MAC framework. The framework is sufficiently flexible to - implement a variety of policy types, including information flow - security policies such as MLS and Biba, as well as policies - based on existing BSD credentials or file protections. Policy - authors may wish to consult this documentation as well as - existing security modules when implementing a new security - service. - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml deleted file mode 100644 index e33a5cc9e9..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/newbus/chapter.sgml +++ /dev/null @@ -1,360 +0,0 @@ - - - - - - Jeroen - Ruigrok van der Werven (asmodai) -
asmodai@FreeBSD.org
- - Written by - - - Hiten - Pandya -
hiten@uk.FreeBSD.org
- - - - - Newbus - - Special thanks to Mathew N. Dodd, Warner Losh, Bill Paul. - Daug Rabson, Mike Smith, Peter Wemm and Scott Long. - - This chapter explains the Newbus device framework in detail. - - Device Drivers - - Purpose of a Device Driver - A device driver is a software component which provides the - interface between the kernel's generic view of a peripheral - (e.g. disk, network adapter) and the actual implementation of the - peripheral. The device driver interface (DDI) is - the defined interface between the kernel and the device driver component. - - - - - Types of Device Drivers - There used to be days in &unix;, and thus FreeBSD, in which there - were four types of devices defined: - - - block device drivers - character device drivers - network device drivers - pseudo-device drivers - - - Block devices performed in way that used - fixed size blocks [of data]. This type of driver depended on the - so called buffer cache, which had the purpose - to cache accessed blocks of data in a dedicated part of the memory. - Often this buffer cache was based on write-behind, which meant that when - data was modified in memory it got synced to disk whenever the system - did its periodical disk flushing, thus optimizing writes. - - - - Character devices - However, in the versions of FreeBSD 4.0 and onward the - distinction between block and character devices became non-existent. - - - - - - - Overview of Newbus - Newbus is the implementation of a new bus - architecture based on abstraction layers which saw its introduction in - FreeBSD 3.0 when the Alpha port was imported into the source tree. It was - not until 4.0 before it became the default system to use for device - drivers. Its goals are to provide a more object oriented means of - interconnecting the various busses and devices which a host system - provides to the Operating System. - - Its main features include amongst others: - - - dynamic attaching - easy modularization of drivers - pseudo-busses - - - One of the most prominent changes is the migration from the flat and - ad-hoc system to a device tree lay-out. - - At the top level resides the root - device which is the parent to hang all other devices on. For each - architecture, there is typically a single child of root - which has such things as host-to-PCI bridges, etc. - attached to it. For x86, this root device is the - nexus device and for Alpha, various - different different models of Alpha have different top-level devices - corresponding to the different hardware chipsets, including - lca, apecs, - cia and tsunami. - - A device in the Newbus context represents a single hardware entity - in the system. For instance each PCI device is represented by a Newbus - device. Any device in the system can have children; a device which has - children is often called a bus. - Examples of common busses in the system are ISA and PCI which manage lists - of devices attached to ISA and PCI busses respectively. - - Often, a connection between different kinds of bus is represented by - a bridge device which normally has one - child for the attached bus. An example of this is a - PCI-to-PCI bridge which is represented by a device - pcibN on the parent PCI bus - and has a child pciN for the - attached bus. This layout simplifies the implementation of the PCI bus - tree, allowing common code to be used for both top-level and bridged - busses. - - Each device in the Newbus architecture asks its parent to map its - resources. The parent then asks its own parent until the nexus is - reached. So, basically the nexus is the only part of the Newbus system - which knows about all resources. - - An ISA device might want to map its IO port at - 0x230, so it asks its parent, in this case the ISA - bus. The ISA bus hands it over to the PCI-to-ISA bridge which in its turn - asks the PCI bus, which reaches the host-to-PCI bridge and finally the - nexus. The beauty of this transition upwards is that there is room to - translate the requests. For example, the 0x230 IO port - request might become memory-mapped at 0xb0000230 on a - MIPS box by the PCI bridge. - - Resource allocation can be controlled at any place in the device - tree. For instance on many Alpha platforms, ISA interrupts are managed - separately from PCI interrupts and resource allocations for ISA interrupts - are managed by the Alpha's ISA bus device. On IA-32, ISA and PCI - interrupts are both managed by the top-level nexus device. For both - ports, memory and port address space is managed by a single entity - nexus - for IA-32 and the relevant chipset driver on Alpha (e.g. CIA or tsunami). - - - In order to normalize access to memory and port mapped resources, - Newbus integrates the bus_space APIs from NetBSD. - These provide a single API to replace inb/outb and direct memory - reads/writes. The advantage of this is that a single driver can easily - use either memory-mapped registers or port-mapped registers - (some hardware supports both). - - This support is integrated into the resource allocation mechanism. - When a resource is allocated, a driver can retrieve the associated - bus_space_tag_t and - bus_space_handle_t from the resource. - - Newbus also allows for definitions of interface methods in files - dedicated to this purpose. These are the .m files - that are found under the src/sys hierarchy. - - The core of the Newbus system is an extensible - object-based programming model. Each device in the system - has a table of methods which it supports. The system and other devices - uses those methods to control the device and request services. The - different methods supported by a device are defined by a number of - interfaces. An interface is simply a group - of related methods which can be implemented by a device. - - In the Newbus system, the methods for a device are provided by the - various device drivers in the system. When a device is attached to a - driver during auto-configuration, it uses the method - table declared by the driver. A device can later - detach from its driver and - re-attach to a new driver with a new method table. - This allows dynamic replacement of drivers which can be useful for driver - development. - - The interfaces are described by an interface definition language - similar to the language used to define vnode operations for file systems. - The interface would be stored in a methods file (which would normally named - foo_if.m). - - - Newbus Methods - - # Foo subsystem/driver (a comment...) - - INTERFACE foo - - METHOD int doit { - device_t dev; - }; - - # DEFAULT is the method that will be used, if a method was not - # provided via: DEVMETHOD() - - METHOD void doit_to_child { - device_t dev; - driver_t child; - } DEFAULT doit_generic_to_child; - - - - When this interface is compiled, it generates a header file - foo_if.h which contains function - declarations: - - - int FOO_DOIT(device_t dev); - int FOO_DOIT_TO_CHILD(device_t dev, device_t child); - - - A source file, foo_if.c is - also created to accompany the automatically generated header file; it - contains implementations of those functions which look up the location - of the relevant functions in the object's method table and call that - function. - - The system defines two main interfaces. The first fundamental - interface is called device and - includes methods which are relevant to all devices. Methods in the - device interface include - probe, - attach and - detach to control detection of - hardware and shutdown, - suspend and - resume for critical event - notification. - - The second, more complex interface is - bus. This interface contains - methods suitable for devices which have children, including methods to - access bus specific per-device information - &man.bus.generic.read.ivar.9; and - &man.bus.generic.write.ivar.9;, event notification - (child_detached, - driver_added) and resource - management (alloc_resource, - activate_resource, - deactivate_resource, - release_resource). - - Many methods in the bus interface are performing - services for some child of the bus device. These methods would normally - use the first two arguments to specify the bus providing the service - and the child device which is requesting the service. To simplify - driver code, many of these methods have accessor functions which - lookup the parent and call a method on the parent. For instance the - method - BUS_TEARDOWN_INTR(device_t dev, device_t child, ...) - can be called using the function - bus_teardown_intr(device_t child, ...). - - Some bus types in the system define additional interfaces to - provide access to bus-specific functionality. For instance, the PCI - bus driver defines the pci interface which has two - methods read_config and - write_config for accessing the - configuration registers of a PCI device. - - - - Newbus API - As the Newbus API is huge, this section makes some effort at - documenting it. More information to come in the next revision of this - document. - - - Important locations in the source hierarchy - - src/sys/[arch]/[arch] - Kernel code for a - specific machine architecture resides in this directory. for example, - the i386 architecture, or the - SPARC64 architecture. - - src/sys/dev/[bus] - device support for a - specific [bus] resides in this directory. - - src/sys/dev/pci - PCI bus support code - resides in this directory. - - src/sys/[isa|pci] - PCI/ISA device drivers - reside in this directory. The PCI/ISA bus support code used to exist - in this directory in FreeBSD version 4.0. - - - - Important structures and type definitions - devclass_t - This is a type definition of a - pointer to a struct devclass. - - device_method_t - This is same as - kobj_method_t (see - src/sys/kobj.h). - - device_t - This is a type definition of a - pointer to a struct device. - device_t represents a device in the system. It is - a kernel object. See src/sys/sys/bus_private.h - for implementation details. - - driver_t - This is a type definition which, - references struct driver. The - driver struct is a class of the - device kernel object; it also holds data private - to for the driver. - -
- <emphasis>driver_t</emphasis> implementation - - struct driver { - KOBJ_CLASS_FIELDS; - void *priv; /* driver private data */ - }; - -
- - A device_state_t type, which is - an enumeration, device_state. It contains - the possible states of a Newbus device before and after the - autoconfiguration process. - -
- Device states<emphasis>device_state_t</emphasis> - - /* - * src/sys/sys/bus.h - */ - typedef enum device_state { - DS_NOTPRESENT, /* not probed or probe failed */ - DS_ALIVE, /* probe succeeded */ - DS_ATTACHED, /* attach method called */ - DS_BUSY /* device is open */ - } device_state_t; - -
- - - 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 d0cce3dbfc..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/pci/chapter.sgml +++ /dev/null @@ -1,369 +0,0 @@ - - - - PCI Devices - - This chapter will talk about the FreeBSD mechanisms for - writing a device driver for a device on a PCI bus. - - - Probe and Attach - - 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. - -/* - * 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(&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); - - Additional Resources - - PCI - Special Interest Group - - PCI System Architecture, Fourth Edition by - Tom Shanley, et al. - - - - - - - Bus Resources - - 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). - - - Base Address Registers - - To do anything particularly useful with a PCI device you - will need to obtain the Base Address - Registers (BARs) from the PCI Configuration space. - The PCI-specific details of obtaining the BAR are abstracted in - the bus_alloc_resource() function. - - For example, a typical driver might have something similar - to this in the attach() function: - - 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); - - - - Handles for each base address register are kept in the - softc structure so that they can be - used to write to the device later. - - These handles can then be used to read or write from the - device registers with the bus_space_* - functions. For example, a driver might contain a shorthand - function to read from a board specific register like this: - -uint16_t -board_read(struct ni_softc *sc, uint16_t address) { - return bus_space_read_2(sc->bar1_bt, sc->bar1_bh, address); -} - - - Similarly, one could write to the registers with: - -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); -} - - - These functions exist in 8bit, 16bit, and 32bit versions - and you should use - bus_space_{read|write}_{1|2|4} - accordingly. - - - - Interrupts - - 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. - - Again, a sample from a device - attach() function says more than - words. - -/* 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); - - - - - - DMA - 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, - vtophys() to help. - -#include <vm/vm.h> -#include <vm/pmap.h> - -#define vtophys(virtual_address) (...) - - - The solution is a bit different on the alpha however, and - what we really want is a function called - vtobus(). - -#if defined(__alpha__) -#define vtobus(va) alpha_XXX_dmamap((vm_offset_t)va) -#else -#define vtobus(va) vtophys(va) -#endif - - - - - - Deallocating Resources - - It is very important to deallocate all of the resources - that were allocated during attach(). - Care must be taken to deallocate the correct stuff even on a - failure condition so that the system will remain usable while - your driver dies. - - - - - 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 de987e88e0..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/scsi/chapter.sgml +++ /dev/null @@ -1,1983 +0,0 @@ - - - - Common Access Method SCSI Controllers - - This chapter was written by &a.babkin; - Modifications for the handbook made by - &a.murray;. - - - Synopsis - - 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: - - - - ncr (/sys/pci/ncr.c) by - Wolfgang Stanglmeier and Stefan Esser - - sym (/sys/dev/sym/sym_hipd.c) by - Gerard Roudier - - aic7xxx - (/sys/dev/aic7xxx/aic7xxx.c) by Justin - T. Gibbs - - - - and from the CAM code itself (by Justing T. Gibbs, see - /sys/cam/*). When some solution looked the - most logical and was essentially verbatim extracted from the code - by Justin Gibbs, I marked it as recommended. - - The document is illustrated with examples in - pseudo-code. Although sometimes the examples have many details - and look like real code, it is 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. - - - - - General architecture - - CAM stands for Common Access Method. It is 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: - - - Peripheral Modules - a - driver for peripheral devices (disk, tape, CDROM, - etc.) - SCSI Interface Modules (SIM) - - a Host Bus Adapter drivers for connecting to an I/O bus such - as SCSI or IDE. - - - 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). - - Because we are interested in writing a SCSI adapter driver - here, from this point on we will consider everything from the - SIM standpoint. - - A typical SIM driver needs to include the following - CAM-related header files: - -#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> - - The first thing each SIM driver must do is register itself - with the CAM subsystem. This is done during the driver's - xxx_attach() function (here and further - xxx_ is used to denote the unique driver name prefix). The - xxx_attach() function itself is called by - the system bus auto-configuration code which we do not describe - here. - - This is achieved in multiple steps: first it is necessary to - allocate the queue of requests associated with this SIM: - - struct cam_devq *devq; - - if(( devq = cam_simq_alloc(SIZE) )==NULL) { - error; /* some code to handle the error */ - } - - Here SIZE is the size of the queue to be allocated, maximal - number of requests it could contain. It is the number of requests - that the SIM driver can handle in parallel on one SCSI - card. Commonly it can be calculated as: - -SIZE = NUMBER_OF_SUPPORTED_TARGETS * MAX_SIMULTANEOUS_COMMANDS_PER_TARGET - - Next we create a descriptor of our SIM: - - 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 */ - } - - Note that if we are not able to create a SIM descriptor we - free the devq also because we can do - nothing else with it and we want to conserve memory. - - If a SCSI card has multiple SCSI buses on it then each bus - requires its own cam_sim - structure. - - An interesting question is what to do if a SCSI card has - more than one SCSI bus, do we need one - devq 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. - - The arguments are: - - - action_func - pointer to - the driver's xxx_action function. - - static void - xxx_action - - - struct cam_sim *sim, - union ccb *ccb - - - - - poll_func - pointer to - the driver's xxx_poll() - - static void - xxx_poll - - - struct cam_sim *sim - - - - - driver_name - the name of the actual driver, - such as ncr or wds. - - softc - 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. - - unit - the controller unit number, for example - for controller wds0 this number will be - 0 - - 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. - - 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. - - - - Finally we register the SCSI buses associated with our SCSI - adapter: - - if(xpt_bus_register(sim, bus_number) != CAM_SUCCESS) { - cam_sim_free(sim, /*free_devq*/ TRUE); - error; /* some code to handle the error */ - } - - If there is one devq 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. - - After that our controller is completely hooked to the CAM - system. The value of devq can be - discarded now: sim will be passed as an argument in all further - calls from CAM and devq can be derived from it. - - 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. - - 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 is 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: - - 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; - - As you can see the path includes: - - - ID of the peripheral driver (NULL here because we have - none) - - ID of the SIM driver - (cam_sim_path(sim)) - - SCSI target number of the device (CAM_TARGET_WILDCARD - means all devices) - - SCSI LUN number of the subdevice (CAM_LUN_WILDCARD means - all LUNs) - - - If the driver can not allocate this path it will not be able to - work normally, so in that case we dismantle that SCSI - bus. - - And we save the path pointer in the - softc structure for future use. After - that we save the value of sim (or we can also discard it on the - exit from xxx_probe() if we wish). - - That is all for a minimalistic initialization. To do things - right there is one more issue left. - - 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: - - 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); - - Now we take a look at the xxx_action() - and xxx_poll() driver entry points. - - - - static void - xxx_action - - - struct cam_sim *sim, - union ccb *ccb - - - - - 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. - - 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. - - There are a few function and macros (in other words, - methods) defined to access the public data in the struct sim: - - - cam_sim_path(sim) - the - path ID (see above) - - cam_sim_name(sim) - the - name of the sim - - cam_sim_softc(sim) - the - pointer to the softc (driver private data) - structure - - cam_sim_unit(sim) - the - unit number - - cam_sim_bus(sim) - the bus - ID - - - To identify the device, xxx_action() can - get the unit number and pointer to its structure softc using - these functions. - - The type of request is stored in - ccb->ccb_h.func_code. So generally - xxx_action() consists of a big - switch: - - 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; - } - - As can be seen from the default case (if an unknown command - was received) the return code of the command is set into - ccb->ccb_h.status and the completed - CCB is returned back to CAM by calling - xpt_done(ccb). - - xpt_done() does not have to be called - from xxx_action(): 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 - xpt_done() may be called from the interrupt - handling routine. - - 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 xxx_action() routine it gets - the status CCB_REQ_INPROG meaning that it is in progress. There - are a surprising number of status values defined in - /sys/cam/cam.h 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: - - - - CAM_DEV_QFRZN - 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 - xpt_freeze_simq(), 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 xpt_done(). This flag causes the CAM - subsystem to unfreeze the queue after it handles the - error. - - CAM_AUTOSNS_VALID - 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. - - CAM_RELEASE_SIMQ - 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 - xpt_freeze_simq(). The controller queue - will be restarted after the SIM driver overcomes the shortage - and informs CAM by returning some CCB with this flag - set. - - CAM_SIM_QUEUED - 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. - - - - The function xxx_action() 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 - xpt_release_simq() and - xpt_release_devq() to unfreeze the queues - directly, without passing a CCB to CAM. - - The CCB header contains the following fields: - - - - path - path ID for the - request - - target_id - target device - ID for the request - - target_lun - LUN ID of - the target device - - timeout - timeout - interval for this command, in milliseconds - - timeout_ch - a - convenience place for the SIM driver to store the timeout handle - (the CAM subsystem itself does not make any assumptions about - it) - - flags - 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. - - - - 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: - -#define ccb_some_meaningful_name sim_priv.entries[0].bytes -#define ccb_hcb spriv_ptr1 /* for hardware control block */ - - The most common initiator mode requests are: - - XPT_SCSI_IO - execute an - I/O transaction - - The instance struct ccb_scsiio csio of the union ccb is - used to transfer the arguments. They are: - - - cdb_io - pointer to - the SCSI command buffer or the buffer - itself - - cdb_len - SCSI - command length - - data_ptr - pointer to - the data buffer (gets a bit complicated if scatter/gather is - used) - - dxfer_len - length of - the data to transfer - - sglist_cnt - counter - of the scatter/gather segments - - scsi_status - place - to return the SCSI status - - sense_data - 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) - - sense_len - 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. - - tag_action - the kind - of tag to use: - - - CAM_TAG_ACTION_NONE - do not use tags for this - transaction - 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 - - - - - - - The general logic of handling this request is the - following: - - 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: - - struct ccb_scsiio *csio = &ccb->csio; - - if ((ccb_h->status & CAM_STATUS_MASK) != CAM_REQ_INPROG) { - xpt_done(ccb); - return; - } - - Also we check that the device is supported at all by our - controller: - - 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; - } - - Then allocate whatever data structures (such as - card-dependent hardware control block) we need to process this - request. If we ca not 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. - - 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; - - 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. - - 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); - - 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. - - 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 is OK to return the CCB with - the status CAM_REQ_INVALID, the current drivers do that. But - it is 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 do not do - that. - - 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; - - Now it is 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: - - int dir = (ccb_h->flags & CAM_DIR_MASK); - - if (dir == CAM_DIR_NONE) - goto end_data; - - 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 is 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 is actively used by CAM. - - 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: - - If disconnection is disabled for this CCB we pass this - information to the hcb: - - if(ccb_h->flags & CAM_DIS_DISCONNECT) - hcb_disable_disconnect(hcb); - - 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. - - 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). - - 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; - - And here is a possible implementation of the function - returning CCB: - - 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); - } - - - XPT_RESET_DEV - send the SCSI BUS - DEVICE RESET message to a device - - 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). - - 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. - - XPT_RESET_BUS - send the RESET signal - to the SCSI bus - - No arguments are passed in the CCB, the only interesting - argument is the SCSI bus indicated by the struct sim - pointer. - - A minimalistic implementation would forget the SCSI - negotiations for all the devices on the bus and return the - status CAM_REQ_CMP. - - 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: - - 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; - - 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. - - XPT_ABORT - abort the specified - CCB - - The arguments are transferred in the instance struct - ccb_abort cab of the union ccb. The only argument field in it - is: - - abort_ccb - pointer to the CCB to be - aborted - - 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. - - The hard way is to implement this request honestly. First - check that abort applies to a SCSI transaction: - - 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; - } - - Then it is 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: - - 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; - - 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 do not 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. - - 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; - - 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). - - 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; - - 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. - - 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; - - That is 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. - - 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: - - 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; - - - XPT_SET_TRAN_SETTINGS - explicitly - set values of SCSI transfer settings - - The arguments are transferred in the instance struct ccb_trans_setting cts -of the union ccb: - - - valid - a bitmask showing - which settings should be updated: - - CCB_TRANS_SYNC_RATE_VALID - - synchronous transfer rate - - CCB_TRANS_SYNC_OFFSET_VALID - - synchronous offset - - CCB_TRANS_BUS_WIDTH_VALID - - bus width - - CCB_TRANS_DISC_VALID - - set enable/disable disconnection - - CCB_TRANS_TQ_VALID - set - enable/disable tagged queuing - - flags - consists of two - parts, binary arguments and identification of - sub-operations. The binary arguments are: - - CCB_TRANS_DISC_ENB - enable disconnection - CCB_TRANS_TAG_ENB - - enable tagged queuing - - - - the sub-operations are: - - CCB_TRANS_CURRENT_SETTINGS - - change the current negotiations - - CCB_TRANS_USER_SETTINGS - - 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) - - - - - - 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 is essentially the - top boundary. - - 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. - - One caveat is that the bus width and synchronous parameters - are per target while the disconnection and tag enabling - parameters are per lun. - - The recommended implementation is to keep 3 sets of - negotiated (bus width and synchronous transfer) - parameters: - - - user - the user set, as - above - - current - those actually - in effect - - goal - those requested by - setting of the current parameters - - - The code looks like: - - 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; - - 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: - - 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 */ - } - - 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 target_negotiated() would return - TRUE. When the card is initialized (in - xxx_attach()) 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. - - XPT_GET_TRAN_SETTINGS - get values of - SCSI transfer settings - - 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. - - XPT_CALC_GEOMETRY - calculate logical - (BIOS) geometry of the disk - - The arguments are transferred in the instance struct - ccb_calc_geometry ccg of the union ccb: - - - - block_size - input, block - (A.K.A sector) size in bytes - - volume_size - input, - volume size in bytes - - cylinders - output, - logical cylinders - - heads - output, logical - heads - - secs_per_track - output, - logical sectors per track - - - - 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: - - 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; - - 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: - - 128 heads, 63 sectors - Symbios controllers - 16 heads, 63 sectors - old controllers - - 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. - - - XPT_PATH_INQ - path inquiry, in other - words get the SIM driver and SCSI controller (also known as HBA - - Host Bus Adapter) properties - - The properties are returned in the instance struct -ccb_pathinq cpi of the union ccb: - - - - version_num - the SIM driver version number, now - all drivers use 1 - - hba_inquiry - bitmask of features supported by - the controller: - - PI_MDP_ABLE - supports MDP message (something - from SCSI3?) - - PI_WIDE_32 - supports 32 bit wide - SCSI - - PI_WIDE_16 - supports 16 bit wide - SCSI - - PI_SDTR_ABLE - can negotiate synchronous - transfer rate - - PI_LINKED_CDB - supports linked - commands - - PI_TAG_ABLE - supports tagged - commands - - PI_SOFT_RST - supports soft reset alternative - (hard reset and soft reset are mutually exclusive within a - SCSI bus) - - target_sprt - flags for target mode support, 0 - if unsupported - - hba_misc - miscellaneous controller - features: - - PIM_SCANHILO - bus scans from high ID to low - ID - - PIM_NOREMOVE - removable devices not included in - scan - - PIM_NOINITIATOR - initiator role not - supported - - PIM_NOBUSRESET - user has disabled initial BUS - RESET - - hba_eng_cnt - mysterious HBA engine count, - something related to compression, now is always set to - 0 - - vuhba_flags - vendor-unique flags, unused - now - - max_target - maximal supported target ID (7 for - 8-bit bus, 15 for 16-bit bus, 127 for Fibre - Channel) - - max_lun - maximal supported LUN ID (7 for older - SCSI controllers, 63 for newer ones) - - async_flags - bitmask of installed Async - handler, unused now - - hpath_id - highest Path ID in the subsystem, - unused now - - unit_number - the controller unit number, - cam_sim_unit(sim) - - bus_id - the bus number, - cam_sim_bus(sim) - - initiator_id - the SCSI ID of the controller - itself - - base_transfer_speed - nominal transfer speed in - KB/s for asynchronous narrow transfers, equals to 3300 for - SCSI - - sim_vid - SIM driver's vendor id, a - zero-terminated string of maximal length SIM_IDLEN including - the terminating zero - - hba_vid - SCSI controller's vendor id, a - zero-terminated string of maximal length HBA_IDLEN including - the terminating zero - - dev_name - device driver name, a zero-terminated - string of maximal length DEV_IDLEN including the terminating - zero, equal to cam_sim_name(sim) - - - - The recommended way of setting the string fields is using - strncpy, like: - - strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); - - After setting the values set the status to CAM_REQ_CMP and mark the -CCB as done. - - - - - - - Polling - - - static void - xxx_poll - - - struct cam_sim *sim - - - - 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 - xxx_poll routine gets the struct cam_sim - pointer as its argument when the PCI interrupt routine by common - convention gets pointer to the struct - xxx_softc and the ISA interrupt routine - gets just the device unit number. So the poll routine would - normally look as: - -static void -xxx_poll(struct cam_sim *sim) -{ - xxx_intr((struct xxx_softc *)cam_sim_softc(sim)); /* for PCI device */ -} - - or - -static void -xxx_poll(struct cam_sim *sim) -{ - xxx_intr(cam_sim_unit(sim)); /* for ISA device */ -} - - - - - Asynchronous Events - - If an asynchronous event callback has been set up then the - callback function should be defined. - -static void -ahc_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg) - - - callback_arg - the value supplied when registering the - callback - - code - identifies the type of event - - path - identifies the devices to which the event - applies - - arg - event-specific argument - - - Implementation for a single type of event, AC_LOST_DEVICE, - looks like: - - 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; - } - - - - - Interrupts - - 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. - - The interrupt routines of the SIM drivers run at the - interrupt level splcam. So splcam() 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 - splcam() 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: - - 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 ... - } - - 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 spl() - family have rather high overhead, so vast amount of tiny - critical sections may not be good either. - - The conditions handled by the interrupt routine and the - details depend very much on the hardware. We consider the set of - typical conditions. - - 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 will not - 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. - - 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; - } - - 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: - - 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); - - First we check if the HCB has completed and if so we check - the returned SCSI status. - - if(hcb_status == COMPLETED) { - scsi_status = get_completion_status(hcb); - - Then look if this status is related to the REQUEST SENSE - command and if so handle it in a simple way. - - 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; - } - - 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. - - 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; - } - - 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). - - 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; - } - - 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. - - if(hcb->flags & DOING_AUTOSENSE) - goto autosense_failed; - - switch(hcb_status) { - - 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. - - 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; - - If the target refuses to accept tags we notify CAM about - that and return back all commands for this LUN: - - 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; - - Then we check a number of other conditions, with processing - basically limited to setting the CCB status: - - 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; - } - - Then we check if the error was serious enough to freeze the - input queue until it gets proceeded and do so if it is: - - 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; - - This concludes the generic interrupt handling although - specific controllers may require some additions. - - - - - Errors Summary - - 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: - - - - CAM_RESRC_UNAVAIL - 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. - - CAM_UNCOR_PARITY - - unrecovered parity error occurred - - CAM_DATA_RUN_ERR - data - overrun or unexpected data phase (going in other direction - than specified in CAM_DIR_MASK) or odd transfer length for - wide transfer - - CAM_SEL_TIMEOUT - selection - timeout occurred (target does not respond) - - CAM_CMD_TIMEOUT - command - timeout occurred (the timeout function ran) - - CAM_SCSI_STATUS_ERROR - the - device returned error - - CAM_AUTOSENSE_FAIL - the - device returned error and the REQUEST SENSE COMMAND - failed - - CAM_MSG_REJECT_REC - MESSAGE - REJECT message was received - - CAM_SCSI_BUS_RESET - received - SCSI bus reset - - CAM_REQ_CMP_ERR - - impossible SCSI phase occurred or something else as weird or - just a generic error if further detail is not - available - - CAM_UNEXP_BUSFREE - - unexpected disconnect occurred - - CAM_BDR_SENT - BUS DEVICE - RESET message was sent to the target - - CAM_UNREC_HBA_ERROR - - unrecoverable Host Bus Adapter Error - - CAM_REQ_TOO_BIG - the request - was too large for this controller - - CAM_REQUEUE_REQ - 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. - - CAM_LUN_INVALID - the LUN - ID in the request is not supported by the SCSI - controller - - CAM_TID_INVALID - the - target ID in the request is not supported by the SCSI - controller - - - - - Timeout Handling - - 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 is 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: - -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); - } -} - - 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. - - - - diff --git a/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml deleted file mode 100644 index c6c78e0feb..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml +++ /dev/null @@ -1,957 +0,0 @@ - -%man; - - -%authors; - -%misc; - - - - -]> - -
- - SMPng Design Document - - - - John - Baldwin - - - Robert - Watson - - - - $FreeBSD$ - - - 2002 - 2003 - John Baldwin - Robert Watson - - - - This document presents the current design and implementation of - the SMPng Architecture. First, the basic primitives and tools are - introduced. Next, a general architecture for the FreeBSD kernel's - synchronization and execution model is laid out. Then, locking - strategies for specific subsystems are discussed, documenting the - approaches taken to introduce fine-grained synchronization and - parallelism for each subsystem. Finally, detailed implementation - notes are provided to motivate design choices, and make the reader - aware of important implications involving the use of specific - primitives. - - - - - Introduction - - This document is a work-in-progress, and will be updated to - reflect on-going design and implementation activities associated - with the SMPng Project. Many sections currently exist only in - outline form, but will be fleshed out as work proceeds. Updates or - suggestions regarding the document may be directed to the document - editors. - - The goal of SMPng is to allow concurrency in the kernel. - The kernel is basically one rather large and complex program. To - make the kernel multi-threaded we use some of the same tools used - to make other programs multi-threaded. These include mutexes, - shared/exclusive locks, semaphores, and condition variables. For - the definitions of these and other SMP-related terms, please see - the section of this article. - - - - Basic Tools and Locking Fundamentals - - - Atomic Instructions and Memory Barriers - - There are several existing treatments of memory barriers - and atomic instructions, so this section will not include a - lot of detail. To put it simply, one can not go around reading - variables without a lock if a lock is used to protect writes - to that variable. This becomes obvious when you consider that - memory barriers simply determine relative order of memory - operations; they do not make any guarantee about timing of - memory operations. That is, a memory barrier does not force - the contents of a CPU's local cache or store buffer to flush. - Instead, the memory barrier at lock release simply ensures - that all writes to the protected data will be visible to other - CPU's or devices if the write to release the lock is visible. - The CPU is free to keep that data in its cache or store buffer - as long as it wants. However, if another CPU performs an - atomic instruction on the same datum, the first CPU must - guarantee that the updated value is made visible to the second - CPU along with any other operations that memory barriers may - require. - - For example, assuming a simple model where data is - considered visible when it is in main memory (or a global - cache), when an atomic instruction is triggered on one CPU, - other CPU's store buffers and caches must flush any writes to - that same cache line along with any pending operations behind - a memory barrier. - - This requires one to take special care when using an item - protected by atomic instructions. For example, in the sleep - mutex implementation, we have to use an - atomic_cmpset rather than an - atomic_set to turn on the - MTX_CONTESTED bit. The reason is that we - read the value of mtx_lock into a - variable and then make a decision based on that read. - However, the value we read may be stale, or it may change - while we are making our decision. Thus, when the - atomic_set executed, it may end up - setting the bit on another value than the one we made the - decision on. Thus, we have to use an - atomic_cmpset to set the value only if - the value we made the decision on is up-to-date and - valid. - - Finally, atomic instructions only allow one item to be - updated or read. If one needs to atomically update several - items, then a lock must be used instead. For example, if two - counters must be read and have values that are consistent - relative to each other, then those counters must be protected - by a lock rather than by separate atomic instructions. - - - - Read Locks versus Write Locks - - Read locks do not need to be as strong as write locks. - Both types of locks need to ensure that the data they are - accessing is not stale. However, only write access requires - exclusive access. Multiple threads can safely read a value. - Using different types of locks for reads and writes can be - implemented in a number of ways. - - First, sx locks can be used in this manner by using an - exclusive lock when writing and a shared lock when reading. - This method is quite straightforward. - - A second method is a bit more obscure. You can protect a - datum with multiple locks. Then for reading that data you - simply need to have a read lock of one of the locks. However, - to write to the data, you need to have a write lock of all of - the locks. This can make writing rather expensive but can be - useful when data is accessed in various ways. For example, - the parent process pointer is protected by both the - proctree_lock sx lock and the per-process mutex. Sometimes - the proc lock is easier as we are just checking to see who a - parent of a process is that we already have locked. However, - other places such as inferior need to - walk the tree of processes via parent pointers and locking - each process would be prohibitive as well as a pain to - guarantee that the condition you are checking remains valid - for both the check and the actions taken as a result of the - check. - - - - Locking Conditions and Results - - If you need a lock to check the state of a variable so - that you can take an action based on the state you read, you - can not just hold the lock while reading the variable and then - drop the lock before you act on the value you read. Once you - drop the lock, the variable can change rendering your decision - invalid. Thus, you must hold the lock both while reading the - variable and while performing the action as a result of the - test. - - - - - General Architecture and Design - - - Interrupt Handling - - Following the pattern of several other multi-threaded Unix - kernels, FreeBSD deals with interrupt handlers by giving them - their own thread context. Providing a context for interrupt - handlers allows them to block on locks. To help avoid - latency, however, interrupt threads run at real-time kernel - priority. Thus, interrupt handlers should not execute for very - long to avoid starving other kernel threads. In addition, - since multiple handlers may share an interrupt thread, - interrupt handlers should not sleep or use a sleepable lock to - avoid starving another interrupt handler. - - The interrupt threads currently in FreeBSD are referred to - as heavyweight interrupt threads. They are called this - because switching to an interrupt thread involves a full - context switch. In the initial implementation, the kernel was - not preemptive and thus interrupts that interrupted a kernel - thread would have to wait until the kernel thread blocked or - returned to userland before they would have an opportunity to - run. - - To deal with the latency problems, the kernel in FreeBSD - has been made preemptive. Currently, we only preempt a kernel - thread when we release a sleep mutex or when an interrupt - comes in. However, the plan is to make the FreeBSD kernel - fully preemptive as described below. - - Not all interrupt handlers execute in a thread context. - Instead, some handlers execute directly in primary interrupt - context. These interrupt handlers are currently misnamed - fast interrupt handlers since the - INTR_FAST flag used in earlier versions - of the kernel is used to mark these handlers. The only - interrupts which currently use these types of interrupt - handlers are clock interrupts and serial I/O device - interrupts. Since these handlers do not have their own - context, they may not acquire blocking locks and thus may only - use spin mutexes. - - Finally, there is one optional optimization that can be - added in MD code called lightweight context switches. Since - an interrupt thread executes in a kernel context, it can - borrow the vmspace of any process. Thus, in a lightweight - context switch, the switch to the interrupt thread does not - switch vmspaces but borrows the vmspace of the interrupted - thread. In order to ensure that the vmspace of the - interrupted thread does not disappear out from under us, the - interrupted thread is not allowed to execute until the - interrupt thread is no longer borrowing its vmspace. This can - happen when the interrupt thread either blocks or finishes. - If an interrupt thread blocks, then it will use its own - context when it is made runnable again. Thus, it can release - the interrupted thread. - - The cons of this optimization are that they are very - machine specific and complex and thus only worth the effort if - their is a large performance improvement. At this point it is - probably too early to tell, and in fact, will probably hurt - performance as almost all interrupt handlers will immediately - block on Giant and require a thread fix-up when they block. - Also, an alternative method of interrupt handling has been - proposed by Mike Smith that works like so: - - - - Each interrupt handler has two parts: a predicate - which runs in primary interrupt context and a handler - which runs in its own thread context. - - - - If an interrupt handler has a predicate, then when an - interrupt is triggered, the predicate is run. If the - predicate returns true then the interrupt is assumed to be - fully handled and the kernel returns from the interrupt. - If the predicate returns false or there is no predicate, - then the threaded handler is scheduled to run. - - - - Fitting light weight context switches into this scheme - might prove rather complicated. Since we may want to change - to this scheme at some point in the future, it is probably - best to defer work on light weight context switches until we - have settled on the final interrupt handling architecture and - determined how light weight context switches might or might - not fit into it. - - - - Kernel Preemption and Critical Sections - - - Kernel Preemption in a Nutshell - - Kernel preemption is fairly simple. The basic idea is - that a CPU should always be doing the highest priority work - available. Well, that is the ideal at least. There are a - couple of cases where the expense of achieving the ideal is - not worth being perfect. - - Implementing full kernel preemption is very - straightforward: when you schedule a thread to be executed - by putting it on a runqueue, you check to see if it's - priority is higher than the currently executing thread. If - so, you initiate a context switch to that thread. - - While locks can protect most data in the case of a - preemption, not all of the kernel is preemption safe. For - example, if a thread holding a spin mutex preempted and the - new thread attempts to grab the same spin mutex, the new - thread may spin forever as the interrupted thread may never - get a chance to execute. Also, some code such as the code - to assign an address space number for a process during - exec() on the Alpha needs to not be preempted as it supports - the actual context switch code. Preemption is disabled for - these code sections by using a critical section. - - - - Critical Sections - - The responsibility of the critical section API is to - prevent context switches inside of a critical section. With - a fully preemptive kernel, every - setrunqueue of a thread other than the - current thread is a preemption point. One implementation is - for critical_enter to set a per-thread - flag that is cleared by its counterpart. If - setrunqueue is called with this flag - set, it does not preempt regardless of the priority of the new - thread relative to the current thread. However, since - critical sections are used in spin mutexes to prevent - context switches and multiple spin mutexes can be acquired, - the critical section API must support nesting. For this - reason the current implementation uses a nesting count - instead of a single per-thread flag. - - In order to minimize latency, preemptions inside of a - critical section are deferred rather than dropped. If a - thread is made runnable that would normally be preempted to - outside of a critical section, then a per-thread flag is set - to indicate that there is a pending preemption. When the - outermost critical section is exited, the flag is checked. - If the flag is set, then the current thread is preempted to - allow the higher priority thread to run. - - Interrupts pose a problem with regards to spin mutexes. - If a low-level interrupt handler needs a lock, it needs to - not interrupt any code needing that lock to avoid possible - data structure corruption. Currently, providing this - mechanism is piggybacked onto critical section API by means - of the cpu_critical_enter and - cpu_critical_exit functions. Currently - this API disables and re-enables interrupts on all of - FreeBSD's current platforms. This approach may not be - purely optimal, but it is simple to understand and simple to - get right. Theoretically, this second API need only be used - for spin mutexes that are used in primary interrupt context. - However, to make the code simpler, it is used for all spin - mutexes and even all critical sections. It may be desirable - to split out the MD API from the MI API and only use it in - conjunction with the MI API in the spin mutex - implementation. If this approach is taken, then the MD API - likely would need a rename to show that it is a separate API - now. - - - - Design Tradeoffs - - As mentioned earlier, a couple of trade-offs have been - made to sacrifice cases where perfect preemption may not - always provide the best performance. - - The first trade-off is that the preemption code does not - take other CPUs into account. Suppose we have a two CPU's A - and B with the priority of A's thread as 4 and the priority - of B's thread as 2. If CPU B makes a thread with priority 1 - runnable, then in theory, we want CPU A to switch to the new - thread so that we will be running the two highest priority - runnable threads. However, the cost of determining which - CPU to enforce a preemption on as well as actually signaling - that CPU via an IPI along with the synchronization that - would be required would be enormous. Thus, the current code - would instead force CPU B to switch to the higher priority - thread. Note that this still puts the system in a better - position as CPU B is executing a thread of priority 1 rather - than a thread of priority 2. - - The second trade-off limits immediate kernel preemption - to real-time priority kernel threads. In the simple case of - preemption defined above, a thread is always preempted - immediately (or as soon as a critical section is exited) if - a higher priority thread is made runnable. However, many - threads executing in the kernel only execute in a kernel - context for a short time before either blocking or returning - to userland. Thus, if the kernel preempts these threads to - run another non-realtime kernel thread, the kernel may - switch out the executing thread just before it is about to - sleep or execute. The cache on the CPU must then adjust to - the new thread. When the kernel returns to the interrupted - CPU, it must refill all the cache information that was lost. - In addition, two extra context switches are performed that - could be avoided if the kernel deferred the preemption until - the first thread blocked or returned to userland. Thus, by - default, the preemption code will only preempt immediately - if the higher priority thread is a real-time priority - thread. - - Turning on full kernel preemption for all kernel threads - has value as a debugging aid since it exposes more race - conditions. It is especially useful on UP systems were many - races are hard to simulate otherwise. Thus, there will be a - kernel option to enable preemption for all kernel threads - that can be used for debugging purposes. - - - - - Thread Migration - - Simply put, a thread migrates when it moves from one CPU - to another. In a non-preemptive kernel this can only happen - at well-defined points such as when calling - tsleep or returning to userland. - However, in the preemptive kernel, an interrupt can force a - preemption and possible migration at any time. This can have - negative affects on per-CPU data since with the exception of - curthread and curpcb the - data can change whenever you migrate. Since you can - potentially migrate at any time this renders per-CPU data - rather useless. Thus it is desirable to be able to disable - migration for sections of code that need per-CPU data to be - stable. - - Critical sections currently prevent migration since they - do not allow context switches. However, this may be too strong - of a requirement to enforce in some cases since a critical - section also effectively blocks interrupt threads on the - current processor. As a result, it may be desirable to - provide an API whereby code may indicate that if the current - thread is preempted it should not migrate to another - CPU. - - One possible implementation is to use a per-thread nesting - count td_pinnest along with a - td_pincpu which is updated to the current - CPU on each context switch. Each CPU has its own run queue - that holds threads pinned to that CPU. A thread is pinned - when its nesting count is greater than zero and a thread - starts off unpinned with a nesting count of zero. When a - thread is put on a runqueue, we check to see if it is pinned. - If so, we put it on the per-CPU runqueue, otherwise we put it - on the global runqueue. When - choosethread is called to retrieve the - next thread, it could either always prefer bound threads to - unbound threads or use some sort of bias when comparing - priorities. If the nesting count is only ever written to by - the thread itself and is only read by other threads when the - owning thread is not executing but while holding the - sched_lock, then - td_pinnest will not need any other locks. - The migrate_disable function would - increment the nesting count and - migrate_enable would decrement the - nesting count. Due to the locking requirements specified - above, they will only operate on the current thread and thus - would not need to handle the case of making a thread - migrateable that currently resides on a per-CPU run - queue. - - It is still debatable if this API is needed or if the - critical section API is sufficient by itself. Many of the - places that need to prevent migration also need to prevent - preemption as well, and in those places a critical section - must be used regardless. - - - - Callouts - - The timeout() kernel facility permits - kernel services to register functions for execution as part - of the softclock() software interrupt. - Events are scheduled based on a desired number of clock - ticks, and callbacks to the consumer-provided function - will occur at approximately the right time. - - The global list of pending timeout events is protected - by a global spin mutex, callout_lock; - all access to the timeout list must be performed with this - mutex held. When softclock() is - woken up, it scans the list of pending timeouts for those - that should fire. In order to avoid lock order reversal, - the softclock thread will release the - callout_lock mutex when invoking the - provided timeout() callback function. - If the CALLOUT_MPSAFE flag was not set - during registration, then Giant will be grabbed before - invoking the callout, and then released afterwards. The - callout_lock mutex will be re-grabbed - before proceeding. The softclock() - code is careful to leave the list in a consistent state - while releasing the mutex. If DIAGNOSTIC - is enabled, then the time taken to execute each function is - measured, and a warning generated if it exceeds a - threshold. - - - - - Specific Locking Strategies - - - Credentials - - struct ucred is the kernel's - internal credential structure, and is generally used as the - basis for process-driven access control within the kernel. - BSD-derived systems use a copy-on-write model for credential - data: multiple references may exist for a credential structure, - and when a change needs to be made, the structure is duplicated, - modified, and then the reference replaced. Due to wide-spread - caching of the credential to implement access control on open, - this results in substantial memory savings. With a move to - fine-grained SMP, this model also saves substantially on - locking operations by requiring that modification only occur - on an unshared credential, avoiding the need for explicit - synchronization when consuming a known-shared - credential. - - Credential structures with a single reference are - considered mutable; shared credential structures must not be - modified or a race condition is risked. A mutex, - cr_mtxp protects the reference - count of struct ucred so as to - maintain consistency. Any use of the structure requires a - valid reference for the duration of the use, or the structure - may be released out from under the illegitimate - consumer. - - The struct ucred mutex is a leaf - mutex, and for performance reasons, is implemented via a mutex - pool. - - Usually, credentials are used in a read-only manner for access - control decisions, and in this case td_ucred - is generally preferred because it requires no locking. When a - process' credential is updated the proc lock - must be held across the check and update operations thus avoid - races. The process credential p_ucred - must be used for check and update operations to prevent - time-of-check, time-of-use races. - - If system call invocations will perform access control after - an update to the process credential, the value of - td_ucred must also be refreshed to - the current process value. This will prevent use of a stale - credential following a change. The kernel automatically - refreshes the td_ucred pointer in - the thread structure from the process - p_ucred whenever a process enters - the kernel, permitting use of a fresh credential for kernel - access control. - - - - File Descriptors and File Descriptor Tables - - Details to follow. - - - - Jail Structures - - struct prison stores - administrative details pertinent to the maintenance of jails - created using the &man.jail.2; API. This includes the - per-jail hostname, IP address, and related settings. This - structure is reference-counted since pointers to instances of - the structure are shared by many credential structures. A - single mutex, pr_mtx protects read - and write access to the reference count and all mutable - variables inside the struct jail. Some variables are set only - when the jail is created, and a valid reference to the - struct prison is sufficient to read - these values. The precise locking of each entry is documented - via comments in sys/jail.h. - - - - MAC Framework - - The TrustedBSD MAC Framework maintains data in a variety - of kernel objects, in the form of struct - label. In general, labels in kernel objects - are protected by the same lock as the remainder of the kernel - object. For example, the v_label - label in struct vnode is protected - by the vnode lock on the vnode. - - In addition to labels maintained in standard kernel objects, - the MAC Framework also maintains a list of registered and - active policies. The policy list is protected by a global - mutex (mac_policy_list_lock) and a busy - count (also protected by the mutex). Since many access - control checks may occur in parallel, entry to the framework - for a read-only access to the policy list requires holding the - mutex while incrementing (and later decrementing) the busy - count. The mutex need not be held for the duration of the - MAC entry operation--some operations, such as label operations - on file system objects--are long-lived. To modify the policy - list, such as during policy registration and de-registration, - the mutex must be held and the reference count must be zero, - to prevent modification of the list while it is in use. - - A condition variable, - mac_policy_list_not_busy, is available to - threads that need to wait for the list to become unbusy, but - this condition variable must only be waited on if the caller is - holding no other locks, or a lock order violation may be - possible. The busy count, in effect, acts as a form of - shared/exclusive lock over access to the framework: the difference - is that, unlike with an sx lock, consumers waiting for the list - to become unbusy may be starved, rather than permitting lock - order problems with regards to the busy count and other locks - that may be held on entry to (or inside) the MAC Framework. - - - - Modules - - For the module subsystem there exists a single lock that is - used to protect the shared data. This lock is a shared/exclusive - (SX) lock and has a good chance of needing to be acquired (shared - or exclusively), therefore there are a few macros that have been - added to make access to the lock more easy. These macros can be - located in sys/module.h and are quite basic - in terms of usage. The main structures protected under this lock - are the module_t structures (when shared) - and the global modulelist_t structure, - modules. One should review the related source code in - kern/kern_module.c to further understand the - locking strategy. - - - - Newbus Device Tree - - The newbus system will have one sx lock. Readers will - hold a shared (read) lock (&man.sx.slock.9;) and writers will hold - an exclusive (write) lock (&man.sx.xlock.9;). Internal functions - will not do locking at all. Externally visible ones will lock as - needed. - Those items that do not matter if the race is won or lost will - not be locked, since they tend to be read all over the place - (e.g. &man.device.get.softc.9;). There will be relatively few - changes to the newbus data structures, so a single lock should - be sufficient and not impose a performance penalty. - - - - Pipes - - ... - - - - Processes and Threads - - - process hierarchy - - proc locks, references - - thread-specific copies of proc entries to freeze during system - calls, including td_ucred - - inter-process operations - - process groups and sessions - - - - Scheduler - - Lots of references to sched_lock and notes - pointing at specific primitives and related magic elsewhere in the - document. - - - - Select and Poll - - The select() and poll() functions permit threads to block - waiting on events on file descriptors--most frequently, whether - or not the file descriptors are readable or writable. - - ... - - - - SIGIO - - The SIGIO service permits processes to request the delivery - of a SIGIO signal to its process group when the read/write status - of specified file descriptors changes. At most one process or - process group is permitted to register for SIGIO from any given - kernel object, and that process or group is referred to as - the owner. Each object supporting SIGIO registration contains - pointer field that is NULL if the object is not registered, or - points to a struct sigio describing - the registration. This field is protected by a global mutex, - sigio_lock. Callers to SIGIO maintenance - functions must pass in this field by reference so that local - register copies of the field are not made when unprotected by - the lock. - - One struct sigio is allocated for - each registered object associated with any process or process - group, and contains back-pointers to the object, owner, signal - information, a credential, and the general disposition of the - registration. Each process or progress group contains a list of - registered struct sigio structures, - p_sigiolst for processes, and - pg_sigiolst for process groups. - These lists are protected by the process or process group - locks respectively. Most fields in each struct - sigio are constant for the duration of the - registration, with the exception of the - sio_pgsigio field which links the - struct sigio into the process or - process group list. Developers implementing new kernel - objects supporting SIGIO will, in general, want to avoid - holding structure locks while invoking SIGIO supporting - functions, such as fsetown() - or funsetown() to avoid - defining a lock order between structure locks and the global - SIGIO lock. This is generally possible through use of an - elevated reference count on the structure, such as reliance - on a file descriptor reference to a pipe during a pipe - operation. - - - - Sysctl - - The sysctl() MIB service is invoked - from both within the kernel and from userland applications - using a system call. At least two issues are raised in locking: - first, the protection of the structures maintaining the - namespace, and second, interactions with kernel variables and - functions that are accessed by the sysctl interface. Since - sysctl permits the direct export (and modification) of - kernel statistics and configuration parameters, the sysctl - mechanism must become aware of appropriate locking semantics - for those variables. Currently, sysctl makes use of a - single global sx lock to serialize use of sysctl(); however, it - is assumed to operate under Giant and other protections are not - provided. The remainder of this section speculates on locking - and semantic changes to sysctl. - - - Need to change the order of operations for sysctl's that - update values from read old, copyin and copyout, write new to - copyin, lock, read old and write new, unlock, copyout. Normal - sysctl's that just copyout the old value and set a new value - that they copyin may still be able to follow the old model. - However, it may be cleaner to use the second model for all of - the sysctl handlers to avoid lock operations. - - - To allow for the common case, a sysctl could embed a - pointer to a mutex in the SYSCTL_FOO macros and in the struct. - This would work for most sysctl's. For values protected by sx - locks, spin mutexes, or other locking strategies besides a - single sleep mutex, SYSCTL_PROC nodes could be used to get the - locking right. - - - - Taskqueue - - The taskqueue's interface has two basic locks associated - with it in order to protect the related shared data. The - taskqueue_queues_mutex is meant to serve as a - lock to protect the taskqueue_queues TAILQ. - The other mutex lock associated with this system is the one in the - struct taskqueue data structure. The - use of the synchronization primitive here is to protect the - integrity of the data in the struct - taskqueue. It should be noted that there are no - separate macros to assist the user in locking down his/her own work - since these locks are most likely not going to be used outside of - kern/subr_taskqueue.c. - - - - - Implementation Notes - - - Details of the Mutex Implementation - - - Should we require mutexes to be owned for mtx_destroy() - since we can not safely assert that they are unowned by anyone - else otherwise? - - - Spin Mutexes - - - Use a critical section... - - - - Sleep Mutexes - - - Describe the races with contested mutexes - - - Why it is safe to read mtx_lock of a contested mutex - when holding sched_lock. - - - Priority propagation - - - - - Witness - - - What does it do - - - How does it work - - - - - Miscellaneous Topics - - - Interrupt Source and ICU Abstractions - - - struct isrc - - - pic drivers - - - - Other Random Questions/Topics - - Should we pass an interlock into - sema_wait? - - - Generic turnstiles for sleep mutexes and sx locks. - - - Should we have non-sleepable sx locks? - - - - - Glossary - - - atomic - - An operation is atomic if all of its effects are visible - to other CPUs together when the proper access protocol is - followed. In the degenerate case are atomic instructions - provided directly by machine architectures. At a higher - level, if several members of a structure are protected by a - lock, then a set of operations are atomic if they are all - performed while holding the lock without releasing the lock - in between any of the operations. - - operation - - - - - block - - A thread is blocked when it is waiting on a lock, - resource, or condition. Unfortunately this term is a bit - overloaded as a result. - - sleep - - - - - critical section - - A section of code that is not allowed to be preempted. - A critical section is entered and exited using the - &man.critical.enter.9; API. - - - - - MD - - Machine dependent. - - MI - - - - - memory operation - - A memory operation reads and/or writes to a memory - location. - - - - - MI - - Machine independent. - - MD - - - - - operation - memory operation - - - - primary interrupt context - - Primary interrupt context refers to the code that runs - when an interrupt occurs. This code can either run an - interrupt handler directly or schedule an asynchronous - interrupt thread to execute the interrupt handlers for a - given interrupt source. - - - - - realtime kernel thread - - A high priority kernel thread. Currently, the only - realtime priority kernel threads are interrupt threads. - - thread - - - - - sleep - - A thread is asleep when it is blocked on a condition - variable or a sleep queue via msleep or - tsleep. - - block - - - - - sleepable lock - - A sleepable lock is a lock that can be held by a thread - which is asleep. Lockmgr locks and sx locks are currently - the only sleepable locks in FreeBSD. Eventually, some sx - locks such as the allproc and proctree locks may become - non-sleepable locks. - - sleep - - - - - thread - - A kernel thread represented by a struct thread. Threads own - locks and hold a single execution context. - - - -
diff --git a/en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml deleted file mode 100644 index aeb4656017..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/sound/chapter.sgml +++ /dev/null @@ -1,687 +0,0 @@ - - - - - - - Jean-Francois - Dockes - Contributed by - - - - - - Sound subsystem - - - Introduction - - The FreeBSD sound subsystem cleanly separates generic sound - handling issues from device-specific ones. This makes it easier - to add support for new hardware. - - The &man.pcm.4; framework is the central piece of the sound - subsystem. It mainly implements the following elements: - - - - A system call interface (read, write, ioctls) to - digitized sound and mixer functions. The ioctl command set - is compatible with the legacy OSS or - Voxware interface, allowing common - multimedia applications to be ported without - modification. - - Common code for processing sound data (format - conversions, virtual channels). - - - A uniform software interface to hardware-specific audio - interface modules. - - - Additional support for some common hardware interfaces - (ac97), or shared hardware-specific code (ex: ISA DMA - routines). - - - - The support for specific sound cards is implemented by - hardware-specific drivers, which provide channel and mixer interfaces - to plug into the generic pcm code. - - In this chapter, the term pcm will - refer to the central, common part of the sound driver, as - opposed to the hardware-specific modules. - - The prospective driver writer will of course want to start - from an existing module and use the code as the ultimate - reference. But, while the sound code is nice and clean, it is - also mostly devoid of comments. This document tries to give an - overview of the framework interface and answer some questions - that may arise while adapting the existing code. - - As an alternative, or in addition to starting from a working - example, you can find a commented driver template at - - http://people.FreeBSD.org/~cg/template.c - - - - - Files - - All the relevant code currently (FreeBSD 4.4) lives in - /usr/src/sys/dev/sound/, except for the - public ioctl interface definitions, found in - /usr/src/sys/sys/soundcard.h - - Under /usr/src/sys/dev/sound/, the - pcm/ directory holds the central code, - while the isa/ and - pci/ directories have the drivers for ISA - and PCI boards. - - - - - Probing, attaching, etc. - - Sound drivers probe and attach in almost the same way as any - hardware driver module. You might want to look at the ISA or PCI specific sections of the handbook for - more information. - - However, sound drivers differ in some ways: - - - - - They declare themselves as pcm - class devices, with a struct - snddev_info device private structure: - - static driver_t xxx_driver = { - "pcm", - xxx_methods, - sizeof(struct snddev_info) - }; - - DRIVER_MODULE(snd_xxxpci, pci, xxx_driver, pcm_devclass, 0, 0); - MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER); - - Most sound drivers need to store additional private - information about their device. A private data structure is - usually allocated in the attach routine. Its address is - passed to pcm by the calls to - pcm_register() and - mixer_init(). - pcm later passes back this address - as a parameter in calls to the sound driver - interfaces. - - - - The sound driver attach routine should declare its MIXER - or AC97 interface to pcm by calling - mixer_init(). For a MIXER interface, - this causes in turn a call to - xxxmixer_init(). - - - - The sound driver attach routine declares its general - CHANNEL configuration to pcm by - calling pcm_register(dev, sc, nplay, - nrec), where sc is the address - for the device data structure, used in further calls from - pcm, and nplay - and nrec are the number of play and - record channels. - - - - The sound driver attach routine declares each of its - channel objects by calls to - pcm_addchan(). This sets up the - channel glue in pcm and causes in - turn a call to - - xxxchannel_init(). - - - - The sound driver detach routine should call - pcm_unregister() before releasing its - resources. - - - - There are two possible methods to handle non-PnP devices: - - - Use a device_identify() method - (example: sound/isa/es1888.c). The - device_identify() method probes for the - hardware at known addresses and, if it finds a supported - device, creates a new pcm device which is then passed to - probe/attach. - - - Use a custom kernel configuration with appropriate hints - for pcm devices (example: - sound/isa/mss.c). - - - - pcm drivers should implement - device_suspend, - device_resume and - device_shutdown routines, so that power - management and module unloading function correctly. - - - - - Interfaces - - The interface between the pcm core - and the sound drivers is defined in terms of kernel objects. - - There are two main interfaces that a sound driver will - usually provide: CHANNEL and either - MIXER or AC97. - - The AC97 interface is a very small - hardware access (register read/write) interface, implemented by - drivers for hardware with an AC97 codec. In this case, the - actual MIXER interface is provided by the shared AC97 code in - pcm. - - - The CHANNEL interface - - - Common notes for function parameters - - Sound drivers usually have a private data structure to - describe their device, and one structure for each play and - record data channel that it supports. - - For all CHANNEL interface functions, the first parameter - is an opaque pointer. - - The second parameter is a pointer to the private - channel data structure, except for - channel_init() which has a pointer to the - private device structure (and returns the channel pointer - for further use by pcm). - - - - - Overview of data transfer operations - - For sound data transfers, the - pcm core and the sound drivers - communicate through a shared memory area, described by a - struct snd_dbuf. - - struct snd_dbuf is private to - pcm, and sound drivers obtain - values of interest by calls to accessor functions - (sndbuf_getxxx()). - - The shared memory area has a size of - sndbuf_getsize() and is divided into - fixed size blocks of sndbuf_getblksz() - bytes. - - When playing, the general transfer mechanism is as - follows (reverse the idea for recording): - - - - pcm initially fills up the - buffer, then calls the sound driver's - xxxchannel_trigger() - function with a parameter of PCMTRIG_START. - - - - The sound driver then arranges to repeatedly - transfer the whole memory area - (sndbuf_getbuf(), - sndbuf_getsize()) to the device, in - blocks of sndbuf_getblksz() bytes. - It calls back the chn_intr() - pcm function for each - transferred block (this will typically happen at - interrupt time). - - - - chn_intr() arranges to copy new - data to the area that was transferred to the device (now - free), and make appropriate updates to the - snd_dbuf structure. - - - - - - channel_init - - xxxchannel_init() is called to - initialize each of the play or record channels. The calls - are initiated from the sound driver attach routine. (See - the probe and attach - section). - - static void * - xxxchannel_init(kobj_t obj, void *data, - struct snd_dbuf *b, struct pcm_channel *c, int dir) - { - struct xxx_info *sc = data; - struct xxx_chinfo *ch; - ... - return ch; - } - - - - - b is the address for the channel - struct snd_dbuf. It should be - initialized in the function by calling - sndbuf_alloc(). The buffer size to - use is normally a small multiple of the 'typical' unit - transfer size for your device. - - c is the - pcm channel control structure - pointer. This is an opaque object. The function should - store it in the local channel structure, to be used in - later calls to pcm (ie: - chn_intr(c)). - - dir indicates the channel - direction (PCMDIR_PLAY or - PCMDIR_REC). - - - - The function should return a pointer to the private - area used to control this channel. This will be passed - as a parameter to other channel interface calls. - - - - - - - - channel_setformat - - xxxchannel_setformat() should set - up the hardware for the specified channel for the specified - sound format. - - static int - xxxchannel_setformat(kobj_t obj, void *data, u_int32_t format) - { - struct xxx_chinfo *ch = data; - ... - return 0; - } - - - - format is specified as an - AFMT_XXX value - (soundcard.h). - - - - - - - channel_setspeed - - xxxchannel_setspeed() sets up the - channel hardware for the specified sampling speed, and - returns the possibly adjusted speed. - - static int - xxxchannel_setspeed(kobj_t obj, void *data, u_int32_t speed) - { - struct xxx_chinfo *ch = data; - ... - return speed; - } - - - - - channel_setblocksize - - xxxchannel_setblocksize() sets the - block size, which is the size of unit transactions between - pcm and the sound driver, and - between the sound driver and the device. Typically, this - would be the number of bytes transferred before an interrupt - occurs. During a transfer, the sound driver should call - pcm's - chn_intr() every time this size has - been transferred. - - Most sound drivers only take note of the block size - here, to be used when an actual transfer will be - started. - - static int - xxxchannel_setblocksize(kobj_t obj, void *data, u_int32_t blocksize) - { - struct xxx_chinfo *ch = data; - ... - return blocksize; - } - - - - The function returns the possibly adjusted block - size. In case the block size is indeed changed, - sndbuf_resize() should be called to - adjust the buffer. - - - - - - - - channel_trigger - - xxxchannel_trigger() is called by - pcm to control data transfer - operations in the driver. - - static int - xxxchannel_trigger(kobj_t obj, void *data, int go) - { - struct xxx_chinfo *ch = data; - ... - return 0; - } - - - - go defines the action for the - current call. The possible values are: - - - - PCMTRIG_START: the driver - should start a data transfer from or to the channel - buffer. If needed, the buffer base and size can be - retrieved through - sndbuf_getbuf() and - sndbuf_getsize(). - - - - PCMTRIG_EMLDMAWR / - PCMTRIG_EMLDMARD: this tells the - driver that the input or output buffer may have been - updated. Most drivers just ignore these - calls. - - - - PCMTRIG_STOP / - PCMTRIG_ABORT: the driver should - stop the current transfer. - - - - - - - If the driver uses ISA DMA, - sndbuf_isadma() should be called before - performing actions on the device, and will take care of the - DMA chip side of things. - - - - - - channel_getptr - - xxxchannel_getptr() returns the - current offset in the transfer buffer. This will typically - be called by chn_intr(), and this is how - pcm knows where it can transfer - new data. - - - - - channel_free - - xxxchannel_free() is called to free - up channel resources, for example when the driver is - unloaded, and should be implemented if the channel data - structures are dynamically allocated or if - sndbuf_alloc() was not used for buffer - allocation. - - - - - channel_getcaps - - struct pcmchan_caps * - xxxchannel_getcaps(kobj_t obj, void *data) - { - return &xxx_caps; - } - - - - - The routine returns a pointer to a (usually - statically-defined) pcmchan_caps - structure (defined in - sound/pcm/channel.h. The structure holds - the minimum and maximum sampling frequencies, and the - accepted sound formats. Look at any sound driver for an - example. - - - - - - - - More functions - - channel_reset(), - channel_resetdone(), and - channel_notify() are for special purposes - and should not be implemented in a driver without discussing - it with the authorities (&a.cg;). - - channel_setdir() is deprecated. - - - - - - The MIXER interface - - - mixer_init - - xxxmixer_init() initializes the - hardware and tells pcm what mixer - devices are available for playing and recording - - static int - xxxmixer_init(struct snd_mixer *m) - { - struct xxx_info *sc = mix_getdevinfo(m); - u_int32_t v; - - [Initialize hardware] - - [Set appropriate bits in v for play mixers] - mix_setdevs(m, v); - [Set appropriate bits in v for record mixers] - mix_setrecdevs(m, v) - - return 0; - } - - - - Set bits in an integer value and call - mix_setdevs() and - mix_setrecdevs() to tell - pcm what devices exist. - - - - Mixer bits definitions can be found in - soundcard.h - (SOUND_MASK_XXX values and - SOUND_MIXER_XXX bit shifts). - - - - - mixer_set - - xxxmixer_set() sets the volume - level for one mixer device. - - static int - xxxmixer_set(struct snd_mixer *m, unsigned dev, - unsigned left, unsigned right) - { - struct sc_info *sc = mix_getdevinfo(m); - [set volume level] - return left | (right << 8); - } - - - - The device is specified as a SOUND_MIXER_XXX - value The volume values are specified in - range [0-100]. A value of zero should mute the - device. - - - - As the hardware levels probably won't match the - input scale, and some rounding will occur, the routine - returns the actual level values (in range 0-100) as - shown. - - - - - - - mixer_setrecsrc - - xxxmixer_setrecsrc() sets the - recording source device. - - static int - xxxmixer_setrecsrc(struct snd_mixer *m, u_int32_t src) - { - struct xxx_info *sc = mix_getdevinfo(m); - - [look for non zero bit(s) in src, set up hardware] - - [update src to reflect actual action] - return src; - } - - - - The desired recording devices are specified as a - bit field - - - - The actual devices set for recording are returned. - Some drivers can only set one device for recording. The - function should return -1 if an error occurs. - - - - - - mixer_uninit, mixer_reinit - - xxxmixer_uninit() should ensure - that all sound is muted and if possible mixer hardware - should be powered down - - xxxmixer_reinit() should ensure - that the mixer hardware is powered up and any settings not - controlled by mixer_set() or - mixer_setrecsrc() are restored. - - - - - - The AC97 interface - - The AC97 interface is implemented - by drivers with an AC97 codec. It only has three methods: - - - - xxxac97_init() returns - the number of ac97 codecs found. - - - ac97_read() and - ac97_write() read or write a specified - register. - - - - - The AC97 interface is used by the - AC97 code in pcm to perform higher - level operations. Look at - sound/pci/maestro3.c or many others under - sound/pci/ for an example. - - - - - - 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 083d21c8b4..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml +++ /dev/null @@ -1,161 +0,0 @@ - - - - The Sysinit Framework - - Sysinit is the framework for a generic call sort and dispatch - mechanism. 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 statically ordered initialization routing - and recompile the kernel. This system also allows kernel modules, - currently called KLD's, to be separately - compiled, linked, and initialized at boot time and loaded even - later while the system is already running. This is accomplished - using the kernel linker and linker - sets. - - - Terminology - - - - Linker Set - - A linker technique in which the linker gathers - statically declared data throughout a program's source files - into a single contiguously addressable unit of - data. - - - - - - - Sysinit Operation - - Sysinit relies on the ability of the linker to take static - data declared at multiple locations throughout a program's - source and group it together as a single contiguous chunk of - data. This linker technique is called a linker - set. Sysinit uses two linker sets to maintain two data - sets containing each consumer's call order, function, and a - pointer to the data to pass to that function. - - Sysinit uses two priorities when ordering the functions for - execution. The first priority is a subsystem ID giving an - overall order Sysinit's dispatch of functions. Current predeclared - ID's are in <sys/kernel.h> in the enum - list sysinit_sub_id. The second priority used - is an element order within the subsystem. Current predeclared - subsystem element orders are in - <sys/kernel.h> in the enum list - sysinit_elem_order. - - 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. - - - - - Using Sysinit - - - Interface - - - Headers - - <sys/kernel.h> - - - - Macros - - SYSINIT(uniquifier, subsystem, order, func, ident) - SYSUNINIT(uniquifier, subsystem, order, func, ident) - - - - - Startup - - The SYSINIT() 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. SYSINIT() 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 function. All - functions must take a constant pointer argument. - - - For example: - - #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); - - - - - Shutdown - - The SYSUNINIT() macro behaves similarly - to the SYSINIT() macro except that it adds - the Sysinit data to Sysinit's shutdown data set. - - For example: - - #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); - - - - - - 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 847666a67b..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/usb/chapter.sgml +++ /dev/null @@ -1,623 +0,0 @@ - - - - USB Devices - - This chapter was written by &a.nhibma;. Modifications made for - the handbook by &a.murray;. - - - Introduction - - 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. - - 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. - - - - Devices connect to ports on the computer - directly or on devices called hubs, forming a treelike device - structure. - - The devices can be connected and disconnected at - run time. - - Devices can suspend themselves and trigger - resumes of the host system - - As the devices can be powered from the bus, the - host software has to keep track of power budgets for each - hub. - - 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) - - Devices are intelligent and contain easily - accessible information about themselves - - - - 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. - - - Structure of the USB Stack - - 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. - - 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. - - 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 or userland. They - use the USB driver interface (USBDI) exposed by the services - layer. - - - - - Host Controllers - - 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. - - 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 USB - specification 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). - - 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. - - 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]. The virtual 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: Universal - Host Controller Interface (UHCI; Intel) and Open - Host Controller Interface (OHCI; Compaq, Microsoft, - National Semiconductor). The UHCI specification has been - designed to reduce hardware complexity by requiring 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. - - - UHCI - - 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. - - 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: - - 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 generated by 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. - - See for a more elaborate description the UHCI - specification. - - - - - OHCI - - 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. - - framelist interruptisochronous control bulk - - 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. - - See for a more elaborate description the - OHCI specification. Services layer The middle layer - provides access to the device in a controlled way and - maintains resources in use by the different drivers and the - services layer. The layer takes care of the following - aspects: - - - The device configuration - information - The pipes to communicate with a - device - Probing and attaching and detaching form a - device. - - - - - - - USB Device Information - - - Device configuration information - - 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 are active 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. - - 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. - - Level 0 Level 1 Level 2 Slot 0 - Slot 3 Slot 2 Slot 1 - (Only 4 out of 32 slots shown) - - 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 transfers on the USB - bus. Access to the descriptors is provided through function - calls. - - - 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. - - Configuration descriptors: The number of - interfaces in this configuration, suspend and resume - functionality supported and power - requirements. - - Interface descriptors: interface class, - subclass and protocol if applicable, number of alternate - settings for the interface and the number of - endpoints. - - Endpoint descriptors: Endpoint address, - direction and type, maximum packet size supported and - polling frequency if type is interrupt endpoint. There is no - descriptor for the default endpoint (endpoint 0) and it is - never counted in an interface descriptor. - - 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. - - - - Class specifications can add their own descriptor types - that are available through the GetDescriptor Request. - - 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. - - 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 - packet size. - - 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. - - 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 - the transfers 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 can be extended by a device - class specification to support additional - functionality. - - - Bulk pipe: This is the USB equivalent to a raw - transmission medium. - 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 specified when creating the - pipe. - - Isochronous pipe: These pipes are intended for - isochronous data, for example video or audio 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. - - - The availability of the necessary bandwidth is calculated - during the creation of the pipe. Transfers are 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 are allowed 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. - - 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]. - - - - - - Device probe and attach - - After the notification by the hub that a new device has been - connected, the service layer switches on 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 be able 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 interfaces within one configuration. Each - driver only needs to support a subset of the interfaces. - - The probing for a driver for a newly attached device checks - first for device specific drivers. If not found, 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 iterates over 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, even though the device might still be - attached. - - - Device disconnect and detach - - A device driver should expect to receive errors during any - transaction with the device. The design of 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. - - 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. - - The disconnection of a device is signaled 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. - - - - - - USB Drivers Protocol Information - - 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 - section on the USB home pages [ 1]. - - 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. - - 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. - - 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. - - 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 key presses 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. - - Example: Firmware download Many devices that have been - developed are based on a general purpose processor with - an additional 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. - - 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 device 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. - - 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. - - 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. - - 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 the existing 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. - - The support for the USB floppy from Y-E Data is again less - straightforward as a new command set has been designed. - - - - 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 2b78f50828..0000000000 --- a/en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml +++ /dev/null @@ -1,260 +0,0 @@ - - - - - - - Matthew - Dillon - Contributed by - - - - - - Virtual Memory System - - - Management of physical - memory—<literal>vm_page_t</literal> - - Physical memory is managed on a page-by-page basis through the - vm_page_t structure. Pages of physical memory are - categorized through the placement of their respective - vm_page_t structures on one of several paging - queues. - - 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. - - 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. - - Additionally, a page may be held with a reference count or locked - with a busy count. The VM system also implements an ultimate - locked state for a page using the PG_BUSY bit in the page's - flags. - - 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. - - 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. - - 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 vs. 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. - - - - The unified buffer - cache—<literal>vm_object_t</literal> - - FreeBSD implements the idea of a generic VM object. - 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. - - VM objects can be shadowed. 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. - - It should be noted that a vm_page_t 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. - - - - Filesystem I/O—<literal>struct buf</literal> - - 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 store. Additionally, filesystems need to be able to map - portions of a file or file metadata into KVM in order to operate on - it. - - The entities used to manage this are known as filesystem buffers, - struct buf's, or - bp'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. - - 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 - vm_page_t's, not filesystem buffers. However, - since filesystem buffers are used to placehold I/O, they do inherently - limit the amount of concurrent I/O possible. However, as there are usually a - few thousand filesystem buffers available, this is not usually a - problem. - - - - Mapping Page Tables—<literal>vm_map_t, vm_entry_t</literal> - - 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. - - FreeBSD associates portions of vm_objects with address ranges in - virtual memory through vm_map_t and - vm_entry_t structures. Page tables are directly - synthesized from the - vm_map_t/vm_entry_t/ - vm_object_t hierarchy. Recall that I mentioned - that physical pages are only directly associated with a - vm_object; that is not quite true. - vm_page_t's are also linked into page tables that - they are actively associated with. One vm_page_t - can be linked into several pmaps, as page tables - are called. However, the hierarchical association holds, so all - references to the same page in the same object reference the same - vm_page_t and thus give us buffer cache unification - across the board. - - - - KVM Memory Mapping - - 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 struct buf entities. - - 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. - - KVM is managed through several mechanisms. The main mechanism - used to manage KVM is the zone allocator. 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 vmstat -m to get an - overview of current KVM utilization broken down by zone. - - - - Tuning the FreeBSD VM system - - 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 and - kernel config options. That is, kernel - compilation options specified in (typically) - /usr/src/sys/i386/conf/CONFIG_FILE. - A description of all available kernel configuration options can be - found in /usr/src/sys/i386/conf/LINT. - - In a large system configuration you may wish to increase - . Values typically range from 10 to 128. - Note that raising too high can cause the - system to overflow available KVM resulting in unpredictable operation. - It is better to leave at some reasonable number and add other - options, such as , to increase specific - resources. - - If your system is going to use the network heavily, you may want - to increase . Typical values range from - 1024 to 4096. - - The NBUF 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 - not try to specify an NBUF - 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. - - By default, FreeBSD kernels are not optimized. You can set - debugging and optimization flags with the - makeoptions directive in the kernel configuration. - Note that you should not use unless you can - accommodate the large (typically 7 MB+) kernels that result. - - makeoptions DEBUG="-g" -makeoptions COPTFLAGS="-O -pipe" - - 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. - - Run time VM and system tuning is relatively straightforward. - First, use Soft Updates on your UFS/FFS filesystems whenever possible. - /usr/src/sys/ufs/ffs/README.softupdates contains - instructions (and restrictions) on how to configure it. - - Second, configure sufficient swap. You should have a swap - partition configured on each physical disk, up to four, even on your - work 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 /var/crash must - have sufficient free space to hold the dump. - - 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. - - - diff --git a/en_US.ISO8859-1/books/handbook/basics/disk-layout.kil b/en_US.ISO8859-1/books/handbook/basics/disk-layout.kil deleted file mode 100644 index 85820c2878..0000000000 Binary files a/en_US.ISO8859-1/books/handbook/basics/disk-layout.kil and /dev/null differ diff --git a/en_US.ISO8859-1/books/handbook/basics/example-dir1.dot b/en_US.ISO8859-1/books/handbook/basics/example-dir1.dot deleted file mode 100644 index f259e8377d..0000000000 --- a/en_US.ISO8859-1/books/handbook/basics/example-dir1.dot +++ /dev/null @@ -1,7 +0,0 @@ -// $FreeBSD$ - -digraph directory { - root [label="Root\n/"]; - root -> "A1/"; - root -> "A2/"; -} diff --git a/en_US.ISO8859-1/books/handbook/basics/example-dir2.dot b/en_US.ISO8859-1/books/handbook/basics/example-dir2.dot deleted file mode 100644 index b846c82399..0000000000 --- a/en_US.ISO8859-1/books/handbook/basics/example-dir2.dot +++ /dev/null @@ -1,8 +0,0 @@ -// $FreeBSD$ - -digraph directory { - root [label="Root\n/"]; - root -> "A1/" -> "B1/"; - "A1/" -> "B2/"; - root -> "A2/"; -} diff --git a/en_US.ISO8859-1/books/handbook/basics/example-dir3.dot b/en_US.ISO8859-1/books/handbook/basics/example-dir3.dot deleted file mode 100644 index 178a3a91bb..0000000000 --- a/en_US.ISO8859-1/books/handbook/basics/example-dir3.dot +++ /dev/null @@ -1,8 +0,0 @@ -// $FreeBSD$ - -digraph directory { - root [label="Root\n/"]; - root -> "A1/"; - root -> "A2/" -> "B1/"; - "A2/" -> "B2/"; -} diff --git a/en_US.ISO8859-1/books/handbook/basics/example-dir4.dot b/en_US.ISO8859-1/books/handbook/basics/example-dir4.dot deleted file mode 100644 index 82d12b421a..0000000000 --- a/en_US.ISO8859-1/books/handbook/basics/example-dir4.dot +++ /dev/null @@ -1,9 +0,0 @@ -// $FreeBSD$ - -digraph directory { - root [label="Root\n/"]; - root -> "A1/"; - root -> "A2/" -> "B1/" -> "C1/"; - "B1/" -> "C2/"; - "A2/" -> "B2/"; -} diff --git a/en_US.ISO8859-1/books/handbook/basics/example-dir5.dot b/en_US.ISO8859-1/books/handbook/basics/example-dir5.dot deleted file mode 100644 index f5aa6e01dc..0000000000 --- a/en_US.ISO8859-1/books/handbook/basics/example-dir5.dot +++ /dev/null @@ -1,9 +0,0 @@ -// $FreeBSD$ - -digraph directory { - root [label="Root\n/"]; - root -> "A1/" -> "C1/"; - "A1/" -> "C2/"; - root -> "A2/" -> "B1/"; - "A2/" -> "B2/"; -} diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml index 675f404e5f..d944c2347a 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -55,7 +55,7 @@ -
+
FreeBSD Mall, Inc. 3623 Sanford Street Concord, CA 94520-1405 @@ -64,7 +64,7 @@ Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW: http://www.freebsdmall.com/ -
+
@@ -113,6 +113,17 @@ + +
+ UNIXDVD.COM LTD + 57 Primrose Avenue + Sheffield + S5 6FS + United Kingdom + WWW: http://www.unixdvd.com/ +
+ + @@ -136,16 +147,16 @@ - -
- FreeBSD Services Ltd - 11 Lapwing Close - Bicester - OX26 6XR - United Kingdom - WWW: http://www.freebsd-services.com/ -
- + +
+ FreeBSD Services Ltd + 11 Lapwing Close + Bicester + OX26 6XR + United Kingdom + WWW: http://www.freebsd-services.com/ +
+
@@ -4356,6 +4367,15 @@ doc/zh_TW.Big5 + + RELENG_4_8 + + + The release branch for FreeBSD-4.8, used only + for security advisories and other seriously critical fixes. + + + RELENG_4_7 @@ -4423,6 +4443,22 @@ doc/zh_TW.Big5 Other revision tags that are available include: + + RELENG_4_8_0_RELEASE + + + FreeBSD 4.8 + + + + + RELENG_5_0_0_RELEASE + + + FreeBSD 5.0 + + + RELENG_4_7_0_RELEASE diff --git a/en_US.ISO8859-1/books/porters-handbook/book.sgml b/en_US.ISO8859-1/books/porters-handbook/book.sgml index 45979f128f..c221960598 100644 --- a/en_US.ISO8859-1/books/porters-handbook/book.sgml +++ b/en_US.ISO8859-1/books/porters-handbook/book.sgml @@ -5340,6 +5340,16 @@ PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} 470103 + + 4.8-RELEASE + 480000 + + + + 4.8-STABLE + 480100 + + 5.0-CURRENT 500000 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 5ded4d2497..0000000000 --- a/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml +++ /dev/null @@ -1,397 +0,0 @@ - - - - - - - Moses - Moore - ´ó¹Æ - - - - - - ¥µ¥¦¥ó¥É - - - ¤³¤Î¾Ï¤Ç¤Ï - - FreeBSD ¤Ï¤¢¤Ê¤¿¤Î¥³¥ó¥Ô¥å¡¼¥¿¤«¤é¸¶²»¤ËÃé¼Â¤ÊºÆÀ¸¤ò³Ú¤·¤à¤¿¤á¤Î¡¢ - ¿ô¿¤¯¤Î¼ïÎà¤Î¥µ¥¦¥ó¥É¥«¡¼¥É¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£ - ¤³¤ì¤Ë¤è¤ê¡¢MPEG Audio Layer 3 (MP3) ¤ä WAV¡¢Ogg Vorbis ¤Ê¤É¤Î - ²»³Ú¤òÏ¿²»¤·¤¿¤êºÆÀ¸¤·¤¿¤ê¤Ç¤­¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ - ²Ã¤¨¤Æ FreeBSD Ports ¥³¥ì¥¯¥·¥ç¥ó¤Ë¤Ï¡¢¤¢¤Ê¤¿¤¬Ï¿²»¤·¤¿²»³Ú¤ò - ÊÔ½¸¤·¤¿¤ê¡¢²»¶Á¸ú²Ì¤ò²Ã¤¨¤¿¤ê¡¢Àܳ¤µ¤ì¤¿ MIDI µ¡´ï¤òÀ©¸æ¤·¤¿¤ê - ¤¹¤ë¤¿¤á¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ - - - - ¤³¤Î¾Ï¤òÆɤá¤Ð¡¢°Ê²¼¤Î¤³¤È¤òÃΤ뤳¤È¤¬¤Ç¤­¤Þ¤¹: - - ¥µ¥¦¥ó¥É¥«¡¼¥É¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÊýË¡ - ¥·¥¹¥Æ¥à¤òÀßÄꤷ¤Æ¥µ¥¦¥ó¥É¥«¡¼¥É¤òǧ¼±¤µ¤»¤ëÊýË¡ - - ¥µ¥ó¥×¥ë¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤òÍøÍѤ·¤Æ¥µ¥¦¥ó¥É¥«¡¼¥É¤¬ - ¤¦¤Þ¤¯Æ°¤¤¤Æ¤¤¤ë¤«¤É¤¦¤«¤ò¥Æ¥¹¥È¤¹¤ëÊýË¡ - ¥µ¥¦¥ó¥É´ØÏ¢¤ÎÀßÄê¤Î¥È¥é¥Ö¥ë¥·¥å¡¼¥ÈÊýË¡ - - - - ¤³¤Î¾Ï¤òÆɤàÁ°¤Ë¡¢°Ê²¼¤Î¤³¤È¤òÍý²ò¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ê¤Þ¤¹: - - - ¿·¤·¤¤¥«¡¼¥Í¥ë¤òÀßÄꤷ¤Æ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÊýË¡ () - - - - - Àµ¤·¤¤¥Ç¥Ð¥¤¥¹¤Î³Îǧ - - PCI - ISA - ¥µ¥¦¥ó¥É¥«¡¼¥É - ÀßÄê¤ò¤Ï¤¸¤á¤ëÁ°¤Ë¡¢¤¢¤Ê¤¿¤¬»ý¤Ã¤Æ¤¤¤ë¥«¡¼¥É¤Î¥â¥Ç¥ë¡¢ - ¤½¤Î¥«¡¼¥É¤¬»ÈÍѤ·¤Æ¤¤¤ë¥Á¥Ã¥×¡¢¤½¤·¤Æ PCI¡¢ISA - ¤É¤Á¤é¤Î¥«¡¼¥É¤Ê¤Î¤«¤ò³Îǧ¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ - FreeBSD ¤Ï¡¢¤µ¤Þ¤¶¤Þ¤Ê PCI ¤ª¤è¤Ó ISA ¤Î¥«¡¼¥É¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£ - ¤â¤·¤¢¤Ê¤¿¤Î¥«¡¼¥É¤¬¼¡¤Î¥ê¥¹¥È¤Ë̵¤¤¾ì¹ç¤Ï¡¢ - &man.pcm.4; ¤Î¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ - ¤³¤ì¤Ï´°Á´¤Ê¥ê¥¹¥È¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¤¬¡¢ - Îɤ¯»È¤ï¤ì¤Æ¤¤¤ë¥«¡¼¥É¤¬¤À¤¤¤¿¤¤´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ - - - - Crystal 4237¡¢4236¡¢4232¡¢4231 - - - - ¥ä¥Þ¥Ï OPL-SAx - - - - OPTi931 - - - - Ensoniq AudioPCI 1370/1371 - - - - ESS Solo-1/1E - - - - NeoMagic 256AV/ZX - - - - Sound Blaster Pro¡¢16¡¢32¡¢AWE64¡¢AWE128¡¢Live - - - - Creative ViBRA16 - - - - Advanced Asound 100¡¢110¡¢¤ª¤è¤Ó Logic ALS120 - - - - ES 1868¡¢1869¡¢1879¡¢1888 - - - - Gravis UltraSound - - - - Aureal Vortex 1 ¤ª¤è¤Ó 2 - - - - - ¥«¡¼¥Í¥ë - ¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó - - ¥«¡¼¥Í¥ëÆâ¤Ç»ÈÍѤ¹¤ë¥É¥é¥¤¥Ð¤Ï¡¢ - »ÈÍѤ¹¤ë¥«¡¼¥É¤Î¼ïÎà¤Ë¤è¤Ã¤Æ°Û¤Ê¤ê¤Þ¤¹¡£ - ¤³¤ÎÀá¤Ç¤Ï¡¢¤½¤ì¤é¤Î¾Ü¤·¤¤¾ðÊó¤È¡¢ - ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ë - ²¿¤òÄɲ乤ì¤ÐÎɤ¤¤Î¤«¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ - - - Creative¡¢Advance¡¢¤ª¤è¤Ó ESS ¼ÒÀ½¥µ¥¦¥ó¥É¥«¡¼¥É - - ¤³¤ì¤é¤Î¥«¡¼¥É¤ò»ÈÍѤ¹¤ë¾ì¹ç¤Ï¡¢ - ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ë°Ê²¼¤ÎÀßÄê¤òÄɲä·¤Þ¤¹¡£ - - device pcm - - PnP ¤Î ISA ¥«¡¼¥É¤ò»ÈÍѤ¹¤ë¾ì¹ç¤Ï¡¢¤µ¤é¤Ë - - device sbc - - ¤â²Ã¤¨¤Æ¤¯¤À¤µ¤¤¡£ - PnP ¤Ç¤Ï¤Ê¤¤ ISA ¤Î¥«¡¼¥É¤ò»ÈÍѤ¹¤ë¾ì¹ç¤Ï¡¢ - - device pcm - - ¤È - - device sbc0 at isa? port0x220 irq 5 drq 1 flags 0x15 - - ¤ò²Ã¤¨¤Þ¤¹¡£ - ¤³¤ì¤é¤Ïɸ½à¤ÎÀßÄê¤Ë¤¢¤ï¤»¤¿¤â¤Î¤Ç¤¹¤Î¤Ç¡¢ - IRQ ¤Ê¤É¤ÎÀßÄê¤ÏɬÍפ˱þ¤¸¤ÆÊѹ¹¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ - ¤Þ¤¿¡¢ÀßÄê¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¡¢&man.sbc.4; - ¤Î¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ - - - ¥Ñ¥Ã¥Á¤òŬÍѤ·¤Æ¤¤¤Ê¤¤ FreeBSD 4.0 ¤Ï - Sound Blaster Live ¤ËÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£ - ¤Þ¤¿¡¢¤³¤Îʸ½ñ¤Ç¤Ï¤½¤ÎÀßÄêÊýË¡¤Ë¤Ä¤¤¤Æ¤Ï°·¤¤¤Þ¤»¤ó¡£ - ¤³¤Î¥«¡¼¥É¤ò»ÈÍѤ¹¤ëÁ°¤Ë¡¢ºÇ¿·¤Î -STABLE - ¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ - - - - - Gravis ¼ÒÀ½ UltraSound ¥«¡¼¥É - - PnP ¤Î ISA ¥«¡¼¥É¤ò»ÈÍѤ¹¤ë¤Ë¤Ï¡¢ - ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ë¼¡¤Î - 2 ¤Ä¤ÎÀßÄê¤òÄɲä·¤Þ¤¹¡£ - - device pcm - - device gusc - - PnP ¤Ç¤Ï¤Ê¤¤ ISA ¥«¡¼¥É¤Î¾ì¹ç¤Ë¤Ï¡¢ - - device pcm - - ¤È - - device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13 - - ¤ò²Ã¤¨¤Þ¤¹¡£ - IRQ ¤Ê¤É¤ÎÀßÄê¤ÏɬÍפ˱þ¤¸¤ÆÊѹ¹¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ - ¤Þ¤¿¡¢ÀßÄê¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¡¢&man.gusc.4; - ¤Î¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ - - - - Crystal ¼ÒÀ½¥µ¥¦¥ó¥É¥«¡¼¥É - - Crystal ¼ÒÀ½¤Î¥«¡¼¥É¤ò»ÈÍѤ¹¤ë¾ì¹ç¤Ï¡¢ - ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ë - - device pcm - - ¤È - - device csa - - ¤ÎξÊý¤¬É¬ÍפǤ¹¡£ - - - - °ìÈÌŪ¤Ê¥«¡¼¥É¤Î¥µ¥Ý¡¼¥È - - PnP ISA ¥«¡¼¥É¤ä PCI ¥«¡¼¥É¤ò»ÈÍѤ¹¤ë¾ì¹ç¤Ï¡¢ - - device pcm - - ¤ò¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤ËÄɲä·¤Þ¤¹¡£ - ¥Ö¥ê¥Ã¥¸¥É¥é¥¤¥Ð¤ò»ý¤¿¤Ê¤¤¡¢PnP ÈóÂбþ¤Î ISA - ¥«¡¼¥É¤Î¾ì¹ç¤Ï¡¢ - - device pcm0 at isa? irq 10 drq 1 flags 0x0 - - ¤ò²Ã¤¨¤Þ¤¹¡£ - IRQ ¤Ê¤É¤ÎÀßÄê¤Ï¡¢ - ¥Ï¡¼¥É¥¦¥§¥¢¤ÎÀßÄê¤Ë¹ç¤¦¤è¤¦¤ËɬÍפ˱þ¤¸¤ÆÊѹ¹¤·¤Æ¤¯¤À¤µ¤¤¡£ - - - - - ¥«¡¼¥Í¥ë¤ÎºÆ¹½ÃÛ - - ɬÍפÊÀßÄê¤ò¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤ËÄɲä·¤¿¤é¡¢ - ¥«¡¼¥Í¥ë¤òºÆ¹½ÃÛ¤·¤Þ¤¹¡£ - ¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¥Ï¥ó¥É¥Ö¥Ã¥¯¤Î¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ - - - - ¥Ç¥Ð¥¤¥¹¥Î¡¼¥É¤ÎºîÀ®¤È¥Æ¥¹¥È - - ¥Ç¥Ð¥¤¥¹¥Î¡¼¥É - ºÆµ¯Æ°¤·¤¿¸å¡¢¥í¥°¥¤¥ó¤·¤Æ cat /dev/sndstat - ¤ò¼Â¹Ô¤·¤Þ¤¹¡£¤¹¤ë¤È¡¢°Ê²¼¤Î¤è¤¦¤Ë½ÐÎϤµ¤ì¤ë¤Ï¤º¤Ç¤¹¡£ - - 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) - - ¥¨¥é¡¼¥á¥Ã¥»¡¼¥¸¤¬½ÐÎϤµ¤ì¤ë¾ì¹ç¤Ï¡¢ - º£¤Þ¤Ç¤Î¼ê½ç¤Î¤É¤³¤«¤¬´Ö°ã¤Ã¤Æ¤¤¤Þ¤¹¡£ - ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤ò¤â¤¦°ìÅÙ¸«Ä¾¤·¤Æ¡¢ - Àµ¤·¤¤¥Ç¥Ð¥¤¥¹¤òÁªÂò¤·¤Æ¤¤¤ë¤«¤É¤¦¤«³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ - - ¥¨¥é¡¼¤¬½ÐÎϤµ¤ì¤º¤Ë pcm0 - ¤¬½ÐÎϤµ¤ì¤¿¾ì¹ç¤Ï¡¢ - su ¥³¥Þ¥ó¥É¤Ç - root ¤Ë¤Ê¤ê¡¢ - ¼¡¤Î¤è¤¦¤Ë¼Â¹Ô¤·¤Þ¤¹¡£ - - &prompt.root; cd /dev -&prompt.root; sh MAKEDEV snd0 - - ¥¨¥é¡¼¤¬½ÐÎϤµ¤ì¤º¤Ë pcm1 - ¤¬½ÐÎϤµ¤ì¤¿¾ì¹ç¤Ï¡¢ - su ¥³¥Þ¥ó¥É¤Ç - root ¤Ë¤Ê¤ê¡¢ - ¼¡¤Î¤è¤¦¤Ë¼Â¹Ô¤·¤Þ¤¹¡£ - - &prompt.root; cd /dev -&prompt.root; sh MAKEDEV snd1 - - ¾å¤Î¥³¥Þ¥ó¥É¤Ï¤É¤Á¤é¤â¡¢ - /dev/snd ¤È¤¤¤¦ - ¥Ç¥Ð¥¤¥¹¤òºîÀ®¤¹¤ë¤â¤Î¤Ç¤Ï¤Ê¤¤¤È¤¤¤¦ÅÀ¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤! - ¤³¤ì¤é¤ÏÂå¤ï¤ê¤Ë¡¢ - ¼¡¤Î¤è¤¦¤ÊÊ£¿ô¤Î¥Ç¥Ð¥¤¥¹¥Î¡¼¥É¤òºîÀ®¤·¤Þ¤¹¡£ - - - - - - ¥Ç¥Ð¥¤¥¹ - ÀâÌÀ - - - - - - /dev/audio - SPARC ¸ß´¹¥ª¡¼¥Ç¥£¥ª¥Ç¥Ð¥¤¥¹ - - - - /dev/dsp - (ÌõÃí: 8 ¥Ó¥Ã¥È¤Ç) ¥µ¥ó¥×¥ê¥ó¥°¤¹¤ë²»À¼¥Ç¥Ð¥¤¥¹ - - - - /dev/dspW - /dev/dsp¤ÈƱÍÍ¡£ - ¤¿¤À¤·¥µ¥ó¥×¥ê¥ó¥°¤Ï 16 ¥Ó¥Ã¥È¡£ - - - - /dev/midi - Raw MIDI ¥¢¥¯¥»¥¹¥Ç¥Ð¥¤¥¹ - - - - /dev/mixer - ¥³¥ó¥È¥í¡¼¥ë¥Ý¡¼¥È¥ß¥­¥µ¡¼¥Ç¥Ð¥¤¥¹ - - - - /dev/music - ¥ì¥Ù¥ë 2 ¥·¡¼¥±¥ó¥µ¥¤¥ó¥¿¥Õ¥§¡¼¥¹ - - - - /dev/sequencer - ¥·¡¼¥±¥ó¥µ¥Ç¥Ð¥¤¥¹ - - - - /dev/pss - ¥×¥í¥°¥é¥à²Äǽ¤Ê¥Ç¥Ð¥¤¥¹¥¤¥ó¥¿¥Õ¥§¡¼¥¹ - - - - - - ¤¹¤Ù¤Æ¤¦¤Þ¤¯¹Ô¤±¤Ð¡¢ - ¥µ¥¦¥ó¥É¥«¡¼¥É¤Îµ¡Ç½¤ò»ÈÍѤ¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ - ¤¦¤Þ¤¯¹Ô¤«¤Ê¤¤¾ì¹ç¤Ï¡¢¼¡¤ÎÀá¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ - - - - ¤è¤¯¤¢¤ëÌäÂê - - - ¥Ç¥Ð¥¤¥¹¥Î¡¼¥É - - - unsupported subdevice XX error ¤¬½Ð¤Þ¤·¤¿! - - - - ¤¤¤¯¤Ä¤«¤Î¥Ç¥Ð¥¤¥¹¥Î¡¼¥É¤¬Àµ¤·¤¯ºîÀ®¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ - Á°Àá¤Î¼ê½ç¤ò¤â¤¦°ìÅÙ¤ä¤Ã¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ - - - - I/O ¥Ý¡¼¥È - - - sb_dspwr(XX) timed out error ¤¬½Ð¤Þ¤·¤¿! - - - - I/O ¥Ý¡¼¥È¤¬Àµ¤·¤¯ÀßÄꤵ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ - - - - IRQ - - - bad irq XX error ¤¬½Ð¤Þ¤·¤¿! - - - - IRQ ¤¬Àµ¤·¤¯ÀßÄꤵ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ - ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ëÃæ¤Î - IRQ ¤ÎÀßÄê¤È¡¢ - ¥µ¥¦¥ó¥É¥«¡¼¥É¤Î IRQ ¤ÎÀßÄ꤬Ʊ¤¸¤Ç¤¢¤ë¤«³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ - - - - - - xxx: gus pcm not attached, out of memory ¤È¤¤¤¦¥¨¥é¡¼¤¬½Ð¤Þ¤¹¡£ - ²¿¤¬µ¯¤­¤¿¤Î¤Ç¤·¤ç¤¦¤«? - - - - ¤³¤ì¤Ï¡¢ - ¥Ç¥Ð¥¤¥¹¤ò»ÈÍѤ¹¤ë¤¿¤á¤ËɬÍפʥá¥â¥ê¤¬³ÎÊݤǤ­¤Ê¤¤»þ¤Ëɽ¼¨¤µ¤ì¤Þ¤¹¡£ - - - - - - - diff --git a/ja_JP.eucJP/man/man1/gtar.1 b/ja_JP.eucJP/man/man1/gtar.1 deleted file mode 100644 index dd06c3dc75..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 -.\" Updated by Robert Eckardt -.\" -.\" %FreeBSD: src/gnu/usr.bin/tar/tar.1,v 1.43 2002/12/12 17:25:52 ru Exp % -.\" -.\" $FreeBSD$ -.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 -¥¢¡¼¥«¥¤¥Ö¤ÎÃæ¤Î 0 ¥Ö¥í¥Ã¥¯ (Ä̾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 -.\" -.\" 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 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 " -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 ¿®¹æ¤Ë¡¢»ØÄꤷ¤¿Ãͤò¥»¥Ã¥È¤·¤Þ¤¹ ( := data)¡£ -DTR ¿®¹æ¤È RTS ¿®¹æ¤Ï¡¢ -ioctl ¥·¥¹¥Æ¥à¥³¡¼¥ë¤Î°ú¿ôÃæ¤Î -.Dv TIOCM_DTR -¤È -.Dv TIOCM_RTS -¤Î¥Ó¥Ã¥È¤Ë¤è¤êÀ©¸æ²Äǽ¤Ç¤¹¡£ -.It TIOCMBIS -DTR ¿®¹æ¤È RTS ¿®¹æ¤ò¥»¥Ã¥È¤·¤Þ¤¹ ( |= data)¡£ -DTR ¿®¹æ¤È RTS ¿®¹æ¤Ï¡¢ -ioctl ¥·¥¹¥Æ¥à¥³¡¼¥ë¤Î°ú¿ôÃæ¤Î -.Dv TIOCM_DTR -¤È -.Dv TIOCM_RTS -¤Î¥Ó¥Ã¥È¤Ë¤è¤êÀ©¸æ²Äǽ¤Ç¤¹¡£ -.It TIOCMBIC -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 . -.\" 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 ¤¬¤¢¤Ã¤¿¤È¤·¤Æ¤â¡¢ -¤Á¤ã¤ó¤ÈÆ°¤­¤Þ¤¹¡£ -¤·¤«¤·¡¢¤½¤ì°Ê³°¤Î¥¢¥À¥×¥¿¤È¤ÎÁȤ߹ç¤ï¤»¤Ï¡¢¥É¥é¥¤¥Ð¤òº®Í𤵤»¤ë¤«¤â -¤·¤ì¤Þ¤»¤ó¡£ -¥Ï¡¼¥É¥¦¥§¥¢¸¡½Ð¤Ç²¿¤«º¤Æñ¤ò´¶¤¸¤¿»þ¤Ï¡¢ -.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 ¥¯¥é¥¹¥¿¤Î³ä¤êÅö¤Æ¥Ý¥ê¥·¤Ë¡¢¤ï¤¶ -¤È°ãÈ¿¤·¤Æ¤¤¤ë¤«¤é¤Ç¤¹¡£ -ÉÔɬÍפ˳ä¤êÅö¤Æ¤é¤ì¤¿¥¯¥é¥¹¥¿¤Ïû¤¤À¸Â¸´ü´Ö¤Ç²òÊü¤µ¤ì¤ë¤¿¤á¡¢ -Ť¤ÌܤǸ«¤ì¤Ð¥«¡¼¥Í¥ë¥á¥â¥ê¾ÃÈñÎ̤ˤϱƶÁ¤·¤Þ¤»¤ó¡£ -.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 , Dec. 1999. -.\"ML Checked by Tetsuya Isaki (°æºêůÌé) , -.\" Satoru Koizumi (¾®Àô ¸ç ) -.\"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 98905b0302..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 -.\" [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 -.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 ¤È < ¤È O[0123456] ¤Ë³¤¯¡¢1 ²»Éä¤Ë¤Ä¤¤¤Æ¤Ï̵¸ú¤Ç¤¹¡£ -(¥ª¥¯¥¿¡¼¥ÖÄɽ¾µ¡Ç½¤Ï -.Tn IBM -BASIC ¤Ç¤Ï¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£) -.It Li > -¸½ºß¤Î¥ª¥¯¥¿¡¼¥Ö¤ò 1 ¤Ä¾å¤²¤Þ¤¹¡£ -.It Li < -¸½ºß¤Î¥ª¥¯¥¿¡¼¥Ö¤ò 1 ¤Ä²¼¤²¤Þ¤¹¡£ -.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 e766b3ddb1..0000000000 --- a/ja_JP.eucJP/man/man8/man8.i386/apm.8 +++ /dev/null @@ -1,159 +0,0 @@ -.\" LP (Laptop Package) -.\" -.\" Copyright (c) 1994 by Tatsumi Hosokawa -.\" -.\" 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.24 2002/12/24 13:41:47 ru Exp % -.\" -.\" use. -.\" -.\" $FreeBSD$ -.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 -¥¹¥¿¥ó¥Ð¥¤¥â¡¼¥É¤Ë°Ü¹Ô¤·¤Þ¤¹¡£ -Ëܥ⡼¥É¤Ç¤Ï¥Õ¥ë¥Ñ¥ï¡¼¥â¡¼¥É̤Ëþ¡¢¥µ¥¹¥Ú¥ó¥É¥â¡¼¥É°Ê¾å¤ÎÅÅÎϾÃÈñ¤È¤Ê¤ê¤Þ¤¹¡£ -¥¿¥¤¥Þ¤â¤·¤¯¤Ï¥ê¥ó¥°¥¤¥ó¥¸¥±¡¼¥¿¥¤¥Ù¥ó¥È¤Ë¤è¤ê¡¢ -¤³¤Î¾õÂÖ¤«¤é¥ì¥¸¥å¡¼¥à¤¹¤ëµ¡Ç½¤ò¥µ¥Ý¡¼¥È¤¹¤ë¥é¥Ã¥×¥È¥Ã¥×¤¬¤¢¤ê¤Þ¤¹¡£ -.Nm -¤Î½ÐÎϤˤè¤ê¡¢¥é¥Ã¥×¥È¥Ã¥×¤¬²¿¤ò¥µ¥Ý¡¼¥È¤¹¤ë¤È¼çÄ¥¤·¤Æ¤¤¤ë¤«¤¬Ê¬¤«¤ê¤Þ¤¹¡£ -.It Fl z -¥·¥¹¥Æ¥à¤ò¥µ¥¹¥Ú¥ó¥É¤·¤Þ¤¹¡£¤³¤ì¤Ï¡¢ -.Nm zzz -¤ÈÅù²Á¤Ç¤¹¡£ -.El -.Sh ¥Ð¥° -¤¤¤¯¤Ä¤«¤Î APM ¼ÂÁõ¤Ç¤Ï¡¢ -.Nm -¤¬É¬ÍפȤ¹¤ë¥Ñ¥é¥á¡¼¥¿¤¬Ä󶡤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ -¤½¤Î¤è¤¦¤Ê¥·¥¹¥Æ¥à¤Ë±÷¤¤¤Æ¤Ï¡¢ -.Nm -¤Ï¡¢¤½¤ì¤é¤òÃΤé¤Ê¤¤¤Èɽ¼¨¤·¤Þ¤¹¡£ -.Pp -¤¤¤¯¤Ä¤«¤Î APM ¼ÂÁõ¤Ç¤Ï¡¢ÅŸ»¥¹¥¤¥Ã¥Á¤ò²¡¤·¤¿¤³¤È¤ä¥«¥Ð¡¼¤¬ -ÊĤá¤é¤ì¤¿¤³¤È¤Ê¤É¤Î¥¤¥Ù¥ó¥È¤ò°·¤¦¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¡£ -¤½¤Î¤è¤¦¤Ê¼ÂÁõ¤Ë±÷¤¤¤Æ¤Ï¡¢ -¥·¥¹¥Æ¥à¤Ï -.Nm -¤« -.Nm zzz -.Ar ¤À¤±¤ò -¤Ä¤«¤Ã¤Æ¥µ¥¹¥Ú¥ó¥É¤¹¤ë -.Ar ¤Ù¤­ -¤Ç¤¹¡£ -.Sh Ãí -.Xr apmconf 8 -¤Ï -.Nm -¤Ë¥Þ¡¼¥¸¤µ¤ì¡¢ -.Nm -¤¬Á´µ¡Ç½¤òÃÖ¤­´¹¤¨¤Þ¤·¤¿¡£ -.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 fd54275a3e..0000000000 --- a/ja_JP.eucJP/man/man8/man8.i386/apmd.8 +++ /dev/null @@ -1,294 +0,0 @@ -.\" Copyright (c) 1999 Mitsuru IWASAKI -.\" Copyright (c) 1999 KOIE Hidetaka -.\" Copyright (c) 1999 Yoshihiko SARUMARU Aq -.\" Copyright (c) 1999 Norihiro Kumagai -.\" 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.14 2002/12/27 12:15:36 schweikh Exp % -.\" -.\" $FreeBSD$ -.\" -.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/share/sgml/freebsd.ent b/share/sgml/freebsd.ent index c531972fde..db2dd63a65 100644 --- a/share/sgml/freebsd.ent +++ b/share/sgml/freebsd.ent @@ -25,8 +25,8 @@ - - + + @@ -35,7 +35,7 @@ - + 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 @@ - - - - - - %includes; - - - - - - - - - - - - - - -]> - -
- - FreeBSD 2.X ±`¨£°Ýµª¶° - - FreeBSD ¤å¥ó­pµe - - - $Date: 1999-11-12 08:34:11 $ - - - ³o¥÷¤å¥ó¬O FreeBSD 2.X ªº±`¨£°Ýµª¶°¡C°£«D¦³¯S§O¥[µù¡A§_«h³o¨Ç±ø¥Ø³£¾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 ¡C - ±z¥i¥H±q ®³¨ì³o¥÷¤å¥óªº³Ì·sª©¥»¡C±z¤]¥i¥H - §Q¥Î HTTP ¨Ó¤U¸ü¥»¤å¥óªº ¡A - ¡A - ¡A - ©Î¬O ¡A©Î¬O¸g¥Ñ - - ¨Ó¤U¸ü gzip'd ªºª©¥»¡C±z©Î³\¤]·Q - ¡C - - - - - -&preface; -&install; -&hardware; -&troubleshoot; -&commercial; -&applications; -&kernelconfig; -&admin; -&x; -&network; -&serial; -&misc; -&hackers; -&acknowledgments; - -
- -- cgit v1.2.3