diff --git a/ja_JP.eucJP/books/Makefile b/ja_JP.eucJP/books/Makefile index 541ef2ef98..49f02274de 100644 --- a/ja_JP.eucJP/books/Makefile +++ b/ja_JP.eucJP/books/Makefile @@ -7,7 +7,6 @@ SUBDIR+= faq #SUBDIR+= fdp-primer SUBDIR+= handbook SUBDIR+= porters-handbook -SUBDIR+= ppp-primer ROOT_SYMLINKS= faq handbook diff --git a/ja_JP.eucJP/books/handbook/backups/Makefile b/ja_JP.eucJP/books/handbook/backups/Makefile deleted file mode 100644 index 622f372326..0000000000 --- a/ja_JP.eucJP/books/handbook/backups/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= backups/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/backups/chapter.sgml b/ja_JP.eucJP/books/handbook/backups/chapter.sgml deleted file mode 100644 index 1f82e4463f..0000000000 --- a/ja_JP.eucJP/books/handbook/backups/chapter.sgml +++ /dev/null @@ -1,968 +0,0 @@ - - - - - バックアップ - - - この章では - - この章ではデータのバックアップ方法とバックアップの作成に - 使われるプログラムについて扱います。 - - - - テープメディア - - テープメディア(tape media) - 一般的なテープメディアには 4mm、8mm、QIC、ミニカートリッジ、 - DLT があります。 - - - 4mm (DDS: Digital Data Storage) - - - テープメディア(tape media) - DDS (4mm) テープ - - - テープメディア(tape media) - QIC テープ - - 4mm テープはワークステーションのバックアップメディアとして - QIC から置き換えられつつあります。この傾向は - QIC ドライブの製造のリーダであった Archive を Conner が買収し - QIC ドライブの製造を中止したことで加速しました。 - 4mm ドライブは小型で静かですが 8mm - ドライブの持っているような信頼性の評判はありません。 - カートリッジは 8mm カートリッジよりも安価で小型 (3 x 2 x 0.5 - インチ; 76 x 51 x 12 mm) です。4mm ドライブ は - 8mm 同様にヘリカルスキャン (訳注: - VTR と同様の回転ヘッドを使う方式) - を使用しているという理由でヘッドの寿命は短いです。 - - これらのドライブのデータスループットは - 150kB/s 程度から最大で 500kB/s 程度の範囲です。データ容量は - 1.3GB から 2.0GB です。ハードウェア圧縮が多くのドライブで可能で、 - およそ 2 倍の容量になります。 - マルチドライブテープライブラリユニットは 1 つの筐体に - 6 ドライブを持つことができ自動的にテープを交換します。 - ライブラリの容量は 240GB に達します。 - - 現在の DDS-3 規格では、12GB (圧縮時 24GB) - までのテープ容量をサポートしています。 - - - 4mm ドライブは 8mm ドライブ同様にヘリカルスキャンを使います。 - ヘリカルスキャンの利点と欠点は 4mm ドライブ と 8mm - ドライブ共通です。 - - テープの寿命は 2000 回のパスあるいは 100 - 回のフルバックアップです。 - - - - 8mm (Exabyte) - - - テープメディア(tape media) - Exabyte (8mm) テープ - - 8mm テープは SCSI - テープドライブとして最もよく使われているもので、 - データ交換用として最良の選択です。ほとんどのサイトには Exabyte - の 2GB 8mm テープドライブがあるでしょう (訳注: Unix - ワークステーションを何台も置いているようなサイトには 1 - 台くらいはあるというような意味です)。8mm - ドライブは信頼性が高く、使いやすく、静かです。 - カートリッジは安価で小型です (4.8 x 3.3 x 0.6 インチ; 122 x 84 - x 15 mm)。欠点は、テープとヘッドの相対的な速度が高速なために - 比較的ヘッドとテープの寿命が短いことです。 - - データスループットは 250kB/s 程度から 500kB/s - 程度の範囲です。データ容量は 300MB から 7GB です。 - ハードウェア圧縮が多くのドライブで可能で、およそ 2 - 倍の容量になります。単一のユニットのドライブから、1 - つの筐体に 6 台のドライブと 120 - 巻のテープを持ったマルチドライブテープライブラリまで - 利用することができます。ライブラリではテープはユニットにより - 自動的に交換されます。ライブラリの容量は 840GB - 以上に達します。 - - Exabyte 社製の Mammoth というモデルは、 - テープ一本あたり 12GB (圧縮時 24GB) をサポートしています。 - このドライブの価格は、通常のテープドライブの約 2 倍です。 - - - データはヘリカルスキャンを使ってテープに記録されます。 - ヘリカルスキャン方式ではヘッドはメディアに対してある傾き - (約 6 度) に配置されます。テープはヘッドのある円筒の周の - 270 度にわたって接触します。テープが円筒面を走行する間、 - 円筒は回転しています。この結果、 - 高密度のデータのつまったトラックは、 - 狭い間隔でテープの上端と下端の間を斜めに横切ります。 - - - - QIC - - - テープメディア (tape media) - QIC-150 - - - QIC-150 テープとドライブはたぶん最も一般的に使われている - ドライブとメディアでしょう。QIC - テープドライブは現実的なバックアップドライブとして - 少なくとも高価なものではありません。 - 欠点はメディアのコストです。QIC テープは 8mm や 4mm - テープに比較して GB あたりのデータの保存で 5 倍ほど高価です。 - しかしあなたの必要とする量が半ダース程のテープで十分であれば、 - QIC は正しい選択となるかもしれません。QIC は - 最も一般的なテープドライブです。 - すべてのサイトに QIC ドライブのどれかの容量のものがあります。 - 問題は、QIC は同じようなテープ (まったく同じ場合もある) - に多様な記録密度があることです。QIC - ドライブは静かではありません。これらのドライブはデータ記録を - 開始する前に音をたててシークしますし、リード、ライト、 - シークの時にはっきりと聞こえる音を出します。QIC - テープの大きさは (6 x 4 x 0.7 インチ; 152 x 102 x 17 mm)。 - ミニカートリッジ - で使われている 1/4 インチ幅のテープについては別に議論します。 - テープライブラリやチェンジャはありません。 - - データスループットは 150kB/s から 500kB/s の範囲です。 - データ容量の範囲は 40MB から 15GB です。ハードウェア圧縮が - 最近の多くのドライブで使えるようになっています。QIC ドライブは - DAT ドライブに置き換えられつつあり、 - あまり頻繁には利用されなくなっています。 - - データは複数のトラックにわかれてテープに記録されます。 - トラックはテープメディアの - 長さ方向の一端からもう一方の端までです。(訳注: 1 トラックの - read/write が終わるとテープの走行方向を反転させ次のトラックの - read/write を行います) トラックの数と、 - それに対応するトラックの幅はテープの容量によって変わります。 - すべてではありませんがほとんどの最近のドライブは - 少なくとも読み出しについては (場合によっては書き込みも) - 下位互換性があります。QIC - はデータの安全性についてはよいといわれています - (ヘリカルスキャンドライブに比べて機構は単純でより丈夫です)。 - - - テープは 5000 回のバックアップで寿命となるでしょう。 - - - - XXX* ミニカートリッジ - - - - - - DLT - - - テープメディア(tape media) - DLT - - - DLT はここに示したドライブのタイプの中で - 最高速のデータ転送レートです。1/2 インチ (12.5mm) - テープが単リールのカートリッジ (4 x 4 x 1 インチ; 100 x 100 x - 25 mm) に入っています。 - カートリッジのひとつの側面全体がスイングゲートになっています。 - ドライブの機構がこのゲートを開け、テープリーダを引き出します。 - テープリーダには楕円形の穴があり、 - ドライブがテープを引っ掛けるのに使います。 - 巻き取りのためのリールはドライブの中にあります。 - ここに挙げた他のカートリッジはすべて (9 - トラックテープはただ一つの例外です) - 送りだしリールと巻き取りリールの両方がカートリッジの中に - あります。 - - データスループットは約 1.5MB/s で、4mm、8mm、QIC - テープドライブの 3 倍です。データ容量は単一のドライブで 10GB から - 20GB の範囲です。 - マルチテープチェンジャ、マルチテープドライブ、5 から - 900 巻のテープを 1 から 20 ドライブで扱う - マルチドライブテープライブラリがあり、50GB から 9TB - の容量が得られます。 - - 圧縮機能により、DLT Type IV フォーマットは - 70GB までの容量をサポートします。 - - データは ( QIC テープのように) - テープの走行方向と並行に複数あるトラックへ記録されます。2 - つのトラックに同時書き込みを行います。Read/Write - ヘッドの寿命は比較的長いと言えます。 - テープの走行が止まればヘッドと - テープの間の相対運動はありません。 - - - - AIT - - - テープメディア(tape media) - AIT - - - AIT は、Sony が発表した新しいフォーマットで、 - テープ一本あたり 50GB (圧縮時) の容量を持っています。 - テープには、記録データ内容の索引情報が記録可能な - メモリチップが内蔵されています。ドライブがこの索引情報を読みとることで、 - テープのどの部分にどのファイルが存在するかを - 高速に調べることができるようになっています。 - 従来のドライブは、この処理に数分の時間を必要としていました。 - 直接テープのメモリチップと通信することでテープ内容を画面表示する - SAMS:Alexandria のようなソフトウェアを使うことで、40 を超える - ATI テープライブラリを操作できるのはもちろんのこと、 - どのテープのどこに、どのファイルがバックアップされているのか調べたり、 - 正しいテープをセットしたり、 - テープ上のデータをリストアしたりすることが可能です。 - - - このようなテープライブラリにかかる費用は $20,000 台です。 - 業務用でないものはもう少し安価でしょう。 - - - - - 新品のテープを最初に使う場合 - - 新品の完全な空テープを読もうとしたり書き込もうとすると処理 - は失敗するでしょう。 - 次のようなコンソールメッセージが出るでしょう。 - - sa0(ncr1:4:0): NOT READY asc:4,1 -st0(ncr1:4:0): Logical unit is in process of becoming ready - - テープに識別ブロック (Identifire Block:block number 0) - がありません。QIC-525 標準の採用されている - QIC テープドライブのすべてで識別ブロックをテープに書きます。 - 2 つの解決方法があります。 - - (訳注: 方法 1)mt fsf 1 - によってテープドライブは識別ブロックをテープに書きます。 - - (訳注: - 方法 2) フロントパネルのボタンを押してテープをとりだします。 - - - 再びテープを入れ、データをテープに dump します。 - - dump はそのうちに DUMP: End of tape - detected と表示し、コンソールには - HARDWARE FAILURE info:280 - asc:80,96 と表示されるでしょう。 - - mt - rewind を使ってテープを巻戻します。 - - この次からはテープの操作は成功するでしょう。 - - - - - バックアッププログラム - - バックアッププログラム(backup software) - - よく使われる3つのプログラムは &man.dump.8;、&man.tar.1;、 - &man.cpio.1; です。 - - - dump と restore - - - バックアッププログラム(backup software) - dump / restore - - dump - restore - - Unix で古くから使われているバックアッププログラムは - dump と restore です。 - これらはディスクドライブをディスクブロックの集まりとして、 - ファイルシステム上につくられるファイル、 - リンク、ディレクトリといった概念よりも低レベルで扱います。 - dump はデバイスやファイルシステム全体をバックアップするもので、 - ファイルシステムの一部や、 - 複数のファイルシステムにまたがるディレクトリツリーの一部だけを - バックアップすることはできません。 - dump はファイルやディレクトリではなく、 - ファイルやディレクトリを構成する生のデータブロックをテープに記録します。 - - - ルートディレクトリで dump を使った場合、 - /home や /usr など、 - 他の多くのディレクトリはバックアップされません。 - これは、上にあげたようなディレクトリが通常、 - 他のファイルシステムへのマウントポイントであったり、 - 他のファイルシステムへのシンボリックリンクとなっているためです。 - - - dump には初期の ATT UNIX のバージョン 6 (1975 - 年ごろ) に由来する癖が残っています。 - デフォルトのパラメータは 9 トラックテープ (6250 bpi) - に適したものになっていて、 - 現在の高密度メディア (最大 62,182 ftpi) に適していません。 - 現在のテープドライブの容量を有効に利用するため、 - これらのデフォルト値をコマンドラインで必ず置き換える必要があります。 - - rhosts - また、rdump と rrestore を用いると、 - 他のコンピュータに接続されたテープドライブを使い、 - ネットワーク経由でデータをバックアップすることも可能です。 - どちらのプログラムもリモートテープドライブにアクセスするために - rcmd と ruserok に依存しています。 - このためユーザがバックアップを実行するためには - rhosts によるリモートアクセスが必要です。 - rdump と rrestore - の引数はリモートコンピュータに適切なものを用います。 - (例えば - FreeBSD コンピュータより komodo という名前の - Sun に接続されている Exabyte テープドライブへ - /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 - /dev/rda0a 2>&1 として - rdumpしたような場合の restore に使います) - 警告: セキュリティは - rhosts の管理にかかっています。 - あなたの状況を注意深く調べてください。 - - ssh を用いると - rdump と rrestore - をより安全な形で利用することができます。 - - - <application>ssh</application> 経由で <command>rdump</command> を使う - - &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh1 -c blowfish \ - targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz - - - - - - <command>tar</command> - - - バックアッププログラム (backup software) - tar - - tar AT&T Unix のバージョン 6 (1975 ごろ) - にさかのぼる事ができます。tar - はファイルシステムと協調して機能し、 - ファイルやディレクトリをテープに書きます。tar は - &man.cpio.1; - で使えるようなフルレンジのオプションは持ちませんが - cpio - で使うような奇妙なコマンドパイプラインは必要ありません。 - - tar - 大部分の tar - にはネットワーク経由のバックアップの機能はありませんが、 - FreeBSD で使用されている GNU の tar は、 - rdump - とおなじ構文でリモートデバイスを扱うことができます。 - komodo - というホスト名の Sun に繋いである Exabyte - のテープデバイスに対して tar を実行するには、 - 次のようにします。 - /usr/bin/tar cf komodo:/dev/nrsa8 。 - 2>&1 リモートデバイスをサポートしていない tar - を使用している場合は、パイプラインと rsh を使うことで、 - リモートテープデバイスにデータを送る事ができます。 - - - &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b - - もしあなたがネットワークを越えるバックアップのセキュリティに - 困っているなら &man.rsh.1; の代わりに &man.ssh.1; を使うべきです。 - - - - <command>cpio</command> - - - バックアッププログラム (backup software) - cpio - - &man.cpio.1; は本来、Unix - ファイルを磁気メディアで交換するためのプログラムです。 - cpio はバイトスワッピング、 - 多くの異なるアーカイブフォーマットの書き込みのオプション - (それ以外にも多数のオプションがあります) があり、 - パイプで他のプログラムにデータを渡す事もできます。 - この最後に挙げた特徴により、cpio - はインストールメディアについては優れた選択です。cpio - は stdin からの入力でなければならず、 - ディレクトリツリーの探索や - ファイルリストについての機能はありません。 - - cpio - &man.cpio.1; - はネットワーク経由のバックアップの機能はありません。 - リモートテープドライブにはパイプラインと &man.rsh.1; - を使って送る事ができます。 - - &prompt.root; for f in directory_list; do -find $f >> backup.list -done -&prompt.root; cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device" - - directory_list - にはバックアップしたいディレクトリのリスト、 - user@host - にはバックアップを実行するユーザ/ホスト名の組合せ、 - backup_device には - バックアップ内容を保存する場所 - (たとえば /dev/nrsa0) を指定します。 - - - - <command>pax</command> - - - バックアッププログラム (backup software) - pax - - pax - POSIX - IEEE - &man.pax.1; は tar と - cpio に対する IEEE/POSIX の回答です。 - 長年の間、様々なバージョンの tar や - cpio は、 - 互いにわずかながら非互換性を有していました。 - 各々をしらみ潰しに標準化する代わりに、POSIX - は新しいアーカイブユーティリティを作ることにしました。 - pax - は専用に開発された新しいフォーマットに加えて、いくつもの cpio - や tar のフォーマットの読み書きに対応しようと試みています。 - コマンド群は tar よりも - cpio の方にいくぶん似ています。 - - - - <application>Amanda</application> - - - バックアッププログラム (backup software) - Amanda - - Amanda - - - Amanda (Advanced Maryland Network Disk Archiver) - は単一のプログラムではなくクライアント / - サーバ型のバックアップシステムです。Amanda サーバは、Amanda - クライアントであるネットワークで - サーバに接続された複数のコンピュータから - 一つのテープドライブへバックアップをおこないます。 - このような場合の一般的な問題はいくつもの大容量の - ディスクからデータディレクトリをテープにバックアップするには - 時間がかかりすぎてしまうという事です。Amanda - はこの問題を解決します。Amanda - は同時に複数のファイルシステムのバックアップをおこなう時に - 「ホールディングディスク」を使う事ができます。 - Amanda の設定ファイルに書いたすべてのファイルシステムの - フルバックアップを特定の間隔でとるために「アーカイブセット」 - と呼ばれるテープグループを作ります。 - これには夜間に作られるすべてのファイルシステムの増分 - (あるいは差分として) のバックアップも含みます。 - 障害の起きたファイルシステムの回復には最も新しい - フルバックアップと増分のバックアップが必要です。 - - 設定ファイルでバックアップのコントロールと Amanda - によるネットワークトラフィック量を設定します。Amanda - はデータをテープに書くのにバックアッププログラムの - いずれかを使うでしょう。Amanda - はその一部分でもパッケージでも利用可能ですが、 - デフォルトではインストールされません。 - - - - 何もしない - - 何もしない - というのはコンピュータのプログラムではありませんが、 - バックアップの戦略として最も広く採用されている物です。 - これには初期投資が必要ありません。 - したがわなければならないバックアップスケジュールもありません。 - ただ何もしないだけです。もしデータに何かが起きたら、 - 苦笑いして耐えてください。 - - あなたにとって時間やデータの価値が少ないか - あるいはまったくないのであれば 何もしない - のはあなたのコンピュータに最も適した - バックアッププログラムでしょう。しかし注意してください。Unix - は便利なツールです。6 ヶ月も使っていれば価値のあるファイルの - 山ができ上がっているでしょう。 - - 何もしないこと は - /usr/obj など、 - コンピュータが同じものをもう一度作り直すことのできる - ディレクトリツリーに対して適した方法です。 - 一つの例として、このハンドブックの HTML 版、PostScript - 版を構成するファイルが考えられます。 - これらは両方とも SGML ファイルから生成されたものなので、 - HTML 版と PostScript 版のバックアップをとる必要はありません。 - 一方、SGML ファイルは定期的にバックアップが行なわれています。 - - - - どのバックアッププログラムが最適でしょう? - - - LISA - - - 定期的に dump しましょう。 - Elizabeth D. Zwicky はここで検討したプログラムすべてについて - 拷問的なテストをおこないました。すべてのデータと - Unixファイルシステムの状態すべてを保存するには明らかに - &man.dump.8; でしょう。Elizabeth - は大きく変化に富んだ異常な状態 - (いくつかはあまり異常でもない状態のものもあります) - になっているファイルシステムで、 - それぞれのプログラムでファイルシステムの - バックアップとリストアを行ってテストしました。 - 特色のある状態には、ホールを持つファイル、 - ホールとヌルブロックを持つファイル、 - 奇妙な文字をファイル名に持つファイル、読み出し不可、 - 書き込み不可のファイル、デバイスファイル、 - バックアップ中にファイルのサイズを変更する、 - バックアップ中にファイルの作成/削除をおこなうなどがあります。 - 彼女は 1991 年 10 月の LISA V で結果の発表をしています。torture-testing Backup and Archive Programs を参照してください。 - - - - 緊急時のリストア手順 - - - 災難の起きる前に - - 起き得るどのような災難に対しても以下の - 4 ステップだけが必要な準備です。 - - - disklabel - - - ステップ 1 では、 - ファイルシステムテーブル (/etc/fstab) - や起動メッセージで示されるすべてのディスクの - disklabel をそれぞれ 2 コピーづつプリント (例えば - disklabel da0 | lpr を実行します) - します。 - - fix-it floppies - - ステップ 2 では、boot.flp と - fixit.flp - にそのシステムのすべてのデバイスドライバが - 含まれているか確認します。最も簡単な確認の方法は、 - フロッピディスクをドライブに入れて再起動し、 - 起動メッセージを確認することです。 - あなたのシステムのデバイスがすべて含まれ、機能していれば、 - step 3 へ飛んでください。 - - そうでないなら、 - そのシステムのすべてのディスクをマウントでき、 - テープドライブにもアクセスできる - 2 種類のカスタム起動フロッピディスクを作る必要があります。 - これらのフロッピディスクには fdisk、disklabel、 - newfs、mount、 - と利用したいバックアッププログラムが - 入っていなければなりません。 - これらのプログラムはスタティックリンクされた - プログラムである必要があります。dump - を使うのであればフロッピディスクに restore - を入れる必要があります。 - - ステップ 3 では、通常の方法でバックアップを作ります。 - 最新のバックアップの後でおこなわれた変更は - 回復することはできません。 - バックアップテープにライトプロテクトをしてください。 - - ステップ 4 では、フロッピディスク - (boot.flp と - fixit.flp あるいはステップ - 2 で作った 2 枚のカスタム起動フロッピディスクです) - とバックアップテープのテストをします。 - 手順のノートを作りましょう。 - このノートは起動フロッピディスク、 - バックアップテープに入れておきプリントアウトしておきます。 - あなたがリストアをおこなうような時は - おそらく錯乱状態でしょうからこのノートはバックアップを - 破壊してしまうようなことを防ぐのに役立つでしょう - (どのようにして破壊するって? tar xvf - /dev/rsa0 とするかわりに偶然 tar cvf - /dev/rsa0 - とタイプしてバックアップテープに上書きしてしまうかも - しれません)。 - - 訳注: 上書きはライトプロテクトをしておけば防げますが、 - なんらかの原因でプロテクトがはずれているかもしれません。 - ちなみに訳者の経験から言えば上のようなミスタイプは - 結構起きます。 - - 安全性を増すために、 - 毎回起動フロッピディスクを作り、2 - 巻のバックアップテープを取ります。 - 一方を離れた場所に保管します。 - 離れた場所は同じ建物の地下室ではいけません。 - 世界貿易センタービルにあった数多くの会社は - 苦い経験よりこの教訓を得ました。 - 離れた場所とはコンピュータやディスクドライブから - かなり離れていて物理的に分離されていなければなりません。 - - - 起動フロッピディスクを作るスクリプトの一例 - - /mnt/sbin/init -gzip -c -best /sbin/fsck > /mnt/sbin/fsck -gzip -c -best /sbin/mount > /mnt/sbin/mount -gzip -c -best /sbin/halt > /mnt/sbin/halt -gzip -c -best /sbin/restore > /mnt/sbin/restore - -gzip -c -best /bin/sh > /mnt/bin/sh -gzip -c -best /bin/sync > /mnt/bin/sync - -cp /root/.profile /mnt/root - -cp -f /dev/MAKEDEV /mnt/dev -chmod 755 /mnt/dev/MAKEDEV - -chmod 500 /mnt/sbin/init -chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt -chmod 555 /mnt/bin/sh /mnt/bin/sync -chmod 6555 /mnt/sbin/restore - -# -# create the devices nodes デバイスノードを作る -# -cd /mnt/dev -./MAKEDEV std -./MAKEDEV sd0 -./MAKEDEV sd1 -./MAKEDEV sd2 -./MAKEDEV st0 -./MAKEDEV pty0 -cd / - -# -# create minimum filesystem table 最小限のファイルシステムテーブル -# -cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < - - - - - - 災難の後に - - 重要な問題は、ハードウェアが生き残ったかどうかです。 - 定期的なバックアップを取っていれば - ソフトウェアについて心配する必要はありません。 - - ハードウェアがダメージを受けていたら、 - 最初にそのダメージを受けた部品を交換してください。 - - ハードウェアに問題がなければ、 - フロッピディスクをチェックしてください。 - カスタム起動フロッピディスクを使っているのであれば - シングルユーザ(boot: プロンプトの出た時に - -s とタイプしてください) - で起動してください。それから次の - 「ファイルシステムを 1 つずつ回復する」 - を読んでください。 - - boot.flp と - fixit.flp - を使っているのであればこのまま読み続けてください。 - boot.flp を入れて起動してください。 - 本来のインストールメニューが表示されるはずです。(ここで) - Fixit--Repair mode with CDROM or - floppy. オプションを選びます。指示の通り - fixit.flp を入れてください。 - restore とその他の必要なプログラムは - /mnt2/stand に置かれています。 - - ファイルシステムを一つずつ回復する - - - mount - - root partition - - disklabel - - - newfs - - 最初のディスクの root パーティションを mount - (例えば mount /dev/da0a /mnt のように) - マウントしてみてください。 - ディスクラベルが破壊されている場合は disklabel - を使ってあらかじめプリントしておいた通りに - パーティションを作り直しラベルをつけてセーブしてください。 - newfs を使いファイルシステムを作り直します。 - ルートパーティションを読み書き可能にマウント (mount - -u -o rw /mnt) しなおします。 - バックアッププログラムとバックアップテープを使って - このファイルシステムのデータを回復します (例えば - restore vrf /dev/sa0 とします)。 - ファイルシステムをアンマウント (umount - /mnt など) して、 - 障害を受けたファイルシステムそれぞれについて - 繰り返してください。 - - システムが動き出したら、 - 新しいテープにデータをバックアップしてください。 - どのような理由で再び事故が起きたりデータが - 失われるかはわかりません。これに時間を費す事で、 - 後々の災難から救われる事になります。 - - - - * 災難対策をしていませんでした。 - どうしたらいいでしょう? - - - -]]> - - - - - - フロッピディスクへのバックアップはどうですか? - - - データをフロッピディスクにバックアップすることはできますか? - backup floppies - floppy disks - - 実はフロッピディスクはバックアップ向きのメディアとは言えません。 - というのは: - - - - 特に長期間に渡って保存する場合、信頼性が低い。 - - - - バックアップ、リストアがとても遅い。 - - - - 容量が小さい (ハードディスク全体の日々のバックアップに - 1 ダース、長期間なら本当にたくさん)。 - - - - けれども、データをバックアップする他の手段がない場合には、 - まったくバックアップをしないよりもフロッピディスクを使うほうが良い - でしょう。 - - これを行う場合には、高品質のものを使うようにしてください。 - まわりに何年も転がっていたフロッピディスクは使わない方よいでしょう。 - 評判のよいメーカの新品を使うことが理想です。 - - - - どうやってデータをフロッピディスクにバックアップ - するのですか? - - フロッピディスクへバックアップする最も良い方法は tar - tar コマンドに (マルチ・ボリューム) - オプションを付けて、複数のフロッピディスクにまたがるバックアップも - できるようにする方法です。 - - カレントディレクトリのすべてのファイルとサブディレクトリを - バックアップするには、以下のようにします (root で): - - &prompt.root; tar Mcvf /dev/fd0 * - - 1 枚目のフロッピディスクがいっぱいになると tar は - 次のボリュームを入れるようプロンプトを表示します。 - ( tar は、さまざまなメディアを扱えるので - ボリュームと表示します。ここではフロッピディスクのことです) - - Prepare volume #2 for /dev/fd0 and hit return: - - これは (ボリューム番号が増えながら) 指定されたすべてのファイルが - 保存されるまで繰り返されます。 - - - - バックアップを圧縮することはできませんか? - - tar - - - gzip - - 圧縮 - - 残念ながら、tar はマルチ・ボリュームに保存する場合は - オプションを使うことができません。 - もちろん、すべてのファイルを gzip してから、フロッピディスクに - tar して、ファイルを gunzip - することはできます! - - - - リストアはどうしますか? - - 保存したファイルすべてをリストアするには: - - &prompt.root; tar Mxvf /dev/fd0 - - 特定のファイルのみをリストアする方法は二つあります。 - まず、一枚目のフロッピディスクを挿入して次のようにします。 - - &prompt.root; tar Mxvf /dev/fd0 filename - - tar は、必要なファイルを見つけるまで、続きのフロッピディスクを - セットするよう表示します。 - - 別の方法として、どのフロッピディスクにファイルが入っているのかが - 分かっているなら、そのフロッピディスクを挿入して上記と同じコマンドを - 使うこともできます。最初のファイルが前のフロッピディスクから続いて - いる場合は、tar は、頼みもしないのに、そのファイルはリストア - できないと警告します! - - - diff --git a/ja_JP.eucJP/books/handbook/contrib/Makefile b/ja_JP.eucJP/books/handbook/contrib/Makefile deleted file mode 100644 index df55e98af7..0000000000 --- a/ja_JP.eucJP/books/handbook/contrib/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= contrib/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/contrib/chapter.sgml b/ja_JP.eucJP/books/handbook/contrib/chapter.sgml deleted file mode 100644 index d124eeb050..0000000000 --- a/ja_JP.eucJP/books/handbook/contrib/chapter.sgml +++ /dev/null @@ -1,688 +0,0 @@ - - - - - - - - Jordan - Hubbard - 寄稿: - - - - - FreeBSD への貢献 - - - - 貢献 - あなたも何か FreeBSD のために貢献したくなりましたか? - 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD - は生き残るためにユーザベースの貢献に頼るようなシステムの一つです. - あなたの貢献は感謝されるだけではなく, FreeBSD - が成長し続けるために極めて重要なものな のです! - - 一部の人達が言っているのとは逆に, - 貢献を受け付けてもらうために腕利 きのプログラマーになるとか - FreeBSD コアチームの人と親友になる必要はありません. FreeBSD - プロジェクトの開発は, - 多くのそして益々増加する世界中の貢献者達によってなされており, 彼らの年齢, - 専門技術分野は多岐に渡ります. - そして手の空いている人よりも成されるべき仕事の方が常に多いのです. - - FreeBSD - プロジェクトがカーネルや散在しているユーティリティよりも, - オペレーティングシステム環境 (と, そのインストール) - に対して責任を持つ ようになったため, - 私たちの TODO リストはドキュメンテーション, - ベータテスト, - 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に広い範囲のタスクに渡ります. - あなたの技能レベルに関わらず, - プロジェクトを支援できることが必ず何かあります! - - FreeBSD - 関連の事業に従事している商業団体が私たちにコンタクトすることも歓迎します. - あなたの製品を (FreeBSD 上で) 動作させるには, - 特別な拡張が必要ではありませんか? - あまりにも風変わりな要求でなければ, - それを受け入れる用意が私たちにあるとわかるはずです. - 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, - ある面において共同して作業をすることができるでしょう. - フリーソフトウェア界は, - ソフトウェアがそのライフサイクルを通してどのように開発され, - 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. - 少なくとももう一度考慮してみることを私たちは強くお奨めします. - - - 何が必要? - - 次のタスクとサブプロジェクトのリストは, コアチームの色々な - TODO - リストと最近2ヶ月で集めたユーザリクエストを合わせたものです. - 可能なところでは, 緊急度によってタスクがランクづけされています. - もしここにあるタスクの実行に興味があるのでしたら, - コーディネータの名前をクリックしてメールを送ってください. - もしコーディネータが決まっていなければ, - あなたがボランティアしてみませんか? - - - 進行中のタスク - - 次のタスクはやっておくべきではありますが, - 特にさし迫っているわけではありません: - - - - 完全な KLD ベースのドライバのサポート / - コンフィグレーションマネージャ. - - - - 穏やかな方法でハードウェアを検知するコンフィグレーションマネージャの作成 - (第3ステージ・ブートの中に?). ハードウェアが必要とする - KLD だけを残す等. - - - - - - PCMCIA/PCCARD. コーディネータ: &a.msmith; と &a.imp; - - - - ドキュメンテーション! - - - - pcic ドライバの信頼性のある操作 (テスト要). - - - - sio.c - のリコグナイザとハンドラ (ほぼ完了). - - - - ed.c のリコグナイザとハンドラ - (ほぼ完了). - - - - ep.c のリコグナイザとハンドラ - (ほぼ完了). - - - - User-mode のリコグナイザとハンドラ - (部分的に完了). - - - - - - 先進的なパワーマネージメント. コーディネータ: &a.nate; - と &a.phk; - - - - APM サブドライバ (ほぼ完了). - - - - IDE/ATA ディスクサブドライバ (部分的に完了). - - - - syscons/pcvt サブドライバ. - - - - PCMCIA/PCCARD ドライバ群との統合 (サスペンド / - レジューム). - - - - - - - - 優先度の低いタスク - - 次のタスクは全くのあら隠し, - または誰もすぐにおこないそうもない投資のような仕事を表します: - - 最初の N 項目は Terry Lambert - terry@lambert.org からのものです. - - - - ネットワークカードと一緒に提供される ODI - カードドライバを使用できるようにする, NetWare サーバ - (プロテクトモードの ODI ドライバ) ローダとサブサービス. - NDIS ドライバと NetWare の SCSI ドライバについても同様. - - - - 前のリビジョンの FreeBSD マシンではなく, Linux - マシンで動作する 「アップグレードシステム」オプション. - - - - カーネルのマルチスレッド化 - (カーネルのプリエンプションが必要). - - - - カーネルのプリエンプション付き対称マルチプロセッシング - (カーネルのプリエンプションが必要). - - - - ポータブルコンピュータのサポートにおける協調の試み. - これは PCMCIA - ブリッジング規則と電源管理イベント処理の変更により, - いくらかは処理できます. しかし, - 内蔵ディスプレイと外部ディスプレイの検出, この 2 - 種類のディスプレイがあるという事実に基づく異なる解像度の選択, - マシンがドックにある場合にはディスクのモータ停止を防止すること, - マシンのブート能力に影響を与えずにドックベースのカードの消滅を可能にすること - (PCMCIA と同じ問題) などの問題があります. - - - - - - もっと簡単なタスク - - 上のセクションで挙げたタスクは膨大な時間の投資または - FreeBSD のカーネルに関する深い知識を必要とします - (もしくはそのどちらも). しかしながら, - "週末ハッカー"やプログラミングのスキルを持たない人々に適した立派なタスクも数多くあります. - - - - FreeBSD-current を運用しており, - 状態の良いインターネット接続があるならば, current.FreeBSD.org - という一日に一回フルリリースを行っているマシンがあります - — 時おり最新のリリースをそこからインストールし, - その過程で何か問題があるなら報告して下さい. - - - - freebsd-bugs - メーリングリストを読んでください. - そこではあなたが建設的なコメントを付けたりテストできるパッチが提供されているような問題がある かもしれません. - もしくはそれらの問題の一つをあなた自身で修正することさえできるかもしれません. - - - - 定期的に FAQ とハンドブックを通して読んでみてください. - もしまずい説明や古い事柄や完全に間違っていることなどがあれば我々に知らせて下さい. - さらに良いのは我々に修正案を送ることです (SGML - は学ぶのにそれほど難しくありませんが, - プレインテキストでも問題はありません). - - - - (もしまだないならば) FreeBSD - のドキュメントを自分の母国語に翻訳するのを手伝ってください — - 作業している人がいるかどうか &a.doc; にメールを送って聞くだけです. - とはいっても, - そうすることによってあなたが全ての FreeBSD - ドキュメントの翻訳に携わるようになるというわけではないですからね - — 実際, - もっとも翻訳が必要とされているドキュメントはインストール方法です. - - - - たまに(もしくは定期的に) freebsd-questions - メーリングリストや - - comp.unix.bsd.freebsd.misc - を読んでください. これは, - あなたの持っている専門知識を共有したり誰かが抱えている問題を解決するのに非常に有効なものになり得ることです. - 時にはあなた自身で新しいことを学ぶことさえできるかもしれません. - これらのフォーラムはやるべきことのアイディアの源にもなり得るのです. - - - - -current に正しく当てられるがしばらく経っても(通常は - 2, 3 週間) -stable - に取り込まれてないようなバグフィックスがあるならばコミッターに丁寧に思い出させてください. - - - - 寄贈ソフトウェアをソースツリーの - src/contrib - に移動させてください. - - - - src/contrib - 以下のコードが最新のものであるか確認してください. - - - - 警告を詳細に報告するようにして - ソースツリー全体(もしくはその一部)を構築してみてください. - そして警告が出ないようにしてください. - - - - ports で, gets() を使っているとか malloc.h - をインクルードしているなどといった警告が出ないようにしてください. - - - - もしなんらかの ports に関わっているなら, - あなたのパッチを作者にフィードバックしてください - (次のバージョンが出た時にあなたが楽になります). - - - - このリストに追加するタスクを提案して下さい! - - - - - - 障害報告 (PR; Problem Report) データベースにおける作業 - - 障害報告 (PR) データベース - - - FreeBSD 障害報告リストでは, 現在問題となっている報告と, - FreeBSD の利用者によって提出された改良の要望に関する全てのリストを公開しています. - open 状態の障害情報を見て, 興味を引く内容かどうか確かめて下さい. - 本当に複雑なものも含まれているでしょうし, - 例えば, 障害報告に対する修正がちゃんとしたものであるかどうか単にチェックするだけのとても簡単な作業もあるでしょう. - - まず, まだ誰にも割り当てられていない障害報告から作業を始めて下さい. - もし, 誰か他の人に割り当てが決まっているけれども自分が作業可能だ, - というものがあれば, 作業ができるかどうか — - 既にテスト用パッチが用意されているのかどうか, あるいは - その問題についてあなたが考えている, - より進んだ考えに関して議論ができるかどうか, - 割り当てられている人に電子メールで問い合わせて下さい. - - - - - - - 貢献の仕方 - - 一般的に, システムへの貢献は次の 6 - つのカテゴリの1つ以上に分類されます: - - - バグ報告と一般的な論評 - - 報告するべきバグがあったり, 提案したいことがあれば: - - 一般的な - 技術的関心事に関するアイデアや提案は &a.hackers; - へメールしてください. 同様に, このような事柄に興味のある - (そして膨大なメール! に耐えられる) 人は, - &a.majordomo; へメールを送って hackers - メーリングリストに参加すると良いでしょう. 情報については - メーリングリスト - を参照してください. - - バグを発見したり変更を送付しようとしている場合は - &man.send-pr.1; プログラムか ウェブベースの - send-pr を使用して報告してください. - バグレポートの各項目を埋めるようにしてください. 65KB - を超えるのでなければ, - レポート中に直接パッチを入れてくださって結構です. - パッチがソースツリーにすぐ適用できるものならば, - 報告の概要に [PATCH] と書いておいてください. - その場合, カット＆ペーストはしないでください. - カット＆ペーストではタブがスペースに展開されてパッチが使い物にならなくなってしまいます. - 20KB を超える場合は, - それらを compress して &man.uuencode.1; - することも検討してください. とても大きくなる場合は ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/ - を利用してください. - - - レポートがファイリングされれば, - バグ報告の確認とトラッキング番号をメールで受け取るはずです. - このトラッキング番号を覚えておき, 問題に関する詳細情報を - bug-followup@FreeBSD.org に - メールで送って更新できるようにしてください. 例えば - "Re: kern/3377" のように, - この番号をサブジェクト行に使用してください. - すべてのバグレポートの追加情報は, - この方法で送付されなければいけません. - - もしタイムリに (あなたの電子メール接続形態にもよりますが, - 3日から 1週間) 確認を受けとれないとか, 何らかの理由で - &man.send-pr.1; コマンドが使用できない場合には, &a.bugs; - へメールを送り, - 誰か代りにバグ報告を送付してもらうようたずねてください. - - - - 文書の変更 - - 文書に関する提案 - - 文書の変更は &a.doc; が監督しています. バグ報告と一般的な論評 - に記述されているように send-pr - コマンドを使用して, 提案や変更 - (どんな些細なものでも歓迎します!) を送ってください. - - - - 現存のソースコードの変更 - - FreeBSD-current - - 現存のソースコードへの追加または変更は, - いくらかトリッキーな仕事で あり, core の FreeBSD - 開発の現状にあなたがどれだけ通じているかに大きく依存します. - FreeBSD-currentとして知られる FreeBSD - の特別な継続的リリースがあります. FreeBSD-current - は開発者の積極的な活動の便宜のために, - 色々な方法で利用可能になっています. FreeBSD-current - の入手と使用方法についての詳しい情報については最新の FreeBSD を追いかける - を参照してください. - - 不幸にして古いソースをもとに仕事をすることは, - 時々あなたの変更が時 代遅れ, または FreeBSD - への簡単な再統合に合わなくなっていることを意味します. - システムの現状に関する議論がおこなわれている &a.announce; と - &a.current; へ参加することで, - この可能性を最小限にすることができます. - - 完全な最新のソースを変更のベースにできることが確実になったと仮定して, - 次のステップは FreeBSD - の保守担当者へ送る差分ファイルの生成です. これは &man.diff.1; - コマンドを使用しておこないますが, context - diff形式が好まれるようです. 例えば: - - - diff - - &prompt.user; diff -c oldfile newfile - - または - - &prompt.user; diff -c -r olddir newdir - - これで指定されたソースファイルまたはディレクトリ階層に対するコンテキスト形式の差分が生成されます. - 詳しい説明は - &man.diff.1; のマ ニュアルページを参照してください. - - 差分ファイル (&man.patch.1; コマンドでテストできます) - を作ったら, それらを FreeBSD - に含めてもらうようメールで送ってください. バグ報告と一般的な論評 - に記述されているように &man.send-pr.1; - コマンドを使用してください. 差分ファイルだけを &a.hackers; - へ送ってはいけません. 途方にくれてしまいます! - 私たちは多忙なので, あなたの提案に大変感謝します - (これはボランティアのプロジェクトです!). - すぐに取りかかることはできませんが, 処理されるまではちゃんと - PR データベースに残っています. - 報告の概要に [PATCH] - と書いてあなたの提案を表明してください. - - - - uuencode - - あなたがそうした方がいいと思う場合 (例えば, - ファイルの追加, 削除または名称変更など), 変更を - tar ファイルにまとめ, &man.uuencode.1; - プログラムにかけてください. shar - アーカイブも歓迎します. - - 例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良く分かっていないとか, - 単に厳しいレビューをおこなっておらず, - リリースする準備ができていないなど, - あなたの変更が潜在的に不安定な性質をも つものである場合, - &man.send-pr.1; で送付するよりむしろ &a.core; - へ直接送ってください. コアチームメーリングリスト宛のメールは, - 日々の仕事のほとんどを FreeBSD でおこなっている人たちの, - より小さなグルー プに届きます. - このグループもまたとても忙しいことに注意して, - 本当に必要な場合にコアチームの彼らにメールを送るだけにしてください. - - コーディングスタイルに関する情報は - &man.intro.9; および &man.style.9; - を参照してください. コードを提出する前には, - 少なくともこの情報を意識しておいてくださるようお願いします. - - - - - 新たなコードやメジャーな付加価値の高いパッケージ - - 重要な大きい仕事の寄贈や, 重要な新しい機能を - FreeBSD に追加する場合には, 変更点を tar/uuencode - したファイルにして送るか, それらを web や FTP - サイトへアップロードしてアクセスできるようにすることのどちらかが通常必要になります. - web や FTP サイトへのアクセスができないときは適切な FreeBSD - のメーリングリストで誰かに変更を受け取って貰ってください. - - 大量のコードを伴った仕事の場合, - コピーライトの神経過敏な問題が常に出てきます. FreeBSD - に含めるコードのコピーライトとして受け入れることができるのは, - 以下の二つです: - - - BSD copyright - - BSD コピーライト. - このコピーライトは権利に縛られない性格と商用企業にとって一般的な魅力をもつために最も好まれます. - FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを - FreeBSD - へ投資する気になった商業関係者による参加を積極的に奨励します. - - - GPLGNU General Public License - GNU General Public License - - GNU一般公有使用許諾, またはGPL. - このライセンスはコードを商用目的に使用する場合に余分な努力が求められるため, - 私たちにあまり評判が良いというわけではありません. しかし, - 私たちは既に GPL 下の高品質なコード (コンパイラ, - アセンブラ, テキストフォーマッタ等) の提供を受けており, - 私たちは現在それを必要としています. そのため, - このライセンスによる新たな貢献を拒絶するというのは愚かなことでしょう. GPL - 下のコードはソースツリー の別の部分, 現在のところ - /sys/gnu か - /usr/src/gnu に入っています. - そのため, GPL が問題となるような人は, - 誰でも簡単にそれとわかるようになっています. - - - - これ以外のタイプのコピーライトによる寄贈は, FreeBSD - へ含めることを考慮する前に, - 注意深いレビューを受けなければなりません. - 作者が独自のチャネルを通して配布しており, - そのような変更をおこなうことを常に奨励している場合でも, - 特に限定的な商用のコピーライトが適用される寄贈は一般に拒否されます. - - あなたの作品に BSD- - スタイルのコピーライトを付けるには, - 保護したいソースコードファイルすべての一番最初に以下のテキストを入れて, - %% - の間を適切な情報に置き換えください. - - Copyright (c) %%適切な年%% - %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. - All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions -are met: -1. Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer as - the first lines of this file unmodified. -2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - -THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR -IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES -OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. -IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, -INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT -NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF -THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - $Id$ - - 便宜をはかるため, - このテキストのコピーは次の場所に置いてあります. - /usr/share/examples/etc/bsd-style-copyright. - - - (訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright - の日本語訳です. - ソースファイルに含めるものは原文の方であることに注意してご利用ください. - また, 原文との間に趣旨の差異が生じた場合, - 原文の内容が FreeBSD プロジェクトの意思であるものとします.) - - -Copyright (C) [年] - [あなたの名前] All rights reserved. - -ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の -条件を満たす場合に限り許可される: -1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の - 否認声明文を保持しなければならない. - -2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の - 否認声明文を, 配布物と共に提供される文書および/または他の資料の中に - 含めなければならない. - -(訳注:ここから「否認声明文」です) - -このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' -で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま -らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献 -者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 -替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 -中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし -て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ -生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過 -失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も, -たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た -ない. - -翻訳: 神田敏広 -御協力 (五十音順・敬称略): - 池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう - 杢野 雅一, 横田＠宇都宮 - - - - - 金銭, ハードウェアまたはインターネットアクセス - - FreeBSD プロジェクトの目的を進めるための寄付や, - 私たちと同じような ボランティアの細く長い!努力を, - 私たちは常に喜んで受け入れています. - また一般的に私たちは自分達で周辺機器を買う資金が不足しているため, - 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です. - - - 資金の寄付 - - FreeBSD財団は, FreeBSD - プロジェクトの目標を推進するために確立された非営利的で税金を免除された財団です. - 501(c)3 の実体として, 財団はコロラド州所得税ならびに, - アメリカ連邦主義者所得税を一般に免除されています. - 免税実体への寄付は, - しばしば有税の連邦政府の所得から差し引くことができます. - - 寄付は以下に送ってください. -
- The FreeBSD Foundation - 7321 Brockway Dr. - Boulder, CO 80303 - USA -
- 財団はまだクレジットカード, - およびPayPalといった他の形式の支払いを受け入れることができません. - - FreeBSD 財団に関するこれ以上の情報は - The - FreeBSD Foundation -- an Introduction を見てください. - 財団への email での連絡は - bod@FreeBSDFoundation.org - へどうぞ. - - - - ハードウェアの寄贈 - - 寄贈 - - FreeBSD プロジェクトは, - 次の3つのカテゴリのどんなハードウェアの寄贈も, - 喜んで受け付けます: - - - - ディスクドライブ, - メモリまたは完全なシステムといった一般用途のハードウェアは, - 資金の寄付の節にある - FreeBSD, Inc. の住所まで送っ てください. - - - - 進行中の受け入れテストのためのハードウェアが必要とされています. - 新たなリリース毎に適切な逆行テストができるように, - 私たちは現在, FreeBSD - がサポートするすべてのコンポーネントのテストラボを設置しよう としています. - 私たちにはまだ, - たくさんの重要な部品 (ネットワークカード, - マザーボードなど) が不足していますので, - このような寄贈をしたいと思っているならば, &a.dg; - へコンタクトしてどの部品がまだ必要とされているかの情報を得てください. - - - - 現在 FreeBSD にサポートされていないハードウェアで, - サポートに追加して欲しいもの. - 私たちが新しいハードウェアを受けとる前にそのタスクを引き受けてくれる開発者を探す必要があるため, - その部品を送る前に &a.core; - にコンタクトを取ってください. - - - - - - インターネットアクセスの寄付 - - 私たちは常に FTP, WWW や cvsup - の新しいミラーサイトを募集しています. - ミラーサイトになりたい場合には &a.hubs; - にコンタクトを取って, 詳しい情報を手に入れてください. - - - - - diff --git a/ja_JP.eucJP/books/handbook/hw/chapter.sgml b/ja_JP.eucJP/books/handbook/hw/chapter.sgml deleted file mode 100644 index 30dfc2989f..0000000000 --- a/ja_JP.eucJP/books/handbook/hw/chapter.sgml +++ /dev/null @@ -1,6638 +0,0 @@ - - - - - PC ハードウェアコンパチビリティ - - 訳: &a.jp.yoshiaki;, 1998 年 3 月 23 日. - - ハードウェアコンパチビリティの問題は現在の - コンピュータ業界でもっとも多く起きる種類の問題であり, - FreeBSDもこれに無縁ではありません. - 安価に普及している PC ハードウェアで動かすことができるという - FreeBSDの利点は, 市場にある驚くほど多様な種類の製品の - サポートの義務というマイナス点でもあります. - FreeBSDのサポートするハードウェアを徹底的に調べて提供することは不 - 可能ですが, このセクションでは - FreeBSDに含まれるデバイスドライバとそ - のドライバがサポートするハードウェアのカタログを示します. - 可能で適切 なものについては特定の製品についての注釈を含めました. - また, このハンドブックの コンフィグレーション - ファイル のセクションにも - サポートされているデバイスのリストがありますので - そちらもご覧ください. - - FreeBSD - はボランティアプロジェクトでテスト部門には資金がありません から, - より多くの情報をこのカタログに載せるにはあなたがたユーザに - 頼らなければなりません. あなた自身の経験により, - あるハードウェアが - FreeBSDで動くか動かないかがわかったとしたら&a.doc; へ - e-mailして知らせてください. サポートされているハードウェアについて - の質問は, &a.questions;(詳しいことは メーリングリスト - を参照してください) へ 宛ててください. - 情報を提供したり質問をする時は FreeBSDのバージョンと使っ - ているハードウェアのできるだけ詳しい情報を含めることを - 忘れないでください. - - - インターネット上のリソース - - 以下のリンクはハードウェアを選ぶのに役に立ちます. - FreeBSDに対して は必要のない (あるいは適用できない) - ように見えるかもしれませんが, ここ - からのハードウェアの情報のほとんどは OSに依存しないものです. - 購入をする前にはあなたの選んだものがサポートされているか - FreeBSDハード ウェアガイドを注意して読んでください. - - - - Toms's Hardware & Performance Guide - - - - 訳注: 日本国内でFreeBSDの動くハードウェアの情報を提供してい - るWWWサーバがあります. - - - - FreeBSD POWERED hardwares - - - - これ以外にも情報を提供しているサーバはあります. いくつかの - URLについて はFreeBSD - Japan. からたどることができます. - - - - 組合せの見本 - - 以下のハードウェアの組合せのサンプルリストは - ハードウェアベンダや FreeBSD - プロジェクトが保証するものではありません. この情 - 報は公共の利益のために公開しているものであり, - 極めて数多くあるであろう - 異なったハードウェアの組合せの中からのある経験の - カタログに過ぎません. やり方はいろいろあります. - 場合によってはうまく行かないこともあります. - 十分気をつけてください. - - - Jordan氏の選んだ組合せ - - 私の作ったワークステーションとサーバの構成は - まずまずうまく行っ ています. - 私はこれを保証できるわけでもありませんし, ここにあげた組 - 合せがずっと best buysであるわけではありません. - 私はできればリス - トを更新して行きますがそれがいつになるかはわかりません. - - 訳注: &a.jkh; 氏は FreeBSDプロジェクト FreeBSD - コアチームのメンバです. - - - マザーボード - - Pentium Pro (P6)システム用で気に入っているのは Tyan - S1668 デュアルプロセッサマザーボードです. これは Intel - PR440FX 同様 オンボードの WIDE SCSI と 100/10MB Intel - Etherexpress NIC が ついています. - これを使えば最高の小型のシングルあるいは - デュアルプロセッサシステム (FreeBSD - 3.0ではサポートされています)を作ることができます. Pentium - Pro 180/256K チップの価格は非常に安くなっていますが, - いつまで手にはいるかはわかりません.. - - Pentium II には, どちらかと言えばひいき目ですが, Adaptec - SCSI WIDE コントローラのついた ASUS P2l97-S マザーボードです. - - For Pentium machines, the ASUS http://www.asus.com.tw/Products/Motherboard/Pentium/P55tp4/index.html - はミッドレンジからハイエンドの Pentium - サーバあるいはワークステーションシステムには - よい選択です. - - フォルトトレラントシステムを構築したいのであれば - パリティメモリを 使い, - 真に24時間/週7日間動作させ続けるアプリケーションであれば - ECCメモリを使うべきでしょう. - - - ECCメモリはいくらか性能のトレードオ フがあります - (それが重要なものであるかそうでないかはあなたのアプ - リケーションによりますが). しかし, - メモリエラーに対しては明らかに - フォルトトレランス性が強化されます. - - - - - ディスクコントローラ - - これはいくらかトリッキーです. 私は ISAから - PCIまですべてコンパチブルな Buslogic コント - ローラを使うようにすすめていましたが, 現在では ISAでは - Adaptec 1542CF, - EISA では Bt747c, PCIでは Adaptec 2940UW - をすすめるよう変わってきています. - - NCR/Symbios の - PCIカードも私のところではうまく動いています, ただ し - BIOS-less モデルのボード(SCSI ボード上に ROMらしいものがない - 場合は, マザーボード上に SCSIアダプタのための BIOSが必要な - ボードである可能性があります 訳注: SC-200など) - を使うのであれば - マザーボードがそれをサポートしているかどうか - 注意しなくてはなりません. - - PCIマシンで2つ以上の - SCSIコントローラが必要となるのであれば, - PCIバスの不足を防ぐために Adaptec 3940 - カードを考えてもいいでしょう. これは1つのスロットで2台の - SCSIコントローラ(と内部バス)を持ちます. - - - - ます. 市場には2つのタイプの 3940 がありますので - 注意しましょう. — 古いモデルでは AIC 7880 - チップを使っていますが, 新しいモデルでは AIC 7895 - を使っています. 新しいモデルでは CAM - ドライバのサポートが必要です. - これはまだ FreeBSD の一部では ありません. - 自分で付け加えるか, CAM binary snapshot リリースから - インストールする必要があります(URLを参照してください). - - - - - - ディスクドライブ - - 私は, 極々特殊な状況を除いて - それだけのお金をかけることができる なら SCSIは - IDEよりもよい と言っています. - 小規模なデスクトップ構成 のシステムでも, - SCSIであればディスクが安くなっていった時にサーバの - (古い入れ換えた) - ディスクを比較的簡単に移し替えることができます. あ - なたが複数のマシンの管理をしているのであれば単純に - 容量について考えるのではなく, 食物連鎖のように考えましょう. - 重要なサーバの場合は議論の余地はありません. - SCSI機器と品質の良いケーブルを使いましょう. - - - - CDROM ドライブ - - 私は SCSIの方が好みますのでもちろん SCSI - CDROMを選びました. 東芝 のドライブは - 常に(スピードがどうであっても)お気に入りでしたが, 古い - Plextor PX-12CS - ドライブも好きです. 高々12倍速のドライブですが, - 高い性能と信頼性を提供してくれています. - - 一般的には, 大部分の SCSI CDROM - ドライブは私の見た限りではほとんどしっかりした構造ですので - 多分 HPや NECの SCSI CDROMでも問題が起き - ることはないでしょう. SCSI CDROM - の価格はここ数ヶ月でかなり下落したようで, 技術的に - 優れた方法でありながら 現在では IDE CDROMと同じ程度の価 - 格になっています. もし IDE と SCSI の CDROM - ドライブの間で選択することができるのなら, 特に IDE - を選ぶ理由はないでしょう. - - - - CD-R (CD Recordable: WORM) ドライブ - - この原稿を書いている時点で, FreeBSDは 3種類の - CDRドライブ (私は これらすべては結局は - Phillips社のドライブであるのではないかと考えているのですが) - をサポートしています : Phillips CDD 522 (Plasmon - のドライブと同様の動作をします), PLASMON RF4100, HP 6020i - です. 私は HP 6020i を CDROMを焼くのに使っています(2.2 - 以降の システムで動きます. — それ以前のリリースの - SCSIコードでは動きません). 非常に調子よく動いています. - システムの /usr/share/examples/worm - を見てください. - ISO9660ファイルシステムイメージ (RockRidge拡張) - を作るスクリプトと それを HP6020i CDR - で焼くためのスクリプトの例があります. - - - - テープドライブ - - 私はたまたま Exabyte の 8mm drives - と HP の - - 4mm (DAT) を持っています. - - バックアップのためであれば, より本質的に丈夫な (また, - より容量が大きい) Exabyteの - 8mmテープの方がおすすめできます. - - - - ビデオカード - - もし (米国では) 99USドルをかけて商品の XサーバをXi Graphics, Inc. (以前の X - Inside, Inc.)から買うことができる なら間違いなく - Matrox Millenium - IIカードをおすすめします. - このカードは無償提供されている XFree86 - (現在のバージョンは 3.3.2です) - のサーバでも非常によく動きます. - - Number 9の S3 - Vision 868と 968 ベースのカード (the 9FX series) - はわりあいと速く, XFree86の S3サーバで - うまくサポートされています, 加えて現在では非常に低価格です. - まず問題も起きないでしょう. - - - - モニタ - - 私の持っている Sony Multiscan 17seII monitors - は非常に調子がいいので, 同じ (トリニトロン) - ブラウン管を使っている Viewsonic をおすすめします. - 17"よりも 大きなモニタ, 例えば 21" - のモニタが実際に必要だとしたらこの文章の執筆時点では - 2,000USドル以下のもの (20"のモニタでは 1,700USドル以下のもの) - はまったくすすめられません. - 20" 以上のクラスでよいモニタは(いくつも) ありますし, - 20" クラスで安いモニタもあり ます. - うまくいかないことに安くてよいモニタはほとんどありません! - - - - - ネットワーキング - - まず最初に, Intel EtherExpress Pro/100B - カードをすすめます. ISA カードでは SMC Ultra 16 - コントローラ, いくらか安めのPCIベースのカード では SMC - 9392DST, SMC EtherPower と Compex ENET32カードがおすすめ - できます. 一般的に DECの DC2104x - イーサネットコントローラチップを 使っている Znyx ZX342 や - DEC DE435/450 などのカードはうまく動くでしょうし, (firewall や - roouter に便利な) 2-port 品や 4-port 品を - よく見つけることができますが, Pro/100B カードは最も少ない - オーバーヘッドで最高の性能を出すでしょう. - - もう一方, - できるだけ低コストでそこその性能で動くものを探しているなら, - ほとんどの NE2000のクローンは極めて低価格で - うまく動いてくれます. - - - - (特殊な) シリアル - - 高速のシリアル ネットワーク インタフェース - (同期シリアルカード) を探しているのであれば Digi International製の - SYNC/570 - シリーズのド ライバが今の FreeBSD-CURRENT にあります. Emerging Technologies - も 提供 するソフトウェアにより T1/E1 - の性能が得られるボードを製造しています. - もっとも私が直接これらの製品を動かした - 経験があるわけではありません. - - 訳注:Emerging TechnologiesのWeb - ページを見るとカードのスペックに Operating Systems: MS-DOS, - MS-WINDOWS, System V UNIX, BSD/OS, FreeBSD, NetBSD and Linux - と書いてあります. また "BSD/OS, FreeBSD and LINUX Router - Card Solutions" というページ - もあってサポートは良さそうです. - - マルチポートカードの選択の幅はかなり広いですが, - FreeBSDがサポー トするいう点では Cyclades - の製品が最も信頼できるでしょう. この最大の理由はこ - の会社が私たちに十分な評価用ボードとスペックを - 供給することを約束してくれているからです. 私は Cyclom-16Y - が最高の性能価格比であると聞 - いていましたが最近は価格のチェックはしていません. - - 訳注: cycladesの WWWサーバでも Supported Operating - Systemsに Linuxや BSDi, FreeBSD が明記されています. - - 他のマルチポートカードで評判がよいのは BOCAおよび - ASTのカードと Stallion - Technologiesで, このカードには ここ - で非公式なドライバが提供されているようです. - - - - オーディオ - - 私は現在 Creative - Labs AWE32 を 使っています. - もっともクリエイティブラボ製品が現在一般的にうまく - 動いているから, ということにすぎませんが. - 他のタイプのサウンド - カードは同様にうまくは動かないと聞いています. 単に私の経験が - 乏しいということにすぎないと言うことなのかも知れませんが. - (私は以前は GUS のファンでしたが, Gravis はサウンドカード - から撤退してしまいました). - - - - ビデオキャプチャー - - ビデオキャプチャーについては2つのいい選択肢があります - — Hauppauge や WinTV などの Brooktree BT848 - チップベースのボードは FreeBSD で非常にうまく動きます. - もう一つの動作するボードは Matrox Meteor - カードです. FreeBSD はクリエィティブラボの古い - video spigotカードの - サポートはしていますがこれは見つけるのは非常に - むずかしいでしょう. Meteor は 440FX - チップセットベースのマザーボードでは - 動きませんので注意してください. - 詳細はマザーボードの節を参照してください. - このような場合には BT848 ベースの - ボードを使った方がよいでしょう. - - - - - - 中心部/プロセッサ - - - - マザーボード, バス, チップセット - - - * ISA - - - - - - * EISA - - - - - - * VLB - - - - - - PCI - - 原作: &a.obrien; 投稿者: &a.rgrimes;. - 25 April 1995. - - 更新: &a.jkh;.最終更新 - 26 August 1996. - - 訳: &a.jp.yoshiaki;. - 12 October 1996. - - Intelの PCIチップセットについて, 以下にさまざまな種類 - の既知の不具合と問題の程度のリストを示します. - - - Mercury: - - ISAバスマスタがISAとPCIブリッジの向 - こう側にある場合は,キャッシュコヒーレンシ(一貫性)の - 問題があります. このハードウェア欠陥に対処してうま - く動かす方法はキャッシュを - offにする以外にはありません. - - - - Saturn-I - (82424ZX の rev 0, 1 ,2): - - ライトバックキャッシュのコヒーレンシに - 問題があります. - このハードウェア欠陥に対処してうまく動かす方法は - 外部キャッ - シュをライトスルーにすること以外にはありませ ん. - Saturn-IIにアップデートしましょう. - - - - Saturn-II - (82424ZX の rev 3 or 4): - - 問題なく動きます. - ただし多くのマザーボードではライトバック動作に必要な - 外部ダーティビット SRAMが実装されていません. - 対策としてはライトスルーモードで動かすか, ダーティ - ビット SRAMをインストールするかがあります. (これは - ASUS PCI/I-486SP3G の rev 1.6 - 以降で使われています) - - - - Neptune: - - 2つより多くの(3台以上の)バスマスタデ - バイスを動かすことができません. Intelは設計の欠陥を - 認めています. 2つを越えるバスマスタを許さない, 特別な - 設計のハードウェアで PCIバスアービタを置き換えることに - より解決されています. (Intelの Altair boardや他にはい - くつかの Intelサーバグループマザーボードに見られます). - そして, もちろん Intelの公式の回答は Triton - チップセットへの 移行で, - こちらでは修整したということです. - - - - Triton (430FX): - - 知られているキャッシュコヒーレンシ - やバスマスタの問題はありませんがパリティチェック機能が - ありません. パリティを使いたいような場合は, 可能であ - れば Triton-II - ベースのマザーボードを選びましょう. - - - - Triton-II (430HX): - - このチップセット - を使っているマザーボードに関するすべての - 報告によれば今の ところ好評です. - 既知の問題はありません. - - - - Orion: - - このチップセットの初期のバージョンでは PCI - write-posting にバグがあり, 大量の PCIバストラフィッ - クのあるアプリケーションでは性能の著しい低下があるとい - う障害がありました. B0以降のリビジョンのチップセットで - は問題は解決されています. - - - - - 440FX: - - これは - Pentium Pro に対応したチップセットで, - 初期の Orion チップセットにあったような問題は見られず, - 問題なく動 いているようです. - また, これは ECCやパリティを含んだ広い - 種類のメモリに対応しています. - 既知の問題は Matrox Meteor - ビデオキャプチャカードに関するものだけです. - - - - - - - - CPU/FPU - - 原作 &a.asami;. - 27 December 1997. - - - P6 クラス (Pentium Pro/Pentium II) - - Pentim Pro, Pentim IIとも - FreeBSDで使うのにまったく問題はありません. 実際, わたしたちのメイン - FTP サイトである ftp.FreeBSD.org - (世界一大きな FTP サイト "ftp.cdrom.com" - としても知られています) では Pentium Pro で - FreeBSD を使っています. 興味のある方向けに - 設定の詳細が公開されています. - - - - Pentium クラス - - Intel Pentium (P54C), Pentium MMX (P55C), AMD K6と - Cyrix/IBM 6x86MXプロセッサは全て - FreeBSDで動作確認がされています. どの - CPUが速いかということはここでは述べません. - インターネットを探せばあれが - 速いとかこっちの方がいいとか教えてくれるサイトは - いっぱいありますので, そちらをご覧ください. :) - - - 一つ注意しないといけないのは, CPU - によって必要な電源電圧や冷却の仕様が 異なるということです. - マザーボードが指定された電圧を供給できることを - 必ず確認しましょう. 例えば, 最近の - MMX チップにはコアと入出力で違う電圧を使うもの (コア 2.9V, - 入出力 3.3V など) がたくさんあります. また, AMDと - Cyrix/IBMのチップには - Intelの製品より熱くなるものがいくつかあります. - その場合には強力なヒートシンク／ファンを使いましょう. - (各社のホームページにお勧めの部品のリストがあります.) - - - - - クロックスピード - - 原作 &a.rgrimes;. - 1 October 1996. - - 更新 &a.asami;. - 最終更新 27 December 1997. - - Pentium クラスのマシンはシステムの - いくつかの部分で異なったクロックスピードを使っています. - これは CPU, 外部メモリバス, PCIバスです. - 別々のクロックスピードが使われるために高速な - CPUを使ったシステムが 低速な - システムよりも必ずしも速いとは限りません. - それぞれの場合の違いを以下の表に示します. - - - - - - CPUクロック MHz - 外部クロックとメモリバス MHz - 外部クロックと内部クロックの比 - PCIバスクロック MHz - - - - - - 6060 - 1.030 - - 6666 - 1.033 - - 7550 - 1.525 - - 9060 - 1.530 - - 10050 - 225 - - 10066 - 1.533 - - 12060 - 230 - - 13366 - 233 - - 15060 - 2.530 (Intel, AMD) - - 15075 - 237.5 (Cyrix/IBM 6x86MX) - - 16666 - 2.533 - - 16666 - 2.533 - - 18060 - 330 - - 20066 - 333 - - 23366 - 3.533 - - - - - - 66 MHz は実際には 66.667 MHzかもしれませんが, - そうだと決まっているわけでもありません. - - Pentium 100 は 50MHzの外部クロックの 2 - 倍または 66MHz の 1.5 倍の両方で - 動かすことができます. - - - 3 倍クロック以上の CPU ではメモリアクセス速度が - 不足気味であるという点には注意していただきたいですが, - 上の表を見るかぎりでは 100, 133, 166, 200, 233 - MHzを使うのが最良だというのがわかります. - - - - AMD K6のバグ - - AMDの K6プロセッサで大きなコンパイルをすると, - セグメンテーションフォルトで - プロセスが落ちることがあるという事例が - 1997年に多数報告されました. これは - '97年の第3四半期に直ったようです. 情報を総合すると, - チップ上の製造年週が 9733 (97年の - 第33週に製造) - 以降のものは大丈夫ということのようです. - - - - - * 486 クラス - - - - - - * 386 クラス - - - - - - 286 クラス - - FreeBSDは 80286マシンでは動きません. 現在の巨大なフ - ルスペックの - UNIXをこのようなハードウェアで動かすことはほとんど - 不可能でしょう. - - - - - メモリ - - FreeBSDをインストールするのに最低限必要なメモリ量は 5 - MBです. いったんシステムが起動してカスタムカーネルを - 作ることができるならば, もっと少ないメモリ - で動かすこともできます. boot4.flp - を使えば 4 MB しかメモリがなく - てもインストールできます. - - - - * BIOS - - - - - - - 入力/出力デバイス - - - * ビデオカード - - - - - - * サウンドカード - - - - - - シリアルポートとマルチポートカード - - - UART とは何か, そしてどのように動作するか - - Copyright © 1996 &a.uhclem;, - All Rights Reserved. - 13 January 1996. - - 訳: &a.jp.saeki;, &a.jp.iwasaki;. - 11 November 1996. - - ( ここからは &a.jp.saeki; が翻訳を担当) - - 汎用非同期送受信コントローラ (UART) - はコンピュータのシリアル通信 サブシステムの鍵となる部品です. - UART は何バイトかのデータを受けとり, これを 1 - ビットずつ順番に送信します. 受信側では, もう一つの UART が - このビット列を完全なバイト列に組み立て直します. - - シリアル転送は, - モデムやコンピュータ間の非ネットワーク型の通信, - ターミナルその他のデバイスで広く使われています. - - シリアル転送には主に同期と非同期という - 二つの形式があります: 通信サブシステムの名前は, - そのハードウェアでサポートされている - 通信モードによって変化します. 通常, - 非同期通信をサポートしているものは文字 A - を含み, 同期通信をサポートしているものは文字 - S を含みます. - 以下で両方の形式について詳しく説明します. - - 通常使われている略号は以下の通りです: -
- UART 汎用非同期送受信装置 (Universal - Asynchronous Receiver/Transmitter) -
- -
- USART 汎用同期-非同期送受信装置 (Universal - Synchronous-Asynchronous Receiver/Transmitter) -
- - - 同期シリアル転送 - - 同期シリアル転送では, - 送信側と受信側がクロックを共有している 必要があります. - さもなければ, 送信側がストローブまたは - その他のタイミング信号を供給して, - 受信側にデータの次のビットを いつ読み込 - めばよいのかを知らせる必要があります. - - ほとんどの同期シリアル通信では, - 常に何らかのデータが転送され続けます. そのため, - 転送のタイミングまでに送信データが用意できていなければ, - 通常のデータのかわりに「埋め草」 (fill character) - が送られます. 同期通信では, - 送信側と受信側との間でデータビットのみが転送されるため, - 同じビット速度の非同期シリアル通信に比べて効率的です. - しかし, - 送信側と受信側でクロック信号を共有するために余分な電線と - 回路が必要となる場合には, - よりコスト高となる可能性があります. - - プリンタやハードディスクでも同期転送の - 一種が使用されています. このときデータが 1 - 組みの電線で送られる一方, クロック信号または - ストローブ信号が別の電線で送られます. - プリンタやハードディスクは通常, - シリアルデバイスではありません. - ほとんどのハードディスクのインタフェース規格では, - データを送るための - 線とは別にクロックまたはストローブ信号を - 送るための線を持っていて, ストローブ 1 - 回毎に一つのデータ全体を送ります. PC 産業界では, - これらはパラレルデバイスとして知られています. - - PC の標準的なシリアル通信ハードウェアは, - 同期モードをサポートして いません. - ここで同期モードについて述べたのは, 非同期モードとの - 比較のために過ぎません. - - - - 非同期シリアル転送 - - 非同期転送は, - 送信側がクロック信号を受信側に送らなくても - データを転送することができます. そのかわり, - 送信側と受信側は - あらかじめタイミングパラメータや同期のために追加される - 特別なビットについて - 取り決めをおこなっておかなければなりません. - - 非同期転送をおこなうために UART - にデータが与えられると, 「スタートビット」 - と呼ばれるビットが転送データの先頭に追加されます. - スタートビットはデータの転送開始を受信側に - 知らせるために使われ, - これにより受信側のクロックを送信側のクロックに - 同期させます. この二つのクロックは, - 転送データの残りのビットを転送する間に 10% - 以上ふらつかないように正確なものでなければなりません. - (この条件は機械式テレタイプの時代に定められたものなので, - 現代の電子装置であれば容易に満足させることができます). - - - スタートビットが送られた後, データの各ビットが最下位 - (LSB) から 順番に送られます. - 転送されるビットの長さはすべて同じになっていて, - 受信側はそれぞれのビットの中央部でそれが - 1 か 0 - かを判断します. 例えば, 仮に 1 ビットを送るのに 2 - 秒かかるとすると, 受信側は - スタートビットの始まりを認識した 1 秒後に信号が - 1 か 0 かを調べ, - その後 2 - 秒ごとに次のビットの値を調べるという動作を繰り返します. - - - 送信側は, いつ受信側がビットの値を 見た - のかはわかりません. 送信側はクロックにしたがって - 次々にビットを転送するだけです. - - 設定によっては, 1 ワードのデータ全体が送られたあとに - 送信側が内部で生成したパリティビットを - 付加する場合があります. - パリティビットは受信側で簡単なエラーチェックを - するために使われます. その後に, 最低でも 1 - ビットのストップビットが送られます. - - 1 ワードのすべてのビットを受信すると, - 受信側がパリティビットの - チェックをおこなうように設定することができます. - (パリティビットを 使用するかどうか, - 送信側と受信側であらかじめ取り決めておかなければ - なりません). - それから受信側はストップビットをチェックします. - もしもストップビットが期待通りの位置に存在しなければ, UART - は 転送エラーが発生したと判断して, - ホストがデータを読もうとした時に - フレーミングエラーが起きたと報告します. 通常, - フレーミングエラーは - 送信側と受信側のクロックが一致していなかったり, - 信号に割り込みが 入った時に起こります. - - データが正しく受信されたかどうかにかかわらず, UART - はスタート, パリティ, ストップビットを自動的に捨てます. - 送信側と受信側で設定が正しく一致していれば, - これらのビットが - 誤ってホストに転送されることはありません. - - 1 - 回の転送が終了する前に次のデータの転送準備ができていれば, - 前のデータのストップビットを送った後, 間を空けずに - 次のデータのスタートビットを送ることができます. - - 非同期転送データは自己同期なので, - 転送するべきデータがない場合は - 転送路は空き状態になります. - - - - UART のその他の機能 - - 転送のためにデータをパラレルからシリアルに変換し, - 受信時に - シリアルからパラレルに戻すという基本的な機能の他に, UART - は通常, 転送路の状態を示したり, - リモートデバイスで次のデータを受けとる準備が - できていない場合にデータの流れを抑制するのに - 使われる信号のための 付加回路も持っています. 例えば UART - に接続されているデバイスがモデムの場合, モデムは - 回線上に搬送波 (carrier) - が存在していることを報告するかもしれません. 一方, - コンピュータはこれらの付加信号を操作することにより - モデムのリセットをおこなったり, - かかってきた電話を取らないように - モデムに指示するかもしれません. - これらの付加信号の機能はそれぞれ EIA RE232-C - 規格で定義されています. - - - - RS-232C と V.24 規格 - - ほとんどのコンピュータシステムでは, UART は EIA - RS-232C 規格に - 準拠した信号を生成するための回路に接続されています. また, - RS-232C の仕様を反映した, V.24 という CCITT 規格に - 準拠したシステムも存在しています. - - - RS-232C のビット割り当て (マークとスペース) - - RS-232C では, 1 - の値をマーク, 0 - の値をスペースと 呼びます. - 通信路にデータが流れていない時, - 回線はマーキング であるとか, - 1 - の値を連続して転送し続けているとか言われます. - - スタートビットは常に 0 (スペース) - で, ストップビットは常に 1 (マーク) - です. このことは, - たとえ複数のデータが連続して転送されている場合でも, - それぞれのデータの転送開始時には必ず, マーク (1) から - スペース (0) - への遷移が回線上で起こるということを意味しています. - - これによって, - 転送されるデータビットの内容にかかわらず, - 送信側と受信側の - クロックを同期させることができるのです. - - ストップビットとスタートビットの間の空き時間は, - その通信路で 1 - ビットを転送するのに必要な時間の正確な倍数である - 必要はありません. (倍数にはゼロを含みます). しかし, - ほとんどの UART では 設計の単純化のために, - 倍数になるように設計されています. - - RS-232C では, 「マーク」信号 (1) - は -2V から -12V の間の電圧で, 「スペース」信号 - (0) は 0V から +12V - の間の電圧で示されます. 送信部は +12V または -12V - を送ることになっていて, 受信部では - 長いケーブルによるいくらかの電圧ロスを - 許容するように定められています. - (ポータブルコンピュータなどで使用されている) - 低消費電力デバイスの 送信部では しばしば +5V と -5V - のみを使用していますが, 短いケーブルを使用するならば, - これらの電圧も RS-232C 受信部の - 許容範囲に入っています. - - - - RS-232C のブレーク信号 - - RS-232C は ブレーク - と呼ばれる信号についても定めています. これは - (スタートビットもストップビットも無しで) 連続して - スペースの値を送ることで発生されます. - データ回路に電流が流れていない場合は, 回線は - ブレーク - を送り続けているものと解釈されます. - - ブレーク 信号は完全な 1 - バイトとスタート, ストップ, パリティ - ビットを送るために必要な時間よりも - 長い間続かなければなりません. ほとんどの UART - はフレーミングエラーとブレークを区別することが - できますが, もしも これを区別できない UART があった場合, - フレーミングエラーの検出をブレークの識別のために - 使用することができます. - - テレタイプの時代には, - 国中でおびただしい数のテレタイプが - (ニュースサービスなどで) 電線で直列に接続されていました. - 任意のテレタイプユニットは, - 電流が流れないように一時的に回路を オープンにすることで - ブレーク - 信号を発生させることができました. これは, - 他のテレタイプが情報を送信している間に, 緊急ニュースを - 送る必要のあるテレタイプが - 割り込みをかけるために使われました. - - 現在のシステムでは, - ブレーク信号には二つのタイプがあります. - もしブレーク信号が 1.6 秒よりも長ければ, それは - 「モデムブレーク」であると解釈されます. - モデムがこの信号を検出すると, - 通信を終了して電話を切ったり, コマンドモードに入るように - プログラムされていることがあります. もしブレーク信号が - 1.6 秒よりも短ければ, それはデータブレークを 示します. - この信号に応答するのはリモートコンピュータの仕事です. - この形のブレークは, - しばしば注意喚起または割り込みのための信号として 使われ, - ASCII の CONTROL-C - 文字の代用とされることもあります. - - マークとスペースは紙テープシステムでの - 穴空き と 穴無し に - 相当しています. - - - ブレーク信号は, - 紙テープまたはその他のバイト列から生成できない - ことに注意してください. - なぜならバイト列は常にスタートビットや - ストップビットとともに送られるからです. UART - には通常, ホストプロセッサからの特別なコマンドにより - 連続したスペース信号を生成する能力があります. - - - - - RS-232C の DTE デバイスおよび DCE デバイス - - RS-232C 規格は二つのタイプの装置を定めています: - それはデータターミナル装置 (DTE) とデータキャリア装置 - (DCE) です. 通常, DTE デバイスはターミナル - (またはコンピュータ) で, DCE は モデムです. - 電話回線を介した通信のもう一方の端である受信側のモデムも - また DCE デバイスで, - そのモデムに接続されているコンピュータは DTE - デバイスです. DCE デバイスが信号を受け取るピンは DTE - デバイスが 信号を送るピンであり, - また逆も同様です. - - 二つのデバイスがともに DTE であったり, ともに DCE - であって, - モデムやそれに類似したメディア変換装置を介さずに - 接続する必要が ある場合, ヌルモデム (NULL modem) - を使わなければなりません. - ヌルモデムはケーブルを電気的に再配列し, - 一方のデバイスの送信出力が - もう一方のデバイスの受信入力に接続され, - その逆もまた同様に 接続されるようにしてくれます. - 同様の変換はすべての制御信号についておこなわれ, - それぞれのデバイスが 他方のデバイスからの DCE (または - DTE) 信号を受けとれるようになります. - - DTE デバイスと DCE - デバイスで生成される信号の数は等しくありません. DTE - デバイスが DCE デバイスのために生成する信号の数は, DTE - デバイスが DCE デバイスから受けとる信号の数よりも - 少なくなっています. - - - - RS-232C のピン割当て - - EIA の RS-232C 規格 (およびこれに相当する ITU の - V.24 規格) は 25 ピンのコネクタ (通常 DB25 が使われます) - を要求し, そのコネクタのほとんどのピンの - 使用目的を定義しています. - - IBM PC および類似のシステムでは, RS-232C - 信号のサブセットが 9 ピンのコネクタ (DB9) - で提供されています. 主に同期モードで使用される信号は PC - のコネクタには含まれていませんが, もともと - この転送モードは IBM が IBM PC で使用することにした UART - ではサポートされていません. - - メーカーによっては RS-232C 用のコネクタに DB25 か - DB9, - またはその両タイプのコネクタを使っている場合があります. - (IBM PC はパラレルプリンタインタフェースにも DB25 - コネクタを 使っているので, このことは - しばしば混乱を引き起こします.) - - 以下は DB25 および DB9 コネクタにおける RS-232C - 信号の割り当て表です. - - - - - - DB25 RS232-C 端子 - DB9 IBM PC 端子 - EIA 回路符号 - CCITT 回路符号 - 一般名称 - 信号源 - 説明 - - - - - - 1 - - - AA - 101 - PG/FG - - - 保安用接地 - - - - 2 - 3 - BA - 103 - TD - DTE - 送信データ - - - - 3 - 2 - BB - 104 - RD - DCE - 受信データ - - - - 4 - 7 - CA - 105 - RTS - DTE - 送信要求 - - - - 5 - 8 - CB - 106 - CTS - DCE - 送信可 - - - - 6 - 6 - CC - 107 - DSR - DCE - データセットレディ - - - - 7 - 5 - AV - 102 - SG/GND - - - 信号用接地 - - - - 8 - 1 - CF - 109 - DCD/CD - DCE - 受信キャリア検出 - - - - 9 - - - - - - - - - - - 予約 (テスト用) - - - - 10 - - - - - - - - - - - 予約 (テスト用) - - - - 11 - - - - - - - - - - - 未割当て - - - - 12 - - - CI - 122 - SRLSD - DCE - 従局受信キャリア検出 - - - - 13 - - - SCB - 121 - SCTS - DCE - 従局送信可 - - - - 14 - - - SBA - 118 - STD - DTE - 従局送信データ - - - - 15 - - - DB - 114 - TSET - DCE - 送信信号エレメントタイミング - - - - 16 - - - SBB - 119 - SRD - DCE - 従局受信データ - - - - 17 - - - DD - 115 - RSET - DCE - 受信信号エレメントタイミング - - - - 18 - - - - - 141 - LOOP - DTE - ローカルループバック - - - - 19 - - - SCA - 120 - SRS - DTE - 従局送信要求 - - - - 20 - 4 - CD - 108.2 - DTR - DTE - データ端末レディ - - - - 21 - - - - - - - RDL - DTE - リモートデジタルループバック - - - - 22 - 9 - CE - 125 - RI - DCE - 被呼表示 - - - - 23 - - - CH - 111 - DSRS - DTE - データ信号速度選択 - - - - 24 - - - DA - 113 - TSET - DTE - 送信信号エレメントタイミング - - - - 25 - - - - - 142 - - - DCE - テストモード - - - - - - - - - ビット, ボー, そしてシンボル - - ボーとは非同期通信における転送速度の単位です. - モデム通信技術の進歩により, 新しいデバイスのデータ速度を - 表記するにあたって, この用語が - しばしば誤って使われるようになりました. - - ボーレートは伝統的に, - 通信路を通して実際に送られるビットの数を 表します. ある - DTE デバイスからもう一方へと実際に移動した - データの量を表すものではありません. ボーレートは, 送信側 - UART で生成されて受信側 UART で取り除かれる スタート, - ストップ, パリティといったオーバーヘッドビットをも - 含んでいます. これは 1 ワード 7 - ビットのデータを送るためには, 実際には 10 ビットの - データが完全に転送される必要があるということを意味します. - そのため, もしパリティを使い, - スタートビットとストップビットが それぞれ 1 - ビットずつ存在する場合には, 1 秒あたり 300 ビットの - 転送能力を持つモデムでは, 7 ビットのワードを通常 30 個しか - 転送することができません. - - もし 1 ワード 8 - ビットのデータとパリティビットを使用する場合には, - データ転送速度は 1 秒あたり 27.27 ワードまで低下します. - なぜなら 8 ビットのワードを送るのに 11 ビットが必要で, - このモデムは 1 秒間に 300 - ビットしか送ることができないからです. - - 1 秒あたりの転送バイト数をボーレートに変換したり, - その逆をおこなう 計算式は, - エラー訂正をおこなうモデムが現れるまでは単純でした. - エラー訂正をおこなうモデムは, ホストコンピュータの UART - から シリアルのビット列を受けとり, - それをバイト列に戻します. - (内蔵モデムを使用している場合でさえ, データは今まで通り - 頻繁にシリアル化されます) - その後これらのバイトはパケットに変換され, - 同期転送方式を用いて 電話回線を通じて送信されます. これは - DTE (コンピュータ) 中の UART で追加されたストップ, - スタート およびパリティビットは, - モデムから送り出される前に, モデムによって - 取り除かれるということを意味します. - これらのバイト列がリモートモデムに受信されると, - リモートモデムは スタート, - ストップおよびパリティビットを追加して, それらを - シリアル形式に変換し, リモートコンピュータの受信側 UART - に送ります. そしてリモートコンピュータの UART はスタート, - ストップおよび パリティビットを取り除きます. - - これらの特別な変換はすべて, - 二つのモデムの間でエラー訂正が - 実行できるようにするためおこなわれています. - エラー訂正とは, 受信側のモデムが正しいチェックサムで - 受信できなかったデータブロックの再送を, - 送信側のモデムに要求することができるということです. - この作業はモデムにより処理されて, DTE デバイスは - このようなプロセスがおこなわれていることに, - 通常気がつきません. - - スタート, - ストップおよびパリティビットを取り除くことにより, - エラー訂正のために二つのモデムの間で共有しなければならない - 追加のビットを, - 実効転送速度を低下させずに送ることができます. そのため, - 送受信 DTE にはエラー訂正がおこなわれているかどうかが - ほとんど見えなくなります. 例えば, もしモデムが 10 個の 7 - ビットデータをもう一方のモデムに送る 際に, スタート, - ストップ, およびパリティビットを送る必要がなければ, - その分の 30 ビットの情報を, - 真のデータの転送速度に影響を与えることなく - エラー訂正のために追加することができるわけです. - - データ圧縮をおこなうモデムでは, - ボーという言葉の使い方は さらに混乱することになります. - 例えば電話回線を通じて送られた二つの 8 ビットデータは, - 送信側モデムに送られた 12 - バイトのデータを表すかもしれません. - 受信側モデムはそのデータを本来の内容に展開し, 受信側の DTE - に渡します. - - また, 最近のモデムはバッファを内蔵しており, (DCE から - DCE へ) 電話線を 流れるデータの転送速度と, 両端の DTE と - DCE の間で流れるデータの - 転送速度とを別々に設定することができます. - モデムによる圧縮を使用する場合, 通常は DTE と DCE - の間の速度を DCE と DCE - の間の速度より速くしておきます. - - 1 バイトを記述するのに必要なビットの数は, - 二つのマシンの間でも DTE-DCE と DCE-DCE - のリンクでそれぞれ変化する場合がありますし, そのうえ, - それぞれのビット転送速度が異なる場合もあります. そのため, - 全体としての通信速度を表現するために - ボーという言葉を使うことは 問題でもありますし, - 真の転送速度を正しく伝えない場合があります. 1 - 秒あたりの転送ビット数 (bps) は DCE と DCE - の間のインタフェースに - おける転送速度を記述するために使うなら正しい用語ですし, - ボーまたは 1 秒あたりのビット数は, - 二つのシステムが電線で直接 接続されていたり, - エラー訂正や圧縮をおこなわないモデムが - 使われている場合には, 許容可能な用語です. - - 最近の高速モデム (2400, 9600, 14,400, 19,200bps - などのもの) も, 実際には 2,400 ボー (正確には 2,400 - シンボル/秒) か, それ以下の 速度で通信しています. - 高速モデムでは, 複数のビットを一つのシンボルで - 伝送する技術 (多値符合化など) を用いて, シンボル速度 - (シンボル/秒) よりも 高い通信速度 (ビット/秒) - を達成しています. これが電話の限られた音声帯域で - 高い伝送速度を得られる理由です. 28,800bps - やそれ以上のモデムでは, シンボル速度自体が - 可変になっていますが, - それ以外は同様の技術が用いられています. - - - - IBM PC の UART - - 元祖 IBM PC を設計した際に, IBM - はナショナル・セミコンダクタ社の INS8250 UART を IBM PC - パラレル/シリアルアダプタで使用することに - 決めました. - - IBM 自身やその他のベンダが作っている後継世代の AT - 互換機でも, INS8250 - そのものやナショナル・セミコンダクタの UART ファミリの - 改良版を使い続けられています. - - - ナショナル・セミコンダクタの UART - ファミリ系統図 - - INS8250 UART - にはいくつかのバージョンと後継の部品があります. - 主要なバージョンを以下に示します. - - - INS8250 -> INS8250B - \ - \ - \-> INS8250A -> INS82C50A - \ - \ - \-> NS16450 -> NS16C450 - \ - \ - \-> NS16550 -> NS16550A -> PC16550D - - - INS8250 - - この部品は元祖 IBM PC と IBM PC/XT で - 使われていました. この部品は本来 INS8250 ACE - (Asynchronous Communications Element) と - いう名前で, NMOS 技術で作られていました. - - 8250 は八つの I/O ポートを占有し, 送信バッファ - 1 バイトと 受信バッファ 1 バイトを持っています. - この元祖の UART はいくつかの - 競合状態などに関する欠陥を持っています. 元祖の - IBM BIOS - はこれらの欠陥を回避してうまく動くようなコードを - 含んでいましたが, そのために BIOS - が欠陥の存在に依存するように なってしまいました. - このため, 元祖 IBM PC や IBM PC/XT では 8250A, - 16450, または 16550 のような後継部品を使うことは - できませんでした. - - - - INS8250-B - - これは NMOS 技術で作られた INS8250 - の低速版です. これもオリジナルの INS8250 - と同じ問題を含んでいます. - - - - INS8250A - - XMOS 技術を使い, - さまざまな機能的欠陥を修正した INS8250 - の改良版です. INS8250A は当初, - クリーンな BIOS を 使用したベンダの - PC クローンで使用されていました. - なぜなら欠陥が修正されたことにより, この部品は - INS8250 や INS8250B の ために書かれた BIOS - で使うことはできなかったからです. - - - - INS82C50A - - これは INS8250A の CMOS 版 (低消費電力版) で, - INS8250A と同じ機能特性を持っています. - - - - NS16450 - - より高速な CPU バスにも対応できるように - 改良されたこと以外は NS8250A と同じです. IBM - はこの部品を IBM AT で使うことに決め, もはや IBM - BIOS が INS8250 - のバグに依存しなくなるように - 変更をおこないました. - - - - NS16C450 - - これは NS16450 の CMOS 版 (低消費電力版) - です. - - - - NS16550 - - 送信バッファと受信バッファをそれぞれ 16 - バイトに 変更したこと以外は NS16450 と同じですが, - バッファの設計に 欠陥があるため, - 信頼して使用することはできません. - - - - NS16550A - - バッファの欠陥が修正されたこと以外は NS16550 - と 同じです. 割り込みへの反応が遅い OS - でも高い信頼性で高速なデータを - 扱うことができることから, 16550A とその後継部品は - PC 産業界で 最も一般的に使われる UART - となりました. - - - - NS16C552 - - これは 2 個の NS16C550A CMOS UARTを - 一つのパッケージに入れた部品です. - - - - PC16550D - - ささいな欠陥が修正されたこと以外は NS16550A と - 同じです. これは 16550 ファミリの D リビジョンで, - ナショナル・セミコンダクタ社から - 提供されている最新の部品です. - - - - - - - NS16550AFとPC16550Dは同じもの - - ( ここからは &a.jp.iwasaki; が翻訳を担当) - - ナショナル・セミコンダクタは - 数年前に部品番号体系を再編成して おり, NS16550AFN - という名称はもはや存在しません. (もしあなたが - NS16550AFN を持っていたら, - 部品の日付コードを見てください. それは 通常 9 - から始まる4桁の数字です. 最初の2桁の数字は年度, 次の2桁 - は部品がパッケージされた年度の週です. あなたの持っている - NS16550AFN は, おそらく数年前のものでしょう.) - - 新しい番号は PC16550DV の様に, - パッケージ材料と形状により接尾辞 に小さな違いがあります - (番号体系についての記述は後述します). - - ここで注意しなければいけないことがあります. 例えば, - ある店に行って 1990年製の NS16550AFN - を15米ドルで売っているとします. ところが, - そのすぐ隣には ナショナル・セミコンダクタが AFN - を生産開始してから それにマイナーな変更を加えて作った - PC16550DN があり, そちらは 最近 - 6ヶ月に作られたものなのに, 簡単に入手できるため - NS16550AFN の 半額 (たくさん一度に買うと - 5米ドルまで下がることもあります) 位で - 買えたりすることがあるのです. - - NS16550AFN のチップ供給は減少し続けているため, - PC16550DN が古い - 部品番号のものとまったく同じ機能を持っていることに, - より多くの人が 気付いて受け入れるまでは, - 価格はおそらく上昇し続けるでしょう. - - - - ナショナル・セミコンダクタの部品番号体系 - - 古い NSnnnnnrqp - の部品番号は, 現在 - PCnnnnnrgp - というフォーマットになっています. - - r - はリビジョンのフィールドです. 現在のナショナルセ - ミコンダクタの 16550 - のリビジョンはDです. - - p - はパッケージタイプのフィールドです. タイプは以下 - の通りです: - - - - - - "F" - QFP - (quad flat pack) L lead type - - - - "N" - DIP - (dual inline package) through hole straight - lead type - - - - "V" - LPCC - (lead plastic chip carrier) J lead type - - - - - - 訳注: 具体的なパッケージ形状についての情報は http://www.national.com/packaging/plastic.html を参照 してください. - - g - は製品グレードのフィールドです. もしパッケージタイ - プの文字の前にIがあれば, - 工業用グレード部品を表し, 標準 - 部品より高いスペックを持ちますが, Miltary 仕様 (Milspec) - ほど高 くはありません. - これは付加的なフィールドです. - - 私たちがかつて NS16550AFN (DIP パッケージ) - と呼んでいたものは, 現在 は PC16550DN または PC16550DIN - と呼ばれています. - - - - - 他のベンダと類似の UART - - 長年に渡り, 8250, 8250A, 16450 そして 16550 - はライセンスされ, - または他のチップベンダにコピーされてきました. 8250, 8250A - そして 16450 の場合は, そのものの回路 - (megacell: LSIの中に組み込む - ことのできるライブラリ化された回路の大規模な物) が Western - Digital と Intel - を含むたくさんのベンダにライセンスされまし た. - 他のベンダは部品を - リバースエンジニアリングした物か同じように - 動作する互換品を製造しました. - - 内蔵モデムにおいては, - モデム設計者はモデムのマイクロプロセッサで 8250A/16450 - をエミュレートすることはよくおこなわれます. - このエミュレート による (互換の) UART - は数百バイトの隠れたバッファを持つでしょう. - バッファのサイズのため, - このような互換品は高速データ処理の能力では 16550A - と変わらない信頼性を持つことができます. しかし, それでも - ほとんどのオペレーティングシステムは UART は 8250A か - 16450 である と報告し, 特殊なドライバが使用されなければ - エミュレートによる UART の余分に存在する - バッファリングの効果的な使用はおこないません. - - 幾つかのモデムメーカーは, - 市場における競争を有利にするために数百バ - イトのバッファを持ち 16550A - の置き換えができるはずの設計を, たとえ - 性能が低下する事になったとしても - 棄てざるを得なくなるような市場の圧 - 力を受けています. - - 一般的にある誤解は, 16550A - と書かれたすべての部品が同じ性能であると いうことです. - それらは異なるものであり, 状況によってはまちがいなく - 欠陥と呼べるものがこれらの 16550A - クローンのほとんどにあります. - - NS16550 が開発された時に, - ナショナル・セミコンダクタは設計に関する - 幾つかの特許を取得し, - 彼らはライセンスを制限して他のベンダが類似 - の特徴を持つチップを供給することを困難にしました. - 特許のため, リバー - スエンジニアリングによる設計とエミュレーションは, - 特許がカバーする - 請求権を侵害を回避しなくてはなりませんでした. 結果として, - これらの コピーのほとんどは, - 多くのコンピュータとモデムのメーカーは支払いた - くはない程の価格であった本物の部品の NS16550A または - PC16550D とまった - く同じような動作をさせることはできませんでした. - - 16550A のクローンに存在する相違点のうち - いくつかは些細なものですが, そのほかに - 特定のオペレーティングシステムやドライバでは - 全然使いものにならないような相違が存在する場合もあります. - あるドライバでは問題なく動作しても, - 別のドライバを使用した場合には - 問題が発生することもありますし, Windows - のドライバにおいても - 充分にテストや考慮がおこなわれなかったイベントの組合わせが - 起こった場合には, - これらの相違点が明らかになるかもしれません. - これはほとんどのモデムベンダと 16550 クローンメーカーが, - NS16550A との互換性のプライマリテストとして Windows for - Workgroups 3.11 と Microsoft MS-DOS ユーティリティの - Microsoft ドライバを使用しているか らです. - この安易過ぎる規準は, もし異なるオペレーティングシステムが - 使用されたらクローンと - 本物の部品の微妙な違いのために問題が発生し得 る, - ということを意味しています. - - ナショナル・セミコンダクタは, どんな OS - のドライバからも独立した互 換性テストを実行する - COMTEST - という名前の入手可能なプログラムを作 成しました. - このタイプのプログラムの目的は, 競合製品にある欠陥のデ - モンストレーションであることをおぼえておくべきです. - ですからそのプ ログラムは, - テスト中の部品の動作の重要な問題と極めてささいな相違を - 同じように報告するでしょう. - - この文書の著者が 1994 - 年に実行した一連のテストでは, ナショナルセミ コンダクタ, - TI, StarTech そして CMD が製造した部品は megacell 及び - COMTEST - でテストされた内蔵モデムに埋め込まれたエミュレーションと同 - 等です. - これらの部品の幾つかで注目される相違点を以下に示します. - これらのテストは1994年に実行されたので, - これらはベンダから供給さ - れた製品の現在の性能には反映されないでしょう. - - 極端に多くの問題やあるタイプの問題が検出された場合に, - COMTEST は通 常は実行を中止することに注意してください. - このテストの一部では, たと - え何回相違点に遭遇しても中止しないように COMTEST - を修正しました. - - - - - - ベンダ - 部品番号 - 報告された「相違点」として知られるエラー - - - - - - National - (PC16550DV) - 0 - - - - National - (NS16550AFN) - 0 - - - - National - (NS16C552V) - 0 - - - - TI - (TL16550AFN) - 3 - - - - CMD - (16C550PE) - 19 - - - - StarTech - (ST16C550J) - 23 - - - - Rockwell - Reference modem with internal 16550 or an - emulation (RC144DPi/C3000-25) - 117 - - - - Sierra - Modem with an internal 16550 - (SC11951/SC11351) - 91 - - - - - - - この文書の著者は今まで, COMTEST プログラムを - 使用して相違点がゼロと報告されるナショナル・ - セミコンダクタ以外の部品を一つも発見しませんでした. - ナショナル・セミコンダクタは長年に渡り 16550 - の五つのバージョンを持っており, 最新の部品は - 機能性のために, ベンチマークを考慮した古い - NS16550AFN と少し異なる振る舞いをすることに - 注意するべきです. - COMTEST はナショナル・セミコンダクタの製品ラインの - 相違点については見て見ぬふりをするようになり, - 部品のリビジョン A, B そして C にあるバグが - 記述されている公式な正誤表がある時でも, - (オリジナルの 16550 を除いては) ナショナル・ - セミコンダクタの部品についてエラーを - 報告しなくなったので, この COMTEST のひいきを - 考慮にいれるべきです. - - - COMTEST からの相違点の単純なカウントが, - 何の相違点が重要であり どれがそうでないのかについて - 多くを明らかにしないことを 理解すること が大切です. - 例えば, 内蔵の UART を持つ上記の二つのモデムで報告され - た相違点の約半分が, - 5及び6ビットキャラクタモードをサポートしないク ローンの - UART によって引き起こされました. 本物の 16550, 16450 そし - て 8250 UART すべてはこれらのモードをサポートし, COMTEST - はこれらの モードの機能性をチェックするので, - 50を越える相違点が報告されました. しかし, - 5及び6ビットキャラクタモードを - サポートするモデムは殆どなく, - 特にこれらはエラー修正と圧縮機能付のものです. - これは5及び6ビット キャラクタモードに関連した相違点は - 差し引いて考えることができること を意味しています. - - COMTEST が報告した相違点の多くは, - タイミングに関する点でしょう. 多くのクローンの設計では, - ホストが一つのポートから読み込んだ時に他 - のあるポートのステータスビットは, - 本当の NS16550AFN と同じ - 長さの時間内で更新されない (あるものは速く, - あるものは遅く) かもしれ ませんが, COMTEST - はこれらの相違点を探します. これは相違点の数は誤 - 解を招き易いものです. - あるデバイスには一つか二つの相違点しかありま - せんがそれらは非常に重大かもしれません. - また別のデバイスは基準部品 と比べて速くまたは遅く status - レジスタを更新するために (適切に書か - れたドライバの操作にはまったく影響しないかもしれません) - 多くの相違点を 報告されるかもしれません. - - COMTEST は問題を引き起こすかも知れない, - または特殊なケースとして処 - 理しなければならない潜在的に矛盾した部品の存在に対して, - 管理者に警 - 告を出すスクリーニングツールとして使用できます. - - もしモデムの中にある 16550 - やシリアルポート接続されているモデムに 対して COMTEST - を実行する場合, モデムがテストキャラクタをエコーし - ないように最初に ATE0&W - コマンドをモデムに発行する必要がありま す. - これをおこなうことを忘れた場合, COMTEST - は少なくともこの相違点を 報告するでしょう: - - Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 - - - - 8250/16450/16550 のレジスタ - - 8250/16450/16550 UART は八つの連続する I/O - ポートアドレスを予約 しています. IBM PC - ではこれらの八つのポートに対して二つの定義された - 位置があり, それらは集合的に COM1 と COM2 - として知られています. PC - クローンとアドオンカードのメーカーは COM3 と COM4 - として知られる二つ の付加的な領域を作成しましたが, - 幾つかのシステムではこれらの余分な COM - ポートは他のハードウェアと衝突します. 最もよく起きるものは - IBM 8514 - エミュレーションを提供するビデオアダプタとの衝突です. - - - COM1 には 0x3f8 から 0x3ff が割り当てられ, 通常 IRQ 4 - が使用されます. COM2 には 0x2f8 から 0x2ff が割り当てられ, - 通常 IRQ 3 が使用されます. COM3 には 0x3e8 から 0x3ef - が割り当てられ, IRQ は標準化されていません. COM4 には - 0x2e8 から 0x2ef が割り当てられ, IRQ - は標準化されていません. - - 8250/16450/16550 UART - のI/Oポートの詳細は以下に提供されています. - - - - - - I/O ポート - 許可されたアクセス - 説明 - - - - - - +0x00 - write (DLAB==0) - Transmit Holding Register (THR). - このポートに書き込まれた情報は - データ命令として 処理され, UART - により送信されます. - - - - +0x00 - read (DLAB==0) - Receive Buffer Register (RBR). - シリアル接続から UART - によって受信されたすべての データ命令は, - このポートを読むことによってホス - トによりアクセスされます. - - - - +0x00 - write/read (DLAB==1) - Divisor Latch LSB (DLL) - マスタ入力クロックの周波数を - このレジスタに入っ ている値で割ることにより, - UART の周波数が決定 されます (IBM PCでは, - マスタクロックの周波数は 1.8432MHzです). - このレジスタには上記の除数の下 - 位8ビットが入っています. - - - - +0x01 - write/read (DLAB==1) - Divisor Latch MSB (DLH) - マスタ入力クロックの周波数をこの - レジスタに入っ ている値で割ることにより, UART - の周波数が決定 されます (IBM PCでは, - マスタクロックの周波数は 1.8432MHzです). - このレジスタには上記の除数の上 - 位8ビットが入っています. - - - - +0x01 - write/read (DLAB==0) - - - - - - - Interrupt Enable - Register (IER) - 8250/16450/16550 の UART - はイベントを四つのカテ - ゴリの一つに分類します. - それぞれのカテゴリは設 定可能です. - それぞれのカテゴリは, どんな類のイ - ベントの発生時に割り込みを - 生成するように設定可 能です. - 8250/16450/16550 の UART は, 有効になっ - ているカテゴリ内でいくつの - イベントが発生してい るかに関わらず, - 単一の外部割り込みシグナルを生 成します. - 割り込みに応答し有効になっている割り - 込みカテゴリ - (通常すべてのカテゴリが有効になって - いる割り込みを持ちます) - を割り込みの本当の原因 - を決定するためにポーリングするかは, - ホストのプ - ロセッサ次第です. - - - - Bit 7 - 予約済み, 常に 0. - - - - Bit 6 - 予約済み, 常に 0. - - - - Bit 5 - 予約済み, 常に 0. - - - - Bit 4 - 予約済み, 常に 0. - - - - Bit 3 - Enable Modem Status Interrupt (EDSSI). - このビットを「1」に設定することで, - 一つ以上の状態ラインで変更が発生した時 - に, UART が割り込みを生成可能となりま - す. - - - - Bit 2 - Enable Receiver Line Status Interrupt (ELSI) - このビットを「1」に設定することで, 入っ - てくるデータにエラー (または BREAK シ - グナル) が検知された時に, UART が割り - 込みを生成するようになります. - - - - Bit 1 - Enable Transmitter Holding Register - Empty Interrupt (ETBEI) - このビットを「1」に設定することで, UART - に送信される一つ以上の付加的な文 - 字に対する空きが生じた時に, UART が割 - り込みを生成するようになります. - - - - Bit 0 - Enable Received Data Available - Interrupt (ERBFI) - このビットを「1」に設定することで, UART が - FIFO のトリガーレベルを越え - る十分な文字を受け取るか, FIFO のタイ - マが期限切れとなるか (古くなったデータ), - FIFO が無効の場合にシグナル文字が受信 - された時に, UART が割り込みを生成する - ようになります. - - - - - - - +0x02 - write - - - - - - - - - - - FIFO Control Register (FCR) - (このポートは 8250 と 16450 の UART では - 存在しません.) - - - - Bit 7 - Receiver Trigger Bit - #1 - - - - Bit 6 - Receiver Trigger - Bit #0この二つのビットは FIFO - が機能している - 場合にレシーバがどの時点で割り込みを生 - 成するかを制御します. - - - - 7 - 6 - 割り込み生成前にいくつの命令 - が 受信されたか. - - - - 0 - 0 - 1 - - - - 0 - 1 - 4 - - - - 1 - 0 - 8 - - - - 1 - 1 - 14 - - - - Bit 5 - 予約済み, 常に 0. - - - - Bit 4 - 予約済み, 常に 0. - - - - Bit 3 - DMA Mode Select. Bit 0 - が「1」 (FIFO 有効) に設定されて いる場合, - このビットの設定は -RXRDY と -TXRDY - の処理を Mode 0 から Mode 1 へ 変更します. - - - - - Bit 2 - Transmit FIFO Reset. - このビットに「1」が書き込まれている場 合, - FIFO の内容は破棄されます. 現在送 - 信されているすべての命令は損なわれずに送 - られるでしょう. この機能は送信中止の場 - 合に役に立ちます. - - - - Bit 1 - Receiver FIFO Reset. - このビットに「1」が書き込まれている場 合, - FIFO の内容は破棄されます. 現在 shift - レジスタ内で組み立てられているすべ - ての命令は損なわれずに受信されるでしょ う. - - - - - Bit 0 - 16550 FIFO Enable. - 設定されている場合, 送信 / 受信両方の FIFO - が有効になります. holding レジス タ, shift - レジスタまたは FIFO 内のすべて の内容は, - FIFO が有効または無効になっ - た時点で失われます. - - - - - - - +0x02 - read - - - - - - - - - - - - Interrupt Identification - Register - - - - Bit 7 - FIFO有効. - 8250/16450 UART では, このビットはゼロ. - - - - Bit 6 - FIFO有効. - 8250/16450 UART では, このビットはゼロ. - - - - Bit 5 - 予約済み, 常に0. - - - - Bit 4 - 予約済み, 常に0. - - - - Bit 3 - Interrupt ID Bit #2. - 8250/16450 UART では, このビットはゼロ. - - - - - Bit 2 - Interrupt ID Bit #1 - - - - Bit 1 - Interrupt ID Bit #0. - これらの3つのビットは進行中の割り込み - を引き起こしたイベントのカテゴリを併せ - て報告します. これらのカテゴリは優先度 - を持つため, イベントの複数のカテゴリが - 同時に発生した場合, UART は最初に最も - 重要なイベントを報告し, ホストは報告さ - れた順に解決するでしょう. 現在の割り込 - みを引き起こしたすべてのイベントは, 新し - い割り込みが生成される前に解決されなけ - ればなりません (これは PC のアーキテク - チャの制限です). - - - - 2 - 1 - 0 - 優先度 - 説明 - - - - 0 - 1 - 1 - First - レシーバエラー (OE, PE, BI, - また FE) - - - - 0 - 1 - 0 - Second - 有効な受信データ - - - - 1 - 1 - 0 - Second - トリガーレベル識別子 - (受信バッファ中の古いデータ) - - - - 0 - 0 - 1 - Third - トランスミッタに - 命令用の空きがある - (THRE) - - - - 0 - 0 - 0 - Fourth - モデムの状態が - 変わった (-CTS, - -DSR, -RI, または - -DCD) - - - - Bit 0 - Interrupt Pending Bit. - このビットが「0」に設定されている場合, - 少なくとも一つの割り込みがペンディング - されています. - - - - - - - +0x03 - write/read - - - - - - - - - - - - Line Control - Register (LCR) - - - - Bit 7 - Divisor Latch Access - Bit (DLAB). 設定されている場合, - transmit/receive register (THR/RBR) と - Interrupt Enable Register (IER) - へのアクセスが無効にな ります. - 現在これらのポートへのすべてのア クセスは - Divisor Latch Register へリダ - イレクトされます. このビットの設定, Divisor - Register のローディング, そし て DLAB - のクリアは割り込みが無効になっ - ている状態でおこなわれるべきです. - - - - Bit 6 - Set Break. - 「1」に設定されている場合, トランスミッ - タはこのビットが「0」に設定されるまで - スペースを切り目なく送信します. これは - 送信されている文字のすべてのビットに優先 - します. - - - - Bit 5 - Stick Parity. parity - が有効になっている場合, このビッ - トの設定はビット4の値に基づき parity - を常に「1」か「0」にします. - - - - Bit 4 - Even Parity Select - (EPS). parity が有効でビット5が「0」の場合, - このビットの設定は偶数 parity が送信そ - して要求されるようにします. そうでなけ - れば奇数 parity が使用されます. - - - - Bit 3 - Parity Enable (PEN). - 「1」に設定されている場合, データの最 - 後のビットとストップビットの間に parity - ビットが挿入されます. また UART - は受信データに存在する parity を要求す - るでしょう. - - - - Bit 2 - Number of Stop Bits - (STB). 「1」に設定されている場合, 5-bit デー - タ命令を使用して, 1.5の Stop ビットが - 送信され各データ命令内に要求されま す. 6, 7 - そして 8-bit データ命令に対し ては, 2つの - Stop ビットが送信され要求 されます. - このビットが「0」に設定され ている場合, - 1つの Stop ビットが各デー - タ命令で使用されます. - - - - Bit 1 - Word Length Select Bit #1 - (WLSB1) - - - - Bit 0 - Word Length Select Bit #0 - (WLSB0) - - - - これらのビットは共に - 各データ命令内のビッ トの数を指定します. - - - - - 1 - 0 - 命令長 - - - - 0 - 0 - 5 Data - Bits - - - - 0 - 1 - 6 Data - Bits - - - - 1 - 0 - 7 Data - Bits - - - - 1 - 1 - 8 Data - Bits - - - - - - - +0x04 - write/read - - - - - - - Modem Control Register - (MCR) - - - - Bit 7 - 予約済み, 常に 0. - - - - Bit 6 - 予約済み, 常に 0. - - - - Bit 5 - 予約済み, 常に 0. - - - - Bit 4 - Loop-Back Enable. - 「1」に設定されている場合, UART のトラ - ンスミッタとレシーバは診断処理のために - 内部的に相互に接続されます. 付け加えて UART - のモデム制御出力はモデム制御入力 - に接続されます. CTS は RTS へ, DTR は - DSRへ, OUT 1 は R1 へ, OUT 2 は DCD へ - 各々接続されます. - - - - Bit 3 - OUT 2. ホストのプロセッサが high または - low に設定するであろう補助的な出力. IBM PC - のシリアルアダプタ (とクローンの殆ど) では, - OUT 2 は 8250/16450/16550 UART - からの割り込み信号をハイインピーダンス - (無効) にするのに使用されます. - - - - Bit 2 - OUT 1. ホストのプロセッサが high または - low に設定するであろう補助的な出力. IBM PC - のシリアルアダプタではこの出力は使用 - されません. - - - - Bit 1 - Request to Send (RTS). - 「1」に設定されている場合, UART の -RTS - ラインの出力は Low (有効) となり ます. - - - - - Bit 0 - Data Terminal Ready (DTR). - 「1」に設定されている場合, UART の -DTR - ラインの出力は Low (有効) となり ます. - - - - - - - - +0x05 - write/read - - - - - - - Line Status Register - (LSR) - - - - Bit 7 - Error in Receiver FIFO. 8250/16450 UART - では, このビットはゼロ です. - FIFOの中に次のエラー条件が一つ以 - 上含まれている場合, このビットは「1」 - に設定されます: PE, FE, または BI. - - - - Bit 6 - Transmitter Empty (TEMT). - 「1」に設定されている場合, 送信 FIFO - または送信 shift レジスタ中に残ってい - る命令はありません. トランスミッタは完 - 全に働いていません. - - - - Bit 5 - Transmitter Holding Register Empty - (THRE). 「1」に設定されている場合, 現在 FIFO - (または holding レジスタ) には少なくと - も一つの送信される付加的な命令に対する - 空きあります. このビットが「1」に設定 - されている時は, 多分トランスミッタはま - だ送信しています. - - - - Bit 4 - Break Interrupt (BI). レシーバは Break - シグナルを検知しました. - - - - Bit 3 - Framing Error (FE). Start - ビットが検知されましたが, Stop - ビットは要求された時間内には現れません - でした. 受信された命令はおそらく勝手に - 解釈されます. - - - - Bit 2 - Parity Error (PE). parity - ビットが受信された命令に対して 不正です. - - - - - Bit 1 - Overrun Error (OE). - 新しい命令が受信され, 受信バッファに空 - きがありませんでした. shift レジスタに - 新たに到着した命令は破棄されます. - 8250/16450 UART では, holding レジスタ - 内の命令は破棄され新たに到着した命令は - holding レジスタに置かれます. - - - - Bit 0 - Data Ready (DR) - 一つ以上の命令がホストが読むであろう受 信 - FIFO にあります. このビットが設定さ - れる前に, 命令は完全に受信され shift - レジスタから FIFO (または 8250/16450 - の設計では holding レジスタ) へ移動さ - れなければなりません. - - - - - - - +0x06 - write/read - - - - - - - Modem Status Register - (MSR) - - - - Bit 7 - Data Carrier Detect (DCD). UART の DCD - ラインの状態を反映します. - - - - Bit 6 - Ring Indicator (RI). UART の RI - ラインの状態を反映します. - - - - Bit 5 - Data Set Ready (DSR). UART の DSR - ラインの状態を反映します. - - - - Bit 4 - Clear To Send (CTS). UART の CTS - ラインの状態を反映します. - - - - Bit 3 - Delta Data Carrier Detect (DDCD). - ホストによって MSR が最後に読み込まれ - た時点から, -DCD ラインが状態を一回以 - 上変えた場合に「1」に設定されます. - - - - Bit 2 - Trailing Edge Ring Indicator (TERI). - ホストによって MSR が最後に読み込まれ - た時点から, -RI ラインが low から high - へ移り変わった場合に「1」に設定されま - す. - - - - Bit 1 - Delta Data Set Ready (DDSR). - ホストによって MSR が最後に読み込まれ - た時点から, -DSR ラインが状態を一回以 - 上変えた場合に「1」に設定されます. - - - - Bit 0 - Delta Clear To Send (DCTS). - ホストによって MSR が最後に読み込まれ - た時点から, -CTS ラインが状態を一回以 - 上変えた場合に「1」に設定されます. - - - - - - - +0x07 - write/read - Scratch Register (SCR). このレジスタは UART - では機能しません. この場所 には - どんな値でもホストによって書き込まれるこ とができ, - その後ホストによって読み込むことが可 - 能です. - - - - - - - - 16550A UART を越えて - - ナショナル・セミコンダクタは付加的な機能を持つ 16550 - と互換 性のある部品を提供していませんが, - 色々な他のベンダがそれを持っ ています. - これらの部品の幾つかは以下に記述されています. 効果的 - にこれらの改良を使用するためには, - 殆どのポピュラーなオペレーティ ングシステムが 16550 - が提供する機能以上のものをサポートしない ため, - ドライバはチップベンダから提供されなければならないことを - 理解しておく必要があります. - - - ST16650 - - デフォルトではこの部品は NS16550A - と似ていますが, 拡 - 張された32バイトの送受信バッファを - オプションで有効にで きます. StarTech - により製造されました. - - - - TIL16660 - - デフォルトではこの部品は NS16550A - と類似した振舞いを しますが, - 拡張された64バイトの送受信バッファをオプショ - ンで有効にできます. Texas Instruments - により製造されま した. - - - - Hayes ESP - - この専売特許のプラグインカードは, - 2048バイトの送受 信バッファを含み, 230.4Kbit/sec - のデータレートをサポー トします. Hayes - により製造されました. - - - - - これらのダムUART に加え, - たくさんのベンダがインテリジェ - ントシリアルコミニュケーションボードを製造しています. こ - のタイプの設計は通常マイクロプロセッサを提供しており, - このマイ クロプロセッサは幾つかの UART - へのインタフェースとなってデータ を処理 / - バッファリングし, そして必要な時にメインの PC のプロセッ - サへ警告を出します. UART - はこのタイプのコミニュケーションシ ステムにおいて PC - のプロセッサによって直接アクセスされないため, - ベンダにとっては 8250, 16450, または 16550 UART - と互換性のある UART を使用する必要はありません. - これにより設計者は, より良い - 性能特性を持つ部品が自由に利用できます. - - - - - <devicename>sio</devicename>ドライバの設定 - - sio ドライバは, NS8250-, - NS16450-, NS16550とNS16550A ベースの EIA RS-232C(CCITT V.24) - 通信用インタフェースをサポートします. ま た, - いくつかのマルチポートシリアルカードもサポートされています. - 技術的 な詳細についてはマニュアル &man.sio.4; - を見てください. - - - Digi International (DigiBoard) PC/8 - - 原作: &a.awebster;. - 1995年8月26日. - - 訳: &a.jp.masaki;.6 - September 1996. - - 以下にDigi International - PC/8Dと16550チップを動作させるための, カーネ - ルconfigの部分を示します. このボードは, - 8本の回線にすべてモデムを接続 - した場合でも良好に動作します. - - options COM_MULTIPORT - を加えるのを忘れないでください. 忘れる - とうまく動作しません! - - device sio4 at isa? port 0x100 tty flags 0xb05 -device sio5 at isa? port 0x108 tty flags 0xb05 -device sio6 at isa? port 0x110 tty flags 0xb05 -device sio7 at isa? port 0x118 tty flags 0xb05 -device sio8 at isa? port 0x120 tty flags 0xb05 -device sio9 at isa? port 0x128 tty flags 0xb05 -device sio10 at isa? port 0x130 tty flags 0xb05 -device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr - - ここで各 SIO - ポートが割り込みを共有する一つのグループであることを表現 - するために, トリッキーな設定をしなければなりません. フラグ - (flags の後 ろの 16 進数) の下から 2 - バイト目にこのグループの最後の SIO ポートの番 - 号を設定します. この例では 11 (16進数では 0x0b) ですから, - 各デバイスの フラグは 0xb05 となります. - - - - Boca 16 - - 寄稿: &a.whiteside;. - 1995年8月26日 - - FreeBSD で Boca 16pord - のボードを動かすことは簡単ですが, そのた - めにはいくつかの作業が必要です. : - - - - 2.0.5 のデフォルトのカーネルは, - マルチポートのサポートをして - いない ので, - あなたは各ポート毎にデバイスエントリを追加する必要が - あります. つまり必要なオプションを付けて, - カーネルの再構築をしなければ なりません. そのためには, - あなたのマシンにカーネルのソースコードが既に - インストールされているか, - あなたの替わりの誰かにカーネル再構築をやって - もらう必要があります. - - - - 2番目に, - あなたはカーネルオプションを正しく設定するために, あな - たのBoca Boardの IO - と割り込みの値を知っている必要があります. - - - - ひとつ重要なことがあります. Boca 16 - に使われている実際の UART チップ は, Boca 16 - のボードではなく, - 外付けのコネクタボックスの中に存在します. - コネクタボックスを接続しないと, - ポートの検出に失敗するでしょう. 私は, - 接続しないまま起動したり, - 後から接続しなおしたりした時にどうなるかをテ - ストしていません. - どちらも実行しないようお奨めします. - - もしあなたがカスタマイズ済みのカーネル - コンフィグレーションファイルを持っ ていなければ, - 一般的な事柄については, FreeBSD - カーネルのコンフィグレーション - を参考にしてください. 以下にBoca 16のボード - に関係する部分だけを記述します. この例では, - あなたがMYKERNELという名前 のカーネルを使っていて, - エディタには viを使っていることを仮定していま す. - - - - 次の1行をconfigファイルに追加してください. - - options COM_MULTIPORT - - - - この device - sionという行を, - 必要に応じて 16 個のデバイス分を追加してください. - 最後のデバイスにだけ, このボード - の割り込みベクタを記述します. (詳細は &man.sio.4; - のマニュア ルページを参照してください.) 以下の例は, - 割り込み 3, ベース IO アドレス 100h の値を持つ Boca - Board の場合です. 各ポートのための IO アドレスは, - 100h, 108h, 110h, ... のよ うに 16 進法で 8 - づつ加えていきます. - - device sio1 at isa? port 0x100 tty flags 0x1005 -device sio2 at isa? port 0x108 tty flags 0x1005 -device sio3 at isa? port 0x110 tty flags 0x1005 -device sio4 at isa? port 0x118 tty flags 0x1005 -… -device sio15 at isa? port 0x170 tty flags 0x1005 -device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr - - フラグエントリは, - あなたが全く同じsioの割り当てを使っていない限り - 必ず - 上記の例から変更してください. フラグは, - 次のように設定します. 0x M - YY - のMは, マスタポート (Boca - 16に搭載された最後 - のポート)のマイナー番号を指定します. さらに - YY の部分はFIFOが - 有効または無効であること (この場合は有効), 割り込みを - (ボード内で) 共 有しているか (この場合はYES), そして, - AST/4 と互換性のある持つ割り込み - 制御レジスタを持っているか (この場合はNO) - を指定します. この例では, - - flags 0x1005 - - というフラグによって, - マスタポートが sio16 であることを示します. も - し同じボードをもう一枚追加し, sio17 から sio28 - を割り当てるなら, 新しい方の - ボードに対応する 16 個のポートのフラグはすべて 0x1C05 - に なります. 28 (== 0x1C) - は新しいボードのマスタポートのマイナー番号で す. - フラグの 05 の部分は変更しないでください. - - - - カーネルコンフィグレーションファイルを - 保存してカーネルの設定を完了しま す. - カーネルをコンパイル後, インストールし, - 新しいカーネルでリブートし てください. - 再コンパイルされたカーネルがうまくインストールされて, - そのカーネルに正 - しいアドレスと割り込みが設定されていたならば, - ブートメッセージは次の ように Boca - ポートの検出に成功するはずです: (sioの番号, - IOとIRQの値は, この例とは異なっているでしょう) - - sio1 at 0x100-0x107 flags 0x1005 on isa -sio1: type 16550A (multiport) -sio2 at 0x108-0x10f flags 0x1005 on isa -sio2: type 16550A (multiport) -sio3 at 0x110-0x117 flags 0x1005 on isa -sio3: type 16550A (multiport) -sio4 at 0x118-0x11f flags 0x1005 on isa -sio4: type 16550A (multiport) -sio5 at 0x120-0x127 flags 0x1005 on isa -sio5: type 16550A (multiport) -sio6 at 0x128-0x12f flags 0x1005 on isa -sio6: type 16550A (multiport) -sio7 at 0x130-0x137 flags 0x1005 on isa -sio7: type 16550A (multiport) -sio8 at 0x138-0x13f flags 0x1005 on isa -sio8: type 16550A (multiport) -sio9 at 0x140-0x147 flags 0x1005 on isa -sio9: type 16550A (multiport) -sio10 at 0x148-0x14f flags 0x1005 on isa -sio10: type 16550A (multiport) -sio11 at 0x150-0x157 flags 0x1005 on isa -sio11: type 16550A (multiport) -sio12 at 0x158-0x15f flags 0x1005 on isa -sio12: type 16550A (multiport) -sio13 at 0x160-0x167 flags 0x1005 on isa -sio13: type 16550A (multiport) -sio14 at 0x168-0x16f flags 0x1005 on isa -sio14: type 16550A (multiport) -sio15 at 0x170-0x177 flags 0x1005 on isa -sio15: type 16550A (multiport) -sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa -sio16: type 16550A (multiport master) - - もしメッセージの表示が速くて読み取れないときは, - - &prompt.root; dmesg | more - - とするとブート時のメッセージを - ゆっくり見ることができます. - - - - 次に, root になってから, - デバイスにあわせたエントリを - /dev/MAKEDEV - スクリプトを使って/dev - に追加します. - - &prompt.root; cd /dev -&prompt.root; ./MAKEDEV tty1 -&prompt.root; ./MAKEDEV cua1 -(中略) -&prompt.root; ./MAKEDEV ttyg -&prompt.root; ./MAKEDEV cuag - - もし, 何らかの理由で発信するデバイスが不要な場合, - cua* デバ - イスを作らないで済ますこともできます. - - - - デバイスが確実に動作しているかどうか - 確認する手っ取り早い方法は, あなたが (rootになって) - 各ポートにモデムを接続してみて, あなたが作成し - た各デバイス毎に - - &prompt.root; echo at> ttyd* - - とやってみてください. 各ポー トが動作していれば - RXの表示が光るのが見えるはず - です. - - - - - - 安価な Multi-UART カードのサポート - - 寄稿: Helge Oldach - hmo@sep.hamburg.com, September - 1999 - - 二つ(またはもっと多くの) COM ポートを備えた - 20$ のマルチ I/O カードでの IRQ 共有が, - FreeBSD でサポートされているか心配ですって? - 次のようにすれば使うことができます. - - 通常, この種のボードをサポートする場合には, - 各ポートに対して個別に IRQ を割り当てて利用します. - 例えば, マザーボード上に COM1 ポート - (sio0–I/O アドレス 0x3F8, IRQ 4) - があり, 二つの UART ポートがついている拡張カードがあるとしましょう. - その場合, この二つのポートには, 二番目のポートを - COM2(sio1–I/O - アドレス 0x2F8, IRQ 3) に, 三番目のポート(sio2)を - I/O アドレス 0x3E8, IRQ 5 に設定する必要があります. - しかしすぐわかるとおり, この方法では IRQ 資源を無駄に浪費します. - 基本的に前セクションに記されている COM_MULTIPORT - の設定に従えば, 拡張カード上の二つのポートで一つの IRQ を使用するように - セットアップすることができます. - - そのような安価な I/O ボードには大抵, - 次に示すような, COM ポートを選択する 4x3 - のジャンパマトリクスがついています. - - o o o * -Port A | - o * o * -Port B | - o * o o -IRQ 2 3 4 5 - - これは, Port A が IRQ 5 に, Port B が IRQ 3 - に結線されていることを示しています. - IRQ の並びはボードにより異なるでしょう—例えば, 他のボードは - IRQ として 3,4,5,7 が選択できるようになっているかも知れません. - - 「ああ, IRQ を共有するには IRQ 3 の列にある 3 - つの接続点をつなぐようなジャンパ線を手作りして, - 両方のポートが IRQ 3 になるように結線すれば良いのか」と - 考えるかも知れませんが, それは正しくありません. - UART の出力段は トーテムポール 接続(*)されているので, - IRQ 3 に複数接続することはできないのです. - そのため, もし UART のどれか一つが IRQ 3 を発行したとしても, - それが期待するような動作になりません. - 拡張ボードやマザーボードの実装に依存することですが, - IRQ 3 信号線は常時 H レベルか, L レベルを保っています. - - - - 訳注: - トーテムポール とは, ディジタル論理回路を構成する - TTL ロジック IC の内部構造の一種です. トーテムポール型出力の場合には - 出力同士を接続すると短絡電流が流れてしまうため, - CPU やメモリで使われている, いわゆるバス接続が使えないという特徴を持っています. - IRQ 信号線が常時 H か L レベルに保たれる, というのは, - 割り込み信号線が正論理/負論理のどちらになっているかが実装に依存することによります. - 以降の解説は, 正論理を仮定して書かれていますのご注意下さい. - - - したがって, 二つの UART の IRQ 出力を分離する必要があります. - そのためには, どちらかの UART が IRQ を発行した時にだけ, - ボード上の IRQ 信号線が H レベルになり, - そうでない時には L レベルになるようにします. - 以下の解決法は, Joerg Wunsch - j@ida.interface-business.de - から提案されたものです: - 二つのダイオード(ゲルマニウム, あるいはショットキー型を強く推奨)と - 1 キロオームの抵抗器一本で, ワイヤード OR を構成します. - 以下に示すのは, 上に示した 4x3 ジャンパの回路図です. - - Diode - +---------->|-------+ - / | - o * o o | 1 kOhm -Port A +----|######|-------+ - o * o o | | -Port B `-------------------+ ==+== - o * o o | Ground - \ | - +--------->|-------+ -IRQ 2 3 4 5 Diode - - 各ダイオードのカソード側は接地点に, - 1 キロオームのプルダウン抵抗器と直列にして接続します. - プルダウン抵抗を接続することはとても重要です. - これはバス上の IRQ 信号線がフロート状態になるのを防ぎます. - - さあ, これでカーネルの設定を変更する準備ができました. - 上に示すような例の場合, 次のような設定になります. - - # standard on-board COM1 port -device sio0 at isa? port "IO_COM1" tty flags 0x10 -# patched-up multi-I/O extension board -options COM_MULTIPORT -device sio1 at isa? port "IO_COM2" tty flags 0x205 -device sio2 at isa? port "IO_COM3" tty flags 0x205 irq 3 - - sio1 と - sio2 の flags - 設定は非常に重要です. 詳細は &man.sio.4; をご覧ください. - (一般的には, "flags" 属性の 2 は, - sio2 の IRQ - を使用するということを示します. - 下位ニブル(訳注: 16 進数一桁のこと) は間違いなく - 5 とするでしょう.) - カーネルの verbose モードが ON になっていると, - こんな風な出力が得られます. - - sio0: irq maps: 0x1 0x11 0x1 0x1 -sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa -sio0: type 16550A -sio1: irq maps: 0x1 0x9 0x1 0x1 -sio1 at 0x2f8-0x2ff flags 0x205 on isa -sio1: type 16550A (multiport) -sio2: irq maps: 0x1 0x9 0x1 0x1 -sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa -sio2: type 16550A (multiport master) - - /sys/i386/isa/sio.c は - irq maps 配列を使っているために - 表示が少々難解なのですが, 基本的なアイデアは - 1,3,4 番目の場所に 0x1 - があるかどうか調べる, というものです. - これはつまり, 対応する IRQ が出力された時にセットされ, - その後クリアされるという, ちょうど期待する動作が - 行なわれることを意味します. - もし, カーネルがこのような表示を出力しない場合, - 大部分は結線の誤りによるものでしょう. - - - - - <devicename>cy</devicename> ドライバのコンフィグ - - 原作: Alex Nash. - 6 June 1996. - - 訳: &a.jp.yuki;. - 6 September 1996. - - Cyclades 社のマルチポートカードは, - 他のマルチポートカードが 使う sio - の代わりに cyドライバを使います. - コンフィグレーションは非常に簡単で, - - - - cy デバイスをあなたの カーネルの - コンフィグレーションに足します. (注意. - あなたのirqやiomemの設定が違っているかもしれません) - - device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr - - - - 新しいカーネルの 再構成と - インストール をします. - - - - デバイスノード - を次(8ポートと仮定しています.) - のように打って作ります: - - &prompt.root; cd /dev -&prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done - - - - もし, 必要なら シリアルデバイス - (ttyd) とそっくりにコピーして dialupエントリを作り, - ttydの代わりに - ttycを使います. 例: - - ttyc0 "/usr/libexec/getty std.38400" unknown on insecure -ttyc1 "/usr/libexec/getty std.38400" unknown on insecure -ttyc2 "/usr/libexec/getty std.38400" unknown on insecure -… -ttyc7 "/usr/libexec/getty std.38400" unknown on insecure - - - - 新しいカーネルで立ち上げます. - - - - - - <devicename>si</devicename> ドライバのコンフィグ - - 原作 &a.nsayer;. 25 March - 1998. - - 訳: &a.jp.yoshiaki;. - 29 Apr 1999. - - マルチポートカードのSpecialix SI/XIO と SX は - si ドライバを使います. - 1台のマシンで4枚までのホストカードを使うことが - できます. 以下のホストカードがサポートされています: - - - - ISA SI/XIO host card (2 versions) - EISA SI/XIO host card - PCI SI/XIO host card - ISA SX host card - PCI SX host card - - - SX と SI/XIO ホストカードは明らかに違いがあるように見えますが - これらの機能は基本的には同じものです. ホストカードはI/O空間を - 利用しませんが, 代りに32Kブロックのメモリ空間を使います. - ISAカードの工場出荷時の設定は0xd0000-0xd7fff - です. - これらはIRQを必要とします. PCIカードではもちろん自動設定されます. - - - ホストカードには最大4個の外部モジュールが接続できます. - 外部モジュールにはそれぞれ4/8本のシリアルポートが内蔵されています. - モジュールは以下の品種があります. - - - SI 4 ポート/ポート モジュール. ポートそれぞれ - 最大 57600 bps がサポートされます. - - XIO 8 ポートモジュール. ポートそれぞれ最大 - 115200 bps がサポートされます. XIOモジュールには 7 - シリアルポートと1 パラレルポート のタイプもあります. - - SXDC, 8ポートモジュール. - ポートそれぞれ最大921600 bps がサポートされます. XIOと同様, - 1つのパラレルポートを持つモデルがあります. - - - ISA ホストカードを設定するには以下の行を - カーネルコンフィグレーション - ファイルに追加します. 数値は適当なものに変更してください. - - device si0 at isa? tty iomem 0xd0000 irq 11 - - 有効なIRQ番号は SX ISA ホストカードでは 9, 10, 11, 12, 15 で - SI/XIO ISAホストカードでは 11, 12, 15 です. - - EISAやPCIカードの設定は, 以下の行を使います: - - device si0 - - コンフィグレーションエントリを追加した後で, 新しいカーネルの - 再構築とインストール - を行ないます. - - 新しいカーネルで再起動した後に, デバイスノード を /dev 以下に - 作成する必要があります. MAKEDEVスクリプト - で注意深く行なってください. 利用するポートの数をタイプします: - - - &prompt.root; cd /dev -&prompt.root; ./MAKEDEV ttyAnn cuaAnn - - (nn はポートの数に置き換えます. - - - login プロンプトにこれらのポート番号を表示させたい場合 - は/etc/ttys - に以下の行を追加する必要があります: - - ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure - - ターミナルタイプは適当なものに変更してください. - 例えばモデムの場合はdialup あるいは - unknownが適当でしょう. - - - - - * パラレルカード - - - - - - * モデム - - - - - - * ネットワークカード - - - - - - * キーボード - - - - - - マウス - - 寄稿: Joel Sutton - jsutton@bbcon.com.au, 2000 年 1 月. - - FreeBSD は PS/2 ポート, シリアルポート, USB - ポートを経由して様々な種類のマウスをサポートしています. - mouse デーモンを使うとマウスを X - とシステムコンソールの両方で利用することができるため, - 多くの人は mouse デーモンを使うことを選んでいます. - mouse デーモンに関する詳細は, &man.moused.8; を参照してください. - この章の例では, mouse デーモンが使われていることを前提にしています. - - - - この節に書かれている各種製品の名前は, 著者が FreeBSD 上で - 動作することを確認したものであり, - ここに書かれていない他の同様のデバイスも動作する可能性があります. - - - - - PS/2 マウス - - - システム設定 - - PS/2 マウスが mouse デーモンで正しく機能するように設定するには, - 以下の行を /etc/rc.conf - に加える必要があります. - - moused_enable="YES" -moused_type="ps/2" -moused_port="/dev/psm0" - - - - 利用できることが分かっている機器 - - - - Logitech First Mouse - 3 ボタン - - - - マイクロソフト社製シリアル-PS/2 互換マウス - - - - - - - シリアルマウス - - - システム設定 - - シリアルマウスが mouse デーモンで正しく機能するよう設定するには, - 以下の行を /etc/rc.conf - に加える必要があります. この例では, マウスが - COM1: に接続されていて, - そのマウスが mouse - デーモンによって自動的に認識されることを前提としています. - - moused_enable="YES" -moused_type="auto" -moused_port="/dev/cuaa0" - - 特定の種類のシリアルマウスで mouse - デーモンを使用する設定に関しては, &man.moused.8; - にある詳細な説明をご覧ください. - - - - 利用できることが分かっている機器 - - - - 一般的なマイクロソフトマウス互換品 - - - - Logitech First Mouse - 3 ボタン - - - - マイクロソフト社製シリアル-PS/2 互換マウス - - - - - - - USB - - - システム設定 - - USB デバイスドライバは比較的最近 FreeBSD に追加されたもので, - まだ GENERIC カーネルには含まれていません. 以下の手順は, - 典型的なシステムで関連するドライバをいかに組み込むかという一例です. - - - - ums デバイスをあなたの - カーネルコンフィグレーション - の usb セクションに追加します. たとえば, 次のようにします. - - - controller usb0 controller uhci0 device ums0 - - - - 新しいカーネルを - 再構築してインストールします. - - - - デバイスノード(device - node) を作ります. それには, 以下のように入力します: - - &prompt.root; cd /dev -&prompt.root; sh MAKEDEV ums0 - - - - 以下の内容を /etc/rc.conf に追加し, - mouse デーモンが正しく動作するように設定します. - - moused_enable="YES" -moused_type="auto" -moused_port="/dev/ums0" - - - - システムを再起動します. - &prompt.root; shutdown -r now - - - - - - 利用できることが分かっている機器 - - - - Logitech TrackMan - Marble Wheel - - - - - - - - * その他 - - - - - -]]> - - - - 記憶装置 - - - ESDIハードディスクの使い方 - - 原作および Copyright © 1995, &a.wilko;. - 24 September 1995. - - 訳: &a.jp.ts; - 2 September 1996. - - ESDIとは Enhanced Small Device Interfaceの略語です. - この技術は, 馴染み 深い ST506や - ST412といったインタフェースに基づくものであり, 世界初の普 及型 - 5.25インチのウィンチェスタディスクを造ったSeagate - Technology社に よって最初に作られました. - - ESDIの Eは拡張 (Enhanced) を表しており, - 実際そのとおりです. まず, イン タフェースの速度は速く, 10 - ないし 15Mビット/秒であり, ST412インタフェー - スに接続したドライブの 5Mビット/秒よりも高速です. また, - 上位レベルのコ マンドがいくつか追加されて, - オペレーティングシステムレベルのドライバ作 成者にとって, - ESDIインタフェースはある程度インテリジェントなものとなり - ました. ただし SCSIほどにインテリジェントではありません. - ESDIは ANSIが 標準化をおこなっています. - - トラックごとのセクタ数を増やすことで, - ESDIドライブの記憶容量は引き上げ られました. 通常, - トラックあたり 35セクタですが, 今までに筆者がみたド - ライブの中で大容量のものは, トラックあたり - 54セクタもありました. - - ESDIは IDEや - SCSIといったインタフェースの普及によって消えつつあります が, - 無料あるいは在庫処分の 格安なドライブが入手可能であることを - 考えると, 少ない (もしくは現状の) - 予算で縛られたシステムにとって, ESDIドライブは - 理想的です. - - - ESDIのコンセプト - - - 物理的な接続 - - ESDIインタフェースでは, - ドライブごとに2つのケーブルを接続します. 第 1 - のケーブルは34ピンのフラットケーブルエッジコネクタで, - コントローラとド ライブ間のコマンドおよびステータスの - 両信号のやりとりのためのものです. コマンド用ケーブルは, - すべての ESDIドライブをデイジーチェーンで結び ますから, - すべてのドライブを接続したバスを構成することに - なります. - - 第 2 のケーブルは 20 ピンのフラットケーブル - エッジコネクタで, ドライブへの データ入出力に使います. - このケーブルは放射状に接続しますから, ドライブ - ごとにコントローラへの専用接続を持つことに - なるわけです. - - 筆者の経験によれば, PC向け ESDI コントローラには, - コントローラあたり最 大 2 - 台までのデバイス接続が可能という制限がありました. これは, - ドライ ブのアドレス割り当てのために, - 単一ビットだけを用意したという WD1003 か - ら持ち越された互換 (?) 機能なのだと思われます. - - - - デバイスのアドレス指定 - - 1本のコマンドケーブルには最大で 7つのデバイスと - 1つのコントローラを接 続することができます. - どのドライブをコントローラがアドレスしているのか - を個別に認識できるようにするために, ESDIデバイスは, - デバイスアドレスを - 設定するためのジャンパかスイッチを備えています. - - PC向けコントローラでは, - 最初のドライブにはアドレス0を設定し, 第2番目の - ディスクへはアドレス1を設定します. - いつも留意すべきことは, - ディスクごとに固有のアドレスを必ず設定するということです! - つまり, コン トローラあたり最大2台のドライブというような - PC向けのものでは, 第1 ドラ イブは第0番ドライブで, - 第2ドライブは第1番ドライブだということです. - - - - ターミネート処理 (termination) - - デイジーチェーン接続用コマンドケーブル - (34ピンのケーブルであることを覚 えていますか? ) では, - 最後のチェーン接続ドライブでターミネートしなけれ - ばなりません. このために, - ESDIドライブにはターミネート用抵抗ネットワー - クが付属しており, - ターミネートする必要がないときにはその抵抗をドライブ - から外したり, またはジャンパで無効 (disable) - にすることができるようになっ ています. - - したがって, ひとつのドライブ, - すなわちコマンドケーブルの最終端に位置す - るドライブだけが, - そのターミネート用抵抗を有効 (installまたは enable) - にすることができます. - コントローラは自動的にコマンドケーブルのもう一方 - の端のターミネート用抵抗を有効にします. - ご注意いただきたいのは, コント - ローラは必ずコマンドケーブルのいずれかの - 端に位置しなければならず, けっ - して途中に位置するようにしては - いけない ということです. - - - - - ESDIディスクの FreeBSDでの使い方 - - ESDI を初めて動かすようにすることが, - どうしてこうも大変なことなのでしょ うか ? - - ESDIディスクを FreeBSD - で動かそうと試みた人たちが激烈なイライラを募らせ - たことは知られています. 今までまったく - ESDIを知らない場合には, 複数の 要因の組み合わせが悪く働いて, - ESDIへの理解を妨げることになるかもしれま せん. - - このことは, ESDIと - FreeBSDの組み合わせは選んではいけないという俗説も生 - み出しました. 以下の節において, 落し穴のすべてとその解決策を - 述べてみようと思います. - - - ESDI速度の違い - - すでに簡単に紹介したように, - ESDIは2種類の速度を持っています. 旧式のド - ライブとコントローラは 10Mビット/秒のデータ転送速度ですが, - 新しいもの では 15Mビット/秒が利用できます. - - 仮に 10Mビット/秒のコントローラへ - 15Mビット/秒のドライブを接続したよ - うな場合に問題が生じることを予想することは簡単です. - したがって必ず, コ ントローラ および - ドライブのマニュアルを参照して, それぞれの 転送速度が - 一致しているかどうかを調べるようにしてください. - - - - トラックについて - - 主流の ESDIドライブは, - トラックあたり34ないし36個のセクタを持ちます. - しかし大部分の (古い) - コントローラは36個以上のセクタを扱うことができま - せん. - - 新しい大容量のドライブでは, - トラックごとにさらに多くの数のセクタを持つ ことができます. - たとえば筆者の 670MBのドライブは, トラックあたり 54セ - クタも持たせることができます. - - 筆者のコントローラは 54 - セクタ数をサポートしていませんでしたが, トラック あたり 35 - セクタという設定で, 問題なく動作しました. しかし, - これが意味す - るのは大量のディスク容量を失うということです. - - もう一度, - 詳しい情報についてハードウェアのドキュメントを - 調べてください. - この例のような仕様からはずれた設定をしたときには, - うまく動くかもしれま せんが, 動かないこともあります. - そのようなときには, 別のより多くの機能 - をもつコントローラで試してみるようにしてください. - - - - ハードセクタとソフトセクタ - - 多くの ESDIドライブでは, - ハードセクタまたはソフトセクタによる処理を, - ジャンパ設定で指定することができます. ハードセクタとは, - 新しいセクタの 開始位置において, - ESDIドライブにセクタパルス (sector pulse) を発生させ - ることです. コントローラはこのパルスを利用して, - 書き込みや読み取りのタ イミングを指示します. - - ハードセクタではセクタのサイズを選ぶことができます - (通常はフォーマット 後セクタあたり256, 512, - および1024バイト). FreeBSDは512バイトのセクタ - サイズを使います. トラックあたりのセクタ数は, - 同じように選択に幅があり ますが, - フォーマット後のセクタのバイト数はすべて同じです. - セクタごとの 未フォーマット - のバイト数は, コントローラがどの程度の調整用の - バイト数を必要とするかによって異なります. - トラックあたりのセクタ数を多 くすれば記憶容量は増えますが, - もしドライブから与えられるバイト数よりも - 多くのものをコントローラが必要とするのであれば, - 問題を生じることがあり ます. - - ソフトセクタでは, - コントローラ自身が読み書きの始まりと終りの位置を決め ます. - なお, ESDI (筆者が知り得たものすべて) では, - ハードセクタがデフォ ルトのようです. - ソフトセクタを試みる必要性は感じたことがありません. - - 通常, FreeBSDをインストールする以前に, - まずセクタ処理の設定を試される ことをおすすめします. - というのも, セクタ処理の設定を変えるたびに, 物理 - フォーマット (low-level format) - をしなければならないからです. - - - - 物理フォーマット処理 - - ESDIドライブは, 使い始める前に, - 物理フォーマットをおこなう必要があります. - もしトラックあたりのセクタ数を変えたり, - ドライブの物理的な設置方法 (水 平や垂直方向) - を変えたときには, ふたたびフォーマットする必要があります - から, よく検討した後でフォーマットしてください. - フォーマット処理の所要 時間を短く予想してはいけません. - 大容量のディスクでは数時間を要します. - - 物理フォーマットが終わったならば, サーフィススキャン - (surface scan) を おこない, - バッドセクタの検出とフラグの処理をします. - ほとんどのディスクには, - メーカが作成したバッドブロックリストを - 記録した用紙またはステッカーが付 いています. さらに, - ほとんどのディスク内にもバッドブロックリストが記録 - されています. - メーカが作成したリストを利用するようにしてください. この - 時点で不良部分をマップし直す方が, - FreeBSDのインストール後におこなうよりも, - はるかに簡単です. - - 物理フォーマットプログラムのなかでも, - トラックの中にひとつでもバッドセ クタがあれば, - 同じトラック内の残りのすべてのセクタを不良とするようなプ - ログラムがありますから, - そのようなものは利用しないようにしてください. - ディスクスペースの浪費だけでなく, より重大な - bad144と関連した悲劇の原 因にもなるからです - (bad144の節を参照のこと). - - - - トランスレーション - - トランスレーションが, - ESDIだけに限定された問題ではないにもかかわらず, - 重大な困難になることがあります. - トランスレーションにはいくつかの側面が あります. - 多くに共通なものは, IBM - PC/ATのオリジナルの設計に起因するディ - スクジオメトリに関する制限を, - うまく回避するような調整を試みるものです (IBM に感謝 ! - ). - - まずはじめに, 1024シリンダに関する (悪) - 名高い制限があります. すなわ ち, - ブート可能なシステムについて, システム関連ファイルは - (オペレーティ ングシステムがどのようなものであっても) , - ディスクの先頭部分の 1024シ リンダ内になければいけない, - という制限です. シリンダ番号を表すためには - 10ビットしか与えられていません. セクタの総数については, - 上限は 64 (0か ら 63) です. この1024シリンダの制限を, - 16ヘッドの制限 (これも ATの仕様 による) と組み合わせると, - かなり限定されたディスク容量しか利用できませ ん. - - この難点を解消するために, PC 向け - ESDIコントローラのメーカは, 自社のコ ントローラボードへ - BIOS PROM拡張を施しました. この BIOS拡張の内容は, - ブート時のディスクI/Oを (OSによっては - すべて のディスクI/Oも) , - トランスレーションを用いておこなうというものです. - すなわち, 大容量のディ スクを, あたかも 32 - ヘッドかつトラックあたり 64 セクタであるようなデバイス - として OSへ知らせるのです. この結果, 総シリンダー数は - 1024よりも少なく なりますから, - 上記の難点などなかったものとして大容量ディスクを使うこと - ができるようになります. なお, 注目いただきたいことは, - FreeBSDカーネル の起動以降, FreeBSDはこの - BIOS拡張機能を使わないということです. 詳しく - は後ほどご説明いたします. - - トランスレーションの第 2 の存在理由は, - 多くの旧いシステムBIOSが, トラッ クあたり 17 - セクタのドライブだけしか扱えない (ST412 という古い仕様) - から, というものです. 比較的新しい BIOSは通常, - 自由な値を設定できるドライブ タイプ - (多くの場合ドライブタイプ47) を持っています. - - - この文書を読み終えられた後で, - どのようにトランスレーションを利用す るにせよ, - ぜひご留意いただきたいことがあります. もし複数の - OSをひとつ のディスクにインストールするときには, - 必ず同じトランスレーションを使わ なければなりません. - - - - トランスレーションに関して, - 筆者が使用したコントローラは, ひとつのドラ - イブを複数のパーティションに論理的に - 分けることができる機能を BIOS のオ - プションとして持っていました - (このような製品はいくつかあると思われる). しかし, - ひとつのドライブにはひとつのパーティションに限定しました. - なぜ なら, このコントローラはパーティション情報を - ディスクへ書き出すからです. つまり, 電源を入れると, - コントローラはこの情報を読み取り, OSに対してディ - スクから読みとった情報に基づくデバイスとして - 知らせるからです. - - - - 代替セクタ処理 - - 多くの ESDI コントローラはバッドセクタを - 取り替える機能を備えています. - ディスクの物理フォーマット処理の途中もしくは終了時に, - バッドセクタであ ることを記録して, - 代わりのセクタを壊れたセクタの位置へ (論理的に) 置き - ます. - - 通常この置き換え処理は, トラック内の N-1 - 個のセクタを実際のデータ記録に 使い, - 第N番目のセクタだけを代替セクタとすることで実現します. - ここでNと いう値はトラック内の物理的セクタの総数です. - このアイデアが生まれた背景 は, - オペレーティングシステムが壊れたセクタを持たない 「完全」 - なディスク を想定している, というものです. しかし - FreeBSDではこのアイデアを使うこ とはできません. - - 理由は, 使用不可 (bad) から - 使用可能 への変換をおこなう のが - ESDIコントローラ上の BIOSだからなのです. FreeBSDは, 真の - 32ビット のオペレーティングシステムであるために, - ブート後には BIOSを使いません. 代わりに - FreeBSDが使うのは, - ハードウェアと直接「対話」するデバイスドラ - イバというものです. - - 結論: - 代替セクタ処理やバッドブロックマッピングなど, - コントローラ・ メーカがなんと呼ぶかは判りませんが, - それらに似た機能を FreeBSDのディス - クへは使わないでください. - - - - バッドブロックの取り扱い - - 前節から残された問題があります. すなわち, - コントローラによるバッドブロッ - ク処理は利用できない状況であるにもかかわらず, - FreeBSDのファイルシステ - ムが想定しているのはあくまで完全無欠なディスクである, - という問題で す. これを解消するために, FreeBSDは - bad144 というツールを採用 しています. - この bad144 (この名前は - DEC社の標準となったバッドブロック 処理に由来している) は, - FreeBSDのスライスごとにバッドブロックを調べま す. - バッドブロックを見つけ出すと, bad144 - は傷ついたブロック番号によるテー ブルを - FreeBSDスライスの末尾へ書き込みます. - - ディスクが動作し始めると, - ディスクから読みとられたテーブルを基に, ディ - スクアクセスを調べます. この bad144 - リストに記録されたブロック番号への 要求が起こると, - 代わりのブロック (同じく FreeBSDスライスの末尾に位置す る) - を使います. このように, bad144 - による置換手続きによって 「完全」 なディ スクを FreeBSD - ファイルシステムへ提供しているのです. - - bad144 - の使用により陥るかもしれない落し穴があります. まず, - ひとつのス ライスには 126 - 個以上のバッドセクタを持てません. もしドライブに 126 - 個以上 のバッドセクタがあったときには, 複数の FreeBSD - のスライスに分けて, 各ス ライスのバッドセクタが 126 - 個以下となるようにする必要があります. くれぐ れも, - ひとつのトラック内にたったひとつの欠陥セクタが - 見つかっただけで, そのトラック内セクタ - すべて - を傷ついたものとして記録するよう - な物理フォーマットプログラムを使わないようにしてください. - 簡単にお解り いただけると思いますが, - このような物理フォーマットをおこなえば, 126個の制 - 限は短時間で達成してしまいます. - - 次に, もしスライスが root - ファイルシステムを含んでいるときには, 1024シ - リンダ以内という BIOSの制限を守っていなければなりません. - ブート処理の ときですから, bad144 リストは BIOS - を使って読み取りますので, このリスト が 1024 - シリンダ限界以内に位置していなければ読みとれません. - - - この制限は root - ファイルシステム だけ - が1024シリンダ限界以内にあれば十分ということではなく, - rootシステムを含 んだ スライス - 全体が1024シリンダ限界以内におさまっている必要 - があります. - - - - - カーネルのコンフィグレーション - - ESDIディスクを扱うドライバは, IDEや ST412 - MFMディスクなどと同じ wd ドライバです. - この wd ドライバは, すべての WD1003 - 互換インタフェースにも利用できるはずです. - - 大部分のハードウェアは, ジャンパの設定によって, - ふたつの I/Oアドレス範 囲と IRQ 値のうちから, - それぞれひとつを選ぶことができます. したがって, wd - タイプのふたつのコントローラを - ひとつのシステムで使うことができます. - - もし設定しようとしているハードウェアが - 標準以外の割り当てをサポートして いれば, - 適切な設定情報をカーネルのコンフィグレーションファイルに - 記述す ることで, この非標準割り当てを利用できます. - 次にカーネルのコンフィグレー ションファイルの例を示します - (このファイルがあるディレクトリは - /sys/i386/conf である). - - # First WD compatible controller -controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr -disk wd0 at wdc0 drive 0 -disk wd1 at wdc0 drive 1 - -# Second WD compatible controller -controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr -disk wd2 at wdc1 drive 0 -disk wd3 at wdc1 drive 1 - - - - - ESDIハードウェアの例 - - - Adaptec 2320コントローラ - - 筆者は, ACB-2320でコントロールされた ESDIディスクへ, - FreeBSDをインストー ルすることができました. なお, - このディスクには他のオペレーティングシス - テムをインストールしていません. - - インストールするために, まず, - NEFMT.EXE (www.adaptec.com から - ftp可能) - でディスクを物理フォーマットし, かつトラックを代替セ - クタとともにフォーマットするかどうかの設問に - NOと答えました. また ACB-2320の - BIOSは使わないように設定しました. そしてシステム - BIOSがブー トできるように, システム - BIOSの自由に設定可能 - オプションを使いまし た. - - 実は, NEFMT.EXEを使う以前に, まず - ACB-2320 の BIOSに組み込まれているフォー - マットプログラムでディスクをフォーマットしてみましたが, - 使えないことが 判りました. なぜなら, - 代替セクタの処理をおこなわないようにするオプションが - 用意されていないからです. - 代替セクタ処理をおこなうようにすると, FreeBSDの - インストール作業は - bad144の実行の段階で失敗しました. - - もし ACB-232xy - をお持ちであれば, そのバージョン番号に注意してください. - 文字 x には - 0 か 2 が入りまして, - ボード上にフロッピーコントローラがあるかど - うかを見分けることができます. - - - 文字 yはさらに興味深いもので, - ブランクか, A-8か, または - Dのいずれかで す. ブランクは, - 単純な10Mビット/秒のコントローラであることを表します. - A-8は, 15Mビット/秒のコントローラで, - かつ 52セクタ/トラックをサポート - しているものであることを表します. Dは, - 15Mビット/秒のコントローラで, かつ 36セクタ/トラック以上 - (52セクタも可能か?) のドライブをサポートし - ているものであることを表します. - - このコントローラのすべてのバージョンはインターリーブ比 - 1:1に対応してい るはずです. FreeBSDは充分高速なので, ぜひ - 1:1と指定してください. - - - - Western Digital WD1007コントローラ - - 筆者は, WD1007でコントロールされた ESDIディスクへ, - FreeBSDをインストー ルすることができました. 正確には - WD1007-WA2というコントローラでした. - これ以外の複数のバージョンも WD1007にあります. - - 利用できるようにするために, - セクタトランスレーションとWD1007の BIOSと - を使わないように設定しました. この設定の意味は, - BIOSに組み込まれた物理 - フォーマットプログラムを使えないようにしたということです. - 代わりに, www.wdc.comから - WDFMT.EXEを入手して, - ディスクをフォーマットし ました. 以後, - 順調に動いています. - - - - Ultrastor U14Fコントローラ - - ネットに流れたいくつかの報告によれば, Ultrastorの - ESDIボードも FreeBSD で動作するようです. - 実際の設定についての詳しい情報はありません. - - - - - 追加資料 - - 本格的に ESDIのプログラミングを計画している方は, - 次の公式規格仕様書を 入手なさることをおすすめします. - - 最新の ANSI X3T10 委員会の文書は次のものです： - - Enhanced Small Device Interface (ESDI) - [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] - - USENETのニュースグループ comp.periphs は, - 詳しい情報を得ることができる注目すべきもので す. - - World Wide Web (WWW) もまた便利な情報源です. Adaptec社の - ESDIコントロー ラについては http://www.adaptec.com/ を参照ください. Western Digital 社のコントローラについては http://www.wdc.com/ を参照ください. - - - - 感謝 - - Andrew Gordon氏より, テスト用の Adaptec - 2320コントローラと ESDIディス - クを送っていただきました. - - - - - SCSIとは? - - 原作:&a.wilko;. - July 6, 1996. - - 訳: &a.jp.yoshiaki;. - 4 November 1996. - - SCSI は Small Computer Systems Interface - (小規模コンピュータシステムインタフェース) - の頭文字をとったものです. - これは ANSI 規格の一つであり, コンピュータ業界において最もよく使われる - I/O バスの一つになっています. SCSI はシュガート社 - (ミニフロッピーディ スクを世界で最初に販売しました) の開発した - SASI (Shugart Associates Standard Interface) - バスを元に規格化されました. - - その後の業界の努力により, - 異なるベンダのデバイスが混在して使えるよう, - より厳密な規格へと規格化されました. - その結果, 認可されたのが ANSI の SCSI-1 規格です. - SCSI-1 仕様の規格化が行なわれたのは 1985 年前後です. - (訳注: SCSI-1 の最終案決定は 1985 年, - ANSI の標準規格としての認可は 1986 年です) - この規格は, すでに現在では時代遅れのものになっており, - 現在の標準は SCSI-2 - (さらに詳しい情報 - を参照してください) で, これもまもなく SCSI-3 - へ移行していくでしょう. - - 物理的な相互接続の規格に加えて, - SCSIではディスクドライブに不可欠な論理的な規格 - (コマンドセット) も定義しています. - この規格は標準コマンドセット (CCS; Common Command Set) - と呼ばれ, ANSI の SCSI-1 とほぼ同時期に制定されました. - SCSI-2 には (改定された) CCS が規格の一部として組み込まれました. - コマンドは, デバイスの種類によって変わります. - たとえばスキャナにおいて, Write コマンドは意味がありません. - - SCSI バスは多くの種類があるパラレルバスです. 最も古く, - 最も利用されているのが 8 bit 幅, シングルエンド (不平衡) 信号, - 50線の信号線のバスです - (もしシングルエンドの意味が分からなくても気にすることはありません. - この文書は, まさにそのような人たちのために書かれているからです). - より新しい設計では 16bit 幅で平衡信号のバスを使います. - この場合, 転送速度は - 20Mbytes/second まで, ケーブルの長さは 25m まで可能です. - SCSI-2では追加のケーブルを使った最大 32bit - のバス幅までが定義されています. - 最近急速に増えているものに Ultra SCSI - (Fast-20 とも呼ばれます) があります. - また, SCSI-2には Ultra2 (Fast-40 とも呼ばれます) - というものも定義されています. - Fast-20 は 1 秒間に 2000 万回の転送 (8bit バスで 20Mbytes/sec), - Fast-40 は 1 秒間に 4000 万回の転送 (8bit バスで 40Mbytes/sec) - を行ないます. - 最近売られているハードディスクのほとんどは, - 不平衡信号の Ultra SCSI (8bit または 16bit) です. - - - 訳注: ここでは電気的な用語としては平衡, 不平衡を用いて, - バスの名称としては基本的にはシングルエンド, - ディファレンシャルとしました. - - - もちろん SCSI バスにはデータ信号だけではなく, - 多くのコントロール信号線があります. - 複数のデバイスがバスを効率よく共有するための - 複雑なプロトコルも規格の一部です. - SCSI-2 ではデータは常に独立したパリティ信号を使ってチェックされます. - SCSI-2 以前では, パリティチェックはオプションでした. - - SCSI-3 ではさらに高速なバスタイプが導入され, - それと共にケーブルの線数を減らし, - より最大バス長を伸ばしたシリアル SCSI が導入されます. - SSA や Fiberchannelといった名前を聞いたことはありませんか? - シリアルバスは現在では, まだいずれの方式も普及していません - (特に一般的な FreeBSD 環境では). - このためシリアルバスタイプについては, - ここではこれ以上は触れません. - - 今までの記述から想像されるように, - SCSI デバイスはインテリジェントです. - これは SCSIの規格 - (この文書は 2 インチ以上の厚さがあります) - と切り離すことはできません. - このため, たとえばハードディスクでは特定のブロックを指す場合は, - ヘッド / シリンダ / セクタによって決めるのではなく, - 単に必要なブロック番号を指定します. - 巧妙なキャッシュ動作や, 不正ブロックの自動置き換えなどの機能は, - この「インテリジェントデバイス」のアプローチによって可能になっています. - - SCSI バスでは任意のデバイスの組で通信することが可能です - (訳注: 任意のデバイスがイニシエータになれるという意味です). - デバイスの機能がそれを許すかどうかはまた別の問題ですが, - 規格では禁止されていません. - その場合は信号の衝突を防ぐために, - 2 つのデバイスがバスを使う前に調停 (arbitrate) - を行なう必要があります. - - SCSI では, - 古い規格のデバイスと新しい規格のデバイスが - 同じバスの上で動くように規格を作っています. - したがって, 古い SCSI-1の デバイスは SCSI-2 - バス上でも普通は動きます. - 普通は, と断った理由は, - ある古いデバイスが (古い) 規格に対して, - 新しいバスでも問題ない程に十分規格に準拠した実装になっているかどうかを - 絶対的に保証することはできない, ということです. - 一般に, 最近のデバイスはよりうまく動作します. - その理由は規格化がより厳密になり, - またメーカーがデバイスの製造において, - よりきちんと規格に従うようになってきているからです. - - 一般的に言って, 単一のバス上で動かすデバイスは SCSI-2 - あるいはより新しいデバイスであれば - うまく動く可能性は高いと言えます. これは新しい - 2GBのディスクを手に入れたとしたら - 古いデバイスを捨ててしまわなければならないという - 意味ではありません. 私のシステムでは SCSI-1以前のディスク, - SCSI-2の QICテープユニット, - SCSI-1のヘリカルスキャンテープユニット (訳注: - VTRのような回転ヘッドを 持ったテープ装置のことです. - DATテープドライブもその一つです), 2台の SCSI-1 - ディスクが一緒に問題なく動いています. - ただし効率の点から古いデバイスと新しい (= 速い) - デバイスを分けたいかもしれません. (訳注: 古いデバイスの中には - disconnectをサポートしないために一連のコマンド実行中に - SCSIバスを占有してしまうデバイスもあります.) - - - SCSI の構成要素 - - 先に述べたように, SCSI デバイスはインテリジェントです. - つまりハードウェア細部にからむ知識は SCSI デバイス自身が - 持っています. そのためホストシステムは, - あるハードディスクがいくつのヘッドを持っているのかとか, - 指定したテープデバイスがいくつのトラックを持つか, - というようなことを知る必要はありません. - もしあなたが知りたいのであれば, - 規格で定義されているコマンドを使って, - デバイスにハードウェアの詳細について問い合わせることができます. - - インテリジェントデバイスの利点は明らかです. - ホストのデバイスドライバはより一般的に書くことができ, - 新しいデバイスを導入する場合でも変更の必要がありません. - - - - 接続でおこなうべきこと, してはならないこと - - ケーブルの接続には鉄則があります. - よい部品を使うことです. バスの速度を上げることができ, - 多くの災難を防ぐことができます. - - ですから, 金メッキのコネクタ, シールドケーブル, - 固定器具付きの頑丈なコネクタカバーなどを - 選ぶのは正しいことです. 2つ目の鉄則は, - ケーブルを必要以上に長くしないことです. - 私は以前にあるマシンでトラブルの 原因を探すのに - 3日間悩んでいましたが, SCSIバスを 1m 短く - することで問題を解決したことがあります. もちろん, - 元のバスの長さでもSCSIの仕様はきちんと - 満たしていたのですが. - - - - - SCSI バスのタイプ - - 電気的に互換性のない 2種類のバスのタイプがあります. - シングルエンドとディファレンシャルのバスです. これは SCSI - デバイスとコントローラは同一のバス上に混在することのできない - 2つのグループに大きく分けられるということを意味しています. - しかし, 特別なハードウェアを使えばシングルエンドバスを - ディファレンシャルバスに (その逆も) 変換することはできます. - これらのバスのタイプの違いは次のセクションで説明します. - - - SCSI関連のドキュメントでは - 異なるタイプのバスを一種の用語とし て略語で表します. - これを次の表に示します. - - - - FWD: Fast Wide Differential (高速 ワイド 平衡) - - - - FND: Fast Narrow Differential (高速 ナロー 平衡) - - - - SE: Single Ended (不平衡) - - - - FN: Fast Narrow (高速 ナロー) - - - - etc. - - - - 少し想像力を働かせればどのような - 意味であるかはわかるでしょう. - - ワイド (Wide) はいくらか曖昧で, 16 または 32 - bitのバスを示します. 私の知る限りでは, 32 bit - のインタフェースは (まだ) 使われていませんので Wide は通常 - 16 bitを意味します. - - 高速 (Fast) はバスのタイミングがいくつかの点で異なり, - ナロー (8 bit) バスでは 低速 (slow) SCSIバスの 5 Mbytes/sec - に対して 10 Mbytes/sec の能力があります. 前にも述べたように, - 20Mbytes/sec や 40Mbytes/sec - のバス速度を持つものも現れてきています (Fast-20 == Ultra - SCSI で Fast-40 == Ultra2 SCSI です). - - - データ線の上位 (> 8) - はデータの転送とデバイスの指定だけに利用されています. - コマンドの送出とステータスメッセージ等は下位側の 8 - bitのデータ線のみを使います. この規格により - ナローデバイスはワイドバス上でも 動作する事ができます. - 利用できるバスの幅はデバイス間で調停 (ネゴシエーション) - されます. デバイスの - IDについてはワイドとナローが混在する時には - 気をつけなければなりません. - - - - シングルエンドバス (不平衡バス) - - シングルエンド SCSIバスは 5Vと 0Vの電圧 - (つまりTTLレベルです) を信号として使い, - それらは共通のグラウンド (GND) レベルを基準 にします. - シングルエンド SCSI 8 bitバスは約25本のグラウンド線 - を持ち, すべてのデバイスを「直線状」に接続します. - 基準ではシングルエンドバスは最大の長さは 6mです. Fast-SCSI - デバイスを使う場合には, この最大長さは 3mに短くなります. - Fast-SCSIでは 5Mbytes/sec ではなく 10Mbytes/sec の転送速度 - が可能になります. - - Fast-20 (Ultra SCSI) と - Fast-40ではそれぞれ1秒間に2000万 (20M) ないしは 4000万 - (40M) 回の転送ができます. したがって, Fast-20では - 8bitバスで 20Mbytes/sec, 16bitバスで 40Mbytes/secとなりま - す. Fast-20ではバスの最大の長さは 1.5m, Fast-40では - 0.75mに なります. Fast-20は限界を相当に広げるものなので - SCSIバス - に雑音が多い場合はその影響を即座に受けます. - - - バス上のいずれかのデバイスが 「高速の」 - 転送を利用する場合は - Fastバスの長さの制限を受けます. - - - 最近の Fast-SCSI デバイスではバスの長さが実際の問題に - なりつつあるのが明らかになっています. - これがディファレンシャル - SCSIバスがSCSI-2の規格に導入された理由です. - - コネクタのピン配置やコネクタの種類については - SCSI-2の規格 (さらに詳しい情報) - を参照してください.コネクタ等について - 詳細なリストがあります. - - 非標準のケーブルを使うデバイスに気をつけてください. - 例えば Apple (の Macintosh は) 25pin の D-type のコネクタ - (シリアルポートやパラレルプリンタに使われているコネクタ -- - 訳注: 日本では一般的に D-sub 25pinと言っています) - を使っています. 公式なSCSIバスでは50 pin - が必要である事からこのコネクタでは - 「独創的なピン配置」が必要な事が想像できるでしょう. ここ - でおこなわれているようにグラウンド線の数を - 減らすことはよい考え ではありません. SCSIの規格通りの 50 - pinの接続の方が望まし いです. Fast-20 や 40 - でこのようなケーブルを使おうなんて - 考えてはいけません. - - - - - ディファレンシャル (平衡) バス - - ディファレンシャル SCSIバスは最大長が 25m です. - シングルエンド Fast-SCSIバスの 3mとはまったく違います. - 平衡信号の背景と なっている考え方は, - それぞれのバスの信号はそれぞれ - 独立したリターン信号線を持つというものです. つまり, - それぞれの信号は (できればより線の) ペアの信号線で - 伝えられます. - これら2つの信号線の差分の電圧で信号が「真」(assert) で - あるか「偽」(de-assert) であるか判定されます. - かなりの電圧 - がグラウンド電位と信号線ペアの間にかかったとしても影響があ - りません (だからといって 10kVの電圧をかけてみたりしないで - ください.. ). - - なぜ平衡信号が よいのかについての説明は - このドキュメントの 範囲を越えています. - 電気的に平衡信号はノイズマージンの点で - 非常に優れたものとして利用されているということを - 受け入れて ください. - ディファレンシャルバスは普通は外部接続に 利用されています. - これは低コストのシングルエンドバスが筐体内の短 - い距離のバスでは非常に多く利用されているからです. - - FreeBSDを使うにおいて, FreeBSD でサポートされている - デバイスドライバがあるのであれば - ディファレンシャルバスの利用で 問題になることは - 何もありません. 例をあげれば, アダプテックの - AHA1740はシングルエンドで, - AHA1744はディファレンシャルです. - 双方のソフトウェアインタフェースはまったく同一です. - - - - ターミネータ - - SCSIにおける用語でのターミネータとはインピーダンスの - マッチングを正確におこなうための抵抗ネットワークです. - インピーダンス マッチングは反射やリンギングを抑え, - バスの信号をきれいにす る重要なものです. たとえば, - あまり状態のよくない回線で長距 - 離の電話をかけた時にあなたは反射をどんなものか - 感じるかもしれません. 20Mbytes/sec で信号の伝わる - SCSIバスでは信号のエコーはありがたくありません. - - 訳注: - 電気信号のパルスは進行波としての性格を持っています. - このため, 一般的には信号線の両端で反射が起きます. - 3mのバスの端からパルスを入れた場合, - 反対の端からの反射波は 20ns後 - 本当は電線中の信号の伝達は - 光速よりも少し遅くなるのでもう少し時間がかかりますが - - に返ってきます. 低速のバスの場合タイミング的な余裕があり, - 反射を繰り返しているうちに反射波は減衰してしまうのですが - 高速のバスの場合は, 反射波の影響が落ち着く前に信号の - 読み込みなどを行うために波形の乱れが誤動作の原因に - なる場合があります. - このためターミネータを使用して反射波の発生をできるだけ - おさえます. - - ターミネータはいろいろな - - 洗練されたものもそうでないものも - 実現方法があります. - もちろん, 内蔵のものと外部という区別もあります. 多くの - SCSIデバイスにはいくつかのソケットがあり, - その中には抵抗ネットワーク (集合抵抗) が - 入っているものもあるかもしれません (いや, おそらく - 間違いなくあるでしょう). ターミネータを - デバイスから外す時は大事にしまっておいてください. SCSIの接 - 続の変更をしようと思った時に必要になるかもしれません. ま - た, - それらしい抵抗ネットワークが見つからないこともあります. - この場合, SCSIデバイスは内蔵ターミネータの有効と無効を切替 - えるジャンパがあります. フラットケーブルに取り付ける特別 - なターミネータもあります. 他には外部コネクタのような形をし - たものやケーブルのないコネクタヘッドだけのものもあります. - いろいろと見られるように多くの選択があります. - - - どのような場合に単純な抵抗 (パッシブ) ターミネータから - アクティブターミネータへ切替えるかという問題があります. - アクティブターミネータはいくらか精巧な回路が信号をより - きれいにするために入っています. - 一般的に受け入れられている意見としては, 長いバスを使ったり - 高速なデバイスを使う場合はアクティブターミネータの - 有効性は増加すると言えます. SCSI バスですでに問題が起きて - いるならアクティブターミネータを試すことを考えていいで - しょう. まず借りることができないか探してみてください. - アクティブターミネータは非常に高価だそうですから. - - ディファレンシャルと - シングルエンドバスのターミネータは互換 - 性がないということを覚えておいてください. これらの2つの種 - 類を - 混在させることはできません. - - OK, ではあなたは - ターミネータをどこに入れればいいでしょうか? これは - SCSIで最も多く誤解されているところです. しかし, これ - は極めて単純なことです.. ここでのルールは - SCSIバスの線 一本一本は必ず両端に - 2個のターミネータを入れる ということです. - つまり 2個であって1個でも3個でもありません. - このルールを受け入れてしたがってください. そうすれば終りの - ない苦しみから救われるでしょう. - なぜなら間違ったターミネーションは不可解なバグを引き起こす - 可能性が非常に高いからです. (ここの 可能性 - に注意; 一見動いているように見える - ことがあるのがやっかいです.) - - よく陥りやすい落し穴はマシンの内部 (フラット) - ケーブルと外部 - ケーブルがコントローラにつながっている場合です. よく見られ - るのはコントローラのターミネータを外すのを忘れることです. - ターミネータは最後の外部デバイスで必要で, コントローラ - には必要ありません! 一般的に, SCSIバスの接続の変更をする場 - 合はこのようなことに注意をしなければなりません. - - - ターミネータの位置は - 信号線ごとに決まることに注意して下さい. - ナローとワイドのケーブルを - 両方コントローラにつないでいる場 合には, - ケーブルの両端とともにコントローラ上ではバスの上位 - 8ビットをターミネートしないといけません. - - - 私自身は, - すべてのデバイスとコントローラのターミネータを外し - ています. 2個の外部ターミネータをセントロニクスタイプ - (訳注: 日本ではケーブルに対してこういう言い方は - あまりしないのでは ないでしょうか) - 外部ケーブルと内部フラットケーブルの - コネクタの両端に接続しています. - こうすることにより接続の変更はかなり簡単になります. - - 最近のデバイスは, - ICターミネータが使われることもあります. - コントロールピンにより無効 / 有効を設定できる 特別の IC - があります. - これは物理的にデバイスから外す必要がありません. - 新しいホストアダプタではセットアップツール等を使って - ソフトウェア的に設定をおこなう場合があります. - また, 中には端子に接続されたケーブルを検出して - ターミネータ を必要に応じて自動的に - 有効にするものもあります. いずれにしろ, マニュアルを見てく - ださい. - - - - ターミネータの電源 - - ここまでの章で議論したターミネータは - 正常に動作するためには 電源が必要です. - SCSIバス上にはこの目的のために利用される線があります. - だから特に気にする必要はないと思いますか? - - ところがそうではないのです. - それぞれのデバイスはデバイス上 - にあるターミネータソケットに電源を供給することはできます. - けれども外部ターミネータがある場合やSCSIバスにターミネータ - の電源を供給するデバイスのスイッチがオフになっているような - 場合にはトラブルが起きるかもしれません. - - イニシエータ (ここではバスの動作を開始-initiate-させる - デバイスを指します -- 訳注: - 簡単に言えばホスト側のアダプタですがSCSIの 規格によれば, - 例えばディスク側がコマンドを発行するような - システムがあってもかまわないことになっているので - こういう言い方をしています) は - ターミネータ電源を供給しなければなりません. - すべてのSCSIデバイスはターミネータの電源を供給することが - できます (必ずしも供給しなければならないというわけ - ではありません). - - - スイッチがオフになっているデバイスが - バス上に存在することを 許すために, - ターミネータの電源はダイオードを通して供給され - なければなりません. これはスイッチを切ったデバイスに電流 - が逆流することを防ぐためです. - - 最悪の事態を避けるために, - ターミネータの電源は普通はヒューズが入っています. - 当然ヒューズは飛ぶかもしれません. この - 場合でもバスが機能停止するとは限りません. 複数のデバイスが - ターミネータの電源を供給しているのであれば, ヒューズが一つ - 飛んでも全体の機能には影響しません. ただ一つの供給線の - ヒューズが飛んだのであれば確かに問題になるでしょう. - 外部ターミネータによっては LED でターミネータ電源 - が与えられていることを示すものもあります. - - 最新の設計ではある程度の時間がたつと 「リセット」され - 自動復帰するヒューズが使われることもあります. - - - - デバイス アドレッシング - - SCSIバスでは接続された異なるデバイスを区別して指定 - できなければなりません. - - これには SCSIではターゲットIDが使われます. - それぞれのデバイ スは特定のターゲットIDを持ちます. - デバイスの IDはジャンパや DIPスイッチなどで設定できます. - ブート時のメニューからIDを - 変更できるようになっているコントローラもあります. (また, - IDを 7から変えることができないコントローラもあります.) - より詳しい情報はデバイスのマニュアルを見てください. - - 複数のデバイスを使う場合は - IDの重複に気をつけてください. - 重複すると普通は混乱状態になります. 同じ IDを共有している - デバイスのうちの一つがI/Oリクエストに答えられたりすると - 非常にやっかいなことになります. - - 8 bitバスでは, 最大8台のターゲットまで可能です. - 最大8台で ある理由は, - バスの8本のデータ線がデバイスの選択に使われる からです. - ワイドなバスでは使えるデバイスの数は増えます - (通常は16になるわけです). - - - ナロー SCSI デバイスは 8 以上のターゲット ID - を持つデバイスとは 通信できないことに注意してください. - ですから, コントローラ - のターゲットIDを8以上にするのはあまりいい考えとは - いえません (CDROMが使えなくなったりします). - - - 同時にバス使用の要求が発生した場合, 最も - IDの大きいデバイス が優先されるという調停がおこなわれます. - このことは SCSIホストアダプタの - IDは通常7番が使われる理由でもあり ます. ただし, - ワイドバスでは下位8ビットが上位8ビットより優 - 先度が高いことに注意してください. つまり, ワイドSCSIのシス - テムではターゲットIDの優先度は高い順に [7 6 .. 1 0 15 14 - .. 9 8] となります. - (どうして下位8ビットの方が優先度が高いかは, - 一つ前の段落を読んで考えてみて下さい.) - - さらにサブユニットとして, 規格では ロジカルユニット, - 短縮形で LUNを持つことができます. - 一つのターゲットIDが複数の LUNを 持つことができます. - 例えば, テープチェンジャを持つテープ ドライブは LUN - 0をテープドライブ自身, LUN 1を テープチェンジャ - に与えることができます. このようにして, - ホストシステムはテープチェンジャの目的の - テープユニットの部分を指定することができます. - - - - バスの形状 - - SCSIバスは直線状です. つまり, Y接続, スター接続, - 円形, クモの巣状の接続などの直線以外の接続ではありません. - 初心者が - よくやる間違いとしてはワイドSCSIのコントローラの端子3つと - もにケーブルをつないでしまうというものがあります. (外部, - 内部ナロー, 内部ワイド.) - よほど運がよければこんなトポロジー - でもちゃんと動くように見えるかもしれませんが, えてしてこう - いうシステムは一番大切な時に使えなくなったりするものです - (これをマーフィーの法則といいます). - - 先に議論したターミネータの問題は直線状以外の場合では - より困難になるだろうということに注意してください. また, - 内部バス用の ケーブルの端子の数よりデバイスの - 数の方が少ない場合には, - 必ず両端の端子にはデバイスをつなぐようにしてください. - 内側の端子を使ってケーブルの端を余らせておくと, - ターミネータの効果が半減します. - - 電気的特性はそのノイズマージンや全体の信頼性において, - 直線状のバスのルールに強く依存しています. - - 直線状バスであるというルールに - したがってください! - - - - - FreeBSD で SCSIを使う - - トランスレーション, BIOS, そしてマジック... - - まず始める前に, - 電気的に問題のないバスであるか調べておいてく - ださい. - - SCSIディスクをPCでブートディスクとして使う場合に, PC - BIOSに 関する気まぐれについて知っておく必要があります. PC - BIOSは ハードディスクへの低レベル物理インタフェースを - 利用するように 実現されています. したがって, BIOSに - (セットアップツールやBIOSビルトイン セットアップを使って) - ディスクの物理パラメータを教えてやる 必要があります. - これはヘッドの数, シリンダの数, - トラックあたりのセクタなどがあり, - プリコンペンセーションや書き込み電流を 減少させるトラック, - などのあまりよく知られていないものもあります. - - SCSIディスクはこれらのことをユーザは - 気にする必要がないはず だと考えるかもしれません. しかし, - 不思議なことに (これらの項 目の) - セットアップはいまだにあるのです. システム BIOSはブート - 時にFreeBSDのカーネルを読み込むためにSCSIディスクに - /ヘッド/シリンダ/セクタ を指定する方法でアクセスするため, - パラメータを知る必要があるのです. - - AT/EISA/PCIバスなどにあり, ディスクに接続される - SCSIホストアダプタや SCSIコントローラは - それ自身のオンボードBIOSを持っています. - システムの起動時に, SCSI BIOSは - システムBIOSのハードディスクの - インタフェースルーチンを乗っ取ります. - システムBIOSをごまかすために - システムセットアップでは普通は `No hard disk' とします. - 簡単ですね? - - 訳注: BIOS で `No hard disk' という設定をおこなうのは - SCSI ドライブから直接起動させるためのテクニックです. - 現在のマザーボードでは SCSI ドライブから起動させるための - オプションを持つ BIOS を使用しているものもあります. また, - ブートセレクタを使って IDEドライブのブートブロックから - SCSIドライブ上の FreeBSDをブートすることもできます. - - SCSI BIOS はドライブの - トランスレーション と呼ばれる - 機能を持ちます. - これはPCがブートするために作られたドライブテー - ブルをごまかすものです. このトランスレーションは多くは - (すべての場合ではありません) - トラックあたり64あるいは32個のヘッドを - 持つ仮想的なドライブを使います. - シリンダの数を変更することで SCSI BIOS - は実際のドライブのサイズに適合させます. 総セクタ数 を 32 * - 64 / 2 で割った結果がメガバイト単位のドライブのサイズ - になります. 2で割っているのは, 通常 512バイトのサイズの - セクタを kByte 単位に変換するためです. - - ではこれですべてうまくいくのでしょうか. いいえ, - そういう訳で はありません. - ブート可能なハードディスクのシリンダ数は 1024よ - り多くすることはできないのです. - トランスレーションを使った 場合でもディスクの - 1GB以上の領域は見えません. ディスクの容量 - がどんどん増加していくにつれこれは問題になってきました. - - - 幸いにして, 単純な解決方法があります. - 単に別のトランスレーショ ンを使えばよいのです. 例えば, - 32個に代わり, 128個のヘッドを使います. ほとんどの場合, - 古いSCSIホストアダプタをアップグレードす - るための新しいバージョンの SCSI BIOS が用意されています. - 新しいアダプタではジャンパ やセットアップソフトによって - SCSI BIOSの使う - トランスレーションを選択できる物もあります. - - ここで非常に重要なことは, - ディスク上のすべての - オペレーティングシステムが - 同一のトランスレーションを使って - 正しいパーティションを得ることです. つまり - FreeBSDをインストールする時に, - ヘッド/シリンダなどについての - 質問にあなたのホストアダプタが - 使用しているトランスレートされた - 値を使わなくてはなりません. - - トランスレーションに関する失敗でよく見られるものは, - ブートしないシステムができたり, 他のパーティションを - 上書きしてしまうことです. すべてのシステムが見えるように - fdiskを使うべきです. - - あなたはデバイスについて - これとは食い違った話を聞いたことが あるかもしれません. - 古い FreeBSDのカーネルはブートする時に SCSI - ディスクのジオメトリ情報を報告していました. - 私のシステムの一つの例を示しましょう. - - aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4> - sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 - - 最近のカーネルは, 普通はこのような情報を報告しません. - たとえば, このようになっています. - - (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 - sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) - - なぜこのように変わったのでしょう? - - この情報は SCSIディスク自身から得られます. - 最近のディスクで はよくゾーンビット記録方式 (zone bit - recording) という 技術が使われています. - これはドライブの外側のシリンダは - 内側よりもスペースが広いのでトラックあたりのセクタ数を - 増やすことができるというアイディアです. この結果, - 外側のシリンダ上のトラックの容量は内側の - シリンダよりも大きくなり, - 全体ではより大きな容量となります. この場合, - ドライブのジオメトリについての報告は, - 最善のものかどうか疑わしく, - ほとんどの場合誤解を招くものであ ることがわかるでしょう. - ジオメトリを調べる場合, ほとんどの場合は BIOSの用い - ている値を与える方がよい結果となり, - BIOSがそのディスクに - ついてまったく関知しないのであれば - (例えばブートディスクで はないなら) - 都合のよい仮想のジオメトリを与えればいいでしょう. - - - - SCSI サブシステムの設計 - - FreeBSDでは階層的な SCSIサブシステムを用いています. - それぞれ 異なるコントローラカードの - デバイスドライバが書かれています. - このドライバはコントローラのハードウェアの - 詳細を知っています. ドライバは - SCSIサブシステムのより上位の階層のコマンドを受け取り, - ステータスを報告するインタフェースを持ちます. - - カードのドライバの最上位には, デバイスのクラスのための - いくつかの一般的なドライバがあります. 具体的にいうと, - テープドライブのためのドライバ (略号は: st), 磁気ディスク - (sd), CDROM (cd) などです. これらのソースコードは - /sys/scsiにあります. - マニュアルページ (man) のセクション 4 にはより詳しい内容が - あるので見てください. - - 多階層の設計は低レベルとより高位の - レベルを分離させることが できます. - 新たに他の種類のハードウェアのサポートを加えることを - より処理しやすい問題にします. - - - - カーネルコンフィグレーション - - あなたのハードウェア構成にしたがって, カーネルの - コンフィグファイルに ホストアダプタについて - 1行あるいは数行程度の記述をする 必要があります. これには - I/O アドレスや割り込みなどについての内容も 含みます. - あなたのアダプタのドライバについてのマニュアルページ - にはより多くの情報があるのでよく読んでください. - これとは別に /sys/i386/conf/LINT - にはカーネルコンフィグファイルについての 概要があります. - LINT - には一般的なものについては可能なすべての - オプションが含まれています. ただし, - LINT - では実際に動作するカーネルを作ることは - できません. - - 当然のことを言うようで恐縮ですが, - カーネルコンフィグファイルは実際のハードウェア構成を - 反映すべきです. そのように割り込みやI/Oアドレス等に - 合わせてカーネルコンフィグファイルを書か - なければなりません. - システムのブート時のメッセージは実際に - 見つけたハードウェアの設定を表示します. - - - ほとんどの EISA/PCI 用のドライバ (具体的には - ahb, - ahc, - ncr と - amdです) - はブート時にコントローラから直接パラメータ - を読みこみます. これらについては, 何も引数をつ - けずにただ controller ahc0 - のように書けば大丈夫で す. - - - 例として FreeBSD 2.2.5-Releaseのいくつかのコメント - ([]の中) をつけた LINT - カーネルコンフィグファイルを示 します. - - # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' -# -# aha: Adaptec 154x -# ahb: Adaptec 174x -# ahc: Adaptec 274x/284x/294x -# aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) -# amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T) -# bt: Most Buslogic controllers -# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 -# ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards -# uha: UltraStore 14F and 34F -# sea: Seagate ST01/02 8 bit controller (slow!) -# wds: Western Digital WD7000 controller (no scatter/gather!). -# - -[ Adaptec AHA274x/284x/294x/394x などのコントローラ] -controller ahc0 - -[ NCR/Symbios 53c875 コントローラ] -controller ncr0 - -[Ultrastor アダプタ] -controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr - -# Map SCSI buses to specific SCSI adapters -controller scbus0 at ahc0 -controller scbus2 at ncr0 -controller scbus1 at uha0 - -# The actual SCSI devices -disk sd0 at scbus0 target 0 unit 0 [SCSI ディスク 0 は scbus 0, LUN 0] -disk sd1 at scbus0 target 1 [unit を省略すると暗黙で LUN 0] -disk sd2 at scbus1 target 3 [uha0 上の SCSIディスク] -disk sd3 at scbus2 target 4 [ncr0 上の SCSIディスク] -tape st1 at scbus0 target 6 [SCSI テープ は ターゲット (ID)6] -device cd0 at scbus? [最初に見つけた CDROM, 固定にしない] - - 上の例では カーネルは ahc (Adaptec 274x) - コントローラをまず探し, その次に NCR/Symbios - のボードというように順番に探して 行きます. その下の行の - controller の記述ではデバイスの詳細 を記述して, - 対応するバスでターゲット ID と LUN が指定された - ものと一致する場合だけ - 認識するようにカーネルに 伝えています. - - 固定された (Wired down) デバイスは - 最初にユニット番号が 与えられるので, - 固定されていないデバイスは同じ種類の - 固定されたユニット - 番号の最も大きい番号の1つ上の番号から割り当てられます. - したがって, ターゲットID 2の SCSIテープを加えると, - ターゲットID 6 - のテープがユニット番号1に固定されているので, - それはst2に設定 されるでしょう. - - - ブート時に見つからなくても固定されたデバ - イスにはユニット番号が常に割り当てられます. - 固定のデバイスに 割り当てられたユニット番号は, - もしそのデバイスのスイッチが - ブート時に切られていてもそのデバイスに - リザーブされています. これは, - 電源を入れて接続した時のユニット番号が与えられます. - デバイスのユニット番号は SCSIバスのターゲットID とは - 何の関係もない - ことに注意してください. - - - 下の例は FreeBSD のバージョン 2.0.5 以前の - カーネルコンフィ グファイルです. - 最初の例との違いはデバイスの固定 (wired - down) がないことです. 固定 - によりどのSCSIターゲットをどの - デバイスに割り当てるかを記述できるようになりました. - - 下のコンフィグファイルにより - 構築されたカーネルでは最初に見つ けた SCSIディスクが - sd0になり, 次に見つけたディスクが sd1に, - という具合に割り当てられます. - もしディスクの削除や追加をおこなう と, - 他の同じタイプのデバイス (この場合はディスク) のすべてが - 「移動して」しまうかもしれません. これによりそのたびに - /etc/fstab - を変更する必要があります. - - 古いスタイルでも動きますが, - 新しいスタイルを使うことが強 く - 推奨されています. これにより SCSIバスのハードウェアを - どのように変更した場合でもトラブルを避けることができます. - ですから, 2.0.5.R以前の - FreeBSDからアップグレードした後に古い - 信頼できるコンフィグファイルを再利用する時はこの部分を - チェックして直してください. - - [Adaptec 174x用のドライバ] -controller ahb0 at isa? bio irq 11 vector ahbintr -[Adaptec 154x用のドライバ ] -controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr -[Seagate ST01/02インタフェースのドライバ] -controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr -controller scbus0 - -device sd0 [4台のSCSI ディスクのサポート, sd0 から sd3] - -device st0 [2台の SCSI テープのサポート] - -[CDROMのドライバ] -device cd0 #Only need one of these, the code dynamically grows - - 両方の例で SCSIディスクがサポートされています. - ブート中に 「固定」の記述がされているタイプ(例えば sd - ディスク) のデバ イスで記述より多くのデバイスが見つかると, - システムは単純に最後の 固定 - のデバイスの番号より - 1つずつ増加させた番号をデバイスに割り当てて行きます. もし - 固定 のデバイスがなければユニット番号は 0 - から始まります. - - man 4 scsi によって - SCSIサブシステムの最新の情報を チェックしてください. - より詳細なホストアダプタドライバの使い 方は, たとえば - Adaptec 294xドライバの場合はman 4 ahc - にあります. - - - - カーネルセットアップでの SCSI チューニング - - 経験的に SCSIバスリセット (ブート時におきます) - 後のINQUIRYコマ - ンドに対して応答が遅くなるデバイスがあります. - INQUIRYコマンドは ブート時にカーネルがどの種類のデバイス - (ディスク, テープ, CDROMなど) - がどのターゲットIDに接続されているかを調べるために - 発行します. ちなみにこのプロセスをデバイスプロービング - (デバイス検出) と言います. - - 「応答の遅いデバイス」の問題を解決するために, - FreeBSDは SCSIバスをリセットした後に SCSIデバイスの検出を - おこなうまでのディレイタイムを調整することができます. - カーネルコンフィグレーションファイルの下に示すような - 行にディレイタイムを設定してください. - - options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device - - この行ではディレイタイムは 15秒です. 私のシステムでは, - 信頼できる古い - CDROMが認識できるように3秒の値を使っています. もし - デバイスの認識で問題が起きる時は大きな値 (30秒であるとか) - から 始めてください. うまく動いたら, - 値を減らしてちょうどよい値 - にチューニングしてください. - - - - Rogue な SCSI デバイス - (訳注: rogue は有名なゲーム, ではなくて 悪党, - 群から離れた, 凶暴な, という意味) - - SCSI の規定は完全で簡潔なものにしようという - 努力はされましたが, 複雑な規定となり, - 正確に実現するのは簡単なことではありません. - いくつかのベンダは他よりもよい仕事をしています. - - ここで イカレた - デバイスが現れることになります. このような デバイスは - FreeBSD のカーネルにいくらか標準的 - ではない振舞をするものと認識されます. - イカレたデバイスは - ブート時にカーネルによって報告されます. 次の例は私の2つの - カートリッジテープユニットです. - - Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:> -Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue - -Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005> -Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue - - 例えば, - あるターゲットIDから実際には1つのデバイスしかないの - にすべての - LUNからの応答があるようなデバイスがあるとします. カー - ネルはその特定のターゲットIDに8個の - LUNがあると誤解してしまう かもしれません. - このような混乱の起きる原因については読者へ - の課題にしておきます. - - FreeBSDの SCSIサブシステムは 検出時の - INQUIRYの応答を見て - 悪い習慣を持つデバイスの認識をしています. - INQUIRYの応答には - デバイスのファームウェアのバージョン番号が含まれるため, - 異なる 動作をするファームウェアのバージョンを - 区別することも可能です. 例えば, - /sys/scsi/st.c や - /sys/scsi/scsiconf.c を 見てください. - どのように行っているか, より多くの情報があります. - - この方法はうまく行きますが, - もちろん既知のデバイスがつながっ - ている場合だけうまくいくということに - 気をつける必要があります. もしあなた以前に Mumbletech - SCSI CDROM (訳注: 架空のメーカ のデバイスです) - を接続した人がいないとしたら, どんな 「ワザ」 - を使ってそれを使うか自分で見つけないと - いけないかもしれません. - - あなたの Mubletech を動かすことができたらその成果を - FreeBSDの 次のリリースへ含めるために - FreeBSD開発チームへ送ってくださ い. 他の - Mumbletechの利用者たちはあなたに感謝するでしょう. - - - - 複数の LUNを持つデバイス - - 単一の SCSI ID上に複数の論理ユニット (LUN) - を持つデバイスを使う ような場合もあるかもしれません. - 多くの場合では FreeBSDは LUN 0 のみを検出します. - このような例としては2台の SCSIではないハード ディスクを - SCSIバスにつなぐブリッジボード (例えば古い Sunシステ - ムに見られる Emulex MD21) があります. - - LUN - が0ではないデバイスは普通はシステムブート時の検出では - 見つかりません. この問題にうまく対処するには - /sys/scsi/scsiconf.c - に適切なエントリを加えてカーネルを再構築 - しなければなりません. - - 以下のように初期化されている構造体を探します. - - { - T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", - "mx1", SC_ONE_LU -} - - LUNが複数あるあなたの Mumbletech BRIDGE2000 - はハードディスク として働きます. - またファームウェアのリビジョン123などを次のよ - うに書き加えます. - - { - T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123", - "sd", SC_MORE_LUS -} - - 訳注: 複数 LUNに対応するためには構造体の最後の要素を - SC_MORE_LUSにします. エントリを作る必要がある場合は - scsiconf.c にある - MBR-7等のエントリを参考にするといいでしょう. - - カーネルは - INQUIRYに一致するデータをブート時にテーブルから - 探してこれにしたがってふるまいます. より多くの情報は - ソースコードを見てください. - - - - タグ コマンド キューイング - - 最近の SCSI デバイス, 特に磁気ディスクではタグ - コマンド キューイング (tagged command queuing: TCQ) - がサポートされています. - - 要約すれば, TCQ は複数の I/O - リクエストを同時に受けることを可能 にすることです. - デバイスはインテリジェントですから,リクエスト - キューにある処理 (ヘッドのポジショニングなど) の最適化を - おこなうことができます. RAID (Redundant Array of - Independent Disks) - のようなSCSIデバイスではTCQ機能はデバイスの持つ並列性の - 利点を生かすために不可欠です. - - 各々の I/O リクエストは単一の tag (タグ - コマンド キューイン グの名前の由来) が与えられます. - FreeBSDはこの tagによりデバ イスドライバのキューの中のどの - I/Oリクエストが完了したかの 識 別をおこないます. - - TQC のリクエストはデバイスドライバが - サポートしていたとしても - あるデバイスのファームウェアではインプリメントが - 正しくない かもしれません. - このような問題に出会うと非常に不可解な問題に つながります. - このような場合は TCQ を無効にしてみてください. - - - - バスマスタ ホストアダプタ - - すべてではありませんが多くの SCSIホストアダプタは - バスマスタコントローラです. これはホストCPUにデータ転送の - 負荷をかけず, ボード自身がI/Oをおこないます. - - これは - FreeBSDのようなマルチタスクのオペレーティングシステム - では大きな利点になります. しかし, - 何らかの問題の起きることも あります. - - 例えば Adaptec 1542 コントローラは ホストバス - (ここでは ISA または AT バス) - を異なった転送速度に設定できます. コントローラが - 異なるレートに設定できるのは すべてのマザーボードで - 高速な転送が できるわけではないからです. - マザーボードに合っていない高速の - データ転送速度を用いた時には, - ハングアップやデータの損傷等の - 問題が起きるかもしれません. - - これを解決する方法は明らかです. - より低いデータ転送速度に設定 - してうまく動くか確かめることです. - - Adaptec 1542 の場合, - 可能な限り高速な転送レートを動的に読み取って, - 正しい決定をおこなうためのオプションを - カーネルコンフィグファイルに 追加することができます. - このオプションはデフォルトでは無効に なっています. - - options "TUNE_1542" #dynamic tune of bus DMA speed - - あなたの使うホストアダプタについてのマニュアルページを - チェックしてください. - また最終的な手段としては究極のドキュメントを - 使ってください - (つまりドライバのソースを読んでくださいというこ - とです). - - 訳注: 2.1.5R - の時点ではすべてのドライバに関してマニュアルページ - があるわけではありません. また上の例の - TUNE_1542のオプション も man aha - にはないようです. ソースのコメントだけで - も一度見ておいてもいいかもしれません. - - - - - 問題を突き止める - - 以下は SCSI - で一般的に問題が起きた場合に解決をするためのチェッ - クリストの試みです. これは完全な物ではありません. - - - - コネクタとケーブルがゆるんでいないかチェックする. - - - - - ターミネータの場所と数を念には念を入れて - チェックする. - - - - 少なくとも 1 - つのターミネータの電源の供給源があるかチェック する - (特に外部ターミネータを使う場合). - - - - ターゲットIDが重複していないかチェックする. - - - - 使用するすべてのデバイスの電源が ON - になっているかチェックする. - - - - 必要最小限のデバイスだけの構成を試してみる. - - - - 可能であれば, - ホストアダプタのスピードを遅くする. - - - - 問題をより単純にするために, - タグコマンドキューイングを可能 であれば無効にする. - (NCRベースのホストアダプタについては man ncrcontrol - を見てください) - - - - カーネルのコンパイルができるのであれば, - SCSIDEBUGオプショ ンをつけて - makeして, デバイスをデバッグモードにしてアクセ - スしてみてください. もしそれでも起動時にデバイスが検出 - されないのであれば, デバイスの設定アドレスが間違っている - のかもしれません. また, /sys/scsi/scsidebug.h に - あるデバッグレベルを変えてみてください. 検出はされるが - 動かないのであれば, &man.scsi.8; コマンドで - (SCSIDEBUG をつけてmakeした) - カーネルが動いている状態で動的にデバッグ - レベルを設定することができます. これは guru (UNIXの達人) - で も混乱してしまうほどの非常に大量のデバッグ情報を - 出すでしょ う. man 4 scsi - にはより正確な情報があります. またman - 8 scsi も見てください. - - - - - - さらに詳しい情報 - - もしあなたがいくらかは本気で - SCSIハッキングをする気があるなら - たぶん正規の規格を持っていたくなるでしょう. - - 承認ずみのアメリカ工業規格は ANSI から購入できます. - 住所と電話番号は - -
- 13th Floor - 11 West 42nd Street - New York - NY 10036 - Sales Dept: (212) 642-4900 -
- - です. - - また, ANSIの規格および委員会の規格案 (ドラフト) - のほとんどは Global Engineering Documents - より買うことができます. 連絡先は - -
- 15 Inverness Way East - Englewood - CO, 80112-5704 - Phone: (800) 854-7179 - Outside USA and Canada: (303) 792-2181 - Fax: (303) 792- 2192 -
- - です. - - X3T10 のドラフトの多くは電子的に利用できる形で SCSI BBS - (719-574-0424) と ncrinfo.ncr.com の Anonymous FTP - サイトから得ることができます. - - 最新の X3T10 委員会の文書は: - - - - AT Attachment (ATA or IDE) [X3.221-1994] - (Approved) - - - - ATA Extensions (ATA-2) [X3T10/948D Rev 2i] - - - - Enhanced Small Device Interface (ESDI) - [X3.170-1990/X3.170a-1991] - (Approved) - - - - Small Computer System Interface — - 2 (SCSI-2) [X3.131-1994] (Approved) - - - - SCSI-2 Common Access Method Transport and - SCSI Interface Module (CAM) - [X3T10/792D Rev 11] - - - - 追加情報を得ることのできる出版物は: - - - - SCSI: Understanding the Small Computer - System Interface, NCR社 - 編. 出版: Prentice Hall, Englewood Cliffs, NJ, 07632 - Phone: (201) 767-5937 ISBN 0-13-796855-8 - - - - Basics of SCSI, - a SCSI tutorial, Ancot Corporation 編 - Ancot の連絡先: - Phone: (415) 322-5322 Fax: (415) 322-0455 - - - - SCSI Interconnection Guide Book, - AMP社の出版物 (発行 4/93, カ - タログ 65237) 色々な - SCSI コネクタのリスト と ケーブル接続方法のガイド. - AMP 社より入手可能. (800) 522-6752 - または (717) 564-0100 - - - - Fast Track to SCSI, - 富士通によるプロダクトガイド, - 入手先: Prentice Hall, Englewood Cliffs, NJ, 07632 - 電話: (201) 767-5937 ISBN 0-13-307000-X - - - - The SCSI Bench Reference, - The SCSI Encyclopedia, SCSI Tutor, - ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 - 電話: (408) 867-6642 - - - - Zadian SCSI Navigator - (クイックリファレンス) および - Discover the Power of SCSI - (最初の本は1時間のビデオとチュートリアルが付属), - Zadian Software, - Suite 214, 1210 S. Bascom Ave., - San Jose, CA 92128, (408) 293-0800 - - - - Usenet のニュースグループ comp.periphs.scsi と - comp.periphs - は特により多くの情報を得るには注目すべき場所です. - また定期的に ポストされる - SCSI-FAQをここから得ることができます. - - 多くの主要な SCSIデバイスとホストアダプタの供給元は FTP - サイト や BBSを開いています. - これらはあなたの持っているデバイスに関す - る貴重な情報源となるでしょう. - - - - - * ディスク/テープ コントローラ - - - * SCSI - - - - - - * IDE - - - - - - * フロッピー - - - - - - - ハードディスクドライブ - - - SCSI ハードディスク装置 - - 寄稿: &a.asami; . - 17 February 1998. - - 訳: &a.jp.miyasita;. - 20 February 1998. - - SCSI の章で述べたように, - 実際, 現在販売されている SCSI ハードディスク装置はすべて - SCSI-2 互換であり, サポートされている SCSI ホストアダプタに - 接続すればそれらは正常に動作するでしょう. - 人々が直面する問題の多くは, ケーブル接続が間違っていたり - (ケーブルが長過ぎる, スター型接続になっている, など), - ケーブル終端の処理が不十分だったり, - 部品が故障していたりのうちのどれかです. - SCSI ハードディスク装置が動作しないときには, まず - SCSI の章を参照して下さい. - しかし SCSI ハードディスク装置を購入するときに - 気を付けておきたいことがふたつあります. - - - 回転速度 - - 現在販売されている SCSI ドライブの回転速度の範囲は - 4,500RPM から 10,000RPM であり, その大部分は 5,400RPM か - 7,200RPM です. 一般的に 7,200RPM - のドライブの方がデータ転送は速いのですが, 5,400RPM - の同容量のものと比べてとても熱くなります. - 現在のディスク装置の故障の大半は熱によるものです. もし PC - のケースの中が非常によく冷却されていなければ, 5,400RPM - かそれ以下のドライブにしておいた方がよいでしょう. - - より高密度で記録するようになっている新しいドライブは - 以前のものに比べてより多くのビットを - 各回転毎に転送することが - できるということに気をつけて下さい. 現在, 5,400RPM - の最高級機種では 1, 2 世代前の 7,200RPM の - ドライブに匹敵する転送速度が出せます. - 仕様一覧からバンド幅の数値を探すには 内部データ - (または転送) 速度 という欄を見て下さい. - 通常その数値は Mbits/s で書かれているので, それを 8 - で割ればそのドライブで出せる速度が Mbytes/s で - おおよそ見当をつけることができます. - - (もしあなたがスピード狂で, - あなたの愛する小さなパソコンちゃんに 10,000RPM - のドライブを載せたいのならそうしても構いませんが, - そのようなドライブはものすごく熱くなります. ドライブへ - 直接 風を当てられるようなファンや - きちんと換気されているディスク区画を持っていないときには - そういうことは考えない方がよいでしょう.) - - 最新の 10,000RPM のドライブや 7,200RPM - のドライブは当然 最新の 5,400RPM - のドライブよりも多くのデータを転送することが できますから, - 絶対的なバンド幅がアプリケーションにとって 必要ならば, - より速いドライブを選ぶしかありません. また, - レイテンシを小さくする必要があるときも, - より速いドライブが適当です. なぜなら, - より速いドライブの方が平均シーク時間が 少ないだけでなく, - 回転遅延という尺度において - 低回転速度のドライブが高回転速度のものに - 勝ることはないからです. (平均回転レイテンシはディスクが 1 - 回転するために要する時間を半分に したものです. すなわち, - 10,000RPM のドライブでは 3 ms, 7,200RPM のドライブでは 4.2 - ms, 5,400RPM のドライブでは 5.6 ms となります.) - レイテンシはシーク時間と回転遅延との和になります. - しかしここで, レイテンシの少ないドライブが欲しいのか, 1 - 秒あたりのアクセス数を増やす方がよいのかを - はっきりさせておかなければいけません. 後者の場合 (例 : - ニュースサーバ) では, 大きな速いドライブを 1 - つ購入することは最適解とはならないでしょう. - 遅いドライブを複数個使ってストライピングされた - ディスクアレイを 作る ccd (連結ディスク) - ドライバを用いることによって, - 全体に必要な費用の点で同様かまたはより - 良い結果を得ることができます. - - ドライブのまわりに適切な空気の - 流れを作るようにする必要が あります. - 高回転速度のドライブを使おうとしているときには特に - 注意してください. 一般的に, ドライブの上下には少なくとも - 1/2 インチ (1.25cm) の すき間が必要です. PC - のケース内の空気がどんなふうに流れているか - 理解しておいてください. - 多くのケースには背面から空気を吸い込む電源が付いています. - どこから空気が入ってくるかを確かめて, まわりに最大量の - 冷たい空気が流れるようにドライブを設置してください. - 効果的に冷却するためには, 不要な穴をいくつか塞いだり - 新しいファンを追加する必要があるかも知れません. - - もうひとつ考慮するべき事柄は騒音です. 7,200RPM - やそれより速い回転速度のドライブの多くは高い周波数の - 音を発生し, この音は多くの人をとても不快にします. - それに加えて, 冷却のために追加されたファンによっても, - 7,200RPM - やそれより速い回転速度のドライブはオフィスや家の環境に - そぐわないものになるかもしれません. - - - - 形状 - - 現在販売されている大部分の SCSI ドライブは 3.5 - インチの 大きさです. それらは高さが 1.6 インチ - (ハーフハイト) のものと 1 インチ - (ロープロファイル) のものとの 2 - 種類に分類されます. ハーフハイトのドライブは CDROM - ドライブと同じ高さです. しかし前節で述べたすき間についての - ルールを忘れないでください. 3.5 インチドライブ用のベイが 3 - 段用意されているときに, ハーフハイトのドライブ 3 個を - (焦がすことなく) - そこに設置することはできないでしょう. - - - - インタフェース - - 現在売られている SCSI ハードドライブの多くは Ultra - または Ultra-wide SCSI です. Ultra SCSI の最大バンド幅は - 20MB/s, Ultra-wide SCSI の場合は 40MB/s です. Ultra と - Ultra-wide の間にケーブル最大長の相違はありませんが, - 同一バスに接続されるデバイスが増えれば増えるほど - 早い時期にバスの整理に関する問題を - 抱えることになるでしょう. - うまく設計されたディスク区画を持っているのでなければ, 5 - 個か 6 個以上の Ultra SCSI ドライブを 1 本のバスに - 接続することは容易なことではありません. - - 一方, 多数のドライブを接続する必要があるときに - Fast-wide SCSI を利用することは悪くないアイデアでしょう. - これは Ultra (narrow) SCSI - と同じ最大バンド幅であると同時に 正しく - 接続することが電気的にとても容易です. - アドバイスとしてはこのようになるでしょうか : - ディスクを多数接続したいときには wide SCSI のドライブを - 選んで下さい. 通常 wide SCSI の方が少し高価ですが, - 将来きっと役に立ちます. (なお, - 価格差を補う余裕がないときにはディスクアレイを - 作るべきではありません.) - - wide SCSI ドライブには 68 ピンのものと 80ピン SCA - (単コネクタ型) のものとの 2 種類があります. SCA - ドライブには 4 ピンの電源コネクタがなく, SCSI ID も 80 - ピンコネクタを通じて設定されます. - 真面目に大規模な記憶システムを作成するような場合には, SCA - ドライブと SCA 筺体 (2 - 種類の電圧が供給できる電源と少なくとも 1 - 個のファンが付いたもの) を使ってください. その方が 68 - ピンの同様のドライブよりも電気的に優れています. なぜなら, - 68 ピンのドライブで作ったディスクアレイに 見られるような - SCSI バスの スタブ - がディスクキャニスタの内部に 存在しないからです. - それらはより簡単に設置することができます - (キャニスタの中にドライブをねじで固定すればよいだけで, - (SCSI ID やディスクアクセス LED 用の線のような) - 細かいケーブルを全部持ち上げるために狭いところへ指を入れて - 握らなくてもよいのです). - - - - - * IDE ハードディスクドライブ - - - - - - - テープドライブ - - 原作: &a.jmb;. - 2 July 1996. - - 訳: &a.jp.yoshiaki;. - 13 October 1996. - - - 一般的なテープアクセスコマンド - - &man.mt.1; はテープドライブへの一般的なアクセス方法を提 - 供します. rewind, - erase, statusなど - の共通コマンドがあります. マニュアルページの &man.mt.1; を見 - てください. より詳しい解説があります. - - - - コントローラインタフェース - - テープドライブにはいくつかの異なったインタフェースがあり - ます. SCSI, IDE, フロッピー, パラレルポートのインタフェース - です. - 非常に多くの種類のテープドライブがこれらのインタフェー - スで使えます. コントローラについての議論はディスク/テープ - のコントローラにあります(訳注:現在未完成です). - - - - SCSI ドライブ - - &man.st.4; ドライバは 8mm (Exabyte), 4mm (DAT: Digital - Audio Tape), QIC (1/4インチカートリッジ), - DLT (デジタルリニアテープ), - QIC ミニカートリッジ, 9トラック (大きなリールがハリウッドの - コンピュータルームで回っているのを見たことがあるでしょう) - をサポートします. - &man.st.4; マニュアルページにより詳しい解説があります. - - - 以下のドライブリストは現在 FreeBSDコミュニティのメンバが - 使っているものです. これらだけが FreeBSDで動くドライブという - わけではありません. - これらは単にたまたま私たちのうちの誰かが使っ - ているというだけです. - - - 4mm (DAT: Digital Audio Tape ) - - Archive Python - 28454 - - Archive Python - 04687 - - HP C1533A - HP C1534A - HP 35450A - HP 35470A - HP 35480A - SDT-5000 - Wangtek 6200 - - - - 8mm (Exabyte) - - EXB-8200 - EXB-8500 - EXB-8505 - - - - QIC (1/4 インチカートリッジ) - - Archive Anaconda 2750 - Archive Viper 60 - Archive Viper 150 - Archive Viper 2525 - Tandberg TDC 3600 - Tandberg TDC 3620 - Tandberg TDC 3800 - Tandberg TDC 4222 - Wangtek 5525ES - - - - DLT (Digital Linear Tape) - - Digital TZ87 - - - - Mini-Cartridge - - Conner CTMS 3200 - Exabyte 2501 - - - - Autoloaders/Changers - - Hewlett-Packard HP C1553A Autoloading DDS2 - - - - - * IDE ドライブ - - - - - - フロッピードライブ - - Conner 420R - - - - * パラレルポートドライブ - - - - - - 詳細な情報 - - - Archive Anaconda 2750 - - このドライブのブートメッセージの識別子は - ARCHIVE ANCDA 2750 28077 -003 type 1 removable - SCSI 2 です. - - これは QIC テープドライブです. - - QIC-1350テープを利用した場合の標準の容量は 1.35GBです. - このドライブは QIC-150 (DC6150), QIC-250 (DC6250), QIC-525 - (DC6525) の - テープを問題なく読み書きすることができます. - - &man.dump.8; を使った時のデータ転送レートは - 350kB/sです. Amanda - における転送レートは 530kB/sと報告されています. - - このドライブは既に生産中止になっています. - - このテープドライブの - SCSIバスコントローラは他のほとんどの - SCSIドライブとピン配置が逆です. Anaconda - テープドライブの前後でSCSIケー - ブルを1/2ひねることができるくらい SCSI - ケーブルが長いことを確認しておく か, 他の - SCSIデバイスのピン配置を入れ換えておく必要 - があります. - - そして, このドライブではカーネルコードの変更が - 2箇所必要です. そ のままではうまく動かないでしょう. - - SCSI-2コントローラを持っているなら, ジャンパの - 6番をショート してください. そうしないとこのドライブは - SCSI-1として働きます. SCSI-1の デバイスとして動作する時, - このドライブはテープのfsf (早送り), rewind (巻 - 戻し),rewoffl (巻戻してオフラインにする) - 等を含む操作を行っている間, - SCSIバスをロックします. - - NCR SCSIコントローラを使う場合, - /usr/src/sys/pci/ncr.c (以 - 下を参照してください)にパッチを行って, カーネルを作り直し, - 新しいカーネ ルをインストールしてください. - - *** 4831,4835 **** }; ! if (np->latetime>4) { /* - ** Although we tried to wake it up, --- 4831,4836 - ---- }; ! if (np->latetime>1200) { /* - ** Although we tried to wake it up, - - 報告者: &a.jmb; - - - - Archive Python 28454 - - このドライブのブートメッセージの識別子は - ARCHIVE Python 28454-XXX4ASB - type 1 removable SCSI 2 - density code 0x8c, 512-byte blocks - です. - - これは DDS-1 テープドライブです. - - 90m テープを使った場合の標準容量は 2.5GBです. - - データ転送速度は不明です. - - このドライブは Sun マイクロシステムが再パッケージして - model 595-3067として出しています. - - 報告者: Bob Bishop rb@gid.co.uk - - スループットは 1.5 MByte/sec クラスですが, - ディスクとテープが同じ SCSI コントローラに接続されている - 場合には遅くなってしまいます. - - 報告者: Robert E. Seastrom - rs@seastrom.com - - - - Archive Python 04687 - - このドライブのブートメッセージの識別子はARCHIVE - Python 04687-XXX 6580 Removable Sequential - Access SCSI-2 deviceです. - - これは DAT-DDS-2 ドライブです. - - 120m テープを使った場合の標準容量は 2.5GBです. - - このドライブはハードウェアデータ圧縮をサポートしています. - スイッチ4は MRS (Media Recognition System:メディア認識システム - )をコントロールします. MRSテープの透明なテープリーダー部分には - しま模様があります. スイッチ 4 をoff - にすると MRS が有効に, on にすると MRS - が無効になります. - - パリティはスイッチ 5 でコントロールされます. スイッチ 5 を - on にするとパリティが有効になります. 圧縮は - スイッチ 6 off で有効です. 圧縮については - SCSI MODE SELECT コマンド (see &man.mt.1;) - の指定が優先されます. - - データ転送レートは 800kB/s です. - - - - Archive Viper 60 - - このドライブのブートメッセージ識別子は - ARCHIVE VIPER 60 21116 -007 - type 1 removable SCSI 1 です. - - これは QICテープドライブです. - - 標準の容量は 60MB です. - - データ転送レートは不明です. - - このドライブは生産中止になっています. - - 報告者: Philippe Regnauld regnauld@hsc.fr - - - - Archive Viper 150 - - このドライブのブートメッセージの識別子は - ARCHIVE VIPER 150 21531 -004 - Archive Viper 150 is a known rogue - type 1 removable SCSI 1です. - このドライブのファームウェアには多くのリビジョ - ンがあります. - あなたのドライブではことなった数字が表示されるかもしれま - せん(例えば 21247 -005). - - これは QICテープドライブです. - - 標準容量は 150/250MBです. 150MB (DC6150) テープと - 250MB (DC6250)テープの記録フォーマットがあります. - 250MBテープは およそ67% 150MBテープより長いです. - このドライブは 120MBのテープを問題 なく読むことができます. - 120MBテープに書き込むことはできません. - - データ転送レートは100kB/sです. - - このドライブは DC6150 (150MB) と DC6250 (250MB) - テープの読み 書きができます. - - このドライブの奇妙な癖は - SCSIテープデバイスドライバはあら かじめ (&man.st.4;) - にあらかじめ組み込まれています. - - FreeBSD 2.2-CURRENTでは, - ブロックサイズの設定を設定するためmt blocksize - 512としてください. (ファームウェアリビジョンが - 21247 -005 である場合の問題です. - 他のリビジョンのファームウェアでは異 なる場合があります.) - これ以前の - FreeBSDバージョンにはこの問題はありません. - - このドライブは生産中止になっています. - - 報告者: Pedro A M Vazquez - vazquez@IQM.Unicamp.BR - - &a.msmith; - - - - Archive Viper 2525 - - このドライブのブートメッセージの識別子は - ARCHIVE VIPER 2525 25462 -011 - type 1 removable SCSI 1です. - - これは QICテープドライブです. - - 標準容量は 525MBです. - - データ転送レートは 90inch/secの場合で 180kB/sです. - - QIC-525, QIC-150, QIC-120, - QIC-24のテープを読むことができま す. QIC-525, QIC-150, - QIC-120 に書き込むことができます. - - ファームウェアのリビジョンが 25462 - -011 以前の物はバグが 多く, - 正しく機能しません. - - このドライブは生産中止になっています. - - - - Conner 420R - - このドライブのブートメッセージの識別子は - Conner tape です. - - これはフロッピーコントローラを - 使うミニカートリッジテープド ライブです. - - 標準容量は不明です. - - データ転送レートは不明です. - - このドライブは QIC-80テープドライブを使います. - - 報告者: Mark Hannon mark@seeware.DIALix.oz.au - - - - Conner CTMS 3200 - - このドライブのブートメッセージの識別子は - CONNER CTMS 3200 7.00 type 1 - removable SCSI 2 です. - - これはミニカートリッジテープドライブです. - - 標準容量は不明です. - - データ転送レートは不明です. - - このドライブは QIC-3080テープカートリッジを使います. - - 報告者: Thomas S. Traylor tst@titan.cs.mci.com - - - - <ulink url="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink> - - このドライブのブートメッセージの識別子は DEC - TZ87 (C) DEC 9206 type 1 removable - SCSI 2 density code 0x19 - です. - - これは DLTテープドライブです. - - 標準容量は 10GBです. - - このドライブはハードウェアデータ圧縮の機能があります. - - データ転送レートは 1.2MB/sです. - - このドライブは Quantum DLT2000と同一の物です. - このドライブ のファームウェアは Exabyteの - 8mmドライブ等のよく知られたいくつかのドラ - イブのエミュレートをおこなうよう設定ができます. - - 報告者: &a.wilko; - - - - <ulink url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink> - - このドライブのブートメッセージ識別子は - EXABYTE EXB-2501です. - - これはミニカートリッジテープドライブです. - - MC3000XLミニカートリッジを使った時の標準容量は 1GBです. - - データ転送レートは不明です. - - このドライブは DC2300 (550MB), DC2750 (750MB), MC3000 - (750MB), MC3000XL (1GB) - ミニカートリッジの読み書きができます. - - 注意: このドライブは SCSI-2の仕様に適合していません. - このドライブは, フォーマット済みのテープ以外を入れた場合, - SCSI MODE_SELCTコマンドで完全にロックアップしてしまいます. - このドライブを使 う前に, - テープブロックサイズを次のように設定します. - - &prompt.root; mt -f /dev/st0ctl.0 blocksize 1024 - - ミニカートリッジは最初に使う前に - フォーマットしなければなりません. FreeBSD 2.1.0-RELEASE - およびそれ以前の場合は - - &prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" - - (あるいは, FreeBSD 2.1.5/2.2から - scsiformatシェルスクリプトを - コピーして持ってきた場合と) FreeBSD - 2.1.5およびそれ以降の場合は &prompt.root; - /sbin/scsiformat -q -w - /dev/rst0.ctl とします. - - 今のところ, - FreeBSDではこのドライブはあまりおすすめできません. - - 報告者: Bob Beaulieu ez@eztravel.com - - - - Exabyte EXB-8200 - - このドライブのブートメッセージの識別子は - EXABYTE EXB-8200 252X type 1 - removable SCSI 1です. - - これは8mmテープドライブです. - - 標準容量は 2.3GBです. - - データ転送レートは 270kB/sです. - - このドライブはブート時の - SCSIバスへの応答はわりあい遅いです. - カスタムカーネルが必要かもしれません (SCSI_DELAYを - 10秒に設定しましょう). 訳注: GENERICカーネルの設定では - 15秒になっています. - - このドライブには非常に多くのファームウェアの - 構成があります. - あるドライブでは特定のベンダのハードウェアに - カスタマイズしてあります. ファームウェアは - EPROMを置き換えることで変更できます. - - このドライブは生産中止になっています. - - 報告者: &a.msmith; - - - - Exabyte EXB-8500 - - このドライブのブートメッセージの識別子は - EXABYTE EXB-8500-85Qanx0 0415 - type 1 removable SCSI 2 です. - - これは 8mmテープドライブです. - - 標準容量は 5GBです. - - データ転送レートは 300kB/sです. - - 報告者: Greg Lehey grog@lemis.de - - - - <ulink url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink> - - このドライブのブートメッセージ識別子は - EXABYTE EXB-85058SQANXR1 05B0 - type 1 removable SCSI 2です. - - これは 圧縮機能を持った 8mmテープドライブで, EXB-5200 - と EXB-8500に対する上位互換品です. - - 標準容量は 5GBです. - - このドライブは - ハードウェアデータ圧縮機能があります. - - データ転送レートは 300kB/sです. - - 報告者: Glen Foster gfoster@gfoster.com - - - - Hewlett-Packard HP C1533A - - このドライブのブートメッセージの識別子は HP - C1533A 9503 type 1 removable SCSI - 2です. - - これはDDS-2テープドライブです. DDS-2 - とはデータ容量を増や すためにハードウェア圧縮と - 狭いトラックを採用したものです. - - 120mテープを使った場合の標準容量は4GBです. - このドライブは - ハードウェアデータ圧縮機能があります. - - データ転送レートは510kB/sです. - - このドライブはヒューレットパッカード社の 6000eU および - 6000i テー プドライブ, C1533A DDS-2 DAT - ドライブに使われています. - - このドライブは 8接点のディップスイッチがあります. - FreeBSDで の適切な設定は 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 - ON; 7 ON; 8 ON です. - - - - - - スイッチ 1 - スイッチ 2 - 結果 - - - - - - On - On - 電源投入時に圧縮 ON, - ホストによるコントロール可能 - - - - On - Off - 電源投入時に圧縮 ON, - ホストによるコントロール不可 - - - - Off - On - 電源投入時に圧縮 OFF, - ホストによるコントロール可能 - - - - Off - Off - 電源投入時に圧縮 OFF, - ホストによるコントロール不可 - - - - - - スイッチ 3 は MRS (Media Recognition System - :メディア認識システ ム) をコントロールします. MRS - テープは透明なテープリーダ部分にしま模 様があります. - これはテープが DDS (Digital Data Storage) グレードである - ことを示します. - しま模様のないテープはライトプロテクトされたものとして - 扱います. スイッチ3をOFFにすると MRSが有効になります. - スイッチ3をONに すると MRSは無効になります. - - 訳注: 安価な音楽用のDATテープを使うには - MRSをOFFにしておきます - - このドライブの設定についてのより詳しい情報は HP SureStore - Tape Products および Hewlett-Packard Disk and Tape Technical Information をご覧ください. - - 注意: - これらのドライブの品質管理は非常に幅がありま す. ある - FreeBSDコアチームのメンバは - このドライブを2つ返品しました. - - 報告者: &a.se; - - - - Hewlett-Packard HP 1534A - - このドライブのブートメッセージの識別子は HP - HP35470A T503 type 1 removable SCSI - 2 Sequential-Access density code - 0x13, variable blocksです. - - これは DDS-1テープドライブです. DDS-1 は最初の DAT - テープフォーマットです. - - 90m テープを使った場合の標準容量は 2GBです. - - データ転送レートは 183kB/sです. - - ヒューレットパッカード社の SureStore 2000i - テープドライブ, C35470A DDS フォーマット - DATドライブ, C1534A DDS フォーマット DATドライブ, HP - C1536A DDS フォーマット DATドライブと - 同じ機構を使用しています. - - HP C1534A DDSフォーマット - DATドライブはグリーンと黄色(アンバー) - の2つの表示ランプがあります. グリーンのランプは動作状 - 態を示し, ローディング中はゆっくり点滅, - ローディングが終了すると点灯, - read/write動作中は速く点滅します. 黄色のランプは警告灯で, - クリーニング - が必要であるかまたはテープが寿命に近くなるとゆっくり点滅, - 致命的なエラー - の場合は点灯します(工場での修理が必要かもしれません). - - - 報告者:Gary Crutcher - gcrutchr@nightflight.com - - - - Hewlett-Packard HP C1553A Autoloading DDS2 - - このドライブのブートメッセージの識別子は未確認です. - - - これはテープチェンジャ付の DDS-2テープドライブです. - DDS-2 とはデータ容量を増や - すためにハードウェア圧縮と狭いトラックを - 採用したものです. - - 120mテープを使用した場合の標準容量は 24GB です. - このドライブはハードウェアデータ圧縮機能があります. - - データ転送レートは510kB/s (標準) です. - - このドライブはヒューレットパッカード社の SureStore - - 12000e テープドライブに使われています. - - このドライブはリアパネルに2つの選択スイッチがあります. - ファンに近いスイッチは SCSI IDです. もうひとつは - 7に設定しておきます. - - 内部に 4個のスイッチがあります. これらは 1 ON; 2 ON; - 3 ON; 4 OFF に設定しておきましょう. - - 現在のカーネルドライバはボリュームの終りで - 自動的にテープを 交換しません. ここに示す - shellスクリプトでテープを交換できます. - - #!/bin/sh -PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH - -usage() -{ - echo "Usage: dds_changer [123456ne] raw-device-name - echo "1..6 = Select cartridge" - echo "next cartridge" - echo "eject magazine" - exit 2 -} - -if [ $# -ne 2 ] ; then - usage -fi - -cdb3=0 -cdb4=0 -cdb5=0 - -case $1 in - [123456]) - cdb3=$1 - cdb4=1 - ;; - n) - ;; - e) - cdb5=0x80 - ;; - ?) - usage - ;; -esac - -scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5" - - - - Hewlett-Packard HP 35450A - - このドライブのブートメッセージの識別子は HP - HP35450A -A C620 type 1 removable - SCSI 2 Sequential-Access density code - 0x13 です. - - これは DDS-1テープドライブです. DDS-1 は最初の DAT - テープフォーマットです. - - 標準容量は 1.2GBです. - - データ転送レートは 160kB/sです. - - 報告者: Mark Thompson - mark.a.thompson@pobox.com - - - - Hewlett-Packard HP 35470A - - このドライブのブートメッセージの識別子は HP - HP35470A 9 09 type 1 removable SCSI - 2です. - - これは DDS-1テープドライブです. DDS-1は最初の DAT - テープフォーマットです. - - 90mテープを使用した時の標準容量は 2GBです. - - データ転送レートは 183kB/sです. - - これはヒューレットパッカード社の SureStore 2000i - テープドライブ, C35470A - DDSフォーマットDATドライブ, C1534A - DDSフォーマットDATドライブ, HP C1536A DDS - フォーマットDATドライブと同 じ機構が使われています. - - 注意: - これらのドライブの品質管理には非常に大き な幅があります. - ある FreeBSDコアチームのメンバは 5台のドライブを返品し - ました. 9ヶ月以上もったものはありません. - - 報告者: David Dawes - dawes@rf900.physics.usyd.edu.au (9 09) - - - - Hewlett-Packard HP 35480A - - このドライブのブートメッセージの識別子は HP - HP35480A 1009 type 1 removable SCSI - 2 Sequential-Access density code - 0x13 です. - - これは DDS-DCテープドライブです. - DDS-DCはハードウェアデータ 圧縮のついたDDS-1です. - DDS-1は最初のDATテープフォーマットです. - - 90mテープを使った場合の標準容量は 2GBです. - 120mテープは使用 できません. - このドライブはハードウェア圧縮機能があります. - 適切なスイッチ設定に関しては, HP C1533A - の節を参照してください. - - データ転送レートは 183kB/sです. - - このドライブはヒューレットパッカード社の SureStore - - 5000eU , 5000i - テープドラ イブ, C35480A DDS フォーマット DAT - ドライブと同じ機構を使っています. - - このドライブは時々, テープの eject操作 (mt - offline) - を行っている時にハングアップすることがあります. - テープをejectさせたり, - ドライブを回復させるにはフロントパネルのボタンを - 押してください. - - 注意: HP 35480-03110 では特有の問題がありました. - 少なくとも2回, FreeBSD 2.1.0 で IBM Server 320に 2940W - SCSIコントローラ - をつけてこのドライブを使っている時にすべての - SCSIディスクのパーティショ ンが失われたことがあります. - この問題は解析も解決もできていません. - - - - <ulink url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink> - - これらには少なくとも DDS-1のものと - DDS-2のものの2つのモデルが あります. DDS-1のものは - SDT-5000 3.02です. DDS-2のものは - SONY SDT-5000 327M です. - DDS-2バージョンには 1MBのキャッシュがあります. この - キャッシュによりあらゆる状況で - テープのデータの流れを途切れさせません. - - このドライブのブートメッセージの識別子は SONY - SDT-5000 3.02 type 1 removable SCSI - 2 Sequential-Access density code - 0x13です. - - 120mテープを使用した場合の標準容量は 4GBです. - このドライブ - はハードウェアデータ圧縮機能があります. - - データ転送レートはドライブのモデルによります. - SONY SDT-5000 327M - でデータ圧縮を行った場合のレートは 630kB/s です. - SONY SDT-5000 3.02では - 225kB/sです. - - Kenneth Merry - ken@ulc199.residence.gatech.edu の報告によれば - このドライブからデータを読むためには, ブロックサイズを - 512バイトにしま す (mt blocksize - 512). - - SONY SDT-5000 327M の情報は Charles - Henrich henrich@msu.edu による報告です. - - 報告者: &a.jmz; - - - - Tandberg TDC 3600 - - このドライブのブートメッセージの識別子は - TANDBERG TDC 3600 =08: type 1 - removable SCSI 2です. - - このドライブはQIC テープドライブです. - - 標準容量は150/250MBです. - - このドライブには奇妙な癖があることが知られていますが, - SCSIテープドライバ (&man.st.4;) - には問題なく動くコードが含まれてい - ます. 問題の修整とSCSI - 2へのコンパチビリティを得るためにファームウェ アをある - (具体的には不明の) バージョンより上にしてください. - - データ転送レートは80kB/sです. - - IBMと Emerald製品のユニットは動かないでしょう. - 問題を解決するためにファームウェア - EPROMを交換してください. - - 報告者: &a.msmith; - - - - Tandberg TDC 3620 - - これは Tandberg TDC - 3600ドライ ブに非常によく似ています. - - 報告者: &a.joerg; - - - - Tandberg TDC 3800 - - このドライブのブートメッセージの識別子は - TANDBERG TDC 3800 =04Y Removable - Sequential Access SCSI-2 device - です. - - これは QIC テープドライブです. - - 標準容量は 525MB です. - - 報告者: &a.jhs; - - - - Tandberg TDC 4222 - - このドライブのブートメッセージの識別子は - TANDBERG TDC 4222 =07 type 1 - removable SCSI 2です. - - これは QICテープドライブです. - - 標準容量は2.5GBです. このドライブは 60M (DC600A) - 以上のすべての カートリッジを読むことができ, 150MB - (DC6150) 以上のすべてのカートリッジを 読み書きできます. - ハードウェア圧縮は 2.5GB カートリッジを使用した時の - オプションとしてサポートされています. - - このドライブには奇妙な癖がありますが, FreeBSD の - 2.2-CURRENT以降の SCSIテープデバイスドライバ (&man.st.4;) - には対応が組み込まれています. それ以前のバージョンの - FreeBSDではmtを用いてテープから1ブロッ - ク読み, テープを巻戻してからバックアッププログラムを - 実行してください. (mt fsr 1; mt rewind; dump - ...). - - データ転送レートは 600kB/s - (データ圧縮時のベンダによる公称) で, start/stop モードでも - 350kB/s にはなります. 容量の小さいカー - トリッジを使った場合にはレートは下がります. - - 報告者: &a.joerg; - - - - Wangtek 5525ES - - このドライブのブートメッセージの識別子は - WANGTEK 5525ES SCSI REV7 3R1 - type 1 removable SCSI 1 - density code 0x11, 1024-byte - blocksです. - - これは QICテープドライブです. - - 標準容量は 525MBです. - - データ転送レートは 180kB/sです. - - 60, 120, 150, 525MB のテープを読むことができます. 60MB - (DC600カートリッジ) には書き込むことはできません. - 120および150テー プに確実に上書きするには, - 先にテープを消去 (mt erase) します. - 120および 150のテープは - 525MBのテープより幅の広いトラックを使用してい - ます(テープ当たりのトラック数は少なくなります). - トラックの幅の外側には上書きされませんので, - テープが消去されない限り 両側に古いデータが残ったまま - 新しいデータが置かれることになります. - - このドライブの奇妙な癖は知られていて, SCSI - テープドライバ (&man.st.4;) に組み込まれています. - - 他のファームウェアのリビジョンで動くことが - 確認されているも のは M75Dです. - - 報告者: Marc van Kempen - marc@bowtie.nl REV73R1 - Andrew Gordon Andrew.Gordon@net-tel.co.uk - M75D - - - - Wangtek 6200 - - このドライブのブートメッセージの識別子は - WANGTEK 6200-HS 4B18 type 1 - removable SCSI 2 Sequential-Access - density code 0x13です. - - これは DDS-1テープドライブです. - - 90mテープを使用した場合の標準容量は 2GBです. - - データ転送レートは 150kB/sです. - - 報告者: Tony Kimball alk@Think.COM - - - - - * 問題のあるドライブ - - - - - - - CDROM ドライブ - - 原作: &a.obrien;. - 23 November 1997. - - Jordan - 氏の選んだ組合せ でふれられているように - FreeBSD プロジェクトでは一般的には IDE - CDROM よりも SCSI CDROM の方が好まれています. しかし全ての - SCSI CDROM ドライブが同じであるというわけではありません. - いくつかの SCSI CDROM ドライブの品質は IDE CDROM - ドライブよりも 低いものであると感じている人もいます. - 東芝は信頼性が高いという評判が ありましたが, 12倍速の XM-5701A - は, SCSI メーリングリストでは ( オーディオ CDROM の再生で) - 何種類かのオーディオ再生ソフトウェアで - ボリュームのコントロールができない, という不満のメールを大量に - 見ることがありました. - - SCSI CDROM のメーカー間の競争のもう一つの局面は, SCSI - 規格に対する忠実度です. 多くの SCSI CDROM は - ターゲットアドレス(ID)の マルチ LUN に応答します. - 既知の規格違反デバイスにはティアックの6倍速ドライブ CD-56S - 1.0D があります. - - - - * その他 - - - - - - - * その他 - - - * PCMCIA - - - - - diff --git a/ja_JP.eucJP/books/handbook/internals/chapter.sgml b/ja_JP.eucJP/books/handbook/internals/chapter.sgml deleted file mode 100644 index ac0f26114b..0000000000 --- a/ja_JP.eucJP/books/handbook/internals/chapter.sgml +++ /dev/null @@ -1,3562 +0,0 @@ - - - - - FreeBSD の内部 - - - - - DMAとはどういったものでどういう働きをするのか - - 原作: - Copyright © 1995,1997 &a.uhclem;, All Rights - Reserved. - 1996 年 10 月 10 日. - 最終更新日 1997 年 10 月 8 日. - - 訳: &a.jp.yasu; - - Direct Memory Access (DMA)は, 中央演算処理装置 - (CPU)からの干渉なく - データを計算機中である場所から別の場所に動かすための手法です. - - - DMA 機能の実装の方法はそれぞれの - 計算機アーキテクチャ間で異なるもので あるため, - ここでの議論はIBMパーソナルコンピュータ(PC), PC/AT - とその互換機における DMA - サブシステムの実装と働きに限定します. - - PCの DMAサブシステムは, Intelの 8237 - DMAコントローラをベースにして います. - 8237はそれぞれ独立にプログラムできる4つのDMAチャネルを持ち, - それぞれどのチャネルもいつでもアクティブにできます. - これらのチャネルは順に 0, 1, 2, 3となっています. PC/ATからは, - セカンド 8237 チップが追加され,それらは 4, 5, 6, 7と - なっています. - - オリジナルの DMAコントローラ(0, 1, 2, 3)は, - 1回の転送で1バイト 転送します. セカンドDMAコントローラ(4, 5, 6, - 7)は1回で 隣接する2つのメモリ番地から 16ビット転送します. - ここで, 最初のバイトは通常偶数のアドレスになります. - 2つのコントローラは全く同じものであり, 転送量が異なるのは - セカンドコントローラがシステムに直結しているためです. - - 8237 は個々のチャネルについて, - DRQと-DACKという2つの電気信号を 持っています. その他に, HRQ - (Hold Request), HLDA (Hold Acknowledge), -EOP (End of - Process)があり, バス制御信号として -MEMR (Memory Read), -MEMW - (Memory Write), -IOR (I/O Read), and -IOW (I/O - Write)があります. - - 8237 DMACは, いわゆるfly-by - DMAコントローラです. これは, データの移動を行う際に, データは - DMACチップを通過せず, DMACチップに格納されないことを意味します. - また, DMACはI/Oポートとメモリアドレス間でのみデータを - 転送することができますが, - 2つのI/Oポートもしくは2つのメモリアドレス - 間ではできません. - - - 8237 は, 非 fly-byモードでは, - 互いに接続された - 2つのチャネルでのメモリ-メモリ間でのDMA操作を許可します. - しかし, PC メーカは, - ただでさえ乏しいこのリソースをこんなふうに 使ったりしません. - なぜなら, - CPUを使用してメモリ間のデータを動かす方が早いからです. - - - PC アーキテクチャでは, それぞれのDMAチャネルは, 通常 - 与えられた DMA - チャネルを使用するハードウェアがそのチャネルについて - DRQ線を使って転送を要求した時のみ動作します. - - - DMA転送の例 - - DMA転送の発生と処理の手順の例をあげてみましょう. - この例では, フロッピーディスクコントローラ (FDC)が - ディスケットから1バイト読み込んで, - DMAを使って,メモリの0x00123456番地に 格納したいとします. - 処理は, FDCが, DRQ2信号(DMAチャンネル2に - 対するDRQ線)を有効にして - DMAコントローラに要求を伝えることで開始されます. - - DMAコントローラは DRQ2 - シグナルが有効になったことを記録します. - するとDMAコントローラはDMAチャネル2がプログラムされ, マスクが - かかっていない(有効になっている)ことを確認します. 同様に, - DMAコントローラは, 他のDMAチャネルがアクティブまたは - アクティブになろうとしていないこと, - そしてより高い優先度を持って いないことを確認します. - 一旦これらのチェックが完了すると, DMACはDMACがバスを使うために - バスを開放するようにCPUに要求します. - DMACはCPUにHRQ信号を送ってバスを要求します. - - CPUはHRQ信号を検出し, 現在の指示の実行を完了します. - 一旦プロセッサがバスを開放することができる状態になると, 解放を - 行います. 通常は CPU により駆動される信号 (-MEMR, -MEMW, - -IOR, -IOW, その他)を すべてハイインピーダンス - (ハイともローとも指定しない)状態にした後, CPUは - HLDA信号を有効にして DMAコントローラにバスを明け渡したことを - 伝えます. - - プロセッサによっては, CPUはバスを使用しないいくつかの - 命令を追加して実行することもできますが, - しかし,プロセッサの内部キャッシュや - パイプライン以外のメモリから - 何か読み出すといった指示に到達したら結局 CPU - は待たなくてはなりません. - - ここで,DMACが バスを託されると, DMACはその - -MEMR, -MEMW, -IOR, -IOW 出力信号をアクティブにし, - DMACから出力されるアドレスは 0x3456にセットされます.これは - 転送しようとする特定のメモリ番地をバイトで - 指示するのに使われます. - - すると DMAC は DMA - 転送をリクエストしたデバイスに転送が始まることを - 知らせます.これは -DACK - 信号をアクティブにすることで行われます. - フロッピーディスクコントローラの場合は, -DACK2を - アクティブにすることで行われます. - - バスのデータ線に転送されるバイトにを出力することについては - フロッピーディスクコントローラが責任をもつことになります. - もし,フロッピーディスクコントローラがバス上にバイトデータを - 出力するのに余計な時間を必要としなければ - (もし周辺装置がもっと時間を必要とする場合には, READY信号を - 経由してDMACに通知します), DMAは 1 DMAクロック待ち, - メモリにバス上のバイトデータを格納するために -MEMW および -IOR - 信号を解除します. そして - FDCはバイトデータが転送されたことを認識します. - - DMAサイクルは1度に1バイトしか転送しないので, - FDCはDRQ2信号を止めて, DMACに転送が終了したことを知らせます. - DMACは-DACK2信号を解除して, FDCはバス上へのデータ出力を - 停止しなくてはならないことを知らせます. - - 次にDMACは他のDMAチャネルのいずれかに要求がきていないか - チェックを行います. - もしどのチャネルのDRQも有効になっていなければ, - DMAコントローラは処理を完了して, -MEMR, -MEMW, -IOR, -IOW - および アドレス信号をハイインピーダンス状態にします. - - 最後に, DMAはHRQ信号を解除します. - CPUはこれを見ると,HOLDA信号を 解除します. そしてCPUは自らの - -MEMR, -MEMW, -IOR, -IOW 信号および アドレス線を有効にし, - 命令の実行やメインメモリや周辺機器へのアクセスを - 再開します. - - 典型的なフロッピーディスクの1セクタについては, - 上記のプロセスが それぞれのバイトについて1回行われ, - 全部で512回繰り返されます. 1 バイト転送される毎に, DMAC - 内のアドレスレジスタはインクリメントされ, 同じくDMAC内にある, - 何バイト転送すればよいかを示すカウンタが - デクリメントされます. - - カウンタが0になると, DMAはEOP信号を送ります. この信号は - カウンタが0であり, DMAコントローラがCPUによって再び - プログラムされるまで, これ以上データは転送されないことを - 示すものです. - - このイベントはターミナルカウント(TC)とも呼ばれます. - EOP信号は1本しかありません. そして, 一度にアクティブにできる - DMAチャネルは一本だけなので, - 現在アクティブであるDMAチャネルこそが, - たった今処理を終了したDMAチャネルだと言うことができます. - - もし, - バッファの転送が完了した時に周辺機器から割り込みを発生させたい - とき, 周辺機器は - -DACKn信号およびEOP信号の両方が同時に発信されたか - どうかをテストします. その場合, DMACはCPUの介在がなければ - これ以上はその周辺機器についての情報を転送しません. その後で, - 周辺機器はプロセッサに割り込みを生じさせるために, - 何らかの割り込み信号を発生させることができます. - PCアーキテクチャ においては, - DMAチップ自身が割り込みを生じさせることはできません. - 周辺機器とそれに関連するハードウェアが割り込みを生成する責任を - 持ちます. また, DMAを使用する周辺機器が割り込みを使用しない - 可能性もあります. - - DMAC が要求を出したときには CPU は常にバスを DMAC - に開放しますが, この動作は, DMAC - がアクティブになった時にプロセッサが命令を実行するのに - かかる時間がわずかに変化することを除いては, アプリケーション, - オペレーティングシステムの両方からはわからないということを - 理解することが重要です. そのため, - プロセッサが確かにDMA転送が完了したことを知るためには, - 周辺装置や DMA - チップ中のレジスタを調べたり,周辺装置からの割り込みを - 受け取る必要があります. - - - - DMA ページレジスタ および 16メガ アドレス空間制限 - - これまで述べたのとは異なり, DMACはアドレス線を 0x0123456 - にセットする 代わりに 0x3456 - だけをセットすることにあなたは気づいたかも しれません. - この理由について少し説明します. - - オリジナルのIBM PCがデザインされた時, IBMは, - DMACと割込み制御チップの 両方を, 8085(8ビットプロセッサで, - 16ビットのアドレス空間(64k)を持つ)と - 組み合わせて使うように設計されたチップを使うことを選びました. - IBM PCが64k以上のメモリをサポートしていたため, - DMACが64kを越えるメモリ番地に読み込み又は書き込みを行うために - 変更を行う必要が生じました. - この問題を解決するためにIBMが行ったのは, - それぞれのDMAチャネルに, - 読み込み元または書き込み先のアドレスの - 上位ビットを保持するための 外部的なラッチを追加することでした. - DMAチャネルがアクティブな時はいつでも, - このラッチの内容はアドレスバスに書かれて, - そのチャネルのDMA操作が 終了するまでそこに保持されます. IBM - はこれらのラッチを ページレジスタ - と呼んでいます. - - そのため上記に示した例では, - DMACはアドレスの0x3456の部分をバス上に 置き, - DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に - 置きます. - これらの2つの値が組み合わされてアクセスされるメモリ中の完全な - アドレスを形成します. - - ページレジスタのラッチはDMAチップとは独立であるので, - 読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を - またいではなりません. 例えば, もし - DMACがメモリの0xffff番地をアクセスした場合, データの転送後, - DMACはアドレスレジスタをインクリメントし, - 0x0000番地にある次のバイトを アクセスします. - 0x10000番地ではありません. - これはおそらく意図されたものとは異なっているでしょう. - - - 物理的な 64Kの境界を 8086モードの - 64k セグメントと混同してはいけません. - セグメントは, セグメント - レジスタに数学的にオフセットレジスタを - 加算して作られるものです. - ページレジスタにはアドレスのオーバーラップも無く, 数学的に - OR を取られることもありません. - - - さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは - 8ビットしか保持しません. よって8+16で24ビットになり, これは - DMAが0から16メガの間のメモリ番地しか指し示せないことを - 意味します. - 16メガ以上のメモリを持ったより新しいマシンにおいても, - 標準的なPCコンパチブルなDMAでは16メガ以上のメモリ番地には - アクセスできません. - - この制限を避けるために, オペレーティングシステムは 16 - メガ以下にある物理的な 64k の境界をまたがない領域に RAM - バッファを 予約します. そして, - DMACはデータを周辺機器からそのバッファに - 転送するようにプログラムされます. 一旦DMACがこのバッファに - データを動かすと, オペレーティングシステムは本当にデータを - 格納したいアドレスにバッファからデータをコピーします. - - 16メガを越えるアドレスからDMAベースの周辺機器にデータを - 書き込む際には, データは16メガ以下に位置したバッファから最初に - コピーされなくてはならず, その後, - DMACはバッファからハードウェアに - データをコピーすることができます. FreeBSDでは, - これらの予約バッファは - バウンスバッファと呼ばれます. MS-DOSの世界では, - これらはスマートバッファなどと呼ばれます. - - - 82374と呼ばれる8237の新しい実装においては, - ページレジスタを16ビットで指定して, - バウンスバッファを使用しなくても, 32 - ビットのアドレス空間全体にアクセスすることが可能です. - - - - - DMA操作モードとその設定 - - 8237 DMA はいくつかのモードで動作します. 主なモードは, - 以下のとおりです. - - - シングル転送モード - - シングルバイト(もしくはワード)が転送されます. - DMAは1バイト毎にバスを開放し, - 再び要求しなくてはなくてはなりません. これは一般に, - すぐにはデータのブロック全てを転送できないデバイスに - よって使用されます. - 周辺装置は次の転送の準備ができる毎にDMAを要求します. - - - 標準的な PC - コンパチブルなフロッピーディスクコントローラ(NEC 765)は - 1バイトのバッファしか持たないので, - このモードを使用します. - - - - ブロック/デマンド転送モード - - 一旦 DMAC がシステムバスを取得すると, - 最大64kまでのデータブロック 全体が転送されます. - もし周辺装置が余分に時間を必要とするときは, - 転送を一時中断するためにREADY信号を有効にします. - READY信号は過度に使われるべきではなく, - 遅い周辺装置の転送の場合は - シングル転送モードを代わりに使うべきです. - - ブロック転送モードとデマンド転送モードの違いは, - 一旦ブロック転送が 始まると, 転送カウンタか 0 - になるまでそれが行われるところです. DRQ は -DACK - が有効になるまでの間は有効でなければなりません. - デマンドモードは DRQ が有効な間転送が続けられます. - DRQが有効でなくなった場合, DMA はその時点で転送を中断し, - バスを解放して CPU に返します. - その後, DRQが有効になると, - 転送は中断したところから再開されます. - - データの転送, - 特に転送に使われるメモリ番地が16Mを越える場合に, CPU - を使った方が効率がよくなるまで CPU - の速度が向上する以前の - 古いハードディスクコントローラはデマンドモードを - 使っていました. - - - - カスケード転送モード - - このメカニズムは DMA - チャネルがバスを要求することを許可する ものですが, - 接続されたデバイスはバス上のアドレス情報の配置に - ついてDMACに代わって責任を持ちます. - これはバスマスタ - と呼ばれる技術の実装に利用されます. - - カスケードモードの DMA - チャネルがバスのコントロールを受け取ると, DMA - は通常行われるようなバス上のアドレスと I/O - コントロール信号の 出力を行いません. 代わりに, - DMAはアクティブなチャネルの -DACK信号を - 有効にします. - - この時点で, アドレスとバスコントロール信号の供給は - DMAチャネルに接続された周辺機器が担当します. - 周辺機器はシステムバスの完全なコントロールを行い, 16 - メガ以下の任意のアドレスの読み込みおよび書き込みを - 行うことが できます. 周辺機器はバスの使用を終えると DRQ - 線を無効にするので, DMA コントローラは CPU - もしくは他のDMAチャネルに制御を返すことが - できます. - - カスケードモードは複数の DMA - コントローラを相互接続するのに 使われます. - PC内ではDMAチャネル4がまさにこの用途に使われています. - 周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると, - スレーブDMAコントローラは HLDREQ を有効にしますが, - この線はCPUではなく, - 実際にはプライマリDMAコントローラのDRQ4に - 接続されています. その後, - チャンネル4になにか仕事があるものと見なしたプライマリの - DMAコントローラは HLDREQ を使ってCPUにバスを 要求します. - バスが与えられると, -DACK4が有効になりますが, - この線は実際にはスレーブDMAコントローラの HLDA信号に - 接続されています. - スレーブDMAコントローラはその後要求したDMAチャネル (0, - 1, 2, 3) に対してデータを転送するか, - SCSIコントローラのような - バスマスタリングを要求する周辺機器にバスを許可します. - - - このような配線がおこなわれているため, - PC/ATシステムの 周辺機器ではDMAチャネルは 0, 1, 2, 3, 5, - 6, 7のみが使用できます. - - - 初期のIBM PCコンピュータでは, DMAチャネル0は操作の - リフレッシュのために予約されていますが, - 最近のシステムでは通常, - 周辺機器によって使用することができます. - - - 周辺機器がバスマスタリングを行っている時は, - システムバスを保持している間絶えずメモリに - もしくはメモリから データを転送することが重要です.もし, - 周辺機器がこのように できないときは, - システムがメインメモリのリフレッシュを - 行なえるようにしばしばバスを開放しなくては - なりません. - - 全ての PC でメインメモリとして使われるダイナミック - RAM は, 中身が 満たされている - ビットを保持するため - 頻繁にアクセスされなくてはなりません. ダイナミック RAM - は, それぞれが 1 ビットのデータを記憶するコンデンサが - たくさん集まって構成されています. - これらのコンデンサは充電された 状態で - 1, 充電されていない状態で - 0 を表します. - 全てのコンデンサは放電するため, 1 - の値を保持するために, - 一定の間隔で電力を加える必要があります. 実際に RAM - チップは RAM の適切な場所に電力を送る作業を行ないますが, - メモリのリフレッシュ作業が RAM を普通にアクセスする時と - 衝突しないように, それをいつ行なうかを - コンピュータが休止状態の時に知らせなくてはなりません. - もしコンピュータがメモリのリフレッシュを - 行なえない場合は, - メモリの中身はわずか数ミリ秒で壊れてしまいます. - - メモリの読み込みと書き込みのサイクルは - リフレッシュサイクルとして カウントされる - (ダイナミック - RAM のリフレッシュサイクルは - 実際には不完全なメモリ読み込みサイクルになります)ので, - 周辺機器のコントローラが連続するメモリ番地から - データの読み込み または書き込みを行う間は, - メモリの全てがリフレッシュされます. - - バスマスタリングはいくつかの SCSI - ホストインタフェースやその他の - ハイパフォーマンスな周辺機器コントローラに - 見られます. - - - - 自動初期化転送モード - - このモードにおいてDMAはバイト, ブロック, - デマンド転送を行いますが, DMA転送カウンタが0になると, - カウンタとアドレスはDMAチャネルが - もともとプログラムされた時のものに戻されます. これは, - 周辺機器が転送を要求している間は転送が続けられることを - 意味します. - 転送領域としてDMACにプログラムされた固定バッファの中で, - 出力操作でDMACがデータを読み出す前もって新しいデータを - 書き込んだり入力操作でDMACが書き込んだあとに, - そこから新しいデータを読み出す作業は CPU - が受け持ちます. - - このテクニックは, サンプリング - 用のバッファが小さいもしくは - それを持たないオーディオデバイスによく使われます. - この環状バッファの管理は更なる CPU - オーバーヘッドになりますが, DMAカウンタが0になり, - 再プログラムされるまでDMAが停止してしまう - ことによって起きる遅延は, - この方法でしかなくす事ができない 場合もあります. - - - - - - - DMAのプログラミング - - プログラムされるDMAチャネルは, 通常, 設定を行う前に - マスクするべきです. - これはハードウェアが予期せずそのチャンネルに対してDRQを有効に - した場合, たとえ全てのパラメータが - 満たされてない場合や更新されていない場合でも, DMACは - それに応答してしまう可能性があるからです. - - マスクを行ってから,ホストは転送の方向(メモリからI/O, - もしくはI/Oからメモリ)と, 転送に使用するDMA操作のモード - (シングル, ブロック, デマンド, カスケードなど)を設定し, 最後に - アドレスや転送の長さを設定します. - 設定される長さはDMACに転送させたい量よりも1少なくなります. - アドレスや転送長のLSBとMSBは同じ8ビットI/O - ポートに書き込まれます. そのためDMACが最初のバイトをLSBとして, - 2番目のバイトをMSBとして 受け取ることを保証するために, - 最初に別のポートに書き込みを行なって LSBとMSB - の判別を行なうフリップフロップをクリアしておく必要があります. - - - そして,DMAのページレジスタを更新します. - これはDMACの外部にあり I/O - ポートの別のセットを通してアクセスされます. - - すべての設定ができると, - DMAチャネルはマスクを解除することができます. - そのDMAチャネルは準備ができたとみなされ, - そのチャンネルのDRQが 有効になると応答します. - - 8237のプログラミングの正確な詳細については, - ハードウェアデータブックを参照してください. PCシステムにおける - I/O マップについても参照する必要があるでしょう. このマップには - DMA およびページレジスタのポートがどこに位置するのかを - 書いてあります. - 以下に完全なポートのマップテーブルを示します. - - - - DMAポートのマップ - - IBM-PCとPC/ATに基づくすべてのシステムでは, - 同じI/Oポートに配置された DMAハードウェアを持っています. - その完全なリストを以下に示します. - DMAコントローラ2に割り当てられたポートは, AT以外のデザインでは - 未定義になっています. - - - 0x00 – 0x1f DMA コントローラ #1 (Channels 0, 1, 2 - and 3) - - DMA アドレス および カウントレジスタ - - - - - - 0x00 - write - Channel 0 starting address - - - - 0x00 - read - Channel 0 current address - - - - 0x01 - write - Channel 0 starting word count - - - - 0x01 - read - Channel 0 remaining word count - - - - 0x02 - write - Channel 1 starting address - - - - 0x02 - read - Channel 1 current address - - - - 0x03 - write - Channel 1 starting word count - - - - 0x03 - read - Channel 1 remaining word count - - - - 0x04 - write - Channel 2 starting address - - - - 0x04 - read - Channel 2 current address - - - - 0x05 - write - Channel 2 starting word count - - - - 0x05 - read - Channel 2 remaining word count - - - - 0x06 - write - Channel 3 starting address - - - - 0x06 - read - Channel 3 current address - - - - 0x07 - write - Channel 3 starting word count - - - - 0x07 - read - Channel 3 remaining word count - - - - - - DMA コマンドレジスタ - - - - - - 0x08 - write - Command Register - - - - 0x08 - read - Status Register - - - - 0x09 - write - Request Register - - - - 0x09 - read - - - - - - 0x0a - write - Single Mask Register Bit - - - - 0x0a - read - - - - - - 0x0b - write - Mode Register - - - - 0x0b - read - - - - - - 0x0c - write - Clear LSB/MSB Flip-Flop - - - - 0x0c - read - - - - - - 0x0d - write - Master Clear/Reset - - - - 0x0d - read - Temporary Register - (新しいバージョンでは利用不可) - - - - 0x0e - write - Clear Mask Register - - - - 0x0e - read - - - - - - 0x0f - write - Write All Mask Register Bits - - - - 0x0f - read - Read All Mask Register Bits (Intel - 82374にのみ存在する) - - - - - - - - 0xc0 – 0xdf DMA コントローラ #2 (Channels 4, 5, 6 - and 7) - - DMA アドレス および カウントレジスタ - - - - - - 0xc0 - write - Channel 4 starting address - - - - 0xc0 - read - Channel 4 current address - - - - 0xc2 - write - Channel 4 starting word count - - - - 0xc2 - read - Channel 4 remaining word count - - - - 0xc4 - write - Channel 5 starting address - - - - 0xc4 - read - Channel 5 current address - - - - 0xc6 - write - Channel 5 starting word count - - - - 0xc6 - read - Channel 5 remaining word count - - - - 0xc8 - write - Channel 6 starting address - - - - 0xc8 - read - Channel 6 current address - - - - 0xca - write - Channel 6 starting word count - - - - 0xca - read - Channel 6 remaining word count - - - - 0xcc - write - Channel 7 starting address - - - - 0xcc - read - Channel 7 current address - - - - 0xce - write - Channel 7 starting word count - - - - 0xce - read - Channel 7 remaining word count - - - - - - DMA コマンドレジスタ - - - - - - 0xd0 - write - Command Register - - - - 0xd0 - read - Status Register - - - - 0xd2 - write - Request Register - - - - 0xd2 - read - - - - - - 0xd4 - write - Single Mask Register Bit - - - - 0xd4 - read - - - - - - 0xd6 - write - Mode Register - - - - 0xd6 - read - - - - - - 0xd8 - write - Clear LSB/MSB Flip-Flop - - - - 0xd8 - read - - - - - - 0xda - write - Master Clear/Reset - - - - 0xda - read - Temporary Register (Intel 82374には存在しない) - - - - 0xdc - write - Clear Mask Register - - - - 0xdc - read - - - - - - 0xde - write - Write All Mask Register Bits - - - - 0xdf - read - Read All Mask Register Bits (Intel - 82374にのみ存在する) - - - - - - - - 0x80 – 0x9f DMA ページレジスタ - - - - - - 0x87 - r/w - Channel 0 Low byte (23-16) page Register - - - - 0x83 - r/w - Channel 1 Low byte (23-16) page Register - - - - 0x81 - r/w - Channel 2 Low byte (23-16) page Register - - - - 0x82 - r/w - Channel 3 Low byte (23-16) page Register - - - - 0x8b - r/w - Channel 5 Low byte (23-16) page Register - - - - 0x89 - r/w - Channel 6 Low byte (23-16) page Register - - - - 0x8a - r/w - Channel 7 Low byte (23-16) page Register - - - - 0x8f - r/w - Low byte page Refresh - - - - - - - - 0x400 – 0x4ff 82374 Enhanced DMA Registers - - Intel 82374 EISA System Component - (ESC)は1996年の初めに発表されました. この中 - には機能的には8237のスーパーセットであり, - 1つのパッケージの中にその他の PC - 互換機のコアとなる周辺コンポーネントをも含んだ DMA - コントローラも含まれています. このチップはEISAとPCI - 両方のプラットホームをターゲットにしたものであり, - scatter-gather I/O やリングバッファを始めとして, - システムDMAをして32ビットの - アドレス空間全体に直接アクセスする能力も提供しています. - - - これらの機能を使用する場合でも, - 過去16年間のPC互換機で利用されてきた - 同等機能を提供するコードも含めておく必要があります. - 互換性の問題から, 82374の レジスタの一部は, - 従来の8237のレジスタをプログラムした 後 - に, 転送の度にプログラムされる必要があります. - 8237のレジスタに書き込みを行うとき, - ソフトウェアの下位互換性のために, - 82374で追加された一部のレジスタの内容が - 強制的に0にクリアされるからです. - - - - - - 0x401 - r/w - Channel 0 High byte (bits 23-16) word count - - - - 0x403 - r/w - Channel 1 High byte (bits 23-16) word count - - - - 0x405 - r/w - Channel 2 High byte (bits 23-16) word count - - - - 0x407 - r/w - Channel 3 High byte (bits 23-16) word count - - - - 0x4c6 - r/w - Channel 5 High byte (bits 23-16) word count - - - - 0x4ca - r/w - Channel 6 High byte (bits 23-16) word count - - - - 0x4ce - r/w - Channel 7 High byte (bits 23-16) word count - - - - 0x487 - r/w - Channel 0 High byte (bits 31-24) page - Register - - - - 0x483 - r/w - Channel 1 High byte (bits 31-24) page - Register - - - - 0x481 - r/w - Channel 2 High byte (bits 31-24) page - Register - - - - 0x482 - r/w - Channel 3 High byte (bits 31-24) page - Register - - - - 0x48b - r/w - Channel 5 High byte (bits 31-24) page - Register - - - - 0x489 - r/w - Channel 6 High byte (bits 31-24) page - Register - - - - 0x48a - r/w - Channel 6 High byte (bits 31-24) page - Register - - - - 0x48f - r/w - High byte page Refresh - - - - 0x4e0 - r/w - Channel 0 Stop Register (bits 7-2) - - - - 0x4e1 - r/w - Channel 0 Stop Register (bits 15-8) - - - - 0x4e2 - r/w - Channel 0 Stop Register (bits 23-16) - - - - 0x4e4 - r/w - Channel 1 Stop Register (bits 7-2) - - - - 0x4e5 - r/w - Channel 1 Stop Register (bits 15-8) - - - - 0x4e6 - r/w - Channel 1 Stop Register (bits 23-16) - - - - 0x4e8 - r/w - Channel 2 Stop Register (bits 7-2) - - - - 0x4e9 - r/w - Channel 2 Stop Register (bits 15-8) - - - - 0x4ea - r/w - Channel 2 Stop Register (bits 23-16) - - - - 0x4ec - r/w - Channel 3 Stop Register (bits 7-2) - - - - 0x4ed - r/w - Channel 3 Stop Register (bits 15-8) - - - - 0x4ee - r/w - Channel 3 Stop Register (bits 23-16) - - - - 0x4f4 - r/w - Channel 5 Stop Register (bits 7-2) - - - - 0x4f5 - r/w - Channel 5 Stop Register (bits 15-8) - - - - 0x4f6 - r/w - Channel 5 Stop Register (bits 23-16) - - - - 0x4f8 - r/w - Channel 6 Stop Register (bits 7-2) - - - - 0x4f9 - r/w - Channel 6 Stop Register (bits 15-8) - - - - 0x4fa - r/w - Channel 6 Stop Register (bits 23-16) - - - - 0x4fc - r/w - Channel 7 Stop Register (bits 7-2) - - - - 0x4fd - r/w - Channel 7 Stop Register (bits 15-8) - - - - 0x4fe - r/w - Channel 7 Stop Register (bits 23-16) - - - - 0x40a - write - Channels 0-3 Chaining Mode Register - - - - 0x40a - read - Channel Interrupt Status Register - - - - 0x4d4 - write - Channels 4-7 Chaining Mode Register - - - - 0x4d4 - read - Chaining Mode Status - - - - 0x40c - read - Chain Buffer Expiration Control Register - - - - 0x410 - write - Channel 0 Scatter-Gather Command Register - - - - 0x411 - write - Channel 1 Scatter-Gather Command Register - - - - 0x412 - write - Channel 2 Scatter-Gather Command Register - - - - 0x413 - write - Channel 3 Scatter-Gather Command Register - - - - 0x415 - write - Channel 5 Scatter-Gather Command Register - - - - 0x416 - write - Channel 6 Scatter-Gather Command Register - - - - 0x417 - write - Channel 7 Scatter-Gather Command Register - - - - 0x418 - read - Channel 0 Scatter-Gather Status Register - - - - 0x419 - read - Channel 1 Scatter-Gather Status Register - - - - 0x41a - read - Channel 2 Scatter-Gather Status Register - - - - 0x41b - read - Channel 3 Scatter-Gather Status Register - - - - 0x41d - read - Channel 5 Scatter-Gather Status Register - - - - 0x41e - read - Channel 5 Scatter-Gather Status Register - - - - 0x41f - read - Channel 7 Scatter-Gather Status Register - - - - 0x420-0x423 - r/w - Channel 0 Scatter-Gather Descriptor Table Pointer - Register - - - - 0x424-0x427 - r/w - Channel 1 Scatter-Gather Descriptor Table Pointer - Register - - - - 0x428-0x42b - r/w - Channel 2 Scatter-Gather Descriptor Table Pointer - Register - - - - 0x42c-0x42f - r/w - Channel 3 Scatter-Gather Descriptor Table Pointer - Register - - - - 0x434-0x437 - r/w - Channel 5 Scatter-Gather Descriptor Table Pointer - Register - - - - 0x438-0x43b - r/w - Channel 6 Scatter-Gather Descriptor Table Pointer - Register - - - - 0x43c-0x43f - r/w - Channel 7 Scatter-Gather Descriptor Table Pointer - Register - - - - - - - - - - FreeBSD VM システム - - 原作: &a.dillon;. 6 Feb 1999 - - - 物理メモリ管理 — <literal>vm_page_t</literal> - - 物理メモリはページ単位に, - vm_page_t構造体を用いて管理されます. - 物理メモリのページは, ページキューの一つに存在する, - それぞれの vm_page_t - 構造体の配置によって分類されます. - - ページは, wired(ワイヤード), active(活性状態), - inactive(非活性状態), cache(キャッシュ状態), - free(使われていない状態)の 各状態をとります. wired - 状態を除いて, ページは通常 - その状態を示す二重連結リストのキューに置かれます. wired - 状態のページがキューに置かれることはありません. - - FreeBSD は, ページカラーリング(page - coloring)を実装するため, cache 状態, free - 状態にあるページ用に, - さらに複雑なページキューを実装しています. その各々の状態は, - プロセッサの L1, L2 キャッシュサイズに応じて最適化された - 多重キューを利用します. FreeBSD は, - 新たなページを確保(allocate)することが - 必要になった場合に確保される VM オブジェクトのために, L1, L2 - キャッシュに対して合理的にアライン(align)されたページを - 得ようと試みます. - - 加えて, ページは参照カウントとともに保持され, - ビジーカウントとともにロックされます. VM システムは, - ページフラグとして PG_BUSY を使う完全ロック状態 - も実装しています. - - - 一般的には, 各々のページキューは最長不使用 (LRU) - 方式で動作します. ページは普通, 最初に wired, もしくは active - 状態に置かれます. wired 状態の場合, - そのページはどこかにあるページテーブルに 関連づけられています. - VM システムはアクティブなキュー内のページをスキャンし, wired - 状態のページにエイジング (訳注: - ページ参照頻度を量る手法の一つ; aging) を施します. そして, - そのページはあまりアクティブでないキューへ - 移動することになります. cache キューに移動させられたページは, - 再利用の候補になっている VM - オブジェクトに割り付けられています. free - キューにあるページは, 完全に自由の状態にあります. FreeBSD は, - free キューにあるページ数を最小限にとどめようと 試みますが, - 割り込み発生時のページ確保を融通するため, - 完全に自由なページをいくつか持っていなければなりません. - - - プロセスがページテーブルに存在しない, - ページキューの一つ(例えば, inactive, cache キュー等)に - 存在するページをアクセスしようとしたとき, - 比較的負荷の小さなページ再活性化フォールトが起こります. - システムメモリに全く存在していないページの場合は, - ディスクからページを読み出す間, - そのプロセスはブロック(block)されます. - - FreeBSD は, ページキューを動的に調節し, - 同期済(clean)のページ, 同期していない(dirty)ページの分類を - 合理的に保つのと同様に, それぞれのキューにあるページが合理的な - 比率に保つように試みます. 再バランス化処理が起こる量は, - システムのメモリ負荷に依存します. この再バランス化処理は - ページアウトデーモンによって実装されていて, - (補助記憶とページを同期して)同期していないページの - クリーニングすることや, (LRU - キュー内でのページ位置を再配置したり, - ページをキューの間を移動することで)ページが頻繁に - 参照状態にあることに注目すること, キューを均等にするための - キュー間ページ移動等を伴います. - ページが実際にどれだけ使われているかを決定するために, FreeBSD - の VM システムは, ページの再活性化フォールトを 自発的に, - 合理的な数だけ発生します. これは, - ページをスワップアウトしたり, クリーニングする時期を - より良く決めることに繋がります. - - - - 統合バッファキャッシュ — - <literal>vm_object_t</literal> - - FreeBSD は, 一般化した VM オブジェクト - という考え方を実装しています. VM オブジェクトは, - 様々な種類の補助記憶(backing store) — 補助記憶なし, - スワップ, 物理デバイス, ファイル, に割り付けられます. - ファイルシステムは - ファイルと関連するインコアデータを管理するのに, 同じ VM - オブジェクトを利用するため, - 統合バッファキャッシュと呼ばれます. - - VM オブジェクトは, シャドウ化 - することができます. シャドウ化とは, - オブジェクトがそれぞれ互いの上に - スタック(stack)されるということです. 例えば, MAP_PRIVATE - mmap() の 動作を実装するために, ファイルに割り付けられた VM - オブジェクトの上にスタックされた, スワップに割り付けられた VM - オブジェクトが存在しているでしょう. このスタッキングは, fork - されたアドレス空間のための 様々な共有属性, - コピーオンライト(訳注: ページ共有のための 手法の一つ; - cow,copy-on-write) を実装するのにも利用されています. - - vm_page_t は, 同時に一つの VM - オブジェクトしか割り付けられることが - できないことに注意しなければなりません. VM - オブジェクトのシャドウ化は, 複数のインスタンスが同じページに - 共有できるように実装されています. - - - - ファイルシステム I/O — <literal>struct - buf</literal> - - - 補助記憶にファイルを使う VM オブジェクトのように, v - ノードを使う VM オブジェクトは通常, - 処理されているかどうかという情報を, - VMシステムが管理する処理情報から独立して - 管理される必要があります. 例えば, VM - システムが物理ページと補助記憶を同期させようとしたとき, VM - システムは, 実際に書き戻す前に, - ページがクリーニング済であるという - マークを付ける必要があるわけです. さらに, ファイルシステムは, - KVM 内で操作できるように, ファイルや, - ファイルメタデータの一部分を KVM にマッピングすることが - できなくてはなりません. - - これを管理するために使われる実体は, - ファイルシステムバッファ, struct buf, - bp として知られています. - ファイルシステムに VM オブジェクトの一部を操作することが - 必要となるときは通常, オブジェクトの部分が struct buf に - マッピングされ, KVM に struct buf - 内のページがマッピングされます. 同じ方法で, ディスク I/O - はオブジェクトの部分を バッファ構造体内にマッピングし, - その時バッファ構造体上の I/O を 発行することで発行されます. - 基礎となっている vm_page_t は, I/O 処理の間 - ビジー(busy)状態になります. ファイルシステムにも - 独立したビジー状態があり, それはハードウェア上の VM - ページの代わりに ファイルシステムバッファで動作する - ファイルシステムドライバのコードに とって有用です. - - FreeBSD は, マッピングを保持するためにある量に制限された - KVM を 予約していますが, KVM - がマッピングを保持するためだけに使われ, - キャッシュデータの能力を制限しないということは - 明確にされるべきでしょう. - 物理データキャッシュを行うことは厳密に - vm_page_t の機能になっており, - ファイルシステムバッファの機能ではありません. しかし, - ファイルシステムバッファは placehold I/O に使われるため, - それは実質的に同時処理可能な I/O 処理量を制限します. - 通常は二, 三千のファイルバッファが利用可能ですから, - このことは問題にならないでしょう. - - - - マッピングページテーブル — - <literal>vm_map_t</literal>, - <literal>vm_entry_t</literal> - - - FreeBSD は, 物理ページテーブルの形態を VM - システムと分離しています. - ハードウェア上にある全てのプロセス毎のページテーブルは, - その場その場で再構成され, 通常, 使い捨てだとみなされています. - KVM を管理するような特殊なページテーブルは, - 最初に永続的な確保が 行われ, - これらのページテーブルが破棄されることはありません. - - - FreeBSD は, vm_objects の部分を, - 仮想メモリのアドレス範囲に vm_map_t と - vm_entry_t 構造体を通して割り付けます. - ページテーブルは, vm_map_t - /vm_entry_t/vm_object_t - という階層から 直接つくられます. “物理ページは, - 直接一つの vm_object に - 割り付けられる” と私が述べたことを思い出して下さい. - ええと, そうですね, しかしそれはいつでも完全に当てはまる, - というわけでもないのです. vm_page_t のは, - 実際に割り付けられた ページテーブルにもリンクされています. - 一つの vm_page_t は - ページテーブルが呼ばれた時, いくつかの - pmaps と リンクされることがあります. - しかし, そのような階層的な割り付けは, 同じ - vm_page_t を参照するオブジェクト内の, - 同じページへの参照全てを保持しているため, その結果, - 常にバッファキャッシュの統合を得ることができるわけです. - - - - - KVM メモリマッピング - - FreeBSD は, 様々なカーネル構造体を保持するため, KVM - を利用します. ファイルシステムバッファキャッシュは, KVM - 内で最も大きなものです. それはつまり, struct - buf の実体に対するマッピングに他なりません. - - Linux と異なり, FreeBSD は全ての物理メモリを KVM - にマッピングしません. これは, FreeBSD が 32 - ビットプラットフォームで 4G バイトまでの メモリを扱える, - ということを意味します. 実際, MMU - がそれを可能にしているならば, 理論上, FreeBSD は 32 - ビットプラットフォームで 8TB - までのメモリを扱うことができることになります. しかし, - 大部分の 32 ビットプラットフォームは 4G バイトの RAM しか - マッピングできないようになっている, - ということには議論の余地があるでしょう. - - - - KVM は, いくつかのメカニズムによって管理されています. - 中心となっているのは, ゾーンアロケータ(zone - allocator)です. ゾーンアロケータは, - 特定の構造体型を確保するために KVM の部分(chunk)を得て, - 一定の大きさのメモリブロックに分割します. vmstat - -m コマンドで, ゾーンによって 分割された, 現在の - KVM 利用状況一覧を得ることができます. - - - - - FreeBSD VM システムのチューニング - - FreeBSD カーネルでは, - 動的に自分自身をチューニングするために, - 協調的な努力が行なわれています. 普通は, - maxusers と NMBCLUSTERS - という カーネルオプション, つまり, - /usr/src/sys/i386/conf/CONFIG_FILE で 指定されるもの以外, 変更する必要はありません. 可能なカーネルオプションの一覧は, /usr/src/sys/i386/conf/LINT に 記載されています. - - 大きなシステムに対しては, maxusers - を増やしたいと思うかも知れませんね. この値は普通, 10 から 128 - の間の値にします. - maxusers を増やしすぎるとシステムの利用可能な - KVM がオーバフローしてしまい, - 予測できない動作に陥ってしまうことに注意して下さい. - maxusers はある適度な値にとどめておいて, - 特定のリソースを制御する NMBCLUSTERS - のような, 他のオプションを増加させる方が良いでしょう. - - - もし, システムが負荷の高いネットワーク用途に使われるなら, - NMBCLUSTERS を増やしたいと望むことでしょう. - この値は普通, 1024 から 4096 の間です. - - - NBUF パラメータも, - 伝統的にシステムの規模を決めるのに使われます. これは, - システムがファイルシステムバッファを I/O のために - マッピングするのに使われる, KVA - の大きさを決めるのに使われます. このパラメータは, - 統合バッファキャッシュには何の影響も与えません. これは - 3.0-RELEASE 以降のカーネルでは動的にチューニングされるため, - 普通は手作業で調整されるべきものではありません. - NBUF パラメータは, - 指定しようとしないことを推奨します. - システムに選択させれば良いのです. - 小さすぎる値は極端に非効率的なファイルシステム動作を招き, - 一方で, 大きすぎる値は wired 状態のページを数多くつくりだし, - ページキューを枯渇させてしまうでしょう. - - デフォルトでは, FreeBSD カーネルは最適化されていません. - カーネルコンフィグにある makeoption - ディレクティブを使って - 最適化とデバッグフラグをセットすることができます. ただし, - それによって得られる大きな (7MB - 超の)カーネルを相手にするのが嫌なら, - オプションは使ってはいけません. - - makeoptions DEBUG="-g" -makeoptions COPTFLAGS="-O -pipe" - - sysctl は, 実行時にカーネルパラメータをチューニングする - 手段を提供しています. しかし, 普通は sysctl 変数, 特に VM - に関連したものを変更する必要が - 生じるようなことはありません. - - 実行時の VM とシステムのチューニングは, 比較的単純です. - まず, 可能ならば UFS/FFS ファイルシステムで softupdates - を使いましょう. - /usr/src/contrib/sys/softupdates/README - のファイルに, - 設定方法に関する手順(と制限)について書かれています. - - - 次に, 十分なスワップを設定します. 作業 - ディスクを含む 各物理ディスク装置毎に一つずつ - (最大四つまで)のスワップパーティションを 設定すべきです. - 少なくとも, メインメモリの 2 倍の スワップ空間が望ましく, - メモリがあまりない場合には, - おそらくそれより多く必要になります. また, - スワップパーティションのサイズは, - 後でパーティションをつくり直しする必要がないように - マシンに設定したいメモリ設定の最大値を基準に - 決めるべきでしょう. もし, クラッシュダンプをとりたい場合, - スワップパーティションは最低限メインメモリと同じの大きさで, - /var/crash にはダンプを保持するのに十分な - 空きがなければなりません. - - NFS 経由のスワップは, -4.x - 以降のシステムで完全に動作しますが, NFS サーバ側では, - ページングがその負荷の主な原因になることに - 注意しなければなりません. - - - - - IPv6/IPsec の実装 - - 原作: &a.shin;, 2000 年 3 月 5 日. - - 訳: &a.jp.hino;, 2001 年 3 月 19 日. - - - 訳注 - - 訳語については IPv6 次世代インターネット・プロトコル, - クリスチャン・ウイテマ著, 村井純監修, WIDE プロジェクト - IPv6 分科会監訳, 松島栄樹訳, 1997, ISBN4-88735-010-4 - を参考にさせていただきました. - - - 本章では, IPv6 と IPsec に関連する実装の詳細について説明します. - これらの機能は - KAME - プロジェクトの成果を取り込んだものです. - - - IPv6 - - - 規格適合性 - - わたしたちの IPv6 関連の機能は, 最新の IPv6 仕様に準処してい - るか, または準処しようと努力しています. 今後の参考のために以下 - に参考文献を挙げておきます (注: これ - は完全なリストではありません - それを維持するのは大変ですか - ら...). - - 詳しくは, 本文書の各章や, RFC, マニュアル - ページ, そしてソースコード中のコメントを参照してください. - - 規格適合テストは, TAHI プロジェクトにより KAME STABLE - kit に対して行われました. その結果は, - http://www.tahi.org/report/KAME/ - で見ることができます. わたしたちはまた, - ニューハンプシャー大学で行われた IOL テスト - (http://www.iol.unh.edu/) - に以前のバージョンで参加したこともあります. - - - - RFC1639: FTP Operation Over Big Address Records - (FOOBAR) (大きなアドレスレコードを用いる FTP 操作) - - - - RFC2428 は RFC1639 よりも推奨されます. FTP クラ - イアントは, まず RFC2428 を試し, もしそれが失敗したな - ら RFC1639 を試します. - - - - - - RFC1886: DNS Extensions to support IPv6 (IPv6 をサポー - トするための DNS 拡張) - - - - RFC1933: Transition Mechanisms for IPv6 Hosts and - Routers (IPv6 ホストおよびルータのための移行機構) - - - - IPv4 互換アドレスはサポートされません. - - - - 自動トンネリング (RFC の 4.3 で述べられています) - はサポートされません. - - - - &man.gif.4; インタフェースは IPv[46]-over-IPv[46] - トンネルを包括的な方法で実装しており, それは仕様で述べ - られている "configured tunnel (構成されたトンネル)" を - カバーしています. 詳細は本文書の - 23.5.1.5をご覧ください. - - - - - - RFC1981: Path MTU Discovery for IPv6 (IPv6 における - 経路 MTU 探索) - - - - RFC2080: RIPng for IPv6 (IPv6 のための RIPng) - - - - usr.sbin/route6d がこれをサポートしています. - - - - - - RFC2292: Advanced Sockets API for IPv6 (IPv6 のため - の拡張ソケット API) - - - - サポートされているライブラリ関数やカーネルの API - については, sys/netinet6/ADVAPI - をご覧ください. - - - - - - RFC2362: Protocol Independent Multicast-Sparse - Mode (PIM-SM) (プロトコル独立マルチキャスト - 疎モード - (sparse mode)) - - - - RFC2362 は PIM-SM のパケットフォーマットを定義し - ています. - draft-ietf-pim-ipv6-01.txt はこれ - に準じて書かれています. - - - - - - RFC2373: IPv6 Addressing Architecture (IPv6 アドレス - 体系) - - - - ノードに必須のアドレス群をサポートし, スコープ要 - 求に準処しています. - - - - - - RFC2374: An IPv6 Aggregatable Global Unicast Address - Format (IPv6 集約可能グローバルユニキャストアドレス形式) - - - - 64 ビット長のインタフェース ID をサポートしていま - す. - - - - - - RFC2375: IPv6 Multicast Address Assignments (IPv6 に - おけるマルチキャストアドレス割り当て) - - - - ユーザランドのアプリケーション群は本 RFC で割り - 当てられている well-known なアドレスを使用しています. - - - - - - - RFC2428: FTP Extensions for IPv6 and NATs (IPv6 と - NAT のための FTP 拡張) - - - - RFC2428 は RFC1639 よりも推奨されます. FTP クラ - イアントは, まず RFC2428 を試し, もしそれが失敗したな - ら RFC1639 を試します. - - - - - - RFC2460: IPv6 specification (IPv6 仕様) - - - - RFC2461: Neighbor discovery for IPv6 (IPv6 における - 近隣探索) - - - - 詳しくは本文書の - 23.5.1.2 をご覧く - ださい. - - - - - - RFC2462: IPv6 Stateless Address Autoconfiguration - (IPv6 におけるステートレスアドレス自動設定) - - - - 詳しくは本文書の - 23.5.1.4 をご覧ください. - - - - - - RFC2463: ICMPv6 for IPv6 specification (IPv6 のため - の ICMPv6 仕様) - - - - 詳しくは本文書の - 23.5.1.9 をご覧ください. - - - - - - RFC2464: Transmission of IPv6 Packets over Ethernet - Networks (イーサネット上での IPv6 パケットの転送方式) - - - - RFC2465: MIB for IPv6: Textual Conventions and General - Group (IPv6 用 MIB: 文字列的変換法と一般グループ) - - - - 必要な統計情報はカーネルにより集計されています. - 実際の IPv6 MIB サポートは ucd-snmp に対するパッチキッ - トとして提供されています. - - - - - - RFC2466: MIB for IPv6: ICMPv6 group (IPv6 用 MIB: - ICMPv6 グループ) - - - - 必要な統計情報はカーネルにより集計されています. - 実際の IPv6 MIB サポートは ucd-snmp に対するパッチキッ - トとして提供されています. - - - - - - RFC2467: Transmission of IPv6 Packets over FDDI - Networks (FDDI ネットワーク上での IPv6 パケットの転送方式) - - - - RFC2497: Transmission of IPv6 packet over ARCnet - Networks (ARCnet ネットワーク上での IPv6 パケットの転送方 - 式) - - - - RFC2553: Basic Socket Interface Extensions for IPv6 - (IPv6 のための 基本的ソケットインタフェースの拡張) - - - - IPv4 射影アドレス (3.7) と IPv6 ワイルドカードバ - インドソケットの特別な動作 (3.8) をサポートしています. - 詳しくは本文書の - 23.5.1.12 - をご覧ください. - - - - - - RFC2675: IPv6 Jumbograms (IPv6 巨大パケット) - - - - 詳しくは本文書の - 23.5.1.7 をご覧ください. - - - - - - RFC2710: Multicast Listener Discovery for IPv6 (IPv6 - のためのマルチキャスト受信者探索) - - - - RFC2711: IPv6 router alert option (IPv6 ルータ警報オ - プション) - - - - draft-ietf-ipngwg-router-renum-08: - IPv6 におけるルータの再番号付け - - - - draft-ietf-ipngwg-icmp-namelookups-02: - ICMP による IPv6 名前検索 - - - - draft-ietf-ipngwg-icmp-name-lookups-03: - ICMP による IPv6 名前検索 - - - - draft-ietf-pim-ipv6-01.txt: - IPv6 用 PIM - - - - &man.pim6dd.8; は密モード (dense mode) を実装しています. - &man.pim6sd.8; は疎モード (sparse mode) を実装しています. - - - - - - draft-itojun-ipv6-tcp-to-anycast-00: - IPv6 エニーキャストアドレス向けに TCP 接続を切断 - - - - draft-yamamoto-wideipv6-comm-model-00 - - - - 詳細は本文書の - 23.5.1.6 を参照してください. - - - - - - draft-ietf-ipngwg-scopedaddr-format-00.txt - : IPv6 のスコープ化アドレス形式の拡張 - - - - - - 近隣探索 - - 近隣探索はきわめて安定しています. 現在, アドレス検索 - (Address Resolution), 重複アドレス検出 (Duplicated Address - Detection), 近隣到達不能性検出 (Neighbor Unreachability - Detection) がサポートされています. もうすぐ, カーネルに代理近 - 隣通知 (Proxy Neighbor Advertisement) サポートを加え, 管理者ツー - ルとして近隣探索取消要請 (Unsolicited Neighbor Advertisement) - を送出するコマンドを加える予定です. - - DAD (重複アドレス検出) が重複を検出した場合, そのアドレ - スは "重複している" という印が付けられ, syslog にメッセージが - 記録されます (そして通常はコンソールに表示されます). "重複して - いる" 印は &man.ifconfig.8; で調べることができます. 重複検出の - チェックおよび重複状態を解消することは管理者の責任となります. - この動作は近いうちに改良するべきです. - - いくつかのネットワークドライバは, そうしないようにと指示 - された場合でもマルチキャストパケットを自分自身に送り返してしま - います (特に無差別 (promiscuous) モードでは). このような状況で - は DAD は重複を検出するでしょう. なぜなら DAD を実行するプログ - ラムは NS パケットの到着を検出し (それが自ノードが出力したもの - であるにもかかわらず) それが重複を表しているとみなすからです. - この問題に対処する方法は, - sys/netinet6/nd6_nbr.c:nd6_dad_timer() 中の "heuristics" とマー - クされた #if 条件のあたりを見てください ("heuristics" 部分のプ - ログラムコードは仕様に反していることに注意してください). - - 近隣探索の仕様 (RFC2461) では, 以下に述べる状況での近隣 - 情報キャッシュの取り扱いについて記述されていません: - - - - 近隣情報キャッシュが空の時に, 下位層 (リンク層) アド - レスを持たない RS/NS/NA/redirect 削除要請パケットを受信 - - - - - 下位層アドレスを持たない通信メディアにおける近隣情報 - キャッシュの取り扱い (IsRouter ビットのために一つの近隣情 - 報キャッシュエントリが必要です) - - - - 一つめの場合については, IETF ipngwg メーリングリストで行 - われた議論に基づく対応策を実装しています. より詳しくは, ソース - コード中のコメントと, 1999 年 2 月 6 日の (IPng 7155) というメー - ルから始まったスレッドを参照してください. - - IPv6 における同一リンク上かどうかの判断ルール (RFC2461) - は, BSD のネットワークコードが想定している条件と全く異なります. - とりあえず, デフォルトルータのリストが空の時には同一リンク上か - どうかの判断ルールはサポートしていません (RFC2461 の 5.2 章, - 第二文節の最後の文 - この仕様のこの章では何カ所かで "host" と - "node" という単語の間違った使い方をしていることに注意). - - サービス妨害攻撃と無限ループをさけるために, ND パケット - 中のオプションは 10 個だけが受け付けられます. そのため, もし - RA に 20 個のプレフィックスを載せたとしても先頭の 10 個のプレ - フィックスしか理解されません. もしこのことが問題となるのなら, - FREEBSD-CURRENT メーリングリストに質問するか, または - sys/netinet6/nd6.c 中の nd6_maxndopt を変 - 更してください. もし多くの要求があるようなら, この変数を変更す - る sysctl 変数を用意できるでしょう. - - - - スコープ番号 - - IPv6 はスコープ化されたアドレスを使います. そのため, - IPv6 アドレスにスコープ番号 (リンクローカルアドレスではインタ - フェース番号, サイトローカルアドレスではサイト番号) を指定する - ことは非常に重要です. スコープ番号が無いと, カーネルにとってス - コープ化された IPv6 アドレスは曖昧なものとなり, そしてカーネル - はそのパケットを出力するインタフェースを選ぶことができないでしょ - う. - - ユーザランドのアプリケーションは, スコープ番号またはイン - タフェース番号を指定するために, 通常は拡張 API (RFC2292) を使 - うべきです. 同様の目的のために, RFC2553 において sockaddr_in6 - 構造体にsin6_scope_id メンバが定義されています. しかしながら, - sin6_scope_id の意味づけは少々曖昧です. もし, あなたが自分のア - プリケーションの移植性について気をつけたいのなら, - sin6_scope_id ではなく拡張 API を使うことをお勧めします. - - カーネル中では, リンクローカルスコープのアドレスに対応す - るインタフェース番号は IPv6 アドレスの二番目の 16 ビット語 (三 - 番めと四番めのバイト) に埋め込まれます. たとえばルーティングテー - ブルとインタフェースアドレス構造体 (struct in6_ifaddr) の中で, - 以下のような例を見ることができるでしょう: - - fe80:1::200:f8ff:fe01:6317 - - 上で述べたアドレスはリンクローカルなユニキャストアドレス - で, それはインタフェース番号が 1 であるネットワークインタフェー - スに属するものです. 埋め込まれた番号によって, 複数のインタフェー - スに対する IPv6 リンクローカルアドレス群を, 効率的に, かつ少々 - のプログラムの対応だけで, 識別することができます. - - &man.route6d.8; や &man.ifconfig.8; のような, ルーティン - グデーモンと設定プログラムは "埋め込まれた" スコープ番号を取り - 扱う必要があります. これらのプログラムはルーティング用のソケッ - トと (SIOCGIFADDR_IN6 のような) ioctl 群を使います. そしてカー - ネル API は二番目の 16 ビット語を書き込んでから IPv6 アドレス - を返します. これらの API はカーネル内部構造体を操作するための - ものです. これらの API を利用するプログラムは, どちらにしろカー - ネル間の違いについて意識する必要があります. - - コマンドラインでスコープ化されたアドレスを指定するときに - は, (ff02:1::1 や fe80:2::fedc のような) 埋め込まれた形式を ＊ - 絶対に＊ 使わないでください. たぶんこれでは動きません. インタ - フェースを指定するコマンドラインオプション (たとえば - ping6 -I ne0 ff02::1) を使うときには, 必ず - ff02::1 や fe80::fedc のような標準形式を使ってください. 一般的 - にいって, コマンドが出力インタフェースを指定するコマンドライン - オプションを持っていないのならば, そのコマンドはスコープ化され - たアドレスを受け付けることはできないでしょう. このことは IPv6 - の, "歯医者のオフィス" をサポートするという前提に反するように - 思えるでしょう. この問題に関して, わたしたちは仕様に何らかの改良を - 加える必要があると信じています. - - いくつかのユーザランドのツールは, - draft-ietf-ipngwg-scopedaddr-format-00.txt - で文書化されている, IPv6 拡張数値記法をサポートしています. - "fe80::1%ne0" というように, 出力インタフェースの名前を使って, - パケットを出力するリンクを指定することができます. この方法によっ - て, 特に問題なくリンクローカルなスコープ化されたアドレスを指定 - することができるでしょう. - - あなたのプログラムでこの拡張数値記法を使うためには, - &man.getaddrinfo.3;, と &man.getnameinfo.3; を NI_WITHSCOPEID - をつけて使用する必要があります. 現在の実装では, リンクとインタ - フェースとが一対一に対応していることを想定しています. これは仕 - 様で述べられているよりも強い想定です. - - - - プラグ & プレイ - - ほとんどの IPv6 ステートレスアドレス自動設定はカーネル中 - に実装されています. 近隣探索機能は全てカーネル内に実装されてい - ます. ルータ通知 (RA: Router Advertisement) のホストへの入力は - カーネル内で実装されています. ルータ要請 (RS: Router - Solicitation) の終端ホストからの出力, RS のルータへの入力, そ - してルータでの RA の出力はユーザランドで実装されています. - - - リンクローカルアドレスと特別アドレスの割り当て - - IPv6 リンクローカルアドレスは IEEE802 アドレス (イーサ - ネットの MAC アドレス) から生成されます. 各インタフェースに - は, そのインタフェースが利用可能になったとき (IFF_UP) に自動 - 的にリンクローカルアドレスが一つ割り当てられます. 同時に, そ - のリンクローカルアドレスに対する直接のルートがルーティングテー - ブルに加えられます. - - 以下に netstat コマンドの出力を示します: - - Internet6: -Destination Gateway Flags Netif Expire -fe80:1::%ed0/64 link#1 UC ed0 -fe80:2::%ep0/64 link#2 UC ep0 - - IEEE802 アドレスを持っていないインタフェース (トンネル - インタフェースのような疑似インタフェースや, ppp インタフェー - ス) は, できる限り, イーサネットインタフェースなどの他のイン - タフェースから IEEE802 アドレスを借用します. もし IEEE802 ア - ドレスを持ったハードウェアが一つもなければ, 最後の手段として - (MD5(ホスト名)で計算される) 疑似乱数値がリンクローカルアドレ - スの元として使われます. もしこれがあなたの用途に合わないなら, - リンクローカルアドレスを手動で設定する必要があるでしょう. - - もしあるインタフェースで IPv6 を使えない (たとえばマルチ - キャストをサポートしない, 等の理由で) ならば, そのインタフェー - スにはリンクローカルアドレスは割り当てられません. 詳細は 2 - 章をご覧ください. - - 各インタフェースは要請されたマルチキャストアドレスとリ - ンクローカルな「全ノード」マルチキャストアドレスに加わります - (すなわち, そのインタフェースがつながれたリンク上で, それぞ - れ fe80::1:ff01:6317 と ff02::1 です). リンクローカルアドレ - スに加え, ループバックアドレス (::1) がループバックインタフェー - スに割り当てられます. また, ::1/128 と ff01::/32 が自動的に - ルーティングテーブルに追加され, そしてループバックインタフェー - スはノードローカルマルチキャストグループである ff01::1 に加 - わります. - - - - ホスト上でのステートレスアドレス自動設定 - - IPv6 仕様では, ノードは二種類に分類されます: - ルータとホストです. - ルータは他宛のアドレスがついたパケットを転送します. ホストは - パケットの転送を行いません. net.inet6.ip6.forwarding によっ - て, このノードがルータであるかホストであるかが決定されます - (1 ならルータで, 0 ならホストです). - - ホストがルータ通知 (Router Advertisement) をルータから - 受信すると, ホストはステートレスアドレス自動設定によって自ら - を自動設定することができます. この動作は - net.inet6.ip6.accept_rtadv によって制御できます (1 にセット - されているとホストは自らを自動設定します). 自動設定によって, - この受信したインタフェースにネットワークアドレスプリフィック - ス (通常はグローバルアドレスプリフィックス) が追加されます. - デフォルトルートも同時に設定されます. ルータは定期的にルータ - 通知パケットを送出します. 隣接するルータに RA パケットを送出 - するよう要求するために, ホストはルータ要請 (Router - Solicitation) を送信することができます. 好きなときに RS パケッ - トを送出するためには, rtsol コマンドを - 使います. また, &man.rtsold.8; デーモンもあります. - &man.rtsold.8; は必要なときにはいつでもルータ要請を送出しま - す. これは移動体のような使い方 (ノート型やラップトップ型コン - ピュータ) をするときにとても調子良く働きます. もしルータ通知 - を無視したいのなら, sysctl で net.inet6.ip6.accept_rtadv を - 0 にしてください. - - ルータでルータ通知を送出するには &man.rtadvd.8 デーモ - ンを使います. - - IPv6 仕様では, 以下の事柄を想定しており, それらに合致 - しないケースに関しては仕様化されていないことに注意してくださ - い: - - - - ホストだけがルータ通知を待ち受けている - - - - ホストは (ループバック以外には) ネットワークインタ - フェースを一つだけ持つ - - - - 以上のことより, ルータや複数のインタフェースを持つホス - トで net.inet6.ip6.accept_rtadv を有効にすることは賢いことで - はないことが分かります. 設定を失敗したノードは変な動作をする - 可能性があります (経験をしてみたい人のために仕様にあわない設 - 定も許されています). - - sysctl 変数を整理すると: - - accept_rtadv forwarding ノードの役割 - --- --- --- - 0 0 ホスト (手動で設定された) - 0 1 ルータ - 1 0 自動設定されたホスト - (仕様ではホストはインタフェー - スを一つのみ持つことを想定して - いるので, 複数のインタフェース - を持つホストの自動設定は想定外) - 1 1 不正, または実験的 - (仕様の想定外) - - RFC2462 の 5.5.3 (e) には到着した RA プリフィックス情 - 報オプションの検証ルールが書いてあります. これは悪意のある - (または設定を失敗した) ルータが非常に短いプリフィックス生存 - 期間を通知してくることに対してホストを防御するためのものです. - ipngwg メーリングリストで Jim Bound による更新があり (メーリ - ングリストアーカイブの "(ipng 6712)" をご覧ください), ここで - の実装はこの Jim の更新を取り入れたものです. - - DAD と自動設定との関係については, 本文書の - 23.5.1.2 をご覧ください. - - - - - - 包括的トンネルインタフェース (Generic tunnel interface) - - GIF (包括的インタフェース: Generic Interface) は構成された - トンネルのための疑似インタフェースです. 詳細は &man.gif.4; に - 述べられています. 現在, - - - - v6 in v6 - - - - v6 in v4 - - - - v4 in v6 - - - - v4 in v4 - - - - が利用できます. gif インタフェースに物理的な (外側の) 始 - 点と終点アドレスを割り当てるためには &man.gifconfig.8; を使い - ます. 内側と外側の IP ヘッダで同じアドレスファミリを使う (v4 - in v4, または v6 in v6) 設定は危険です. 無限段数のトンネルを作っ - てしまうようにインタフェースとルーティングテーブルを設定するの - はとても簡単だからです.注意してください! - - - gif は ECN (Explicit Congestion Notification: 明示的輻輳 - 通知) とともに使えるように設定することができます. ECN との親和 - 性については 23.5.4.5 - をご覧ください. - また, 設定方法に関しては &man.gif.4; をご覧ください. - - もし IPv4-in-IPv6 トンネルを gif インタフェースを使って - 設定しようと思っているなら, &man.gif.4; を注意深く読んでくださ - い. gif インタフェースに自動的に割り当てられる IPv6 リンクロー - カルアドレスを削除する必要があるでしょう. - - - - 始点アドレスの選択 - - 現在の始点選択ルールはスコープ指向です (いくつかの例外も - あります - 以下を参照してください). ある終点アドレスに対する始 - 点 IPv6 アドレスは以下の規則に従って選択されます: - - - - もし始点アドレスがユーザにより明示的に指定 (たとえば拡 - 張 API を通じて) されていたならば, その指定されたアドレス - が使われる. - - - - 出力インタフェース (通常はルーティングテーブルを検索 - することにより決定される) にアドレスが割り当てられており, - そのアドレスが終点アドレスと同一のスコープを持っているなら - ば, そのアドレスが使われる. - - これがもっとも一般的な場合です. - - - - もし上記の場合を満たすアドレスがなかったときには, 送 - 出するノードが持つインタフェースのうちのどれか一つに割り当 - てられているグローバルアドレスを選択する. - - - - もし上記の場合を満たすアドレスがなかったときで, 終 - 点アドレスがサイトローカルスコープであった場合には, 送出す - るノードが持つインタフェースのうちのどれか一つに割り当てら - れているサイトローカルアドレスを選択する. - - - - もし上記の場合を満たすアドレスがなかったときは, 終 - 点に向かっているルーティングテーブルエントリに関連づけられ - たアドレスを選択する. これは最後の手段であり, スコープ違反 - を引き起こす可能性がある. - - - - たとえば, ff01::1 に対しては ::1 が選択され, - fe80:1::2a0:24ff:feab:839b に対しては - fe80:1::200:f8ff:fe01:6317 が選択されます (埋め込まれたインタ - フェース番号に注意 - - 23.5.1.3 で述べられている - - この番号により正しい始点アドレスが選択できます. これらの埋め込 - まれた番号は通信路 (wire) 上では存在しません). もし出力インタ - フェースが該当するスコープに対して複数のアドレスを持っていた場 - 合は, 始点は最長一致法 (規則 3) で選択されます. たとえば, 出力イ - ンタフェースに, 3ffe:501:808:1:200:f8ff:fe01:6317 と - 3ffe:2001:9:124:200:f8ff:fe01:6317 が付けられていたとします. - 終点アドレスが 3ffe:501:800::1 であるとすると, 始点アドレスと - しては 3ffe:501:808:1:200:f8ff:fe01:6317 が選択されます. - - 上記の規則は IPv6 仕様では文書化されていないことに注意し - てください. これは「実装に任された」項目と考えられているのです. - 上記の規則に則らないケースがいくつかあります. 一つの例は, 接続 - 済みの TCP セッションで, この場合は tcb に保存されているアドレ - スを始点とします. 他の例としては, 近隣通知 (Neighbor - Advertisement: NA) の際の始点アドレスです. 仕様 (RFC2461 - 7.2.2) によれば, NA の始点アドレスは対応する NS (近隣要請) の - ターゲットアドレスであるべきとされています. この場合は, 上記の - 最長一致規則ではなく仕様に従います. - - 新規に接続を行うとき (規則 1 に当てはまらないとき) に, - 他に選択肢がある限り, 推奨有効期間切れアドレス (preferred - lifetime が 0 であるアドレス）を始点アドレスとして選択すること - はありません. もし他の選択肢がなければ, 最後の手段として推奨有 - 効期限切れアドレスが使われます. もし複数の推奨有効期間切れアド - レスがあるときには, 上記のスコープ規則に従ってそれらのアドレス - からの選択が行われます. もし何らかの理由により推奨有効期間切れ - アドレスの使用を禁止したいのならば, - net.inet6.ip6.use_deprecated を 0 に設定してください. 推奨有効 - 期間切れアドレスに関連する問題は, RFC2462 5.5.4 に記述されてい - ます (注意: IETF の ipngwg では推奨有効期間切れアドレスをどの - ように使うべきかの議論がいくつか進行中です). - - - - 巨大ペイロード - - 巨大ペイロード中継点毎オプションは実装されており, 65,535 - バイトよりも長いペイロードを持つ IPv6 パケットを送信するときに - 利用できます. しかし, MTU が 65,535 よりも大きな物理インタフェー - スは現在サポートされていませんから, そのようなペイロードはルー - プバックインタフェース (たとえば lo0) 上でのみ利用できます. - - もし巨大ペイロードを試してみたいのならば, まず始めに, ルー - プバックインタフェースの MTU が 65,535 バイトよりも大きくなる - ようにカーネルの再構成を行わなければなりません; 以下の行をカー - ネル構成ファイルに追加してください: - - - options "LARGE_LOMTU" #To test jumbo payload - - - そして新しいカーネルをコンパイルしてください. - - 次に, &man.ping6.8; コマンドを -b と -s オプション付きで - 使うことで巨大ペイロードを試してみることができます. -b オプショ - ンはソケットバッファの大きさを拡大するために指定しなければなリ - ません. -s オプションによりパケット長を指定します. その値は - 65,535 よりも大きくなるでしょう. たとえば以下のように入力してく - ださい: - - - &prompt.user; ping6 -b 70000 -s 68000 ::1 - - - IPv6 仕様では, 巨大ペイロードオプションは分割された - (fragtment) ヘッダを持つパケットでは使えないことになっています. - この条件が破られると ICMPv6 Parameter Problem メッセージが送信 - 元に送られるはずです. この仕様には従っているのですが, 通常はこ - の ICMPv6 エラーを見ることはできないでしょう. - - IPv6 パケットが受信されると, そのフレーム長が調べられ, - そして IPv6 ヘッダ中のペイロード長フィールド, またはもしあれば - 巨大ペイロードオプションの値, で指定された長さと比較されます. - もし前者の方が後者よりも短ければ, パケットは廃棄され統計情報が - 更新されます. この統計情報は, &man.netstat.8; コマンドを `-s - -p ip6' オプション付きで実行すると見ることができます: - - - &prompt.user; netstat -s -p ip6 - ip6: - (snip) - 1 with data size < data length - - - それ故, カーネルはエラーを起こしたパケットが本当に巨大ペ - イロードである, すなわち, そのパケット長が 65,535 バイトよりも - 長い場合にしか ICMPv6 エラーを送りません. 上で述べたように, 現 - 在そのような巨大な MTU をもつ物理インタフェースはサポートされ - ていませんので, IPMPv6 エラーが返ることは滅多にないでしょう. - - - 現状では, 巨大パケット上の TCP/UDP はサポートされていま - せん. これはテストできる通信メディアが (ループバック以外) 存在 - しないためです. もしこれを必要としているなら, わたしたちに連絡して - ください. - - IPsec は巨大パケットの上では動作しません. これは, 巨大パ - ケットと AH を同時にサポートする場合の仕様の「ねじれ」のせいで - す (AH ヘッダサイズはペイロード長に影響を及ぼし, そしてこのこ - とが, 巨大ペイロードオプションと AH が両方付いた到着パケッ - トを認証することを本当に困難にしてしまうのです). - - *BSD において巨大パケットをサポートするには基本的な問題 - がいくつかあります. それらをここで指摘したいのですが, このリス - トを完成させるためにはもっと時間が必要です. その中のいくつかを - 以下に挙げます: - - - - 4.4BSD では mbuf の pkthdr.len フィールドは "int" 型 - ですから, 32 ビットアーキテクチャの CPU 上では 2 ギガバイ - ト以上の巨大パケットを保持できません. 巨大パケットを正しく - サポートするには, このフィールドは, 4 ギガバイト + IPv6 ヘッ - ダ + 下位層ヘッダを保持できるように拡張されなければなりま - せん. そのため, 少なくとも int64_t に拡張する必要がありま - す (u_int32_t では十分では＊ありません＊). - - - - 多くの場所で, パケット長を格納するための場所を誤って - "int" としてしまっています. それらをもっと大きな整数型に変 - 換する必要があります. この作業には細心の注意が必要です. な - ぜならパケット長の計算をするときにオーバフローを起こしてし - まうかもしれないからです. - - - - たくさんの場所で, パケットのペイロード長を調べるのに, - 間違って IPv6 ヘッダの ip6_plen フィールドをチェックしてい - ます. そうではなくて, mbuf の pkthdr.len を調べなければな - りません. ip6_input() が入力時に巨大ペイロードオプションの - 健全性をチェックするようにすれば, その後は mbuf の - pkthdr.len を安全に使うことができるでしょう. - - - - TCP のコードには, もちろん, たくさんの場所の注意深い更 - 新が必要でしょう. - - - - - - ヘッダ処理中のループ防止 - - IPv6 仕様はパケットに任意の数の拡張ヘッダがつくことを許 - しています. もし IPv6 パケット処理コードを BSD の IPv4 コード - が実装されているのと同様の方法で実装すると, 何重もの関数呼び出 - しのせいでカーネルスタックがオーバーフローしてしまうでしょう. - sys/netinet6 のコードは, カーネルスタックオーバフローを回避す - るように注意深く設計されています. そのために, sys/netinet6 の - コードでは独自のプロトコルスイッチ構造体を "struct ip6protosw" - (netinet6/ip6protosw.h を参照してください) - として定義しています. 互換性のために, IPv4 の部分 - (sys/netinet) にはこの変更を行っていませんが, しかし, 小さな変 - 更が pr_input() のプロトタイプについて行われています. そのため - "struct ipprotosw" も定義されています. 以上の理由により, 非常 - に多くの IPsec ヘッダを持つ IPsec-over-IPv4 パケットを受け取っ - たときにカーネルスタックがオーバーフローする可能性があります. - IPsec-over-IPv6 は大丈夫です. (もちろん, それら全ての IPsec ヘッ - ダが全て処理されるには, 一つ一つの IPsec ヘッダがそれぞれ - IPsec の試験をパスする必要があります. そのため, 外部の攻撃者が - そのような攻撃をすることは不可能です.) - - - - ICMPv6 - - RFC2463 が公開された後, IETF の ipngwg は, ネットワーク - メディア上の ICMPv6 ストームを引き起こさないように, ICMPv6 向 - け直し (redirect) に対して ICMPv6 エラーパケットを出さないよう - に決定しました. これはすでにカーネル内で実装されています. - - - - アプリケーション - - ユーザランドのプログラミングのために, RFC2553, RFC2292, - そして発行準備中の internet draft で定義されている, IPv6 ソケッ - ト API をサポートしています. - - IPv6 上の TCP/UDP は利用可能であり, きわめて安定していま - す. &man.telnet.1;, &man.ftp.1;, &man.rlogin.1;, &man.rsh.1;, - &man.ssh.1, 等を試してみてください. これらのアプリケーションは - プロトコル非依存となっています. つまり, DNS に従って自動的に - IPv4 と IPv6 を選択します. - - - - カーネルの内部 - - ip_forward() は ip_output() を呼びだしていますが, - ip6_forward() は ip_output() を直接呼びだします. これは, ルー - タは IPv6 のパケットを断片に分割してはいけないからです. - - ICMPv6 は最大 1280 まで, できる限り元のパケットをコピー - して含んでおく必要があります. たとえば, UDP6/IP6 ポート不到達 - ICMPv6 パケットは, 全ての拡張ヘッダと, ＊未変更の＊ UDP6 と - IP6 ヘッダを含まなければなりません. そのため, TCP を除く全ての - IP6 関数はオリジナルのパケットを保存しておくために, ネットワー - クバイト順をホストバイト順に変換しません. - - tcp_input() と udp6_input(), icmp6_input() は, 拡張ヘッ - ダがあるために, IP6 ヘッダのすぐ後ろにトランスポートヘッダがあ - ることを仮定できません. そのため, in6_cksum() は IP6 ヘッダと - トランスポートヘッダが連続しないようなパケットを処理できるよう - に実装されています. チェックサム計算のための TCP/IP6 ヘッダ構 - 造体も, UDP6/IP6 ヘッダ構造体も存在しません. - - IP6 ヘッダと, 拡張ヘッダ, トランスポートヘッダを容易に処 - 理できるように, ネットワークドライバに対する新たな要求事項とし - て, パケットを一つの内部 mbuf に納めるか, または, 一つ以上の外 - 部 mbuf に納める必要性を追加しました. 典型的な古いドライバは, - 96 から 204 バイトのデータ用の二つの内部 mbuf を用意しますが, - 今後はそのようなパケットデータは一つの外部 mbuf に記録されるこ - とになります. - - netstat -s -p ip6 を実行すると, ドラ - イバが上記の要求を満たしているかどうかが分かります. 以下の例で - は "cce0" は要求を満たしていません (詳細は 2 章をご覧ください.) - - - Mbuf statistics: - 317 one mbuf - two or more mbuf:: - lo0 = 8 - cce0 = 10 - 3282 one ext mbuf - 0 two or more ext mbuf - - - 各入力関数は始めの段階で, IP6 とそのヘッダが連続した領域 - にあるかどうかを調べるために IP6_EXTHDR_CHECK を呼び出します. - IP6_EXTHDR_CHECK は mbuf が M_LOOP フラグを持っているときのみ - m_pullup() を呼び出します. M_LOOP フラグは, パケットがループバッ - クインタフェースからきたことを示します. 物理的なネットワークイ - ンタフェースからきたパケットに対しては m_pullup() が呼ばれるこ - とはありません. - - IP と IP6 両方の再構成 (reassemble) 機能は m_pullup() を - 呼び出すことはありません. - - - - IPv4 射影アドレスと IPv6 ワイルドカードソケット - - RFC2553 では, IPv4 射影 (mapped) アドレス (3.7) と IPv6 - ワイルドカードバインドソケットの特別な振る舞い (3.8) が記述さ - れています. 仕様では以下の動作が許されています: - - - - AF_INET6 ワイルドカードバインドソケットで IPv4 接続 - を受け付ける. - - - - 特別な形式のアドレス, たとえば ::ffff:10.1.1.1 を使うこ - とで AF_INET6 ソケットから IPv4 のパケットを送出する. - - - - - しかし, 仕様自体が非常に込み入っており, またこの仕様では - ソケット層がどう動作すべきかということについて何も規定していま - せん. ここでは前者を "待ち受け側" と呼び, 後者を "開始側" と呼 - ぶことにします. - - 同一のポート上で, 両アドレスファミリのワイルドカードバイ - ンドを実行することができます. - - 以下の表に FreeBSD 4.x の動作を示します. - - - 待ち受け側 開始側 - (AF_INET6 ワイルド (::ffff:10.1.1.1 への接続) - カードソケットが - IPv4 接続を受ける.) - --- --- -FreeBSD 4.x 設定可能 サポートされている - デフォルト: 有効 - - - 以下の章で, より詳細を述べると共に, どうやってこの動作を - 設定するかを示します. - - 待ち受け側に対するコメント: - - RFC2553 は, ワイルドカードバインドの問題についてあまりに - も少ししか議論していません. 特に, ポート空間の問題, 失敗モード, - そして AF_INET/INET6 ワイルドカードバインド間の関連について. - この RFC に関しては, これに準処しているにもかかわらず異なった - 動作をするいくつかの別々の解釈が成り立ちます. そのため, 移植可 - 能なアプリケーションを実装する際には, カーネルの動作について一 - 切の仮定をおくべきではありません. &man.getaddrinfo.3; を使う - のがもっとも安全な方法です. ポート番号空間とワイルドカードバイ - ンドの問題は, 1999 年 3 月半ばに ipv6imp メーリングリストにお - いてつっこんだ議論がなされましたが, 最終的な合意は得られなかっ - たようです (つまり, 実装次第ということです). メーリングリスト - のアーカイブを調べてみてはいかがでしょうか. - - サーバアプリケーションで, IPv4 と IPv6 の両方の接続を受 - けたいのなら, 別の方法が二つあります. - - 一つは, AF_INET ソケットと AF_INET6 ソケットを使う方法で - す (二つのソケットが必要です). &man.getaddrinfo.3; を - ai_flags に AI_PASSIVE を設定して使い, そして, 返ってきた全て - のアドレスに対して &man.socket.2; と&man.bind.2; を使います. - 複数のソケットを開くことで, 適切なアドレスファミリを持つソケッ - ト上で接続を受けることができます. IPv4 接続は AF_INET ソケット - で受けられ, そして IPv6 接続は AF_INET6 ソケットで受けられるで - しょう. - - もう一つの方法は, AF_INET6 のワイルドカードバインドソケッ - トを使う方法です. ai_flags にAI_PASSIVE を, ai_family に - AF_INET6 を設定し, そして一つ目の引数であるホスト名を NULL に - して &man.getaddrinfo.3; を使ってください. そして返ってきたア - ドレス (IPv6 の未指定アドレスであるはずです) に対して - &man.socket.2; と &man.bind.2; を行います. この一つのソケット - で, IPv4 と IPv6 のパケットを受けることができます. - - 移植可能な方法で, AF_INET6 ワイルドカードバインドソケッ - トで IPv6 のみをサポートするには, 待ち受けしている AF_INET6 ソ - ケットに対して接続要求をしてきた相手アドレスを毎回チェックする - ようにしてください. もしそのアドレスが IPv4 射影アドレスであっ - たなら, その接続を遮断する必要があるかもしれません. この条件を - 判定するのに, IN6_IS_ADDR_V4MAPPED() マクロを使うことができま - す. - - この問題をもっと簡単に解決するために, システム依存の - &man.setsockopt.2; オプション, IPV6_BINDV6ONLY があります. そ - の使い方を以下に示します. - - - int on; - - setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, - (char *)&on, sizeof (on)) < 0)); - - - この呼び出しが成功すれば, このソケットは IPv6 パケットの - みを受信します. - - 開始側についてのコメント: - - アプリケーション実装者へのアドバイス: 移植可能な (複数種 - の IPv6 カーネル上で動作する) IPv6 アプリケーションを実装する - には, 以下に述べる点が成功への鍵となると信じます: - - - - ＊絶対に＊ AF_INET も AF_INET6 もハードコードしない. - - - - - システムを通じて &man.getaddrinfo.3; と - &man.getnameinfo.3; を使う. gethostby*() や, getaddrby*(), - inet_*(), getipnodeby*() を絶対に使わない (既存アプリケー - ションを簡単に IPv6 対応とするために, getipnodeby*() が便 - 利なこともあるでしょう. しかし, 可能であれば, コードを書き - 直して &man.getaddrinfo.3; と &man.getnameinfo.3; を使うよ - うに努力してみてください.) - - - - ある終点 (destination) に対して接続したいときは, - &man.telnet.1; のように, &man.getaddrinfo.3; を使って, 返っ - てきた全ての終点について試すようにしてください. - - - - いくつかの IPv6 プロトコルスタックは, バグありの - &man.getaddrinfo.3; 付きで出荷されています. 最低限きちんと - 動作するバージョンをあなたのアプリケーションと一緒に出荷し, - それを最後の手段として使いましょう. - - - - もし AF_INET6 ソケットから IPv4 と IPv6 の両方の接続を行 - いたいのなら, &man.getipnodebyname.3; を使う必要があるでしょう. - 既存のアプリケーションを工数最小で IPv6 対応に更新したいのなら - ば, この方法がよいでしょう. しかし, これは一時的な解であること - に注意してください. なぜなら, スコープ化された IPv6 アドレスを - 全く扱うことができないという欠点があるので - &man.getipnodebyname.3; 自身を推薦できないからです. IPv6 の名 - 前検索には, &man.getaddrinfo.3; が推奨される API です. ですか - ら, 時間があるときには, アプリケーションを &man.getaddrinfo.3; - を使うように書き換えるべきです. - - 外部に出ていく接続を行うアプリケーションを書くときに, も - し AF_INET と AF_INET6 とを完全に別々のアドレスファミリとして - 取り扱うのならば, 話は非常に単純になります. {set,get}sockopt - の問題は単純になり, DNS の問題も単純になるでしょう. IPv4 射影 - アドレスに依存する手法は推薦できません. - - - tcp と inpcb の統合コード - - FreeBSD 4.x では, tcp に関しては IPv4 と IPv6 でコード - を共有しています (sys/netinet/tcp* で). そして udp4/6 では別々 - のコードです. 統合した inpcb 構造体を使っています. - - このプラットフォームは IPv4 射影アドレスをサポートする - ように設定できます. カーネルの設定は以下のようにまとめられま - す: - - - - デフォルトでは, AF_INET6 ソケットはある条件下では - IPv4 接続をハンドリングできます. そして IPv4 射影の IPv6 - アドレス中に入っている IPv4 の終点へ向けて接続を開始する - ことができます. - - - - 以下のように sysctl を使ってシステム全体でそれを無 - 効にできます. - - - sysctl -w net.inet6.ip6.mapped_addr=0 - - - - - - - 待ち受け側 - - 各ソケットは特別な AF_INET6 ワイルドカードバインドを - サポートするように設定できます (デフォルトで有効です). 以 - 下のように, ソケット毎に &man.setsockopt.2; を使ってこれを - 無効にできます. - - - int on; - - setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, - (char *)&on, sizeof (on)) < 0)); - - - ワイルドカード AF_INET6 ソケットは, 以下の条件が成り - 立つときのみ, IPv4 接続をハンドリングできます: - - - - その IPv4 接続にマッチする AF_INET ソケットが存 - 在しない - - - - その AF_INET6 ソケットは IPv4 通信を受け付けるよ - うに設定されている, すなわち - getsockopt(IPV6_BINDV6ONLY) が 0 を返す. - - - - open/close の順番は問題となりません. - - - - 開始側 - - FreeBSD 4.x では, ノードが IPv4 射影アドレスをサポー - トするように設定されているときには, IPv4 射影アドレス - (::ffff:10.1.1.1) へ向けての接続がサポートされています. - - - - - - - sockaddr_storage - - RFC2553 が最後の仕上げにかかっている頃, sockaddr_storage - 構造体のメンバにどのように名前を付けるかという議論がありました. - 一つの提案は, それがいじってはいけないものであるのだから, メン - バ名の前に "__" を付ける ("__ss_len" のように), というものでし - た. 他の提案は, それらのメンバを直接操作する必要があるのだから, - なにも付けない ("ss_len" のように), というものでした. この件に - 関する明確な合意は得られませんでした. - - その結果として, RFC2553 では sockaddr_storage 構造体は以 - 下のように定義されました: - - - struct sockaddr_storage { - u_char __ss_len; /* address length */ - u_char __ss_family; /* address family */ - /* and bunch of padding */ - }; - - - これに反して, XNET ドラフトでは以下のように定義されまし - た: - - - struct sockaddr_storage { - u_char ss_len; /* address length */ - u_char ss_family; /* address family */ - /* and bunch of padding */ - }; - - - 1999 年 12 月に, RFC2553bis では後者 (XNET) の定義を採用 - することで合意がなされました. - - 現在の実装は, RFC2553bis の議論の結果, XNET の定義に適合 - するようになっています. - - 複数の IPv6 実装を調べたならば, 両方の定義を見ることにな - るでしょう. ユーザランドのプログラマとして, この件に対応するもっ - とも移植性が高い方法は: - - - - GNU autoconf を使って, ss_family と/または ss_len - がこのプラットフォームで利用可能であることを確かめる, - - - - - -Dss_family=__ss_family として (ヘッダファイルも含め - て) 全てを __ss_family に統合してしまう, または - - - - __ss_family には絶対に手を出さない. sockaddr * へキャ - ストして, 以下の例のように sa_family を使う: - - - struct sockaddr_storage ss; - family = ((struct sockaddr *)&ss)->sa_family - - - - - - - - - ネットワークドライバ - - ここで, 以下の二項目を標準的なドライバでサポートすることが必須 - となります: - - - - mbuf クラスタリングが要求されます. この安定版リリース - においては, 全てのドライバが期待通りに動くように, 全てのオペ - レーティングシステムにおいて MINCLSIZE を MHLEN+1 に変更しま - した. - - - - マルチキャスト. もしあるインタフェースについて - &man.ifmcstat.8; が一つもマルチキャストグループを示さないな - ら, そのインタフェースは修正が必要です. - - - - もしあるドライバが上記要求をサポートしないなら, そのドラ - イバでは IPv6 と/または IPsec 通信には使えません. もしあなた - のカードで IPv6/IPsec の使用に関して何か問題を見つけたなら, 是 - 非それを freebsd-bugs@FreeBSD.org に報告してくだ - さい. - - (注: かつて, 全ての PCMCIA ドライバに in6_ifattach() を呼 - ぶことを要求したことがありました. 現在では, もはやこの要求は - 取り下げています) - - - - トランスレータ - - ここでは IPv4/IPv6 トランスレータを四つに分類します: - - - - トランスレータ A --- 移行の初期 - の段階で使われるもので, IPv6 島上の IPv6 ホストから IPv4 - 海上の IPv4 ホストへの接続を確立できるようにするものです. - - - - - トランスレータ B --- 移行の初期 - の段階で使われるもので, IPv4 海上の IPv4 ホストから IPv6 - 島上の IPv6 ホストへの接続を確立できるようにするものです. - - - - - トランスレータ C --- 移行の後期 - の段階で使われるもので, IPv4 島上の IPv4 ホストから IPv6 - 海上の IPv6 ホストへの接続を確立できるようにするものです. - - - - - トランスレータ D --- 移行の後期 - の段階で使われるもので, IPv6 海上の IPv6 ホストから IPv4 - 島上の IPv4 ホストへの接続を確立できるようにするものです. - - - - - 分類 A のための TCP 中継トランスレータはサポートされてい - ます. これは "FAITH" と呼ばれます. 分類 A のための IP ヘッダト - ランスレータも提供しています. (後者は FreeBSD 4.x ではまだ取り - 込まれていません.) - - - FAITH TCP 中継トランスレータ - - FAITH システムはカーネルの助けを借りた &man.faithd.8; と - 呼ばれる TCP 中継デーモンを利用します. FAITH は IPv6 アドレス - プリフィックスを一つ予約し, そのプリフィックスに向かう TCP 接 - 続を IPv4 終点に向けて中継します. - - たとえば, 予約された IPv6 プリフィックスが - 3ffe:0501:0200:ffff:: で, TCP 接続の IPv6 終点が - 3ffe:0501:0200:ffff::163.221.202.12 であるならば, その接続は - 163.221.202.12 という IPv4 終点に向けて中継されます. - - - 終点 IPv4 ノード (163.221.202.12) - ^ - | 163.221.202.12 へ向けた IPv4 tcp - FAITH-中継 二重スタックノード - ^ - | 3ffe:0501:0200:ffff::163.221.202.12 へ向けた IPv6 TCP - 始点 IPv6 ノード - - - FAITH-中継 二重スタックノードでは &man.faithd.8; を起動 - しておく必要があります. - - より詳細な情報は, - src/usr.sbin/faithd/README をご覧ください. - - - - - IPsec - - IPsec は主に三つの構成要素からなります. - - - - ポリシ管理 - - - - 鍵管理 - - - - AH と ESP のハンドリング - - - - - ポリシ管理 - - 現在のカーネルには実験的なポリシ管理コードが実装されてい - ます. セキュリティポリシを管理するには二つの方法があります. 一 - つは, &man.setsockopt.2; を使ってソケット一つずつにポリシを設 - 定する方法です. この場合のポリシ設定は - &man.ipsec.set.policy.3; で説明されています. もう一つの方法は, - &man.setkey.8; によって PF_KEY インタフェース経由でカーネル内 - のパケットフィルタをもとにしたポリシを設定する方法です. - - ポリシエントリはその番号によって並び替えられることはない - ので, エントリを追加するときの順番がとても重要になります. - - - - 鍵管理 - - このキットで実装されている鍵管理コード (sys/netkey) は, - 自家製の PFKEY v2 実装です. これは RFC2367 に準処しています. - - - 自家製の IKE デーモンである "racoon" がこのキットに含ま - れています (kame/kame/racoon). 基本的に, racoon はデーモンとし - て走らせる必要があり, それから鍵を要求するポリシをセットアップ - します (たとえば, ping -P 'out ipsec - esp/transport//use' というように). カーネルは鍵を交 - 換するために, 必要に応じて racoon デーモンにアクセスします. - - - - AH と ESP のハンドリング - - IPsec のモジュールは, 標準の IPv4/IPv6 処理中の "フック" - として実装されています. パケットを送信するときに, - ip{,6}_output() は 一致する SPD (Security Policy Database: セ - キュリティポリシデータベース) があるかどうかをチェックして - ESP/AH 処理が必要かどうかを判断します. もし ESP/AH が必要なら, - {esp,ah}{4,6}_output() が呼ばれ, mbuf が適切に更新されます. パ - ケットを受信したときは, プロトコル番号に従って, すなわち - (*inetsw[proto])() という形で {esp,ah}4_input() が呼ばれます. - {esp,ah}4_input() はそのパケットの認証情報を解読 / 試験し, そ - して数珠繋ぎのヘッダと ESP/AH のためのパディングを取り除きます. - パケット受信時に ESP/AH ヘッダを取り除いてしまっても安全です. - なぜなら受信したパケットを "あるがまま" の形で使うことは絶対に - ないからです. - - ESP/AH を使うことによって, TCP4/6 における実効データセグ - メント長は ESP/AH によって挿入される数珠繋ぎのヘッダの増加分だ - け影響を受けます. わたしたちのコードはこの場合を考慮に入れています. - - - 基本的な暗号機能は "sys/crypto" ディレクトリの中にありま - す. ESP/AH 変換は wrapper 関数と一緒に {esp,ah}_core.c に記述され - ています. もしアルゴリズムを追加したかったら, wrapper 関数を - {esp,ah}_core.c に追加し, そして追加する暗号アルゴリズムを実装 - したコードを src/crypto に追加してください. - - このリリースでは, トンネルモードは以下の制限と共に部分的 - にサポートされています: - - - - IPsec トンネルは GIF による包括的トンネリングインタ - フェースと結合されていません. ip_output() と - tunnelifp->if_output() の間で無限ループを構成してしまうか - もしれないので, 非常に注意深く作業する必要があります. 統合 - した方がよいか, よくないか, 意見はいろいろ出ています. - - - - MTU と 分割禁止ビット (IPv4) についての考慮はさらな - るチェックを必要としています, が, 基本的にはうまく動いてい - ます. - - - - AH トンネルのための認証モデルは再考する必要があるで - しょう. 今後, ポリシ管理エンジンを改良する必要が出てくると - 思われます. - - - - - - RFC と ID への準処 - - カーネル内の IPsec コードは以下の標準に準処しています - (もしくは, 準処しようと努力しています): - - rfc182[5-9].txt で文書化されている - "old IPsec" 仕様 - - rfc240[1-6].txt と, - rfc241[01].txt, - rfc2451.txt, - draft-mcdonald-simple-ipsec-api-01.txt - (このドラフトは期限切れですが, - - ftp://ftp.kame.net/pub/internet-drafts/ から入手できま - す) で文書化されている "new IPsec" 仕様. - (注: IKE 仕様, rfc241[7-9].txt はユーザラ - ンドの "racoon" IKE デーモンとして実装されています) - - 現在サポートしているアルゴリズムは: - - - - old IPsec AH - - - - 空の暗号チェックサム (文書化されていません. デ - バッグのためだけのものです) - - - - 128 ビットの暗号チェックサムと鍵付き MD5 - (rfc1828.txt) - - - - 128 ビットの暗号チェックサムと鍵付き SHA1 - (文書化されていません) - - - - 128 ビットの暗号チェックサムと HMAC MD5 - (rfc2085.txt) - - - - 128 ビットの暗号チェックサムと HMAC SHA1 - (文書化されていません) - - - - - - old IPsec ESP - - - - 空の暗号化 (文書化されていません, - rfc2410.txt と似たものです) - - - - DES-CBC モード (rfc1829.txt) - - - - - - new IPsec AH - - - - 空の暗号チェックサム (文書化されていません. デ - バッグのためだけのものです) - - - - 96 ビットの暗号チェックサムと鍵付き MD5 - (文書化されていません) - - - - 96 ビットの暗号チェックサムと鍵付き SHA1 - (文書化されていません) - - - - 96 ビットの暗号チェックサムと HMAC MD5 - (rfc2403.txt) - - - - 96 ビットの暗号チェックサムと HMAC SHA1 - (rfc2404.txt) - - - - - - new IPsec ESP - - - - 空の暗号化 - (rfc2410.txt) - - - - DES-CBC with derived IV - (draft-ietf-ipsec-ciph-des-derived-01.txt, - draft expired) - - - - DES-CBC with explicit IV - (rfc2405.txt) - - - - 3DES-CBC with explicit IV - (rfc2451.txt) - - - - BLOWFISH CBC - (rfc2451.txt) - - - - CAST128 CBC - (rfc2451.txt) - - - - RC5 CBC - (rfc2451.txt) - - - - 上記のそれぞれは, 以下と結合可能: - - - - HMAC-MD5(96 ビット) による ESP 認証 - - - - HMAC-SHA1(96 ビット) による ESP 認証 - - - - - - - - 以下のアルゴリズムはサポートされて ＊いません＊: - - - - old IPsec AH - - - - 128 ビットの暗号チェックサムと HMAC MD5 + 64 ビット - の再送攻撃防止 (rfc2085.txt) - - - - 160 ビット暗号チェックサムと鍵付き SHA1 + 32 ビッ - トのパディング - (rfc1852.txt) - - - - - - IPsec (カーネル内) と IKE (ユーザランドの "racoon") は, - 何回もの相互接続性試験イベントで試験されていて, そこでの結果とし - て, 多くの他の実装とうまく相互接続可能であることがわかっていま - す. また, 現在の IPsec 実装は, RFC に記述された IPsec 暗号ア - ルゴリズムを非常に広くカバーしています (知的所有権の問題がない - アルゴリズムに限ってカバーしています). - - - - IPsec トンネルにおける ECN の考察 - - ECN と親和性のある IPsec トンネルは, - draft-ipsec-ecn-00.txt で述べられている方 - 法を用いてサポートされています. - - 通常の IPsec トンネルは RFC2401 で記述されています. カプ - セル化されるときに, 内側の IP ヘッダの IPv4 TOS フィールド (ま - たは, IPv6 トラフィッククラスフィールド) が外側の IP ヘッダに - コピーされます. カプセル解放の時には外側の IP ヘッダは単に削ら - れるだけです. 外側の IP ヘッダの TOS / トラフィッククラスフィー - ルド中の ECN ビットが失われてしまうため, このカプセル解放規則 - は ECN と互換性がありません. - - IPsec トンネルを ECN と親和性があるようにするために, カ - プセル化手順とカプセル解放手順を変更する必要がありました. これ - については, - - http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt - の 3 章で記述されています. - - net.inet.ipsec.ecn (または net.inet6.ipsec6.ecn) に設定 - する値によって, IPsec トンネルの実装は三通りの動作を行います: - - - - RFC2401: ECN を考慮しない (sysctl の値が -1 の時) - - - - ECN 禁止 (sysctl の値が 0 の時) - - - - ECN 許可 (sysctl の値が 1 の時) - - - - この振る舞いはノード毎に設定可能であり SA 毎ではないこ - とに注意してください (draft-ipsec-ecn-00 では SA 毎の設定を要 - 求していますが, それは大変すぎます). - - ここで述べた動作をまとめると以下のようになります (より詳 - しくはソースコードをご覧ください): - - - カプセル化 カプセル解放 - --- --- -RFC2401 内側から外側へ 外側の TOS ビットを落とす - 全ての TOS ビットをコピー. (内側の TOS ビットをそのまま使う) - -ECN 禁止 内側から外側へ ECN ビット以外 外側の TOS ビットを落とす - (0xfc でマスク) の TOS ビット (内側の TOS ビットをそのまま使う) - をコピー. ECN ビットを 0 に. - -ECN 許可 内側から外側へ ECN CE 以外 内側の TOS ビットを変更して使う. - (0xfe でマスク) の TOS ビット もし外側の ECN CE ビットが 1 な - をコピー. ECN CE ビットを 0 に. ら, 内側の ECN CE ビットを有効に. - - - 設定方法に関する一般的な戦略は以下のようになります: - - - - もし IPsec トンネルの両端が ECN に親和性がある動作を - するのなら, その両方を "ECN 許可" と設定した方がよいでしょ - う (sysctl の値を 1 に設定). - - - - もし反対側の端が TOS ビットに関して非常に厳密に動作 - するなら, "RFC2401" を使ってください (sysctl の値を -1 に - 設定). - - - - その他の場合, "ECN 禁止" (sysctl の値を 0 に設定). - - - - デフォルトの動作は, "ECN 禁止" (sysctl の値が 0) です. - - より詳しくは, 以下を参照してください: - - - http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, - RFC2481 (Explicit Congestion Notification: 明示的輻輳通知), - src/sys/netinet6/{ah,esp}_input.c - - (詳しい分析をしてくれた, 長 健二朗 氏 - kjc@csl.sony.co.jp に感謝します) - - - - 相互接続性 - - 以下に, これまでに KAME と IPsec/IKE の相互接続性試験を - 行ったプラットフォーム (の一部) を挙げます. これらのプラット - フォームも KAME も, 試験以降に何らかの実装の変更を行っているで - しょうから, 以下のリストは参考にとどめてください. - - Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure), - Ericsson ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel, - Microsoft WinNT, NIST (linux IPsec + plutoplus), Netscreen, OpenBSD, - RedCreek, Routerware, SSH, Secure Computing, Soliton, Toshiba, - VPNet, Yamaha RT100i - - - - diff --git a/ja_JP.eucJP/books/handbook/kerneldebug/Makefile b/ja_JP.eucJP/books/handbook/kerneldebug/Makefile deleted file mode 100644 index 34e4530a6e..0000000000 --- a/ja_JP.eucJP/books/handbook/kerneldebug/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= kerneldebug/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml deleted file mode 100644 index f31a82f3a3..0000000000 --- a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml +++ /dev/null @@ -1,719 +0,0 @@ - - - - - カーネルデバッグ - - 原作 &a.paul; and &a.joerg; - - 訳: &a.jp.yoshiaki;. 1997 年 3 月 18 日. - - - <command>gdb</command> - によるカーネルのクラッシュダンプのデバッグ - - ここではクラッシュダンプ (crash dump : 訳注 この文脈では - kernel 自身 - の異常によって停止した場合に出力されるイメージを指します) - によるカーネルデバッグの方法を示します。 - - ここではダンプするための十分なスワップ - (swap) の容量があるものとします。 - もし複数のスワップパーティションを持ち、 - 最初のパーティションがダンプ - を保持するのに十分な大きさを持たない場合は - 別のダンプデバイスを使うよ - うに (config kernel 行で) - カーネルのコンフィグをおこなうか、&man.dumpon.8; - コマンドを使って別のデバイスを示すことができます。&man.dumpon.8; - を使うもっともよい方法は変数 dumpdev を - /etc/rc.conf で設定することです。一般的には - /etc/fstab で設定されているスワップデバイスが - 使われるでしょう。 - スワップに使えないデバイスへのダンプ、 - 例えばテープへのダンプは現在サポートさ - れていません。カーネルのコンフィグは - config によって行ってください。 - FreeBSD - カーネルのコンフィグレーション - には FreeBSD のカーネルの設定の詳細がありますので - 参照してください。 - - &man.dumpon.8; コマンドを使ってどこへダンプするか - カーネルに伝えてください - (&man.swapon.8; によってそのパーティションが - スワップとして設定された - 後でなければならないことに注意してください)。これは普通は - /etc/rc.conf や /etc/rc - で設定されます。あるいは - 別の方法としてカーネルコンフィグレーションファイルの - config 行の dump 節で - ダンプデバイスをハードコードすることができます。 - この方法はあまりよくは - ありません。カーネルがブート時に crash - する場合のクラッシュダンプを取り - たい時だけ使うべきです。 - - - 以下では gdbという用語は - gdb - をカーネルデバッグモードで動かしていることを意味します。 - gdb を - オプションをつけて起動することで、 - このモードになります。 - カーネルデバッグモードでは、プロンプトが - (kgdb) に変わります。 - - - - FreeBSD 3 およびそれ以前のシステムを使っているなら、 - 巨大なデバッグカーネルをそのままインストールするのではなく - strip されたデバッグ用カーネルをつくるべきでしょう。 - - &prompt.root; cp kernel kernel.debug -&prompt.root; strip -g kernel - - この手順は必須ではありませんが、ぜひ行なうことをおすすめします - (FreeBSD 4 およびそれ以降では、カーネルの make - の段階で自動的にこれが行なわれます)。 - 自動的に、あるいは上のコマンドを手動で実行してカーネルが strip - されたら、普通に make install - と実行し、カーネルをインストールして構いません。 - - FreeBSD の古いリリース (3.1 を含まない以前のもの) は、 - 標準で a.out カーネルを使っていることに注意してください。 - これはシンボルテーブルが常に物理メモリ上に存在することを要求するため、 - strip されていないデバッグカーネルに含まれる大きなシンボルテーブルは非常に無駄になります。 - ELF カーネルを使った FreeBSD の最近のリリースでは、 - そのような問題がなくなりました。 - - - カーネルを作った時にそのコピーを - kernel.debug という名前で作りましょう。 - また、オリジナルに対して strip - -gを実行します。 - オリジナルを普通にインストールします。また strip - していないカーネルも同様にインストールすることができますが、 - シンボルテーブルの参照時間 - がいくつかのプログラムでは劇的に増加するでしょう。また、 - カーネル全体はブート時に読み込まれ - スワップアウトされないため数メガバイトの物理メ - モリが無駄になります。 - - 例えばブートプロンプトで - 新しいカーネルの名前をタイプすることによって、 - 新しいカーネルをテストした場合で、 - 再びシステムを動かすのに別のカーネ - ルで立ち上げることが必要な場合はブートプロンプトで - フラグ - を使いシングルユーザの状態にしてください。 - そして以下のような操作をおこないます。 - - &prompt.root; fsck -p -&prompt.root; mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする -&prompt.root; savecore -N /kernel.panicked /var/crash -&prompt.root; exit # ...マルチユーザモードへ移行 - - ここに示した &man.savecore.8; は (現在動いているものとは別の) - カーネルのシンボル名の抽出をおこなうために使っています。 - 抽出はデフォルトで - は現在動いているカーネルに対しておこなわれ、 - クラッシュダンプとカーネルシンボ - ルのくい違いのためにまったく何もしません - (訳注: そのためにオプション - で実際にダンプをおこしたカーネルを指定します)。 - - クラッシュダンプの起きた後に - /sys/compile/WHATEVERへ行き - gdbを動かします。gdb - より次のようにします。 - - symbol-file kernel.debug -exec-file /var/crash/kernel.0 -core-file /var/crash/vmcore.0 - - こうすると、 - クラッシュダンプを使ってカーネルソースを他のプログラムと同様に - デバッグすることができます。 - - 次に gdb - での手順のセッションのログを示します。長い行は読 - みやすくするために改行しました。また、 - 参照のために行番号を入れてあります。ただし、これは実際の - pcvt コンソールドライバの開発中の実際のエ - ラーのトレースです。 - - 1:Script started on Fri Dec 30 23:15:22 1994 - 2:&prompt.root; cd /sys/compile/URIAH - 3:&prompt.root; gdb -k kernel /var/crash/vmcore.1 - 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel -...done. - 5:IdlePTD 1f3000 - 6:panic: because you said to! - 7:current pcb at 1e3f70 - 8:Reading in symbols for ../../i386/i386/machdep.c...done. - 9:(kgdb) where -10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) -11:#1 0xf0115159 in panic () -12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) -13:#3 0xf010185e in db_fncall () -14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) -15:#5 0xf0101711 in db_command_loop () -16:#6 0xf01040a0 in db_trap () -17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) -18:#8 0xf019d2eb in trap_fatal (...) -19:#9 0xf019ce60 in trap_pfault (...) -20:#10 0xf019cb2f in trap (...) -21:#11 0xf01932a1 in exception:calltrap () -22:#12 0xf0191503 in cnopen (...) -23:#13 0xf0132c34 in spec_open () -24:#14 0xf012d014 in vn_open () -25:#15 0xf012a183 in open () -26:#16 0xf019d4eb in syscall (...) -27:(kgdb) up 10 -28:Reading in symbols for ../../i386/i386/trap.c...done. -29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ -30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ -31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ -32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ -33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ -34:ss = -266427884}) (../../i386/i386/trap.c line 283) -35:283 (void) trap_pfault(&frame, FALSE); -36:(kgdb) frame frame->tf_ebp frame->tf_eip -37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. -38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ -39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) -40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); -41:(kgdb) list -42:398 -43:399 tp->t_state |= TS_CARR_ON; -44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ -45:401 -46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) -47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); -48:404 #else -49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); -50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ -51:407 } -52:(kgdb) print tp -53:Reading in symbols for ../../i386/i386/cons.c...done. -54:$1 = (struct tty *) 0x1bae -55:(kgdb) print tp->t_line -56:$2 = 1767990816 -57:(kgdb) up -58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ -59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) -60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); -61:(kgdb) up -62:#2 0xf0132c34 in spec_open () -63:(kgdb) up -64:#3 0xf012d014 in vn_open () -65:(kgdb) up -66:#4 0xf012a183 in open () -67:(kgdb) up -68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ -69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ -70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ -71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ -72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) -73:673 error = (*callp->sy_call)(p, args, rval); -74:(kgdb) up -75:Initial frame selected; you cannot go up. -76:(kgdb) quit -77:&prompt.root; exit -78:exit -79: -80:Script done on Fri Dec 30 23:18:04 1994 - - 上の出力についてのコメントをします。 - - - line 6: - - これは DDB (後述) からのダンプです。このため - because you said to! という - panicコメントがつき、ページフォルトのトラップによって - DDBに入ったことが原因の、やや長いスタックトレー - スがあります。 - - - - line 20: - - スタックトレースでのこれは - trap()関数の位置です。 - - - - line 36: - - 新しいスタックフレームを使用するように指定しています。 - ただし、ここでこれを指定する必要ありません。 - trap の場合、スタックフレームは正しい場所を指していると考えられるからです。 - ソースコードの 403 行を見ると、tp - ポインタのアクセスが失敗しているか、 - 配列のアクセスが範囲外である可能性が高いことがわかります。 - - - - line 52: - - 怪しいポインタですが、 - アクセスは正常におこなえました。 - - - - line 56: - - ところが、明らかにポインタはゴミを指しています。これで - エラーを見つけました! (ここのコードの部分からはよくわかり - ませんが、 - tp->t_lineはコンソールデバイスの規定 - する行を参照しているので、 - もっと小さな整数でなければなりません。) - - - - - - - DDD によるクラッシュダンプのデバッグ - - カーネルのクラッシュダンプは ddd - のようなグラフィカルなデバッガで調べることもできます。 - 通常はコマンドラインで オプションをつけて - ddd を起動します。たとえば: - - &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 - - クラッシュダンプを ddd - のグラフィカルなインタフェースを使って - 見ることができます。 - - - - 突然ダンプした場合の解析 - - カーネルが予想もしない時にコアダンプして config - -g - を行ってコンパイルされていなかった場合にはどうしたら - よいでしょう。すべてが失われるわけではありません。 - パニックを起こさないでください。 - - もちろん、クラッシュダンプを使えるようにする必要があります。 - 使い方は前述の部分を見てください。 - - カーネルのコンパイルディレクトリ - (/usr/src/sys/arch/conf) - で、設定ファイルを編集します。以下の行のコメントを外します - (行が存在しなければ追加します): - - makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols - - カーネルを再構築しましょう。 - Makefileのタイムスタンプの変更により、例えば trap.o - などのいくつかの他のオブジェクトファイルも作り直さ - れます。少しの幸運があれば、 - オプションが追加されても作ら - れるコードは変更されず、いくらかのデバッグシンボル以外には - 問題を - 起こしたコードとそっくりな新しいカーネルを手に入れることが - できます。少なくとも &man.size.1; - コマンドで古い方と新しい方のサイズを比較すべきです。 - これが食い違っていれば、 - 多分あきらめなければならないでしょう。 - - ダンプを使って前述のように動かして調べます。 - デバッグシンボルは 必ずしも十分ではありません。 - 上の例ではスタックトレースでいくつかの関 - 数の行番号や引数リストが表示されないかもしれません。 - もしより多くのデバッグシンボルが必要であれば、十分になるまで - 適切なオブジェクトファイ ルを消して (makeして) - gdb セッションを繰り返してください。 - - これは必ずしもうまく動くと保証はできません。 - しかしほとんどの場合でうまくいくでしょう。 - - - - DDBを使ったオンラインカーネルデバッグ - - gdb - は非常に高レベルのユーザインタフェースを提 - 供するオフラインデバッガですが、いくつかのことはできません。 - (できないことの中で) - 極めて重要なことはカーネルコードへのブレークポイ - ントの設定とシングルステップ実行です。 - - カーネルの低レベルデバッグが必要であれば、DDBと呼ばれる - on-lineデバッガが使えます。ブレークポイントの設定、 - シングルステップのカーネルの実行、 - 変数の検査と変更などができます。 - ただし、これはカーネルのソースファ - イルにアクセスすることはできません。 - gdbのようにすべてのデ - バッグ情報にはアクセスできず、global と - static のシンボルにアクセスすることができるだけです。 - - カーネルに DDB - を含めるためにはコンフィグファイルに次のようなオプショ - ンを加えて、 - - options DDB - - 再構築をおこないます。( - FreeBSD のカーネルの設定の詳細については FreeBSD - カーネルのコンフィグレーションを参照してくださ - い。 - - - 古いバージョンの起動ブロックを使っている場合、ですと、 - デバッガのシンボルが完全にはロードされないかもしれません。 - その時は起動ブロックを最新のものに更新してください。 - 新しい起動ブロックは、DDB シンボルを自動的にロードします。 - - - DDB カーネルの実行において、 - DDB に入るいくつかの方法があります。最初の、 - 最も早い方法はブートプロンプトが出ている時に - のブートフラグをタイプすることです。 - カーネルはデバッグモードで起動し、デバイスのプローブ以前に - DDB に入ります。したがって、デバイスのプローブ/初期 - 設定ファンクションのデバッグができます。 - - 2 つ目のシナリオはキーボードのホットキーで、通常は - Ctrl-Alt-ESC です。syscons ではホットキーは再設定することができ、 - 配付されているいくつかのキーマッピングでは別のキーに - 再設定されていますので確認しておいてください。シリアルラインの - BREAK を使ってシリアルコンソールから DDB へ入ることを可 - 能にするオプションもあります - (カーネルコンフィグレーションファイルの options - BREAK_TO_DEBUGGER)。これは多くのつまらないシリ - アルアダプタが、例えばケーブルを引き抜いた時に - BREAK 状態を意味もなく - 作り出してしまうのでデフォルトでは無効になっています。 - - 3つ目は、DDB - を使うようになっているカーネルがパニック状態になると DDB - へ入るというものです。このため、 - 無人運転するマシンのカーネルに DDB を - 入れるのは賢明ではありません。 - - DDB のコマンドはおおまかには gdb - のいくつかのコマンドと似て - います。おそらく最初にブレークポイントを - 設定する必要があるでしょう。 - - b function-name -b address - - 数値はデフォルトでは 16 進数で、 - シンボル名とはまったく異なります。16 進数で a-f - の文字で始まる場合は、先頭に 0x - をつける必要があります(それ以外の数字の場合はどちらでもか - まいません)。function-name + - 0x103のような単純な式を使うことができます。 - - 割り込みされたカーネルから処理を続行するためには、 - - c - - とタイプするだけです。 - スタックのトレースには - - trace - - とします。 - - - DDB にホットキーで入った場合は、カーネルはその - (ホットキーの) 割り込み - の処理を行っていますのでスタックトレースは - あまり役にたたないことに注意してください。 - - - ブレークポイントを削除したい場合は、 - - del -del address-expression - - とします。 - 最初の形式はブレークポイントにヒットしたすぐ後で使うことができ、 - 現在のブレークポイントを削除します。2 番目の形式では任意のブレー - クポイントを削除することができますが、 - 次の形式で得られるような正確な - アドレスを与えることが必要です。 - - show b - - カーネルをシングルステップ実行させるには - - s - - としてみてください。これは関数呼出し先までステップ実行 (step - into function) するでしょう。 - 次のステートメントが終了するまでの DDBトレースは - - n - - によっておこなうことができます。 - - - これは gdb の next - 命令とは異ります。gdbの - finish 命令と似ています。 - - - メモリ上のデータを調べるには (例として) 次のようにします。 - - x/wx 0xf0133fe0,40 -x/hd db_symtab_space -x/bc termbuf,10 -x/s stringbuf - - word/halfword/byte 単位でアクセスをおこない、hex (16進) - /dec (10進) / - char (文字) /string (文字列) で表示します。 - カンマの後ろの数字はオブジェク - トカウントです。次の 0x10 個の要素を表示するには、単純に - - x ,10 - - とします。同様に次のように使うことができます。 - - x/ia foofunc,10 - - foofunc - の最初の 0x10 個の命令語をディスアセンブルし、 - foofunc - の先頭からのオフセットとともに表示します。 - - メモリの内容を変更するには write コマンドを使います。 - - w/b termbuf 0xa 0xb 0 -w/w 0xf0010030 0 0 - - コマンドモディファイアの - (b/h/w) - はデータを 書くサイズを定義し、 - これに続く最初の式は書き込むアドレス、残りがこれ - に続く連続するメモリアドレスに書き込まれるデータになります。 - - - 現在のレジスタ群の内容を知りたい場合は - - show reg - - とします。また、単一のレジスタの値を表示するには、例えば - - p $eax - - とします。また値の変更は - - set $eax new-value - - とします。 - - DDBからカーネルの関数を呼び出す必要がある場合は、単に - - call func(arg1, arg2, ...) - - とします。return 値が出力されます。 - - 動いているプロセスの &man.ps.1; スタイルの概要は - - ps - - です。 - - カーネルの失敗の原因の調査が終わったら、ここで再起動すべきです。 - それまでの不具合により、カーネルのすべての部分が期待するような - 動作をしているわけではないということを忘れないでください。 - 以下のうちいずれかの方法でシステムのシャットダウンおよび再起動を行ってください。 - - panic - - カーネルをコアダンプしてリブートしますので、後で - gdbによってコアの高レベル解析をすることができます。 - このコマンドは通常、一度 - continue命令を使った後に - 使うことになるでしょう。 - - call boot(0) - - は動いているシステムを `clean' に shut - down するよい方法です。すべてのディスクを - sync() して最後にリブートします。 - ディスクとカー - ネルのファイルシステムインタフェースが破損していない限り、 - ほぼ完全に `clean' にシャットダウンするよい方法でしょう。 - - - call cpu_reset() - - は大惨事を防ぐための最後の手段で 「赤い大きなボタン」 - を押すのとほとんど同じです (訳注: - リセットボタンを押すのとほぼ同じであるという意味です)。 - - 短いコマンドの要約は - - help - - をタイプします。ただし、デバッグセッションのために - &man.ddb.4; の - マニュアルページのプリントアウトを用意しておくことを - 強くお奨めします。 - カーネルのシングルステップ中にオンラインマニュアルを - 読むことは難しいということを覚えておいてください。 - - - - リモート GDB を使ったオンラインカーネルデバッグ - - この機能は FreeBSD 2.2 からサポートされました。 - これは本当にすばらし い機能です。 - - GDB はすでにかなり以前より - リモートデバッグ をサポートしてい ます。 - これはシリアル回線を使い非常に単純なプロトコルで行ないます。 - もちろん、この方法では今までに示した方法とは違い、 - 2 台のマシンが必要になります。1 台はデバッグ環境のためのホストで、 - すべてのソースとす - べてのシンボルを含んだバイナリのコピーを持っています。もう 1 台は - ターゲットマシンで、同一のカーネルのコピー (ただしデバッグ情報は - 取り除いてあるもの) を単に実行するためのものです。 - - この場合、カーネルのコンフィグレーションは config - -g で行な い、 - を含めなくてはなりません。そうして通常通りコンパイルし ます。 - こうして作ったバイナリファイルはデバッグ情報のために非常に大き - くなります。このカーネルをターゲットマシンにコピーして - strip -x でデバッグシンボルを取り除きます。 - そして ブートオプションを使いブートします。 - sio デバイスにフラグ 0x80 が設定されているターゲットマシンの - シリアル回線を、デバッグホストのいずれかのシリアル回線に - つないでください。 - それからデバッグ (訳注:ホスト) マシン上で、ターゲットとなって - いるカーネルのコンパイルディレクトリで gdb を起動します: - - &prompt.user; gdb -k kernel -GDB is free software and you are welcome to distribute copies of it - under certain conditions; type "show copying" to see the conditions. -There is absolutely no warranty for GDB; type "show warranty" for details. -GDB 4.16 (i386-unknown-freebsd), -Copyright 1996 Free Software Foundation, Inc... -(kgdb) - - リモートデバッグセッションの初期化 - (1 番目のシリアルポートを使用することの設定) - を以下のように行ないます。 - - (kgdb) target remote /dev/cuaa0 - - 次にターゲットマシン (デバイスのプローブ直前で DDB - に入っています) で次のように入力します: - - Debugger("Boot flags requested debugger") -Stopped at Debugger+0x35: movb $0, edata+0x51bc -db> gdb - - DDB は次のような出力を返すでしょう。 - - Next trap will enter GDB remote protocol mode - - gdbと入力するたびにリモート GDB - とローカル DDB が交互に切り替わります。 - トラップをすぐに起こすために単に ``s'' (step) と入力して下さい。 - そうするとホストの GDB はターゲットのカーネルの制御を行なうよ - うになります。 - - Remote debugging using /dev/cuaa0 -Debugger (msg=0xf01b0383 "Boot flags requested debugger") - at ../../i386/i386/db_interface.c:257 -(kgdb) - - このセッションではソースコードへのフルアクセスや Emacs の - window 上 の gud-mode (これは別の Emacs window - に自動的にソースコードを表示します) で動かすなど、通常の GDB - セッションでできることのほとんどのことができます。 - - - - GDB を使ったローダブルモジュールのデバッグ - - モジュール内部で発生する panic のデバッグや、 - 動的モジュールを使っているマシンを GDB - でリモートデバッグしている場合、 - モジュールのシンボル情報を得る方法を - GDB に伝える必要があります。 - - まず、モジュールをデバッグ情報を含めて構築する必要があります。 - - &prompt.root; cd /sys/modules/linux -&prompt.root; make clean; make COPTS=-g - - リモート GDB を使っている場合は、 - ターゲットマシンで kldstat を実行することで - モジュールがどこにロードされたか調べることが可能です。 - - &prompt.root; kldstat -Id Refs Address Size Name - 1 4 0xc0100000 1c1678 kernel - 2 1 0xc0a9e000 6000 linprocfs.ko - 3 1 0xc0ad7000 2000 warp_saver.ko - 4 1 0xc0adc000 11000 linux.ko - - クラッシュダンプをデバッグしている場合、 - linker_files->tqh_first から始まる - linker_files リストを調べ、 - 探している filename が見つかるまで - link.tqe_next ポインタをたどる必要があります。 - エントリ中の address メンバが、 - モジュールのロードアドレスです。 - - 次に、モジュール内の text セクションのオフセットを調べます。 - - &prompt.root; objdump --section-headers /sys/modules/linux/linux.ko | grep text - 3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2 - 10 .text 00007f34 000062d0 000062d0 000062d0 2**2 - - 必要なのは .text セクションで、 - 上の例では 10 にあたります。その 4 番目の 16 進数フィールド - (全部で 6 フィールドあります) が、ファイル中の text - セクションのオフセットになります。 - そして、このオフセットをモジュールのロードアドレスに加算すると - モジュールのコードの再配置アドレスを求めることができます。 - この例では 0xc0adc000 + 0x62d0 = 0xc0ae22d0 です。 - GDB コマンド add-symbol-file を使い、 - 得られたモジュールの情報をデバッガに伝えるには、次のようにします。 - - (kgdb) add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0 -add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0? -(y or n) y -Reading symbols from /sys/modules/linux/linux.ko...done. -(kgdb) - - これで、モジュール内のすべてのシンボルにアクセスできるようになります。 - - - - コンソールドライバのデバッグ - - DDBを動かすためにはコンソールドライバが必要ですから、 - コンソールドラ イバ自身に不具合のある場合は複雑になります。 - シリアルコンソールを利 用する方法 (ブートブロックを変更するか - Boot:プロンプトで - と入力する) を思い出してください。 - そして標準ター ミナルを最初のシリアルポートに設定します。DDBは、 - もちろんシリアルコンソールを含むいずれの - コンソールドライバの設定でも動作します。 - - diff --git a/ja_JP.eucJP/books/handbook/kernelopts/Makefile b/ja_JP.eucJP/books/handbook/kernelopts/Makefile deleted file mode 100644 index 066428747c..0000000000 --- a/ja_JP.eucJP/books/handbook/kernelopts/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= kernelopts/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/kernelopts/chapter.sgml b/ja_JP.eucJP/books/handbook/kernelopts/chapter.sgml deleted file mode 100644 index 537e719d23..0000000000 --- a/ja_JP.eucJP/books/handbook/kernelopts/chapter.sgml +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - - - Jörg - Wunsch - 原作 - - - - - カーネルコンフィグレーションの - 新しいオプションを追加する - - 訳: &a.jp.yoshiaki;, 1996 年 12 月 29 日. - - - この章をお読みになる前に FreeBSD - カーネルのコンフィグレーション の章の内容を - 理解しておいてください. - - - - そもそも<emphasis>カーネル - オプション</emphasis>って何? - - カーネルオプションの使い方は基本的には - FreeBSD - カーネルのコンフィグレーション - の章に書いてあります. - そこには伝統的な形式と新しい形式のオプションの説明があります. - すべてのカーネルのオプションを新しい形式のものに置き換え, - コンフィグファイル - を修正して &man.config.8; を実行した後に - カーネルのコンパイルディレクトリで - make depend を実行すれば, - ビルドプロセスが自動的に変更された - オプションを検出し, 必要なファイルだけを - 再コンパイルするようにすることが - 最終的な目的です. &man.config.8; - を実行するたびに古いコンパイルディレクトリ - を消してしまう現在のやりかたは, - やがておこなわれなくなるでしょう. - - 基本的に, カーネルオプションはカーネルのコンパイルプロセスの - C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make - できる ようにするためには, 対応する部分のカーネルソース - (またはカーネルの .h ファイル) - がオプションを使えるようにあらかじめ書かれていなければ - なりません. - つまりデフォルト値をコンフィグファイルのオプションで置き換え - られるようになっていなければなりません. - これは普通は次のようになっています. - - #ifndef THIS_OPTION -#define THIS_OPTION (some_default_value) -#endif /* THIS_OPTION */ - - この場合, - 管理者がコンフィグファイルのオプションに別の値を記述すれば, - デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, - 新しい値はプリプロセッサによってソースコード中で - 置き換えられるため, デフォルトの値が使われていた場所において C - の式として有効な値でなければ なりません. - - また, 単に特定のコードを有効にするか - 無効にするかを設定するための - 値を持たないオプションも作ることができます. - - #ifdef THAT_OPTION - -[あなたのコードが入ります] - -#endif - - コンフィグファイルに THAT_OPTION - と記述するだけで (値の有無 にかかわらず) - 対応する部分のコードが組み込まれます. - - C 言語にくわしい人であれば - コンフィグオプションとされているもの - は少なくとも一つの #ifdef - で参照されているということはすぐに理解 できるでしょう. ところで, - ごく一部の人たちは次のようなものを試して - みようとするかもしれません. - - options notyet,notdef - - このようにコンフィグファイルをしておくと, - カーネルのコンパイルは うまく行きません. - - (訳注: たとえば MATH_EMULATE のように - 有効/無効のためのパラメータを 持たないオプションの場合, - 無効とするためのパラメータをつけて, オプション - で「無効とする」と明示することはできないという意味です) - - 明らかに, - 任意のオプション名がカーネルソースツリー全体でどのように - 使われているかを追いかけることは非常に難しいことです. このことが - 新しい形式 - のオプションの機構を採り入れる理由の背景です. - ここではそれぞれのオプションは - カーネルコンパイルディレクトリにある別々の - .h ファイルとなり, - opt_foo.h - という名前に されます. この方法では, 通常の Makefile - の依存関係が適用され, make - プログラムはオプションが変更された時に再コンパイルが必要な - ものを見つけることができます. - - 古い形式のオプションの機構は, - 局部的なオプションや実験的なオプション - のような一時的に利用されると考えられるオプションにおいては - 有効です. つまり #ifdef - をカーネルのソースに追加するのは簡単であり, - それがそのままカーネルコンフィグオプションになります. この場合, - 管理者はオプションの利用において - 依存関係を把握しておく責任があります (また, - 手動でカーネルの一部分を - 強制的に再コンパイルする必要があるかもしれません). - サポートされている - オプションのすべてについて一つでも変更があると, &man.config.8; - は サポートされていないオプションがコンフィグファイルの中に - あるという警告 を出しますが, カーネルの Makefile - 内にはそれを含めます. - - - - ではどのようにして追加するのでしょう? - - 最初に sys/conf/options (または - sys/<arch>/conf/options.<arch>, たとえば sys/i386/conf/options.i386) - を編集し, 新しいオプション を含めるのに最適な - opt_foo.h - ファイルを選びます. - - 新しいオプションの必要がなくなったとしたら, - これを取り除きます. たとえば, SCSI - サブシステムに関するすべてのふるまいについてのオプション - の変更は opt_scsi.h に入れられます. - デフォルトでは, 適切 なオプションファイルに単に記述されます. - たとえば FOO であれば 値は対応するファイルの - opt_foo.h に格納されます. これは右端に別 - のファイル名を書いて置き換えることができます. - - 新しいオプションを加えるのに使えそうな - opt_foo.h - がない場合は新しい名前を作ってください. 意味のある名前を作り - options[.<arch>] - ファイル に新しいセクションのコメントをつけてください. - &man.config.8; は自動的 - に変更を検出して, 次の実行からは (訳注: 新しい - .h) ファイル を作ります. - ほとんどのオプションはヘッダファイルに入れられます. - - 大量のオプションを一つの - opt_foo.h - にまとめると - コンフィグファイルの一つのオプションを変更したときに - 多くのファイルが 再コンパイルされる原因になります. - - 新しいオプションに依存するカーネルファイルは - 最終的には見つけ出されます. - ただし, オプションを作っただけで対応するソースがどこにもない場合は別です. - &prompt.user; find /usr/src/sys -type f | xargs fgrep NEW_OPTION - オプションに対応するソースを見つけるのに上記のコマンドは便利です. - 見つけたすべてのファイルで編集, 追加をおこないます. - - #include "opt_foo.h" - - ファイルの先頭の, すべての - #include <xxx.h> より前に入れます. - この場合, オプションによって次のようにしてデフォルト値 - を持たせている標準のヘッダファイル内の値を置き換えるため, - 順番は非常に 重要です. - - #ifndef NEW_OPTION -#define NEW_OPTION (something) -#endif - - システムヘッダファイル (たとえば - /usr/include/sys/ にある ファイル) - をオプションで置き換えることは, ほとんどの場合で失敗します. - そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, - include しないとオプションの値によって - 不整合が起きてしまう場合を除き, それらの ファイルに - opt_foo.h - を include しないでください. - そう, 現在このような例がいくつか存在していますが, - 必ずしも正しい方法 ではありません. - - diff --git a/ja_JP.eucJP/books/handbook/policies/Makefile b/ja_JP.eucJP/books/handbook/policies/Makefile deleted file mode 100644 index 1c03490aa3..0000000000 --- a/ja_JP.eucJP/books/handbook/policies/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= policies/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/policies/chapter.sgml b/ja_JP.eucJP/books/handbook/policies/chapter.sgml deleted file mode 100644 index 938a29953f..0000000000 --- a/ja_JP.eucJP/books/handbook/policies/chapter.sgml +++ /dev/null @@ -1,506 +0,0 @@ - - - - - - - Poul-Henning - Kamp - 寄稿: - - - - ソースツリーのガイドラインおよび方針 - - 訳者: &a.jp.mihoko;、1996 年 9 月 6 日 - - 本章は、FreeBSD - のソースツリーについてのさまざまなガイドラインや - ポリシーについて書かれています。 - - - Makefile 中の <makevar>MAINTAINER</makevar> - port 保守担当 (ports maintainer) - - 1996 年 6 月 - - FreeBSD 配布物の特定の部分が、一人の人やグループによって保守 - されている場合は、ソースツリーの当該 - Makefile に - - MAINTAINER= email-addresses - - が付け加えられています。これを記述することによって、 - この部分が誰によって保守管理されているかを世界中のユーザに - 伝えることができます。 - - この意味は次のとおりです: - - 保守担当者がそのコードを所有し、そのコードに対する責任を持っ - ています。すなわち、 - その人がそのコードに関するバグの修正やトラブル報告 - に対する回答をします。また、 - そのコードが寄贈ソフトウェアの場合には、そのソフトウェアの - 新しいバージョンに適切に追従させる作業をその人が行い - ます。 - - 保守担当者が決められているディレクトリに対して - 変更をおこなう場合は、変更をおこなう前に、 - その変更内容を保守担当者に送って、 - 保守担当者にレビューをしてもらってください。保守担当者が、 - 電子メールに一定期間応答しない場合にのみ、 - 保守担当者がレビューすることなしに、 - 変更をおこなうことが認められます。しかしながら、 - そのような場合でも可能な限り、変更点を第三者にレビュー - してもらうようにしてください。 - - もちろん、この義務を引き受けることができない人やグループを - 保守管理者として追加することはできません。また、 - 保守管理者がソースツリー管理者 ("committer") である必要は - ありません。 - - - - - - - Poul-Henning - Kamp - 寄稿: - - - David - O'Brien - - - - - - 寄贈ソフトウェア - 寄贈ソフトウェア - - 訳者: &a.jp.mihoko; - - - FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD - プロジェクト以外のところで保守されています。歴史的な経緯から、 - 私たちはこれを 寄贈 ソフトウェアと - 呼んでいます。perl や gcc - patch などがその例です。 - - ここ数年来、この種のソフトウェアの取り扱いには、 - さまざまな方法が 取られてきましたが、 - どの方法にもいくつかの利点と欠点があります。 - これまで欠点のない明確な方法はありませんでした。 - - 議論した結果、これらの方法のうちの一つが - 公式な 方法として選択されました。その方法が、今後、 - この種のソフトウェアを取り込む場合に、使用されます。その上、 - この方法では、だれもが (cvs - にアクセス権のない人でさえ) 公式 - バージョンのソースに対する差分を簡単に得ることができます。 - これは古い方法にはなかった大きな利点です。ですから、 - 既存の寄贈ソフトウェアも、 - この方法に収束していくことを強く望んでいます。 - この方法を使用することにより、寄贈ソフトウェアの主な開発者に、 - 変更点を返すのがとても容易になります。 - - しかしながら結局、寄贈ソフトウェアの取扱は、 - 実際に作業を行っている人々に委ねられています。 - もしこの方法を使用することが、その人が扱っているパッケージには - 極端に合わないような場合には、コアチームの承認さえあれば、 - これらのルールに反しても、 - 他の開発者の一般的な合意は得られるでしょう。 - 将来にわたってパッケージを保守できるということは、 - 大変重要な事柄に なってきます。 - - - RCS のファイルフォーマットと CVS - のベンダブランチの使用には不幸な設計上の制限があります。 - したがって、 - ベンダブランチの内容をいまだに引きずっているファイルに - 対して小さな、些細な変更、そして / あるいは - 膨大な変更を加えることには、 - 強い反対があります。 - 誤字訂正 はもちろんこの中に入りますし、 - しかも 膨大な の範疇に入るので、リビジョンが - 1.1.x.x - であるファイルに対する誤字訂正は避けられることになっています。 - 一文字の変更したことによるリポジトリの肥大は、 - 非常に劇的なものになり得るのです。 - - - プログラミング言語 Tcl は、 - この方法が活用されているよい例になっています: - - src/contrib/tcl には、 - このパッケージの保守管理者が配布したソースが含まれています。 - この中からは FreeBSD に完全には適用 - できない部分が削除されています。Tcl の場合は、 - mac、win、 - compat というサブディレクトリは、FreeBSD - に取り込む前に削除されていました。 - - src/lib/libtcl には、 - ライブラリを生成したり、ドキュ - メントをインストールする際に使用される、標準の - bsd.lib.mk の規則を使用した - bmake スタイルの - Makefile だけが含まれています。 - - src/usr.bin/tclsh には、 - bsd.prog.mk 規則を使用して、 - tclsh - プログラムや関連するマニュアルページを生成 / インストールする - bmake スタイルの Makefile - だけが含まれています。 - - src/tools/tools/tcl_bmake には、Tcl - ソフトウェアを更新する必要が生じたときの助けになる 2 つのシェルス - クリプトが含まれています。これらは、 - ソフトウェアを構築するのに使用したり、 - インストール対象になるソフトウェアではありません。 - - ここ重要なのは、src/contrib/tcl - ディレクトリが、規則にしたがっ て作られているということです。 - つまり、できるだけ FreeBSD に特化した - 変更をおこなわないようにしたソースを (RCS - のキーワードを拡張しないで、CVS のベンダブランチに) おくようにし - ています。 - freefall 上の「簡易取り込み」ツールは、 - 寄贈ソフトウェアを取り込む手助けとなります。けれども、 - このツールの実行方法に疑問が生じた場合は、まずはじめに質問して、 - 失敗をしないようにしてください。そして、 - その疑問を 解決して からツールを使用してください。 - CVS に寄贈ソフトウェアを取り込む際には、 - 事故があってはいけません。 - よくあるような間違いをおかさないように、 - 十分注意してください。 - - 先ほど述べたように、残念なことに CVS - にはベンダブランチという設計制限があります。このため、CVS - に寄贈ソフトウェアを取り込むには、オリジナル配布ソースに - 適用されるベンダからの 公式 パッチと、 - ベンダブランチに逆輸入された 結果が必要です。 - ベンダブランチの一貫性を破壊したり、将来、 - 新しいバージョンを取り込む - 時に衝突を起こしてしまったりというような - 困難な事態に陥らないようにしなければなりません。そのために、 - FreeBSD が管理しているバージョンに対して、 - 公式パッチを決して当ててはいけませんし、公式パッチを "commit" - してはいけません。 - - 多くのパッケージが、他のアーキテクチャや他の環境と FreeBSD - との互換性を保ためのファイルをいくつか含んでいます。そこで、 - スペースを節約するために、FreeBSD - にとっては無意味な配布ツリー上の一 - 部を削除することが許されています。けれども、 - 削除されずに残ったファイルに対する、著作権の通知やリリース - ノートのような情報を含んだファイルは、決して削除しては - いけません。 - - bmake Makefile - が何らかのユーティリティによって、配布ツリー - から自動的に生成できると、うまくいけば、新しいバージョンへの - アップグレードをより簡単におこなうことができます。 - もしこのようなユーティリティを作成できた場合には、将来の管理者に - とって便利になるように、移植の際に、 - src/tools ディレクトリ上に、(必要に応じて) - そのユーティリティを必ずチェックインしてください。 - - src/contrib/tcl - レベルのディレクトリには、FREEBSD-upgrade - と 呼ばれるファイルが追加されており、そのファイルでは - 次のような内容が記述されています。 - - - - ディレクトリ上に存在するファイル - - - - オリジナルの配布物をどこから入手すればよいか また、 - 公式配布 サイトはどこか - - - - オリジナルの作者にパッチを送り返すためには、 - どこに送ればよいか - - - - FreeBSD に特化した変更点の概要 - - - - しかしながら、寄贈ソースと一緒に - FREEBSD-upgrade ファイルを - 取り込まないでください。それよりむしろ、 - (訳注: このファイルを) 初回に取り込んだ後は、コマンド cvs - add FREEBSD-upgrade ; cvs ci を実行してください。 - src/contrib/cpio を例にすると、 - 次のようになります: - - このディレクトリは「ベンダ」ブランチ上のオリジナル配布ファイル -の初期ソースが含まれています。いかなる事情があっても、 -パッチや cvs コミットによってこのディレクトリ上のファイルを -アップグレードしてはいけません。 -(訳注: ベンダから配布された) 新しいバージョンや公式パッチだけが -(訳注: このディレクトリに) 取り込まれなくてはいけません。 -ベンダの RCS Id が CVS に入ってしまうのを避けるために、"-ko" オプ -ションをつけてインポートすることを忘れないで下さい。 - -GNU cpio 2.4.2 を取り込むためには、以下のファイルが削除されました: - - INSTALL cpio.info mkdir.c - Makefile.in cpio.texi mkinstalldirs - -cpio を新しいバージョンにアップデートするためには、次の作業を -おこないます: - - 1. 空のディレクトリに新しいバージョンを取り出します。 - [ファイルに「いかなる変更」も加えてはいけません] - - 2. 上記にリストされたファイルと、FreeBSD には無意味な - ファイルを削除します。 - - 3. 次のコマンドを実行します: - cvs import -ko -m 'Virgin import of GNU cpio v<version>' \ - src/contrib/cpio GNU v<version> - - たとえば、バージョン 2.4.2 を取り込むためには、次のように - タイプします: - cvs import -ko -m 'Virgin import of GNU v2.4.2' \ - src/contrib/cpio GNU v2.4.2 - - 4. FreeBSD に対するローカルな変更と、新しいバージョンとの間での - 矛盾を解消するために、ステップ 3 で出力された命令を実行します。 - -いかなる事情があっても、この手順から外れてはいけません。 - -cpio にローカルな変更を加えたい場合には、メインブランチ (別名 HEAD) に対して -パッチを実行し、コミットしてください。 -決して GNU のブランチにローカルな変更を加えないでください。 - -ローカルにおこなわれたすべての変更を次のリリースに含めるために、 -"cpio@gnu.ai.mit.edu" に提出してください。 - -obrien@FreeBSD.org - 30 March 1997 - - - - ソース管理上注意が必要なファイル (Encumbered Files) - - 場合によっては FreeBSD のソースツリーの中にソース管理上 - 注意が必要なファイルを含む必要があるかも知れません。例えば、デバイス - を操作する前に、そのデバイスに小さなバイナリコードをダウンロード - する必要があり、しかも我々が そのソースコードを持っていない場合、 - そのバイナリファイルのことをソース管理上注意が必要である (encumbered) - と言います。 - 以下に挙げるガイドラインでは、ソース管理上注意が必要なファイルを - FreeBSD ソースツリーにいれる方法を示します。 - - - - - システムの CPU(s) によってインタプリタされたり - 実行されたりするファイルで、しかもソース形式でないファイルは - すべて、ソース管理上注意が必要なファイルです。 - - - - BSD または GNU よりも制限されたライセンスを持つファイルは - すべて ソース管理上注意が必要なファイルです。 - - - - ハードウェアによって使用されるダウンロード可能な - バイナリコードを含むファイルは、(1) または (2) の条件が - 当てはまらなければ、ソース管理上注意が必要なファイル - ではありません。 - そのようなファイルはアーキテクチュアに依存しない - ASCII 形式 (file2c または uuencode が推奨されます) で保存 - します。 - - - - コアチーム (core team) - ソース管理上注意が必要なファイルはすべて、CVS リポジトリ - に加える前に、 - コアチーム (core team) からの特別な承認 - が必要です。 - - - - ソース管理上注意が必要なファイルは src/contrib - または src/sys/contrib に入ります。 - - - - すべてのモジュールは一緒に置きます。ソース管理上とくに注意 - を必要としないコードとコードを共有していない限りは、 - モジュールの置場を分ける必要はありません。 - - - - オブジェクトファイルは - arch/filename.o.uu> と命名されます。 - - - - カーネルファイル - - - - 必ず - conf/files.* (構築を簡単にするため) -に記述するようにして下さい。 - - - - 必ず LINT に記述して下さい、 - ただし、それをコメントアウトすべきかどうかは - Core team がその都度 - 判断します。 - もちろん Core team は - あとでそれを変更することもできます。 - - - - リリースエンジニア (release engineer) - リリースエンジニア - は、それをそのリリースにいれるかどうかを決定します。 - - - - - - ユーザランドのファイル - - - - Core team は、そ - のコードが make world の中で構築される - べきかどうかを決定します。 - - - - リリースエンジニア - は、それをそのリリースにいれるかどうかを決定します。 - - - - - - - - - - - Satoshi - Asami - 寄稿: - - - Peter - Wemm - - - David - O'Brien - - - - - - 共有ライブラリ - - もしあなたが共有ライブラリをサポートする機能を port - に追加した り、 - 共有ライブラリをサポートしていない他のソフトウェアに追加する - 場合には、共有ライブラリのバージョン番号を次の規則にしたがって - つけてください。一般的には、この規則は、 - ソフトウェアのリリースバージョンとは全く関係ありません。 - - 共有ライブラリを作成する三つの重要な規則は - 次の通りです: - - - - 1.0 から始める - - - - 過去のバージョンに互換性のある変更の場合は、 - マイナー番号を増やす (ELF システムでは - マイナー番号が無視されることに注意して下さい) - - - - 互換性のない変更の場合は、メジャー番号を増やす - - - - 例えば、機能追加とバグ吸収の場合は、 - マイナー番号を増やします。機能削除、 - 関数呼び出しのシンタックスなどが変更された場合は、 - 強制的にメジャー番号を変更します。 - - メジャー.マイナーー - (x,y) - の形式のバージョン番号を使用します。FreeBSD における - a.out 形式のダイナミックリンカは、 - x.y.z - という形式のバージョン番号 は扱えません。 - この場合、y の後のバージョン番号 - (つまり三つ目の数字) は、 - どのライブラリがリンクされているかを決めるために、共有ライブラ - リ番号を比較する際に、すべて無視されます。 - 小さな リビジョンだけが - 異なる二つの共有ライブラリが指定 されると、 - ld.so は、 - リビジョンの大きい方の共有ライブラリを リンクします。すなわち、 - もしあなたが libfoo.so.3.3.3 をリンク - していたとすると、リンカは頭の 3.3 - という部分だけを認識し、libfoo.so.3 - ではじまり その後に 3 - 以上の数字が続くもののうち、 - 最も大きい番号 - の付いているライブラリをリンクします。 - - - ld.so はいつも最も大きい - マイナー リビジョンのものを使うことに - 注意してください。例えば、プログラムがはじめ - libc.so.2.0 を リンクしていたとしても、 - libc.so.2.0 よりも - libc.so.2.2 を優先して使用します。 - - - さらに、ELF ダイナミックリンカはマイナーバージョンを全く扱いません。 - しかし、作成した Makefile がそのようなシステムでも - 「きちんと動作できる」ように、メジャー番号およびマイナー番号を - 指定する必要があります。 - - - 移植されていないライブラリに対しては、 - 共有ライブラリのバージョン番号はリリースごとに一度だけ変更し、 - また、主要な共有ライブラリのバージョン番号は、OS の主リリースごとに - 一度だけ変更する、というのが私たちのポリシーです。 - つまり、X.0 は (X+1).0 になります。 - あなたがシステムライブラリのバージョン番号を上げた場合は、 - Makefile の commit ログを確認してください。 - 結果としてそのリリースには、共有ライブラリのバージョン番号が - アップデートされた Makefile - に入るので、最初にその変更を 確かめるのがソースツリー管理者 - ("committer") の責務です。その後のどんな変更も、 - そのリリースには入りません。 - - diff --git a/ja_JP.eucJP/books/handbook/staff/Makefile b/ja_JP.eucJP/books/handbook/staff/Makefile deleted file mode 100644 index 905a9c2403..0000000000 --- a/ja_JP.eucJP/books/handbook/staff/Makefile +++ /dev/null @@ -1,16 +0,0 @@ -# -# Build the Handbook with just the content from this chapter. -# -# $FreeBSD$ -# -# Original revision: 1.1 - -CHAPTERS= staff/chapter.sgml - -VPATH= .. - -MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} - -DOC_PREFIX?= ${.CURDIR}/../../../.. - -.include "../Makefile" diff --git a/ja_JP.eucJP/books/handbook/staff/chapter.sgml b/ja_JP.eucJP/books/handbook/staff/chapter.sgml deleted file mode 100644 index 68addb28aa..0000000000 --- a/ja_JP.eucJP/books/handbook/staff/chapter.sgml +++ /dev/null @@ -1,1406 +0,0 @@ - - - - - FreeBSDプロジェクトスタッフ - - 訳: &a.hanai;, 1996 年 8 月 28 日. - - FreeBSDプロジェクトは, - 以下の人々によって管理運営されています. - - - FreeBSD コアチーム - - FreeBSD コアチームは, - プロジェクトの 運用委員会 を形成し, FreeBSD - プロジェクトの全般的な目的や方針の決定を行います. さらに, - FreeBSDプロジェクトの 特定の分野の - 運用も行っています. - - (姓でアルファベット順): - - - - &a.asami; - - - - &a.dg; - - - - &a.jkh; - - - - &a.grog; - - - - &a.imp; - - - - &a.dfr; - - - - &a.jesper; - - - - &a.msmith; - - - - &a.rwatson; - - - - &a.peter; - - - - - - - - FreeBSD の開発者たち - - (CVSの)commitする権利を持っていて, FreeBSD - のソースツリーについて 作業をおこなっている人々がいます. - すべてのコアチームのメンバはま た 開発者でもあります. - - - - &a.akiyama; - - - - &a.jmas; - - - - &a.will; - - - - &a.ugen; - - - - &a.toshi; - - - - &a.babkin; - - - - &a.dbaker; - - - - &a.jhb; - - - - &a.dmlb; - - - - &a.rvb; - - - - &a.dougb; - - - - &a.mike; - - - - &a.mbarkah; - - - - &a.tobez; - - - - &a.stb; - - - - &a.pb; - - - - &a.abial; - - - - &a.jb; - - - - &a.nbm; - - - - &a.mb; - - - - &a.bbraun; - - - - &a.jmb; - - - - &a.torstenb; - - - - &a.wilko; - - - - &a.jake; - - - - &a.dburr; - - - - &a.adrian; - - - - &a.dwcjr; - - - - &a.charnier; - - - - &a.jon; - - - - &a.luoqi; - - - - &a.ache; - - - - &a.ejc; - - - - &a.kjc; - - - - &a.cjh; - - - - &a.cjc; - - - - &a.nik; - - - - &a.archie; - - - - &a.chris; - - - - &a.alc; - - - - &a.cracauer; - - - - &a.dec; - - - - &a.pds; - - - - &a.adam; - - - - &a.brooks; - - - - &a.bsd; - - - - &a.jwd; - - - - &a.dillon; - - - - &a.mdodd; - - - - &a.dd; - - - - &a.iedowse; - - - - &a.gad; - - - - &a.dufault; - - - - &a.uhclem; - - - - &a.tegge; - - - - &a.deischen; - - - - &a.eivind; - - - - &a.julian; - - - - &a.rse; - - - - &a.ue; - - - - &a.ru; - - - - &a.se; - - - - &a.bde; - - - - &a.jasone; - - - - &a.sef; - - - - &a.jedgar; - - - - &a.green; - - - - &a.fenner; - - - - &a.lioux; - - - - &a.jfieber; - - - - &a.jfitz; - - - - &a.scrappy; - - - - &a.lars; - - - - &a.dirk; - - - - &a.sf; - - - - &a.shige; - - - - &a.billf; - - - - &a.furuta; - - - - &a.gallatin; - - - - &a.patrick; - - - - &a.tg; - - - - &a.gibbs; - - - - &a.brandon; - - - - &a.gioria; - - - - &a.graichen; - - - - &a.cg; - - - - &a.rgrimes; - - - - &a.jmg; - - - - &a.hanai; - - - - &a.roger; - - - - &a.mharo; - - - - &a.dannyboy; - - - - &a.thepish; - - - - &a.jhay; - - - - &a.sheldonh; - - - - &a.mikeh; - - - - &a.helbig; - - - - &a.ghelmer; - - - - &a.erich; - - - - &a.chm; - - - - &a.nhibma; - - - - &a.flathill; - - - - &a.orion; - - - - &a.pho; - - - - &a.horikawa; - - - - &a.hosokawa; - - - - &a.jeh; - - - - &a.hsu; - - - - &a.foxfair; - - - - &a.tom; - - - - &a.mph; - - - - &a.imura; - - - - &a.shin; - - - - &a.itojun; - - - - &a.iwasaki; - - - - &a.mjacob; - - - - &a.keith; - - - - &a.gj; - - - - &a.trevor; - - - - &a.phk; - - - - &a.tomsoft; - - - - &a.joe; - - - - &a.cokane; - - - - &a.kato; - - - - &a.kris; - - - - &a.kiri; - - - - &a.andreas; - - - - &a.lkoeller; - - - - &a.motoyuki; - - - - &a.jkoshy; - - - - &a.kuriyama; - - - - &a.alex; - - - - &a.chern; - - - - &a.reg; - - - - &a.jlemon; - - - - &a.truckman; - - - - &a.ijliao; - - - - &a.lile; - - - - &a.clive; - - - - &a.kevlo; - - - - &a.scottl; - - - - &a.ade; - - - - &a.jmacd; - - - - &a.smace; - - - - &a.bmah; - - - - &a.dwmalone; - - - - &a.mckay; - - - - &a.mckusick; - - - - &a.eric; - - - - &a.ken; - - - - &a.dinoex; - - - - &a.hm; - - - - &a.sanpei; - - - - &a.bmilekic; - - - - &a.mita; - - - - &a.non; - - - - &a.jim; - - - - &a.marcel; - - - - &a.dan; - - - - &a.tmm; - - - - &a.amurai; - - - - &a.markm; - - - - &a.rich; - - - - &a.knu; - - - - &a.nakai; - - - - &a.max; - - - - &a.newton; - - - - &a.rnordier; - - - - &a.davidn; - - - - &a.obrien; - - - - &a.danny; - - - - &a.okazaki; - - - - &a.olgeni; - - - - &a.ljo; - - - - &a.onoe; - - - - &a.marko; - - - - &a.gpalmer; - - - - &a.fsmp; - - - - &a.smpatel; - - - - &a.cp; - - - - &a.wpaul; - - - - &a.mp; - - - - &a.alfred; - - - - &a.roam; - - - - &a.wes; - - - - &a.cpiazza; - - - - &a.pirzyk; - - - - &a.jdp; - - - - &a.bp; - - - - &a.steve; - - - - &a.mpp; - - - - &a.markp; - - - - &a.darrenr; - - - - &a.csgr; - - - - &a.greid; - - - - &a.martin; - - - - &a.benno; - - - - &a.luigi; - - - - &a.paul; - - - - &a.roberto; - - - - &a.chuckr; - - - - &a.jesusr; - - - - &a.guido; - - - - &a.groudier; - - - - &a.dima; - - - - &a.asmodai; - - - - &a.ps; - - - - &a.sada; - - - - &a.hrs; - - - - &a.wsanchez; - - - - &a.nsayer; - - - - &a.sos; - - - - &a.wosch; - - - - &a.schweikh; - - - - &a.dick; - - - - &a.jseger; - - - - &a.semenu; - - - - &a.gshapiro; - - - - &a.shiba; - - - - &a.tshiozak; - - - - &a.simokawa; - - - - &a.vanilla; - - - - &a.silby; - - - - &a.shafeeq; - - - - &a.demon; - - - - &a.msmith; - - - - &a.ben; - - - - &a.nsouch; - - - - &a.issei; - - - - &a.des; - - - - &a.sobomax; - - - - &a.dcs; - - - - &a.brian; - - - - &a.mks; - - - - &a.stark; - - - - &a.murray; - - - - &a.sumikawa; - - - - &a.gsutter; - - - - &a.unfurl; - - - - &a.nyan; - - - - &a.tanimura; - - - - &a.taoka; - - - - &a.mtaylor; - - - - &a.dt; - - - - &a.mi; - - - - &a.yar; - - - - &a.cwt; - - - - &a.pst; - - - - &a.ume; - - - - &a.rv; - - - - &a.hoek; - - - - &a.nectar; - - - - &a.jayanth; - - - - &a.wjv; - - - - &a.bean; - - - - &a.swallace; - - - - &a.takawata; - - - - &a.assar; - - - - &a.dwhite; - - - - &a.nate; - - - - &a.wollman; - - - - &a.keichii; - - - - &a.joerg; - - - - &a.kbyanc; - - - - &a.uch; - - - - &a.yokota; - - - - &a.andy; - - - - &a.zarzycki; - - - - &a.phantom; - - - - &a.jmz; - - - - - - - FreeBSD ドキュメンテーションプロジェクト - - FreeBSD - ドキュメンテーションプロジェクトは複数のサービスを提供 - しています. それぞれのサービスは, 以下の担当者とその - 副担当者によって運用されています. - - - - ドキュメンテーションプロジェクト担当 - - - &a.nik; - - - - - ハンドブック編集担当 - - - &a.jim; - - - - - FAQ 編集担当 - - - &a.faq; - - - - - ニュースフラッシュ編集担当 - - - &a.jim; - - - - - - In the Press 編集担当 - - - &a.jkoshy; - - - - - FreeBSD Really-Quick NewsLetter編集担当 - - - Chris Coleman chrisc@vmunix.com - - - - - ギャラリーページ担当 - - - &a.phantom; - - - - - 商用ベンダーページ担当 - - - &a.phantom; - - - - - WEB 更新担当 - - - &a.www; - - - -]]> - - - ユーザグループ担当 - - - &a.grog; - - - - - FreeBSD プロジェクトおよびタスクリスト担当 - - - &a.asmodai; - - - - - FreeBSD Java プロジェクト - - - &a.patrick; - - - - - LinuxDoc から DocBook への移行 - - - &a.nik; - - - - - - - 担当者 - - - - - ドキュメンテーションプロジェクト担当 - - - &a.nik; - - - - - 起動ブロック - - - &a.rnordier;, &a.jhb; - - - - - ローダ - - - &a.jhb; - - - - - 国際化 - - - &a.ache; - - - - - - ポストマスタ - - - &a.jmb; - - - - - リリースコーディネータ - - - &a.jkh; - - - - - 広報および渉外担当 - - - &a.jkh; - - - - - - セキュリティ担当 - - - &a.kris; - - - - - - CVS ツリー管理者 - - - 責任者: &a.peter; - - 副責任者: &a.jdp; - - - - - - - ports コレクション担当 - - - &a.asami; - - - - - 標準化担当 - - - &a.wollman; - - - - - XFree86 Project, Inc. との渉外担当 - - - &a.rich; - - - - - - GNATS 管理者 - - - &a.steve; - - - - - diff --git a/ja_JP.eucJP/books/ppp-primer/Makefile b/ja_JP.eucJP/books/ppp-primer/Makefile deleted file mode 100644 index ebd1cb0888..0000000000 --- a/ja_JP.eucJP/books/ppp-primer/Makefile +++ /dev/null @@ -1,29 +0,0 @@ -# -# $FreeBSD$ -# -# FreeBSD Japanese Documentation Project -# Original revision: 1.1 -# -# Build the PPP PrimerQ -# - -MAINTAINER=doc@FreeBSD.org - -DOC?= book - -FORMATS?= html-split html - -INSTALL_COMPRESSED?= gz -INSTALL_ONLY_COMPRESSED?= - -# -# 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 - -DOC_PREFIX?= ${.CURDIR}/../../.. - -.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ja_JP.eucJP/books/ppp-primer/book.sgml b/ja_JP.eucJP/books/ppp-primer/book.sgml deleted file mode 100644 index 48f16bf17c..0000000000 --- a/ja_JP.eucJP/books/ppp-primer/book.sgml +++ /dev/null @@ -1,2378 +0,0 @@ - - -%entities; -]> - - - - - - - - - - -PPP - Pedantic PPP Primer - - - -Steve -Sims - -
SimsS@IBM.net
- - - - -$FreeBSD$ - -これは FreeBSD システムをローカル環境のダイアルアップルータ / -ゲートウェイとしてセットアップするためのステップアップガイドです. -内容は, 特に指定のない限り FreeBSD 2.2 以降のバージョンを想定しています. - - - - - -概要: - -FreeBSD 2.2 におけるユーザモード PPP -("IIJ-PPP" としても知られています) は, -現在ダイアルアップインターネット環境における Packet Aliasing をサポートしています. -この機能は, "Masquerading", -"IP Aliasing", そして -"Network Address Translation" としても -知られており, この機能を生かせば FreeBSD システムをイーサネットを基盤とした -ローカルエリアネットワーク (LAN) とインターネットサービスプロバイダ間の -ダイアルオンデマンドルータとして活用することができます. -LAN 上のシステムは FreeBSD システムを経由することにより, -単一のダイアルアップ接続を通してインターネットと情報を交換することが -できるのです. - -このガイドは - - - -FreeBSD システムをダイアルアウト接続できるように設定し, - - - -ダイアルアウト接続をネットワーク上の他のシステムと共用し, - - - -Windows システムが FreeBSD システムをインターネットへの -ゲートウェイとして用いる - - - -のための方法を説明しています. - - -このガイドは IP Aliasing の設定を助けることに重点を置いたものですが, -個々の構成要素をインストールし設定する時に必要となる具体例も含まれていますから, -どの章をとっても, FreeBSD でネットワークに関する様々な設定を行うときの -助けになるでしょう. - - - - -ローカルエリアネットワーク (LAN) をつくる - -ppp は通常 一台の ローカルな FreeBSD マシンに -サービスを提供するために設定されていますが, LAN に接続された資源とインターネット, -またはその他のダイアルアップサービス間の「ゲートウェイ」(または「ルータ」)として -使用することもできます. - - -典型的なネットワークトポロジ - -このガイドでは, 典型的なローカルエリアネットワークでは, -次のような接続を行っていると想定しています. - -+---------+ ----> ダイアルアップインターネット接続 -| FreeBSD | \ (例: So-net, Infoweb, RIMNET, 等) -| |-------- -| "Curly" | -| | -+----+----+ - | -|----+-------------+-------------+----| <-- イーサネットネットワーク - | | | - | | | -+----+----+ +----+----+ +----+----+ -| | | | | | -| Win95 | | WFW | | WinNT | -| "Larry" | | "Moe" | | "Shemp" | -| | | | | | -+---------+ +---------+ +---------+ - - - - - -ローカルエリアネットワークに関する想定 - -このガイド中のネットワークでは, 次のようなことを想定しています. - -三台のワークステーションとサーバはイーサネットでつながっています. - - - - -FreeBSD サーバ ("Curly") は 'ed0' として設定された - NE-2000 アダプタを使用しています. - - - -Windows-95 ワークステーション ("Larry") は Microsoft -「ネイティブ」な 32 ビット TCP/IP ドライバを使用しています. - - - -Windows for Wrokgroups ワークステーション ("Moe") は -Microsoft の 16 ビット TCP/IP エクステンションを使用しています. - - - -Windows NT ワークステーション ("Shemp") は Microsoft -「ネイティブ」な 32 ビット TCP/IP ドライバを使用しています. - - - - - -イーサネットで結ばれた LAN 内部での IP アドレスは, RFC-1597 -で提案された「予約」アドレスの中から選ばれています. -具体的には以下の通り. - - - - - - - 名前 - IP Address - 備考 - - - - - - Curly - 192.168.1.1 - FreeBSD マシン - - - - Larry - 192.168.1.2 - Win95 マシン - - - - Moe - 192.168.1.3 - WfW マシン - - - - Shemp - 192.168.1.4 - Windows NT マシン - - - - - -このガイドではモデムは FreeBSD マシンの一番目のシリアルポート -('/dev/cuaa0' DOS 用語では -'COM1:') に接続されているものとします. - -最後に, インターネットサービスプロバイダ (ISP) は PPP/FreeBSD -サイドと ISP サイドの両方に自動的に IP アドレスを割り当てるものとします. -(つまり, リンクの両端で動的 IP アドレス割り当てが行われます.) -PPP のダイアルアウトの設定の詳細については, 第 2 章 -「FreeBSD システムの設定」で扱います. - - - - - -FreeBSD システムの設定 - -ローカルエリアネットワーク (LAN) の統合を進める前に -FreeBSD マシンについて基本的な情報を三つ知っておく必要があります. - - - - - -FreeBSD システムのホスト名 (ガイドの例の中では "Curly"), - - - -ネットワークの設定, - - - -/etc/hosts ファイル. (ネットワーク内の -他のシステムの名前を IP アドレスをリストにしたもの) - - - - - -FreeBSD システムをネットワークインストールした場合, -これらの幾つかはすでに設定されている場合があります. - -インストール時に FreeBSD システムの設定を正しく行った自信がある場合でも, -後のステップでつまずかないよう, もう一度見直しておくと良いでしょう. - - - -FreeBSD のホスト名の確認 - -FreeBSD システムのインストール時に, マシンのホスト名が指定, -保存されている場合があります. -確認のため, 以下のコマンドをプロンプトから入力してください. - - - -# hostname - - - -FreeBSD システムのホスト名が表示されたはずです. -もしホスト名が正しければ (すぐわかるでしょ :-), - まで進んでください. - -例えば, ガイド中のネットワークでは, インストール中 / -後にホスト名を正しく設定していれば, 'hostname` コマンドは -'curly.my.domain' を返します. (ここでは ".my.domain" -の部分はあまり気にしないでください. それは後で片付けます. -ここで大事なのは最初のドットまでの部分です.) - -FreeBSD のインストール時にホスト名を設定していない場合, -たぶん 'myname.my.domain` という答が返ってくるはずです. -/etc/rc.conf を編集し, マシンに名前をつけてください. - - - -FreeBSD のホスト名を設定する - -念のため: システム設定ファイルを編集するためには -'root' でログインする必要があります! - -警告: システム設定ファイルにおかしな変更を -加えた場合, システムが正常に **起動しない** 可能性があります! -くれぐれもご注意を! - -ブート時に FreeBSD システムのホスト名を決定している設定ファイルは -/etc/rc.conf です. デフォルトのテキストエディタ -('ee') を使ってこのファイルを編集しましょう. - -ユーザ 'root' でログインし, 以下のコマンドを入力して -/etc/rc.conf をエディタに読み込みましょう. - - -# ee /etc/rc.conf - - - -矢印キーや scroll down を使って, FreeBSD システムのホスト名を -記述した部分を見つけましょう. デフォルトではこうなっているはずです. - ---- -### Basic network options: ### -hostname="myname.my.domain" # Set this! ---- - - -これを次のように変えましょう.(あなたの環境に合わせてください) - ---- -### Basic network options: ### -hostname="curly.my.domain" # Set this! ---- - - - -ホスト名を変更したら, 'Esc' キーを押してコマンドメニューを呼び出して下さい. -"leave editor" を選択し, 確認を求めてきたら "save changes" -を選びましょう. - - - - - -イーサネットインタフェイスの設定の確認 - -もう一度確認ですが, このガイドでは FreeBSD -システムのイーサネットインタフェイスとして 'ed0' -が用いられていると想定しています. これは NE-1000, NE-2000, -WD/SMC models 8003, 8013 と Elite Ultra (8216) -ネットワークアダプタがデフォルトで使用するものです. - -これ以外のネットワークアダプタは FreeBSD -では異なったデバイス名で参照されます. FAQ -をチェックして, ネットワークアダプタの記述を探してください. -アダプタのデバイス名が分からない場合は, FreeBSD FAQ を読んで, -使用中のカードのデバイス名を確かめ, 以下のステップで登場するデバイス名をその名前 -(例えば 'de0', -'zp0' など) に読み替えてください. - -ホスト名と同様, イーサネットインタフェイスも FreeBSD -システムのインストール時に設定されている場合があります. - -FreeBSD システムの (イーサネットその他の) -インタフェイスに関する設定を表示するために, -以下のコマンドを入力してください. - -# ifconfig -a - - -(フツーの言葉に直すと, 「うちのネットワークデバイスの -InterFace -CONFIGuration を見せて」って意味です) - -例えば... - -# ifconfig -a - ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu -1500 - inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 - ether 01:02:03:04:05:06 - lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 - tun0: flags=8050<POINTOPOINT,RUNNING, MULTICAST> mtu 1500 - sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552 - ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 - lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 - inet 127.0.0.1 netmask 0xff000000 -# _ - - - -この例では, 以下のデバイスが表示されました. - -ed0: イーサネットインタフェイス - -lp0: パラレルポートインタフェイス (このガイドでは触れません) - -tun0: 「トンネル」デバイス ユーザモード ppp が使うやつです! - -sl0: SL/IP デバイス (このガイドでは触れません) - -ppp0: もう一つの PPP デバイス (カーネル ppp 用. このガイドでは触れません) - -lo0: 「ループバック」デバイス (このガイドでは触れません) - -この例では, 'ed0' デバイスは「上がって」動作しています. -以下の表示がキーになります. - - - -このデバイスのステータスは "UP" で, - - - -インターネット ("inet") アドレス -(この例では 192.168.1.1) を持ち, - - - -有効なサブネットマスク ("netmask" 0xffffff00 は 255.255.255.0 -に等しい) を持ち, - - - -有効なブロードキャストアドレス (この例では 192.168.1.255) -を持っている. - - - - - -もしイーサネットカードに関する表示がこんな感じだったら, - -ed0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 - ether 01:02:03:04:05:06 - - -イーサネットカードはまだ設定されていません. - -イーサネットインタフェイスの設定が正しく行われているなら, - まで進んでください. - - - -イーサネットインタフェイスの設定 - -年のため: システム設定ファイルを編集するためには -'root' でログインする必要があります! - -警告: システム設定ファイルにおかしな変更を -加えた場合, システムが正常に **起動しない** 可能性があります! -くれぐれもご注意を! - -ブート時に FreeBSD -システムのネットワークインタフェイスの設定を決定している設定ファイルは -/etc/rc.conf です. デフォルトのテキストエディタ ('ee') -を使ってこのファイルを編集しましょう. - -ユーザ 'root' でログインし, 以下のコマンドを入力して -/etc/rc.conf をエディタに読み込みましょう. - - # ee /etc/rc.conf - -/etc/rc.conf の先頭から 20 行ほどの所に, -システムのブート時にアクティブにするネットワークインタフェイスを記述する節があります. -デフォルトの設定ファイルでは, 当該行は次のようになっています. - - - -network_interfaces="lo0" # List of network interfaces (lo0 is loopback). - - - -FreeBSD に 'ed0' という名前の -別のデバイスを加えることを伝えるには, -この行を修正する必要があります. この行を次のように変えてください. - - - -network_interfaces="lo0 ed0" # List of network interfaces (lo0 is loopback). - - - -(ループバックデバイス ("lo0") と -イーサネットデバイス ("ed0") の定義の間に -スペースを入れるのを忘れないでください!) - - 念のため: イーサネットカードの名前が -'ed0' でない場合, -きちんとその正しいデバイス名を指定してください - -FreeBSD をネットワークインストールした場合, - 'network_interfaces=' -の行がすでにイーサネットアダプタを参照している場合があります. その場合, -それが正しいデバイス名かどうかを確認してください. - -次に, イーサネットデバイス ('ed0') -インタフェイスの設定を行いましょう. - -アクティブにするインタフェイスの指定行の下に, -各インタフェイスに対する実際の設定を記述する行があります. -/etc/rc.conf のデフォルトでは, この一行があるだけです. - - - -ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. - - - -この下に 'ed0' デバイスの -設定を記述する行を加えましょう. - -FreeBSD をネットワークインストールした場合, -'ifconfig_ed0=' -の行がループバックデバイスの定義の下に存在する場合があります. -その場合, 記述された値が正しいものであるかどうか確認してください. - -このガイドでは, -ループバックデバイスの定義のすぐ次の行に次の一文を加えることにします. - - - -ifconfig_ed0="inet 192.168.1.1 netmask 255.255.255.0" - - - -/etc/rc.conf の編集が終わったとき, -ネットワークインタフェイスの記述と設定を行う行は, -だいたいこんな感じになっているはずです. - - - ---- -network_interfaces="ed1 lo0" # List of network interfaces (lo0 is loopback). -ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. -ifconfig_ed1="inet 192.168.1.1 netmask 255.255.255.0" ---- - - - -/etc/rc.conf の編集が終わったら, -'Esc' キーを押してコントロールメニューを呼び出して下さい. -"leave editor" を選択し, 確認を求めてきたら "save changes" -を選びましょう. - - - - - -パケットフォワーディングの有効化 - -デフォルトでは, FreeBSD システムは様々なネットワークインタフェイス間で -IP パケットのフォワードを行いません. 言い換えると, ルーティングの機能 -(ゲートウェイの機能とも言えます) は無効にされています. - -FreeBSD システムただ一台をインターネット用のワークステーションとして使用し, -LAN ノードと ISP 間とのゲートウェイとして使用しない場合は, - まで進みましょう. - -PPP プログラムを使用してローカルの FreeBSD マシンを LAN -のワークステーション (つまりルータ) としても機能させる場合は, -IP フォワーディングを有効にする必要があります. - -IP パケットのフォワーディングを有効にするためには -/etc/rc.conf を編集する必要があります. - - このファイルは /etc/defaults/rc.conf - によるデフォルト値を上書きします. - デフォルトゲートウェイの設定はそのファイルの - 以下の行で行われています. - - gateway_enable="NO" - - 上書きするには, 以下の様な行を - - gateway_enable="YES" - - /etc/rc.conf に追加します. - -注意: FreeBSD システムのインストール時に -IP フォワーディングが有効になっていた場合, すでに -'gateway_enable=YES' -という設定が行われている場合があります. - - - -他の LAN ホストのリスト (<filename>/etc/hosts</filename>) をつくる - -FreeBSD システムの LAN に関する設定の最後のステップは, -ローカルエリアネットワーク (LAN) -に接続された様々なシステムのホスト名と TCP/IP アドレスのリストをつくることです. -このリストは '/etc/hosts' の中に記述されます. - -デフォルトの状態では, このファイルにはホスト名が一つしか含まれていません. -ループバックデバイス ('lo0') のホスト名とアドレスです. -ネットワークに関する約束事にしたがって, このデバイス名はいつも "localhost" -と名付けられ, 127.0.0.1 という IP アドレスを持つことになっています -. - -/etc/hosts を編集するために, -以下のコマンドを入力してください. - - # ee /etc/hosts - - - -ファイルの終りまで一気に移動して, -(途中のコメントも気をつけて見ておきましょう. -有益な情報がいくつか書いてありますよ!) -LAN 上のホストの IP アドレスとホスト名を入力してください. -ガイド中のネットワークでは次のようになります. - -192.168.1.1 curly curly.my.domain # FreeBSD システム -192.168.1.2 larry larry.my.domain # Windows '95 システム -192.168.1.3 moe moe.my.domain # Windows for Workgroups -システム -192.168.1.4 shemp shemp.my.domain # Windows NT システム - - - -('127.0.0.1 localhost' -のエントリが書かれた行は変更する必要はありません.) - -入力を終えたら, 'Esc' キーを押してコントロールメニューを呼び出してください. -"leave editor" を選択し, 確認を求めてきたら "save changes" -を選びましょう. - - - - -FreeBSD システムのテスト - -おめでとう! これで FreeBSD システムはネットワークに接続された -UNIX システムとして設定されました. /etc/rc.conf -を変更した場合, ここで FreeBSD システムをリブートしてください. -これには二つの大きな目的があります. - - - -インタフェイスの設定に加えた変更を反映させ, - - - -システムが設定エラーを報告せずに再起動することを確かめるためです. - - - - - -システムのリブートが完了したら, -ネットワークインタフェイスのテストを行ってください. - - - -ループバックデバイスの動作点検 - -ループバックデバイスが正しく設定されているかどうか確かめるために, -'root' でログインしてこう入力してください. - -# ping localhost - - - -こういうメッセージが見えるはずです. - -# ping localhost -PING localhost.my.domain. (127.0.0.1): 56 data bytes -64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.219 ms -64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.287 ms -64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.214 m -[...] - - -このメッセージは Ctrl-C を押すまで延々流れ続けます. - - - - -イーサネットデバイスの動作点検 - -イーサネットデバイスが正しく設定されているかどうか確かめるために, -こう入力してください. - -# ping curly - - - -こういうメッセージが見えるはずです. - -# ping curly -PING curly.my.domain. (192.168.1.1): 56 data bytes -64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.219 ms -64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.200 ms -64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.187 ms -[...] - - - -この二つの例で大事なのは, ホスト名 (loopback と curly) が正しく -IP アドレス (127.0.0.1 と 192.168.1.1) -に関連づけられているのを確認することです. -これで /etc/hosts ファイルの内容が正しいかどうか確認できます. - -もし "curly" の IP アドレスが 192.168.1.1 ではない, あるいは -"localhost" のアドレスが 127.0.0.1 ではない場合, - まで戻って -/etc/hosts の内容を見直してください. - -ping コマンドの出力でホスト名とアドレスは正しく対応づけられているが, -何か他のエラーが表示されるなら, -インタフェイスの設定がうまく行っていないのでしょう. - まで戻って最初から確認し直してください. - -チェックが全部終わったら, つぎの章に進んでください. - - - - - - -PPP のダイアルアウト接続の設定 - -ppp ドライバには, 基本的には "Interactive" と "Automatic" -という二つの動作モードがあります. - -Interactive モードでは, - - - - - -手動で ISP に接続を確立し, - - - -ネットサーフィンを楽しんだり, -ファイルやメールを転送したりのなにやかやの後で, - - - -手動で ISP との接続を切断することになります. - - - - - -Automatic モードでは, PPP プログラムは FreeBSD -システムが内部的にどういう処理を行っているかじっと観察していて, -必要に応じて自動的に ISP と接続, 切断し, -あたかもネットワークがインターネットに直接接続されているかのように振る舞います. - -この章ではこの二つのモードのうち, `ppp` 環境を -"Automatic" モードで動作させる設定に重点を置いて説明します. - - - -オリジナルの PPP 設定ファイルをバックアップする - - - FreeBSD の最近のバージョンではサンプルファイルが - /usr/share/examples/ppp にありますので - この段階は不要です. - - -PPP 用のファイルに何か変更を加える前に, FreeBSD -システムのインストール時につくられたデフォルトのファイルのコピーを取っておきましょう. - -'root' でログインして, 次の手順を踏んでください. - -'/etc' ディレクトリに移ります. - -# cd /etc - -'ppp' ディレクトリ内のオリジナルのファイルのバックアップをつくります. - -# cp -R ppp ppp.ORIGINAL - -これで '/etc' ディレクトリの下に 'ppp' と -'ppp.ORIGINAL' という二つのサブディレクトリができました. - - - - -お手製の PPP 設定ファイルをつくる - -FreeBSD のインストール中に, たくさんの設定ファイルのサンプルが -/usr/share/examples/ppp ディレクトリの中につくられます. -少し時間を取ってファイルの内容を眺めてみてください. -これらのサンプルは実際の稼働例に基づいたもので, PPP -プログラムの機能や特長がよくあらわれています. - -これらのサンプルファイルを参考にし, -必要に応じて実際の設定に生かすことを強くお勧めします. - -`ppp` プログラムに関する詳細な情報がほしいなら, ppp の man を -読んでください. - -# man ppp - - - -PPP ダイアラで使われている `chat` -スクリプト言語に関する詳細な情報がほしいなら, -chat の man を読んでください. - -# man chat - - - -この章の残りの部分は PPP 関連のファイルのお勧め設定です. - - - -'<filename>/etc/ppp/ppp.conf</filename>' ファイル - -'/etc/ppp/ppp.conf' ファイルにはダイアルアウト PPP -接続に必要な設定と情報が含まれています. -このファイルには複数の接続の設定が含まれていてもかまいません. -FreeBSD ハンドブック (XXX URL? XXX) には, -このファイルの内容と文法に関する詳しい記述があります. - -この章では, -ダイアルアウト接続を行うための必要最小限の設定についてのみ説明します. - -下の /etc/ppp/ppp.conf ファイルは, ガイド中の LAN において, -ダイアルアウトインターネットゲートウェイの機能を提供するのに十分なものです. - - ppp.confの文法の完全なものは&man.ppp.8;に記述されています. -特に, コロンで終了しない行 (例えばdefault:やinteractive:), -!で始まるコマンド (例えば!include) はラベルではないことに注意してください. -また, コメントはインデントされなければいけないにも注意してください! - - -################################################################ -# PPP 設定ファイル ('/etc/ppp/ppp.conf') -# -# デフォルト設定; PPP が発動した時常に実行され, 全ての -# システム設定に適用される. -################################################################ -default: - set device /dev/cuaa0 - set speed 57600 - disable pred1 - deny pred1 - disable lqr - deny lqr - set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0M0 OK-AT-OK\\dATDT\\T TIMEOUT 40 CONNECT" - set redial 3 10 -# -# -################################################################ -# -# interactive モード用の設定: -# -# `ppp -alias interactive` で発動せよ. -# -################################################################ -interactive: - set authname _リモートシステムでのユーザ ID_ - set authkey _リモートシステムでのパスワード_ - set phone 1-800-123-4567 - set timeout 300 - set openmode active - accept chap -# -################################################################ -# -# demand-dial (automatic) モードではこの設定が使われる: -# -# 'ppp -auto -alias demand' で発動せよ. -# -################################################################ -demand: - set authname _リモートシステムでのユーザ ID_ - set authkey _リモートシステムでのパスワード_ - set phone 1-800-123-4567 - set timeout 300 - set openmode active - accept chap - set ifaddr 127.1.1.1/0 127.2.2.2/0 255.255.255.0 - add 0 0 127.2.2.2 -################################################################ - -# /etc/ppp/ppp.conf はこれでおしまい -このファイル - 実際のシステムから持ってきたものですが - には, -設定に関連する三つのセクションがあります. - - -"<emphasis remap="tt">default</emphasis>" セクション - -'default:' セクションには, -このファイルの他のどのセクションからも参照される値と設定がおさめられています. -このセクションの内容が, -暗黙の内に他のセクションの設定に書き加えられるものと考えておけば良いでしょう. - -ここは全てのダイアルアップセッションにおいて共通な -「グローバルなデフォルト設定」を置いておくのに丁度良い場所です. -例えばモデムの設定やダイアルの前準備等の, -通常接続先のシステムに応じて変更する必要のない設定を置くのに特に適しています. - -サンプルとして挙げた '/etc/ppp/ppp.conf' ファイルの -"default" セクションを一行づつ見ていきましょう. - -set device /dev/cuaa0 - - -この文は PPP プログラムに一番目のシリアルポートを使用するよう通知しています. -FreeBSD 下における '/dev/cuaa0' デバイスとは, DOS, Windows, -Windows 95 なんかで言うところの "COM1:" と同じポートのことです. - -モデムが COM2: につながれている場合は, -'/dev/cuaa1' を指定してください. COM3: の場合は -'/dev/cuaa2' です. - - - -set speed 57600 - - - -この文はシリアルポートとモデム間での送信 / 受信速度を設定しています. -この例で使用されているのは 28.8k のモデムですが, 値を 57600 に設定しておけば, -最近のモデムに組み込みのデータ圧縮機能のおかげでスループットが上がり, -シリアルリンク間でより高い転送速度を得ることができます. - -モデムとの通信に問題がある場合, この設定を 38400, -あるいは 19200 まで下げてみてください. - - - -disable pred1 -deny pred1 - - - -この二行は PPP プログラムの "CCP/Predictor type 1" -圧縮機能を無効にしています. 現在のバージョンの `ppp` -は draft Internet standards に従ったデータ圧縮法をサポートしていますが, -残念なことに, 多くの ISP -では, この機能をサポートしていない機器が使用されています. -どちらにせよ多くのモデムは実行時に圧縮を行っていますから, FreeBSD -側でこの機能を無効にし, リモート側がこの機能を要求してきた場合に拒否しても, -大してパフォーマンスは落ちないでしょう. - - - -disable lqr -deny lqr - - - -この二行は Point-to-Point protocol (PPP) の完全な仕様の一部である -"Line Quality Reporting" (回線品質報告) 機能を制御しています. -(詳細は RFC-1989 を参照してください.) - -一行目 "disable lqr" -は回線の品質状態をリモートエンドのデバイスへ報告しないよう, -PPP プログラムに命じています. - -二行目, "deny lqr" はリモートエンドからの回線品質報告要求を拒否するよう, -PPP プログラムに命じています. - -最近のダイアルアップ用のモデムには大抵自動エラー検出 / -訂正機能がついていますし, -LQR 報告機能は多くのベンダの製品で完全には実装されていませんから, -通常はこの二行をデフォルト設定に加えておいても大丈夫でしょう. - - - -set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0M0 -OK-AT-OK\\dATDT\\T TIMEOUT 40 CONNECT" - - - -注意: (このドキュメントでは改行が入っているように見えるかもしれませんが, -実際にはこの文の途中で改行を入れないでください.) - -この行は PPP プログラムにモデムのダイアル法と, -以下のようなダイアル時の基本的なガイドラインを指定しています. - - - -モデムが "BUSY" リザルトコードを返した場合, -ダイアル試行は失敗したものとし, - - - -モデムが "NO CARRIER" -リザルトコードを返した場合もダイアル試行は失敗したものとし, - - - -PPP プログラムは以下のイベント各々が 5 -秒間のタイムアウト期間内に終了するものと想定する. - - - -初期状態では, PPP プログラムはモデムに対して何も想定していない -(上の例の \"\" の部分で指定されている) - - - -プログラムはモデムにモデム初期化文字列 "ATE1Q0M0" -を送り, "OK" という返事が返ってくるのを待つ. レスポンスが帰ってこない場合, -プログラムはモデムに attention コマンド ("AT") を送り, -再び "OK" という返事が返ってくるのを待つ. - - - -プログラムは一秒間待ち時間を入れ ("\\d" の部分で指定されている), -モデムにダイアリング文字列を送る. "ATDT" -はトーンダイアリングを用いてダイアルを行う場合の標準モデムコマンドであり, -回線がトーンダイアルではない場合, "ATDT" を "ATDP" と置換する必要がある. -"\\T" 文字列は実際の電話番号が入る場所である ("set dial 123-4567" -で指定された値が自動的に挿入される). - - - - - - - -最後に, (最大) 40 秒のタイムアウトの前に, PPP プログラムはモデムが -"CONNECT" リザルトコードを返すと想定している. - - - - - -この対話におけるいかなる時点での失敗もダイアリングの失敗と解釈され, -PPP プログラムは接続に失敗します. - -(PPP ダイアラで使用されているミニスクリプト言語の詳細については -"chat" の man を参照してください.) - - - -set redial 3 10 - - -この行はダイアル接続を直ちに確立することができなかった場合, -リダイアルまで 10 秒の間隔を挟んで (必要な場合は 3 回まで) -再試行するよう, PPP プログラムに指定しています. - - - - -"<emphasis remap="tt">interactive</emphasis>" セクション - -'interactive:' セクションには, -特定のリモートシステムと「対話的 (interactive)」に -PPP セッションを確立するときに使用される値と設定がおさめられています. -このセクションの設定には, "default" セクションの内容が自動的に追加されます. - -このガイド中の "interactive" セクションの例では, -接続先のリモートシステムは, -何らかの風変わりなスクリプト言語を使用しないでもユーザ認証を行うことができるものと想定しています. -つまり, このサンプルでは接続を確立するために CHAP プロトコルを使用します. - -おおざっぱに言うと, もし Windows95 -のダイアラの「接続」ボタンを押しただけで接続が確立できる環境なら, -このサンプルはうまく働きます. - -一方, もし Microsoft Windows95 のダイアルアップネットワーク機能を利用して -ISP に接続するとき, Microsoft Plus! -の「ダイアルアップスクリプトツール」に頼るか, Windows 95 -の接続オプションで「ダイアル後にターミナルウィンドウを表示する」を選択しなければならない場合, -ISP と接続を行うためには, PPP 設定ファイルのサンプルや ppp の man で -"expect / response" スクリプトの例を参考にする必要があるでしょう. -"set login" コマンドはそのような目的に使用できます. - -まあ、それよりも PAP / CHAP 認証を提供している ISP -を探した方が良いかもしれませんけどね! - -この設定例は, 以下のプロパイダと接続するために使えることが分かっています. - - - -Various Shiva LanRovers - - - -The IBM Network (http://www.ibm.net/) - - - -AT&T WorldNet (http://att.com/worldnet/) - - - -Erol's (http://www.erols.com/) - - - - - -サンプルとして挙げた '/etc/ppp/ppp.conf' ファイルの -"interactive" セクションを一行づつ見ていきましょう. - - - -set authname _リモートシステムでのユーザ ID_ - - -リモートシステムでログイン時に使用する名前を指定します. - - - -set authkey _リモートシステムでのパスワード_ - - -リモートシステムで使用するパスワードです. - - - -set phone 1-800-123-4567 - - -リモートシステムの電話番号です. PBX (Private Branch eXchange, 構内交換機) -の内部にいる場合は, 9, を番号の前に加えることができます. - - - -set timeout 300 - - -300 秒 (5 分) 間データが流れなかった場合, 自動的に回線を切断するよう PPP -プログラムに命じています. この値は必要に応じて変更することができます. - - - -set openmode active - - -モデムが接続したらすぐに交渉を試みるよう PPP -プログラムに命じています. 自動的にこれを行うリモートサイトもありますが, -自分からは行わないサイトもあります. -このオプションを使えば, -リンクのこちら側でイニシアチブを取って接続確立を試みることができます. - - - -accept chap - - -ユーザ認証に "Challenge-Handshake Authentication Protocol" -を用いるよう PPP プログラムに命じています. ローカル側とリモート側でユーザ ID -とパスワードとしてやり取りされる値は, 上の 'authname' と 'authkey' -のエントリからとられます. - - - - -"<emphasis remap="tt">demand</emphasis>" セクション - -特定のリモートサイトと「ダイアル・オン・デマンド」な PPP -セッションを確立するときに使用される値と設定がおさめられています. -このセクションの設定にも, "default" セクションの内容が自動的に追加されます. - -最後の二行を除いて, このセクションの設定は "interactive" -モードの設定で用いられているのと全く同じものです. - -前の方でも述べているように, このガイド中にあらわれる -"demand" セクションの例では, 接続先のリモートシステムは CHAP -プロトコルを利用した接続確立法を理解できるものと想定しています. - -サンプルとして挙げた '/etc/ppp/ppp.conf' ファイルの -"demand" セクションを一行づつ見ていきましょう. - - - -set authname _リモートシステムでのユーザ ID_ - - -リモートシステムでログイン時に使用する名前を指定します. - - - -set authkey _リモートシステムでのパスワード_ - - -リモートシステムで使用するパスワードです. - - - -set phone 1-800-123-4567 - - -リモートシステムの電話番号です. - - - -set timeout 300 - - - -300 秒 (5 分) 間データが流れなかった場合, 自動的に回線を切断するよう PPP -プログラムに命じています. この値は必要に応じて変更することができます. - - - -set openmode active - - - -モデムが接続したらすぐにネゴジェーションを試みるよう PPP -プログラムに命じています. 自動的にこれを行うリモートサイトもありますが, -自分からは行わないサイトもあります. -このオプションを使えば, -リンクのこちら側でイニシアチブを取って接続確立を試みることができます. - - - -accept chap - - - -ユーザ認証に "Challenge-Handshake Authentication Protocol" -を用いるよう PPP プログラムに命じています. ローカル側とリモート側でユーザ ID -とパスワードとしてやり取りされる値は, 上の 'authname' と 'authkey' -のエントリからとられます. - - - -set ifaddr 127.1.1.1/0 127.2.2.2/0 255.255.255.0 - - - -PPP リンクのローカル側とリモート側の「偽の」 IP アドレスのペアを設定し, -ローカル側の 'tun0' (トンネル) デバイス -に 127.1.1.1 の, リモート側には -127.2.2.2 の IP アドレスを生成するように PPP プログラムに命じています. -両方のアドレスに '/0' をつけておけば, -それらのアドレスの先頭から 0 ビットまでが重要な部分で, -残りの部分はリンクが確立されたときに, -ローカル側とリモート側のシステムの交渉によって変更してもよい -(というか, この場合は必ず変更されなければならない) と PPP -プログラムに教えることができます. -255.255.255.0 という文字列は, -それらの仮想デバイス間に適用されるサブネットマスク値を -PPP プログラムに教えています. - -注意. この例では ISP がリンクの両端に対して IP -アドレスを動的に提供するものと想定しています! もし ISP -からローカル側で使用すべき具体的な IP アドレスの割り当てを受けている場合, -127.1.1.1 の代わりにその IP アドレスを入力してください. - -逆に, ISP がリモート側で使用する具体的な IP アドレスを指定している場合, -127.2.2.2 の代わりにその IP アドレスを入力してください. - -これらの場合においても, 各アドレスの後ろの '/0' -を残しておくのが良い考えでしょう. -もしそれらのアドレスが実際に変更された場合でも, -PPP プログラムはその変更に対応することができるからです. - - - -add 0 0 127.2.2.2 - - - -最後の行では, ISP システムの (偽の) IP アドレスを指す -IP トラフィックのデフォルトルートを追加するよう, -PPP プログラムに命じています. - -注意: 前の行で 127.2.2.2 の代わりに ISP -に指定されたアドレスを用いている場合, ここでも 127.2.2.2 -の代わりにその番号を使用してください. - -この「偽」の IP トラフィックルートを追加しておけば, -アイドル中の PPP プログラムは以下の動作を自動的に行うことができます. - - - -ISP と「自動的に」 接続を確立し, - - - -リンクのローカル側とリモート側の IP アドレスを再設定し, - - - -ローカルのマシンと ISP 間でパケットを転送する. - - - - - -"default" セクションの timeout の値に指定された秒間 TCP/IP -のトラフィックが流れなかった場合, -PPP プログラムは自動的にダイアルアップ接続を切断し, -始めの状態に戻ります. - - - - - -'<filename>/etc/ppp/ppp.linkup</filename>' ファイル - -PPP の設定を完全にするために必要なもう一つのファイルが -'/etc/ppp/ppp.linkup' です. -このファイルにはダイアルアップリンクが確立した後に, -PPP プログラムが実行すべき命令が含まれています. - -ダイアルアップ接続の場合, PPP プログラムはリモート側の偽の IP アドレス -(前の章の例では 127.2.2.2) に対して生成されたデフォルトルートを削除し, -(ダイアルアップ接続の確立中にわかる) 実際のリモートエンドの IP -アドレスを指す新しいデフォルトルートをインストールする必要があります. - -典型的な '/etc/ppp/ppp.linkup' ファイル: - -#########################################################################= - -# PPP Link Up File ('/etc/ppp/ppp.linkup') -# -# このファイルは PPP がネットワーク接続を確立した後でチェックされます. -# -# このファイルは以下の順序で検索されます. -# -# 1) まず, ローカル側に割り当てられた IP アドレスが検索され, -# 関連するコマンドが実行されます. -# -# 2) IP アドレスが見つからない場合, PPP の起動時に指定されたラベル名が -# 検索され, 関連するコマンドが実行されます. -# -# 3) いずれの場合にも当てはまらない場合, 'MYADDR:' ラベルの下の -# コマンドが実行されます. -# -#########################################################################= - -# -# このセクションは /etc/ppp/ppp.conf 内の "demand" の設定で -# 使用される. -demand: - delete ALL - add 0 0 HISADDR -# -# /etc/ppp/ppp.conf 中の他の全ての設定ではこちらを用いる -# -MYADDR: - add 0 0 HISADDR -######################################################################## -# End of /etc/ppp/ppp.linkup - - -'/etc/ppp/ppp.conf' で使用されているのと全く同じ "demand:" -というタグのセクションがあることに注意して下さい. -このセクションでは, "demand" の設定を用いてリンクが確立された場合, - - - -PPP プログラムが生成した全ての IP ルーティング情報を削除し, - - - -リモートエンドの実際のアドレスをデフォルトルートに追加する - - - - -よう, PPP プログラムに命じています. - -'/etc/ppp/ppp.conf' 内で 'set ifaddr' や 'add 0 0' -を使用している設定 (つまり, ダイアルオンデマンドの設定) においては, -/etc/ppp/ppp.linkup 内で "delete ALL" や "add 0 0 HISADDR" -コマンドを実行することが重要になります. - -これこそがリンクのオンデマンド設定を制御するメカニズムだからです. - -/etc/ppp/ppp.linkup 内で明示的に名前を指定されていない設定は, -"MYADDR:" セクションにあるコマンドを (それが何であれ) 実行します. -非デマンドダイアルの設定 (例えばサンプルの "interactive:") -はこれに該当します. このセクションでは, ISP (リモートエンド) の IP -アドレスをデフォルトルートに追加しているだけです. - - - - - -IP Aliasing - -今までのステップは, ISP にダイアルアップで接続しようとしているどのような -FreeBSD システムにとっても共通のものです. - -もしこのガイドを読む目的が FreeBSD とインターネットをダイアルアウト -ppp で接続することだけである場合, - まで進んでください. - -PPP プログラムをオンデマンドモードで動かす非常に大きな利点の一つは, -プログラムがローカルエリアネットワーク (LAN) 上の他のシステム間の IP -トラフィックを自動的にルーティングできる点にあります. -この機能は "IP Aliasing", -"Network Address Translation", "Address Masquerading" または -"Transparent Proxying" などの様々な名前で知られています. - -しかしながら, どのような呼び名が使用されるにせよ, -このモードは自動的に得られるものではありません. PPP -プログラムをごく普通に起動した場合, プログラムは LAN -のインタフェイスとダイアルアウト接続間でパケットを転送しません. -要するに, FreeBSD システムだけが ISP に接続され, -他のワークステーションはその接続を「共用」することができないのです. - -プログラムが以下のコマンドのいずれかで起動されたとしましょう. - -# ppp interactive (Interactive mode) - - または - -# ppp -auto demand (Dial-on-Demand mode) - -すると, システムは FreeBSD マシンに対してのみ, -インターネットに接続されたワークステーションとしての機能を提供するでしょう. - -PPP プログラムを LAN の資源とインターネット間のゲートウェイとして起動するには, -代わりに以下のコマンドのいずれかを使用してください. - -# ppp -alias interactive (Interactive mode) - - または - -# ppp -auto -alias demand (Dial-on-Demand mode) - -また, ``alias enable yes'' というコマンドを ppp -の設定ファイルにいれておく方法をとることもできます -(詳細については man をご覧ください). - - に進んでも, -このことは忘れないでおいてください. - - - - - -Windows システムの設定 - -第 1 章で説明したように, ガイド中のネットワークはローカルエリアネットワーク -(LAN) 間のゲートウェイ (ルータ) として FreeBSD システム ("Curly") -を使用しています. -LAN 自体は二系統の Windows ワークステーションで構成されていますが, -LAN のノードが Curly をルータとして使用するには, -各ノードが適切に設定される必要があります. -このセクションは Windows ワークステーションのダイアルアップネットワークの -設定法を説明するものではありません. そちらの説明をお捜しなら, -http://www.aladdin.co.uk/techweb/ をお勧めします. - - - -Windows 95 の設定 - -Windows 95 を LAN に接続された資源として設定するのは比較的簡単です. -Windows 95 のネットワークの設定で ISP に対するデフォルトのゲートウェイとして -FreeBSD システムを使用するよう変更するだけで済むからです. -以下の手順を踏んでください. - -Windows 95 用の "hosts" ファイルをつくる - -LAN 上の他の TCP/IP システムに接続するためには, - で -FreeBSD システムにインストールした "hosts" -ファイルとまったく同じものを作成してやる必要があります. - - - - - -「スタート」ボタンを押し,「ファイル名を指定して実行」を選択して -"notepad \WINDOWS\HOSTS" (引用符は除いてください) と入力し, -「OK」ボタンを押してください. - - - -エディタが開いたら, の hosts -ファイルに書いてあるアドレスとシステム名を入力してください. - - - -編集が終わったらノートパッドを閉じてください -(ファイルをセーブするのをお忘れ無く!). - - - - - -Windows 95 の TCP/IP ネットワークの設定 - - - - - -タスクバーの「スタート」ボタンを押し, -「設定」「コントロールパネル」を選択してください. - - - -「ネットワーク」アイコンをダブルクリックして開いてください. - - -ネットワークのすべての構成要素に対する設定が表示されます. - - - -「ネットワークの設定」 タブを選択し, -現在のネットワーク構成の中から "TCP/IP->インタフェイスのタイプ" -を選択してください ("インタフェイスのタイプ" の部分には, -あなたのシステムのイーサネットの名称かタイプが入ります). - - -TCP/IP がネットワーク構成に入っていない場合は, -次の作業に進む前に「追加」ボタンを押し, TCP/IP をインストールしてください. - -(ヒント: 「追加」「プロトコル」「Microsoft」「TCP/IP」「OK」) - - - -「プロパティ」ボタンを押し, TCP -コンポーネント関連の設定を表示させて下さい. - - - - - -IP アドレス情報の設定 - - - -「IP アドレス」のタブをクリックし - - - -「IP アドレスを指定」ラジオボタンをクリックしてください. - - -(ガイド中の LAN では Windows 95 システムは "Larry" -という名前です.) - - - -「IP アドレス」のフィールドに "192.168.1.2" を入力してください. - - - -「サブネット マスク」フィールドに 255.255.255.0 を入力してください. - - - - - -ゲートウェイの情報の設定 - - - - - -「ゲートウェイ」タブをクリックしてください. - - -ガイド中のネットワークでは, FreeBSD -マシンがインターネットへのゲートウェイとして働き, -イーサネットで結ばれた LAN と PPP -ダイアルアップ接続間でパケットをルーティングします. -FreeBSD のイーサネットインタフェイスの IP アドレス, 192.168.1.1 -を「新しいゲートウェイ」フィールドに入力し, 「追加」ボタンを押してください. -他のゲートウェイが「インストール済のゲートウェイ」リスト内に定義されているなら, -削除しておいたほうが良いかもしれません. - - - - - -DNS 情報の設定 - -このガイドでは, インターネットサービスプロバイダ (ISP) -が利用可能なドメインネームサーバ (または「DNS サーバ」) -のリストを提供しているものと想定しています. ローカル側の FreeBSD -システム上で DNS サーバを走らせたいなら, -第 6 章「熱心な学習者への練習問題」に DNS を FreeBSD -システム上でセットアップする時の tips がありますので参照してみてください. - - - - - -「DNS 設定」のタブをクリックしてください - - - -「DNS を使用する」のラジオボタンが選択されているかどうか確認してください. - - -(このボタンが選択されていない場合, アクセスできるのは hosts -ファイルに書かれたエントリだけなので, -ネットサーフィンをしようとしてもうまく行きません!) - - - -「ホスト名」フィールドに Windows 95マシンの名前を入力してください. -このガイドでは "Larry" です. - - - -「ドメイン名」フィールドにローカルネットワーク名を入力してください. -このガイドでは "my.domain" です. - - - -「DNS サーバの検索順」セクションに ISP の -DNS サーバの IP アドレスを入力してください. 一つ入力するごとに "Add" -ボタンを押して, -この作業を ISP の提供するアドレスをすべて入力するまで続けてください. - - - - - -その他の Windows 95 の TCP/IP オプション - -このガイドでは, -「詳細設定」「WINS 設定」「バインド」のタブの下にある設定は重要ではありません. - -Windows Internet Naming Service ("WINS") を使用したいなら, -http://www.localnet.org/ へ行ってみましょう. WINS の設定, -特にインターネット透過でのファイル共有に関する詳細な情報が得られます. - -後始末 - - - -「OK」ボタンを押して TCP/IP プロパティのウィンドウを閉じてください. - - - -「OK」ボタンを押してネットワークコントロールパネルを閉じてください. - - - -要求された場合, コンピュータをリブートしてください. - - - - - -これでおしまいです! - - - - -Windows NT の設定 - -Windows NT を LAN の資源として設定するのも比較的簡単です. -Windows NT を設定する手順は, ユーザインタフェイスの些細な差異を除けば -Windows 95 と似ています. - -ここでの手順は Windows NT 4.0 ワークステーション用のものですが, -原則的には NT 3.5x でも同じです. Windows NT 3.5x を使用している場合, -「Windows for Workgroups の設定」を参照するのも良いかもしれません. -NT 3.5 と WfW はユーザインタフェイスが同じだからです. - -次の手順を踏んでください. - -Windows NT 用の "hosts" ファイルをつくる - -LAN 上の他の TCP/IP システムに接続するためには, 3.4 章で -FreeBSD システムにインストールした "hosts" -ファイルとまったく同じものを作成してやる必要があります. - - - - - -「スタート」ボタンを押し, 「ファイル名を指定して実行」を選択して -"notepad \WINNT\SYSTEM32\DRIVERS\ETC\HOSTS" (引用符は除いてください) -と入力し, 「OK」ボタンを押してください. - - - -エディタが開いたら, 3.4 章の hosts -ファイルに書いてあるアドレスとシステム名を入力してください. - - - -編集が終わったらノートパッドを閉じてください -(ファイルをセーブするのをお忘れ無く!). - - - - - -Windows NT の TCP/IP ネットワークの設定 - - - - - -タスクバーの「スタート」ボタンを押し, -「設定」「コントロールパネル」を選択してください. - - - -「ネットワーク」アイコンをダブルクリックして開いてください. - - - -"Identification" タブを選択し, "Computer Name" と "Workgroup" -フィールドの内容を確かめてください. -このガイドでは "Shemp" を名前に, "Stooges" をワークグループに使用します. -必要に応じて "Change" ボタンを押し, 内容を修正してください。 - - - -"Protocols" タブを選択してください. - - -インストール済のネットワークプロトコルが表示されます. -プロトコルが幾つも表示されるかもしれませんが, このガイドで大事なのは -「TCP/IP プロトコル」だけです. 「TCP/IP プロトコル」が表示されていない場合, -「追加」ボタンを押してこのプロトコルを読み込んでください. - -(ヒント:「追加」「TCP/IP プロトコル」「OK」) - - - -「TCP/IP プロトコル」を選択し, 「プロパティ」ボタンを押してください. - - -TCP/IP の様々な設定を行うためのタブが表示されるはずです. - - - - - -IP アドレスの設定 - -イーサネットインタフェイスが「アダプタ」ボックスの中に表示されているかどうか確かめてください. -表示されていない場合, -アダプタの一覧表をスクロールさせて正しいインタフェイスを探してください. - - - -「IP アドレスを指定する」ラジオボタンを押して, -三つのテキストボックスを有効にしてください. - - -ガイド中の LAN では, Windows NT システムは "Shemp" -という名前です - - - -「IP アドレス」フィールドに "192.168.1.4" を入力してください. - - - -「サブネットマスク」フィールドに 255.255.255.0 を入力してください. - - - - - -ゲートウェイの情報の設定 - -ガイド中のネットワークでは, FreeBSD -マシンがインターネットへのゲートウェイとして働き, -イーサネットで結ばれた LAN と PPP -ダイアルアップ接続間でパケットをルーティングします. - - - -FreeBSD のイーサネットインタフェイスの IP アドレス, 192.168.1.1 -を「新しいゲートウェイ」フィールドに入力し, 「追加」ボタンを押してください. - - -他のゲートウェイが「インストール済のゲートウェイ」リスト内に定義されているなら, -削除しておいたほうが良いかもしれません. - - - - - -DNS の設定 - -繰り返しますが, このガイドでは, インターネットサービスプロバイダ (ISP) -が利用可能なドメインネームサーバ (または「 DNS サーバ」) -のリストを提供しているものと想定しています. - -ローカル側の FreeBSD システム上で DNS サーバを走らせたいなら, -第 6 章「熱心な学習者への練習問題」に DNS を FreeBSD -システム上でセットアップする時の tips がありますので参照してみてください. - - - - - -「DNS」タブをクリックしてください. - - - -「ホスト名」フィールドに Windows NT マシンの名前を入力してください. -このガイドでは "Shemp" です. - - - -「ドメイン名」フィールドにローカルネットワーク名を入力してください. -このガイドでは "my.domain" です. - - - -「DNS サーバの検索順」セクションに ISP の -DNS サーバの IP アドレスを入力してください. 一つ入力するごとに "Add" -ボタンを押して, -この作業を ISP の提供するアドレスをすべて入力するまで続けてください. - - - - - -その他の Windows NT の TCP/IP オプション - -このガイドでは, -"WINS Address" と "Routing" タブの下にある設定は使用しません. - -Windows Internet Naming Service ("WINS") を使用したいなら, -http://www.localnet.org/ へ行ってみましょう. WINS の設定, -特にインターネット透過でのファイル共有に関する詳細な情報が得られます. - -後始末 - - - -「OK」ボタンを押して TCP/IP プロパティセクションを閉じてください. - - - -「閉じる」ボタンを押してネットワークコントロールパネルを閉じてください. - - - -要求された場合, コンピュータをリブートしてください. - - - - - -これでおしまいです! - - - - -Windows for Workgroups の設定 - -Windows for Workgroups をネットワーククライアントとして作動させるには, -Microsoft TCP/IP-32 -ドライバディスクがワークステーションにインストールされている必要があります. -TCP/IP ドライバは WfW の CD / ディスクには付属していません. -コピーは ftp://ftp.microsoft.com:/peropsys/windows/public/tcpip/ -から手に入ります. - -TCP/IP ドライバを読み込んだら、次の手続きを踏んでください. - -Windows for Workgroups 用の "hosts" ファイルをつくる - -LAN 上の他の TCP/IP システムに接続するためには, 3.4 章で -FreeBSD システムにインストールした "hosts" -ファイルとまったく同じものを作成してやる必要があります. - - - -プログラムマネージャで "File" ボタンを押し, "Run" を選択して -"notepad \WINDOWS\HOSTS" (引用符は除いてください) と入力し, -"OK" ボタンを押してください. - - - -エディタが開いたら, 3.4 章の hosts -ファイルに書いてあるアドレスとシステム名を入力してください. - - - -編集が終わったらノートパッドを閉じてください -(ファイルをセーブするのをお忘れ無く!). - - - - - -Windows for Workgroups の TCP/IP ネットワークの設定 - - - - - -プログラムマネージャのメインウィンドウで, -"Network" グループのアイコンをダブルクリックして開いてください. - - - -"Network Setup" アイコンをダブルクリックしてください. - - - -"Network Drivers Box" で "Microsoft TCP/IP-32" -のエントリをダブルクリックしてください. - - - - - -Windows for Workgroups の IP アドレスの設定 - -正しいイーサネットインタフェイスが "Adapter" -リストで選択されているかどうか確認してください. 選択されていない場合, -インタフェイスが表示されるまでリストをスクロールさせ, -クリックして選択してください. - - - -"Enable Automatic DHCP Configuration" -チェックボックスが選択されていないことを確かめてください. 選択されている場合, -クリックして "X" 印を取り除いてください. - - - -ガイド中の LAN では, Windows for Workgroups システムは "Moe" -という名前です. "IP Address" フィールドには "192.168.1.3" を入力してください. - - - -"Subnet Mask" フィールドに 255.255.255.0 を入力してください. - - - - - -ゲートウェイの情報の設定 - -ガイド中のネットワークでは, FreeBSD -マシンがインターネットへのゲートウェイとして働き, -イーサネットで結ばれた LAN と PPP -ダイアルアップ接続間でパケットをルーティングします. - - - - - -FreeBSD システムの IP アドレス, 192.168.1.1 を "Default Gateway" -フィールドに入力してください. - - - - - -DNS の設定 - -繰り返しますが, このガイドでは, インターネットサービスプロバイダ (ISP) -が利用可能なドメインネームサーバ (または「DNS サーバ」) -のリストを提供しているものと想定しています. -ローカル側の FreeBSD システム上で DNS サーバを走らせたいなら, -第 6 章「インターネット初心者への課題」に DNS を FreeBSD -システム上でセットアップする時の tips がありますので参照してみてください. - - - -"DNS" ボタンを押してください. - - - -"Host Name" フィールドに Windows for Workgroups -マシンの名前を入力してください. このガイドでは "Moe" です. - - - -"Domain" フィールドにローカルネットワーク名を入力してください. -このガイドでは "my.domain" です. - - - -"Domain Name Service (DNS) Search Order" セクションに ISP の -DNS サーバの IP アドレスを入力してください. 一つ入力するごとに "Add" -ボタンを押して, -この作業を ISP の提供するアドレスをすべて入力するまで続けてください. - - - - - -後始末 - - - -"OK" ボタンを押して TCP/IP 設定ウィンドウを閉じてください. - - - -"OK" ボタンを押してネットワークセットアップウィンドウを閉じてください. - - - -要求された場合, コンピュータを再起動してください. - - - - - -これでおしまいです! - - - - - -ネットワークのテスト - -上記の作業を適切に完了したなら, -PPP をインターネットへのゲートウェイとして機能させることができるはずです. - - - -ダイアルアップリンクのテスト - -最初に, モデムと ISP 間で接続を確立できるかどうかテストします. - - - - -イーサネット LAN のテスト - - *** TBD *** - - - - - -熱心な学習者への練習問題 - - - -ミニ DNS システムの作成 - -確かにドメインネームサービス (DNS) -ヒエラルキーの管理は黒魔術にも似た作業ではありますが, -FreeBSD システムを ISP へのゲートウェイとして作動させながら, -同時に小さな DNS サーバとしても働かせることも可能なのです. - -FreeBSD システムのインストール時に /etc/namedb -ディレクトリに作成されるファイルを元にすれば, -ガイド中のネットワークに権威を持ちながら, -インターネットの DNS -アーキテクチャに対する正面玄関としての役割も果たすネームサーバをつくることができるのです. - -最小限の DNS の設定を行うには, 以下の三つのファイルが必要になります. - -/etc/namedb/named.boot -/etc/namedb/named.root -/etc/namedb/mydomain.db - - - -/etc/namedb/named.root ファイルは FreeBSD -のベースインストールの一部として自動的にインストールされますが, -他の二つのファイルは手で書いてやる必要があります. - - - -<filename>/etc/namedb/named.boot</filename> ファイル - -/etc/namedb/named.boot ファイルは DNS -サーバのスタートアップ時の設定をコントロールします. -基本的には, ネームサーバに以下の情報を伝えます. - - - -どこに設定ファイルが存在し, - - - -どの「ドメイン名」を管理するのか. そして - - - -どこへ行けば他の DNS サーバを見つけられるのか. - - - - - - 'ee' エディタを使って, 以下の内容の -/etc/namedb/named.boot ファイルをつくってください. - -; boot file for mini-name server - -directory /etc/namedb - -; type domain source host/file backup file - -cache . named.root -primary my.domain. mydomain.db - - - -セミコロンで始まる行はコメントです. このファイル内で重要な行は - - - -directory /etc/namedb - - -ネームサーバに '/etc/namedb/named.boot' -の残りのセクションで参照される設定ファイルの存在するディレクトリを伝えています. - - - -cache . named.root - - -ネームサーバにインターネットの "Top-Level" の DNS サーバの一覧が -'named.root' ファイルに書いてあることを伝えています. -(このファイルはベースインストールの一部に含まれているので, -このドキュメントでは内容については説明しません.) - -ネームサーバに対して, "my.domain" という DNS ドメインを -「管理する (authoritative)」こと, "my.domain" (このローカルネットワーク) -上のシステムのホスト名と IP アドレスのリストは 'mydomain.db' -ファイル内にあることを伝えています. - - - - - -/etc/namedb/named.boot ファイルをつくってセーブしたら, -つぎの章に進んで /etc/namedb/mydomain.db ファイルをつくってください. - - - - -<filename>/etc/namedb/mydomain.db</filename> ファイル - -/etc/namedb/mydomain.db ファイルはローカルエリアネットワーク -(LAN) のすべてのシステムのホスト名と IP アドレスを一覧にしたものです. - -このファイルで使用されている文の詳細な説明については, -named の man を参照してください. - -このガイド中のネットワークで DNS サーバの設定を最低限行う -/etc/namedb/mydomain.db ファイルは, 次のような内容になるでしょう. - -@ IN SOA my.domain. root.my.domain. ( - 961230 ; 通し番号 - 3600 ; 問い合わせ - 300 ; 再試行 - 3600000 ; 無効化 - 3600 ) ; 有効期間 - IN NS curly.my.domain. - -curly.my.domain. IN A 192.168.1.1 # FreeBSD マシン -larry.my.domain. IN A 192.168.1.2 # Win'95 マシン -moe.my.domain. IN A 192.168.1.3 # WfW マシン -shemp.my.domain. IN A 192.168.1.4 # Windows NT マシン - -$ORIGIN 1.168.192.IN-ADDR.ARPA - IN NS curly.my.domain. -1 IN PTR curly.my.domain. -2 IN PTR larry.my.domain. -3 IN PTR moe.my.domain. -4 IN PTR shemp.my.domain. - -$ORIGIN 0.0.127.IN-ADDR.ARPA - IN NS curly.my.domain. -1 IN PTR localhost.my.domain. - - - -簡単に説明すると, このファイルでは, ローカルの DNS -サーバは以下のようであると宣言しています. - - - -'my.domain' というドメインに対する管理情報の始点 -(Start of Authority, "SOA") であり, - - - -'my.domain' に対するネームサーバ ("NS") であり, - - - -'192.168.1.' と '127.0.0.' で始まる全ての IP -アドレスに対する逆引き情報に責任があること ("$ORIGIN ...") - - - - - -このファイルにワークステーションのエントリを加えるとき, -一つのシステムにつき二つの行を加える必要があります. -一つは頭のセクション, ホスト名がインターネットアドレス ("IN A") -に対応づけられる部分で, もう一つは $ORIGIN -1.168.192.IN-ADDR.ARPA セクションの, -アドレスをホスト名に逆付けする部分です. - - - - -DNS サーバの起動 - -デフォルトではシステムのブート時に DNS サーバ -('/usr/sbin/named') は起動しません. この振る舞いは, -以下のように '/etc/rc.conf' -を一行変えるだけで変更することができます. - -'ee' エディタを使って /etc/rc.conf を読み込み, -このようなセクションに当たるまで 40 行ほど下ってください. - ---- -named_enable="NO" # Run named, the DNS server (or NO). -named_flags="-b /etc/namedb/named.boot" # Flags to named (if enabled). ---- - - -このセクションを次のように変えましょう. - ---- -named_enable="YES" # Run named, the DNS server (or NO). -named_flags="-b /etc/namedb/named.boot" # Flags to named (if enabled). ---- - - -ファイルをセーブしてマシンを再起動してください. - -または, 次のコマンドを打ち込んでネームサーバデーモンを起動してください. - -# named -b /etc/namedb/named.boot - - - -/etc/namedb 以下のファイルを変更した場合はいつも, -変更に対応させるために, -ネームサーバのプロセスにキックスタートをかけてやる必要があります. -これは以下のシステムコマンドで実行できます. - -# kill -HUP `cat /var/run/named.pid` - - - - - - - -PPP フィルタとの戯れ - -PPP プログラムには, PPP 経由のトラフィックに対して, -選択的にフィルタをかける能力があります. -これが正式のファイアウォールほどセキュアーだとはとても言えませんが, -リンクの使用についてある種のアクセス制御を提供することはできるのです. - -(FreeBSD システムをよりセキュアーにする方法を知りたい方は -'man ipfw' してください) - -PPP 下で使用できる様々なフィルタとその制御法についての完全な説明は -PPP の man にあります. - -PPP プログラムに適用できる制御法には四つのクラスがあります. - - - -afilter - アクセスカウンタ (または "Keep Alive") のフィルタ - - -設定ファイル中の set timeout= -文に無視されるイベントの種類を制御します. - - - -dial - ダイアリングフィルタ - - -デマンドダイアルモードの PPP に無視されるイベントの種類を制御します. - - - -in - インプットフィルタ - - -システムに入ってくるパケットを, -破棄すべきものと通過してよいものに仕分けるやり方を制御します. - - - -out - アウトプットフィルタ - - -システムから出てゆくパケットを, -破棄すべきものと通過してよいものに仕分けるやり方を制御します. - - - - - -以下は実際に稼働しているオペレーティングシステムから一部拝借して来たものです. -このシステムは「通常の」インターネットオペレーションに十分な素地を提供しつつ, -PPP がすべてのデータをダイアルアップ接続越しにやり取りすることのないようにしています. -各ルールセットのロジックを解説する簡単なコメントをつけてあります. - -# -# KeepAlive フィルタ -# ICMP,DNS と RIP パケットが流れても「通信中」とはみなさない -# - set filter alive 0 deny icmp - set filter alive 1 deny udp src eq 53 - set filter alive 2 deny udp dst eq 53 - set filter alive 3 deny udp src eq 520 - set filter alive 4 deny udp dst eq 520 - set filter alive 5 permit 0/0 0/0 -# -# ダイアルフィルタ -# 注意: この設定では ICMP もダイアルアウトのトリガになる -# - set filter dial 0 permit 0/0 0/0 -# -# ident パケットの通過を許可する -# - set filter in 0 permit tcp dst eq 113 - set filter out 0 permit tcp src eq 113 -# -# インターネットへの telnet 接続を許可する -# - set filter in 1 permit tcp src eq 23 estab - set filter out 1 permit tcp dst eq 23 -# -# インターネットへの ftp アクセスを許可する -# - set filter in 2 permit tcp src eq 21 estab - set filter out 2 permit tcp dst eq 21 - set filter in 3 permit tcp src eq 20 dst gt 1023 - set filter out 3 permit tcp dst eq 20 -# -# DNS への問い合わせを許可する -# - set filter in 4 permit udp src eq 53 - set filter out 4 permit udp dst eq 53 -# -# DNS ゾーン転送を許可する -# - set filter in 5 permit tcp src eq 53 - set filter out 5 permit tcp dst eq 53 -# -# ローカルネットワークから / へのアクセスを許可する -# - set filter in 6 permit 0/0 192.168.1.0/24 - set filter out 6 permit 192.168.1.0/24 0/0 - set ifilter 6 permit 0/0 192.168.1.0/24 - set ofilter 6 permit 192.168.1.0/24 0/0 -# -# ping と traceroute への返答を許可する -# - set filter in 7 permit icmp - set filter out 7 permit icmp - set filter in 8 permit udp dst gt 33433 - set filter out 9 permit udp dst gt 33433 -# -# cvsup を許可する -# - set filter in 9 permit tcp src eq 5998 - set filter out 9 permit tcp dst eq 5998 - set filter in 10 permit tcp src eq 5999 - set filter out 10 permit tcp dst eq 5999 -# -# 時間の同期のために NTP を許可する -# - set filter in 11 permit tcp src eq 123 dst eq 123 - set filter out 11 permit tcp src eq 123 dst eq 123 - set filter in 12 permit udp src eq 123 dst eq 123 - set filter out 12 permit udp src eq 123 dst eq 123 -# -# SMTP もいいかも! -# - set filter in 13 permit tcp src eq 25 - set filter out 13 permit tcp dst eq 25 -# -# -# `whois` を多用するので, これも通す -# - set filter in 14 permit tcp src eq 43 - set filter out 14 permit tcp dst eq 43 - set filter in 15 permit udp src eq 43 - set filter out 15 permit udp dst eq 43 -# -# 上記のどのルールにもマッチしない場合, パケットはブロックされる. -#------- - - - -フィルタクラス一つにつき, -20 個までのフィルタリングルールを適用することができます. -各クラスのルールは 0 から 20 までの連続した数字である必要がありますが, -あるフィルタクラスに対するルールは, ルールセット '0' -が定義されるまでは有効になりません! - -PPP の設定でフィルタリングルールを使用しない場合, -ISP への接続中はすべてのトラフィックがシステムに出入りすることになります. - -フィルタリングルールを使用したいなら, 上記の設定を -/etc/ppp/ppp.conf ファイルの "default:", "demand:", または -"interactive:" セクションのどれか (あるいはすべて - 選ぶのはあなたです) -に追加してください. - - - -