- Clean up stale files

Discussed with:	ryusuke
This commit is contained in:
Gabor Kovesdan 2012-09-27 17:33:19 +00:00
parent 8e733d28eb
commit b576d61de4
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=39622
17 changed files with 0 additions and 17193 deletions

View file

@ -7,7 +7,6 @@ SUBDIR+= faq
#SUBDIR+= fdp-primer
SUBDIR+= handbook
SUBDIR+= porters-handbook
SUBDIR+= ppp-primer
ROOT_SYMLINKS= faq handbook

View file

@ -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"

View file

@ -1,968 +0,0 @@
<?xml version="1.0" encoding="euc-jp" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.49
$FreeBSD$
-->
<chapter id="backups">
<title>バックアップ</title>
<sect1 id="backups-synopsis">
<title>この章では</title>
<para>この章ではデータのバックアップ方法とバックアップの作成に
使われるプログラムについて扱います。</para>
</sect1>
<sect1 id="backups-tapebackups">
<title>テープメディア</title>
<indexterm><primary>テープメディア(tape media)</primary></indexterm>
<para>一般的なテープメディアには 4mm、8mm、QIC、ミニカートリッジ、
DLT があります。</para>
<sect2 id="backups-tapebackups-4mm">
<title>4mm (DDS: Digital Data Storage)</title>
<indexterm>
<primary>テープメディア(tape media)</primary>
<secondary>DDS (4mm) テープ</secondary>
</indexterm>
<indexterm>
<primary>テープメディア(tape media)</primary>
<secondary>QIC テープ</secondary>
</indexterm>
<para>4mm テープはワークステーションのバックアップメディアとして
QIC から置き換えられつつあります。この傾向は
QIC ドライブの製造のリーダであった Archive を Conner が買収し
QIC ドライブの製造を中止したことで加速しました。
4mm ドライブは小型で静かですが 8mm
ドライブの持っているような信頼性の評判はありません。
カートリッジは 8mm カートリッジよりも安価で小型 (3 x 2 x 0.5
インチ; 76 x 51 x 12 mm) です。4mm ドライブ は
8mm 同様にヘリカルスキャン (訳注:
VTR と同様の回転ヘッドを使う方式)
を使用しているという理由でヘッドの寿命は短いです。</para>
<para>これらのドライブのデータスループットは
150kB/s 程度から最大で 500kB/s 程度の範囲です。データ容量は
1.3GB から 2.0GB です。ハードウェア圧縮が多くのドライブで可能で、
およそ 2 倍の容量になります。
マルチドライブテープライブラリユニットは 1 つの筐体に
6 ドライブを持つことができ自動的にテープを交換します。
ライブラリの容量は 240GB に達します。</para>
<para>現在の DDS-3 規格では、12GB (圧縮時 24GB)
までのテープ容量をサポートしています。
</para>
<para>4mm ドライブは 8mm ドライブ同様にヘリカルスキャンを使います。
ヘリカルスキャンの利点と欠点は 4mm ドライブ と 8mm
ドライブ共通です。</para>
<para>テープの寿命は 2000 回のパスあるいは 100
回のフルバックアップです。</para>
</sect2>
<sect2 id="backups-tapebackups-8mm">
<title>8mm (Exabyte)</title>
<indexterm>
<primary>テープメディア(tape media)</primary>
<secondary>Exabyte (8mm) テープ</secondary>
</indexterm>
<para>8mm テープは SCSI
テープドライブとして最もよく使われているもので、
データ交換用として最良の選択です。ほとんどのサイトには Exabyte
の 2GB 8mm テープドライブがあるでしょう (訳注: Unix
ワークステーションを何台も置いているようなサイトには 1
台くらいはあるというような意味です)。8mm
ドライブは信頼性が高く、使いやすく、静かです。
カートリッジは安価で小型です (4.8 x 3.3 x 0.6 インチ; 122 x 84
x 15 mm)。欠点は、テープとヘッドの相対的な速度が高速なために
比較的ヘッドとテープの寿命が短いことです。</para>
<para>データスループットは 250kB/s 程度から 500kB/s
程度の範囲です。データ容量は 300MB から 7GB です。
ハードウェア圧縮が多くのドライブで可能で、およそ 2
倍の容量になります。単一のユニットのドライブから、1
つの筐体に 6 台のドライブと 120
巻のテープを持ったマルチドライブテープライブラリまで
利用することができます。ライブラリではテープはユニットにより
自動的に交換されます。ライブラリの容量は 840GB
以上に達します。</para>
<para>Exabyte 社製の <quote>Mammoth</quote> というモデルは、
テープ一本あたり 12GB (圧縮時 24GB) をサポートしています。
このドライブの価格は、通常のテープドライブの約 2 倍です。
</para>
<para>データはヘリカルスキャンを使ってテープに記録されます。
ヘリカルスキャン方式ではヘッドはメディアに対してある傾き
(約 6 度) に配置されます。テープはヘッドのある円筒の周の
270 度にわたって接触します。テープが円筒面を走行する間、
円筒は回転しています。この結果、
高密度のデータのつまったトラックは、
狭い間隔でテープの上端と下端の間を斜めに横切ります。</para>
</sect2>
<sect2 id="backups-tapebackups-qic">
<title>QIC</title>
<indexterm>
<primary>テープメディア (tape media)</primary>
<secondary>QIC-150</secondary>
</indexterm>
<para>QIC-150 テープとドライブはたぶん最も一般的に使われている
ドライブとメディアでしょう。QIC
テープドライブは現実的なバックアップドライブとして
少なくとも高価なものではありません。
欠点はメディアのコストです。QIC テープは 8mm や 4mm
テープに比較して GB あたりのデータの保存で 5 倍ほど高価です。
しかしあなたの必要とする量が半ダース程のテープで十分であれば、
QIC は正しい選択となるかもしれません。QIC は
<emphasis>最も</emphasis>一般的なテープドライブです。
すべてのサイトに QIC ドライブのどれかの容量のものがあります。
問題は、QIC は同じようなテープ (まったく同じ場合もある)
に多様な記録密度があることです。QIC
ドライブは静かではありません。これらのドライブはデータ記録を
開始する前に音をたててシークしますし、リード、ライト、
シークの時にはっきりと聞こえる音を出します。QIC
テープの大きさは (6 x 4 x 0.7 インチ; 152 x 102 x 17 mm)。
<link
linkend="backups-tapebackups-mini">ミニカートリッジ</link>
で使われている 1/4 インチ幅のテープについては別に議論します。
テープライブラリやチェンジャはありません。</para>
<para>データスループットは 150kB/s から 500kB/s の範囲です。
データ容量の範囲は 40MB から 15GB です。ハードウェア圧縮が
最近の多くのドライブで使えるようになっています。QIC ドライブは
DAT ドライブに置き換えられつつあり、
あまり頻繁には利用されなくなっています。</para>
<para>データは複数のトラックにわかれてテープに記録されます。
トラックはテープメディアの
長さ方向の一端からもう一方の端までです。(訳注: 1 トラックの
read/write が終わるとテープの走行方向を反転させ次のトラックの
read/write を行います) トラックの数と、
それに対応するトラックの幅はテープの容量によって変わります。
すべてではありませんがほとんどの最近のドライブは
少なくとも読み出しについては (場合によっては書き込みも)
下位互換性があります。QIC
はデータの安全性についてはよいといわれています
(ヘリカルスキャンドライブに比べて機構は単純でより丈夫です)。
</para>
<para>テープは 5000 回のバックアップで寿命となるでしょう。</para>
</sect2>
<sect2 id="backups-tapebackups-mini">
<title>XXX* ミニカートリッジ</title>
<para></para>
</sect2>
<sect2 id="backups-tapebackups-dlt">
<title>DLT</title>
<indexterm>
<primary>テープメディア(tape media)</primary>
<secondary>DLT</secondary>
</indexterm>
<para>DLT はここに示したドライブのタイプの中で
最高速のデータ転送レートです。1/2 インチ (12.5mm)
テープが単リールのカートリッジ (4 x 4 x 1 インチ; 100 x 100 x
25 mm) に入っています。
カートリッジのひとつの側面全体がスイングゲートになっています。
ドライブの機構がこのゲートを開け、テープリーダを引き出します。
テープリーダには楕円形の穴があり、
ドライブがテープを引っ掛けるのに使います。
巻き取りのためのリールはドライブの中にあります。
ここに挙げた他のカートリッジはすべて (9
トラックテープはただ一つの例外です)
送りだしリールと巻き取りリールの両方がカートリッジの中に
あります。</para>
<para>データスループットは約 1.5MB/s で、4mm、8mm、QIC
テープドライブの 3 倍です。データ容量は単一のドライブで 10GB から
20GB の範囲です。
マルチテープチェンジャ、マルチテープドライブ、5 から
900 巻のテープを 1 から 20 ドライブで扱う
マルチドライブテープライブラリがあり、50GB から 9TB
の容量が得られます。</para>
<para>圧縮機能により、DLT Type IV フォーマットは
70GB までの容量をサポートします。</para>
<para>データは ( QIC テープのように)
テープの走行方向と並行に複数あるトラックへ記録されます。2
つのトラックに同時書き込みを行います。Read/Write
ヘッドの寿命は比較的長いと言えます。
テープの走行が止まればヘッドと
テープの間の相対運動はありません。</para>
</sect2>
<sect2>
<title id="backups-tapebackups-ait">AIT</title>
<indexterm>
<primary>テープメディア(tape media)</primary>
<secondary>AIT</secondary>
</indexterm>
<para>AIT は、Sony が発表した新しいフォーマットで、
テープ一本あたり 50GB (圧縮時) の容量を持っています。
テープには、記録データ内容の索引情報が記録可能な
メモリチップが内蔵されています。ドライブがこの索引情報を読みとることで、
テープのどの部分にどのファイルが存在するかを
高速に調べることができるようになっています。
従来のドライブは、この処理に数分の時間を必要としていました。
直接テープのメモリチップと通信することでテープ内容を画面表示する
SAMS:Alexandria のようなソフトウェアを使うことで、40 を超える
ATI テープライブラリを操作できるのはもちろんのこと、
どのテープのどこに、どのファイルがバックアップされているのか調べたり、
正しいテープをセットしたり、
テープ上のデータをリストアしたりすることが可能です。
</para>
<para>このようなテープライブラリにかかる費用は $20,000 台です。
業務用でないものはもう少し安価でしょう。
</para>
</sect2>
<sect2>
<title>新品のテープを最初に使う場合</title>
<para>新品の完全な空テープを読もうとしたり書き込もうとすると処理
は失敗するでしょう。
次のようなコンソールメッセージが出るでしょう。</para>
<screen>sa0(ncr1:4:0): NOT READY asc:4,1
st0(ncr1:4:0): Logical unit is in process of becoming ready</screen>
<para>テープに識別ブロック (Identifire Block:block number 0)
がありません。QIC-525 標準の採用されている
QIC テープドライブのすべてで識別ブロックをテープに書きます。
2 つの解決方法があります。</para>
<para>(訳注: 方法 1)<command>mt fsf 1</command>
によってテープドライブは識別ブロックをテープに書きます。</para>
<para>(訳注:
方法 2) フロントパネルのボタンを押してテープをとりだします。
</para>
<para>再びテープを入れ、データをテープに <command>dump</command> します。</para>
<para><command>dump</command> はそのうちに <literal>DUMP: End of tape
detected</literal> と表示し、コンソールには
<literal>HARDWARE FAILURE info:280
asc:80,96</literal> と表示されるでしょう。</para>
<para><command>mt
rewind</command> を使ってテープを巻戻します。</para>
<para>この次からはテープの操作は成功するでしょう。</para>
</sect2>
</sect1>
<sect1 id="backup-programs">
<title>バックアッププログラム</title>
<indexterm><primary>バックアッププログラム(backup software)</primary></indexterm>
<para>よく使われる3つのプログラムは &man.dump.8;、&man.tar.1;、
&man.cpio.1; です。</para>
<sect2>
<title>dump と restore</title>
<indexterm>
<primary>バックアッププログラム(backup software)</primary>
<secondary>dump / restore</secondary>
</indexterm>
<indexterm><primary><command>dump</command></primary></indexterm>
<indexterm><primary><command>restore</command></primary></indexterm>
<para>Unix で古くから使われているバックアッププログラムは
<command>dump</command> と <command>restore</command> です。
これらはディスクドライブをディスクブロックの集まりとして、
ファイルシステム上につくられるファイル、
リンク、ディレクトリといった概念よりも低レベルで扱います。
<command>dump</command> はデバイスやファイルシステム全体をバックアップするもので、
ファイルシステムの一部や、
複数のファイルシステムにまたがるディレクトリツリーの一部だけを
バックアップすることはできません。
<command>dump</command> はファイルやディレクトリではなく、
ファイルやディレクトリを構成する生のデータブロックをテープに記録します。</para>
<note>
<para>ルートディレクトリで <command>dump</command> を使った場合、
<filename>/home</filename> や <filename>/usr</filename> など、
他の多くのディレクトリはバックアップされません。
これは、上にあげたようなディレクトリが通常、
他のファイルシステムへのマウントポイントであったり、
他のファイルシステムへのシンボリックリンクとなっているためです。</para>
</note>
<para><command>dump</command> には初期の ATT UNIX のバージョン 6 (1975
年ごろ) に由来する癖が残っています。
デフォルトのパラメータは 9 トラックテープ (6250 bpi)
に適したものになっていて、
現在の高密度メディア (最大 62,182 ftpi) に適していません。
現在のテープドライブの容量を有効に利用するため、
これらのデフォルト値をコマンドラインで必ず置き換える必要があります。</para>
<indexterm><primary><filename>rhosts</filename></primary></indexterm>
<para>また、<command>rdump</command> と <command>rrestore</command> を用いると、
他のコンピュータに接続されたテープドライブを使い、
ネットワーク経由でデータをバックアップすることも可能です。
どちらのプログラムもリモートテープドライブにアクセスするために
<command>rcmd</command> と <command>ruserok</command> に依存しています。
このためユーザがバックアップを実行するためには
<literal>rhosts</literal> によるリモートアクセスが必要です。
<command>rdump</command> と <command>rrestore</command>
の引数はリモートコンピュータに適切なものを用います。
(例えば
FreeBSD コンピュータより <hostid>komodo</hostid> という名前の
Sun に接続されている Exabyte テープドライブへ
<command>/sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8
/dev/rda0a 2>&amp;1</command> として
<command>rdump</command>したような場合の restore に使います)
警告: セキュリティは
<literal>rhosts</literal> の管理にかかっています。
あなたの状況を注意深く調べてください。</para>
<para><command>ssh</command> を用いると
<command>rdump</command> と <command>rrestore</command>
をより安全な形で利用することができます。</para>
<example>
<title><application>ssh</application> 経由で <command>rdump</command> を使う</title>
<screen>&prompt.root; <userinput>/sbin/dump -0uan -f - /usr | gzip -2 | ssh1 -c blowfish \
targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz</userinput></screen>
</example>
</sect2>
<sect2>
<title><command>tar</command></title>
<indexterm>
<primary>バックアッププログラム (backup software)</primary>
<secondary><command>tar</command></secondary>
</indexterm>
<para><command>tar</command> AT&amp;T Unix のバージョン 6 (1975 ごろ)
にさかのぼる事ができます。<command>tar</command>
はファイルシステムと協調して機能し、
ファイルやディレクトリをテープに書きます。<command>tar</command> は
&man.cpio.1;
で使えるようなフルレンジのオプションは持ちませんが
<command>cpio</command>
で使うような奇妙なコマンドパイプラインは必要ありません。</para>
<indexterm><primary><command>tar</command></primary></indexterm>
<para>大部分の <command>tar</command>
にはネットワーク経由のバックアップの機能はありませんが、
FreeBSD で使用されている GNU の <command>tar</command> は、
<command>rdump</command>
とおなじ構文でリモートデバイスを扱うことができます。
<hostid>komodo</hostid>
というホスト名の Sun に繋いである Exabyte
のテープデバイスに対して <command>tar</command> を実行するには、
次のようにします。
<command>/usr/bin/tar cf komodo:/dev/nrsa8 。
2>&amp;1</command> リモートデバイスをサポートしていない tar
を使用している場合は、パイプラインと <command>rsh</command> を使うことで、
リモートテープデバイスにデータを送る事ができます。
</para>
<screen>&prompt.root; <userinput>tar cf - . | rsh <replaceable>hostname</replaceable> dd of=<replaceable>tape-device</replaceable> obs=20b</userinput></screen>
<para>もしあなたがネットワークを越えるバックアップのセキュリティに
困っているなら &man.rsh.1; の代わりに &man.ssh.1; を使うべきです。</para>
</sect2>
<sect2>
<title><command>cpio</command></title>
<indexterm>
<primary>バックアッププログラム (backup software)</primary>
<secondary><command>cpio</command></secondary>
</indexterm>
<para>&man.cpio.1; は本来、Unix
ファイルを磁気メディアで交換するためのプログラムです。
<command>cpio</command> はバイトスワッピング、
多くの異なるアーカイブフォーマットの書き込みのオプション
(それ以外にも多数のオプションがあります) があり、
パイプで他のプログラムにデータを渡す事もできます。
この最後に挙げた特徴により、<command>cpio</command>
はインストールメディアについては優れた選択です。<command>cpio</command>
は <filename>stdin</filename> からの入力でなければならず、
ディレクトリツリーの探索や
ファイルリストについての機能はありません。</para>
<indexterm><primary><command>cpio</command></primary></indexterm>
<para>&man.cpio.1;
はネットワーク経由のバックアップの機能はありません。
リモートテープドライブにはパイプラインと &man.rsh.1;
を使って送る事ができます。</para>
<screen>&prompt.root; <userinput>for f in <replaceable>directory_list; do</replaceable></userinput>
<userinput>find $f >> backup.list</userinput>
<userinput>done</userinput>
&prompt.root; <userinput>cpio -v -o --format=newc < backup.list | ssh <replaceable>user</replaceable>@<replaceable>host</replaceable> "cat > <replaceable>backup_device</replaceable>"</userinput></screen>
<para><replaceable>directory_list</replaceable>
にはバックアップしたいディレクトリのリスト、
<replaceable>user</replaceable>@<replaceable>host</replaceable>
にはバックアップを実行するユーザ/ホスト名の組合せ、
<replaceable>backup_device</replaceable> には
バックアップ内容を保存する場所
(たとえば <filename>/dev/nrsa0</filename>) を指定します。</para>
</sect2>
<sect2>
<title><command>pax</command></title>
<indexterm>
<primary>バックアッププログラム (backup software)</primary>
<secondary><command>pax</command></secondary>
</indexterm>
<indexterm><primary><command>pax</command></primary></indexterm>
<indexterm><primary>POSIX</primary></indexterm>
<indexterm><primary>IEEE</primary></indexterm>
<para>&man.pax.1; は <command>tar</command> と
<command>cpio</command> に対する IEEE/POSIX の回答です。
長年の間、様々なバージョンの <command>tar</command> や
<command>cpio</command> は、
互いにわずかながら非互換性を有していました。
各々をしらみ潰しに標準化する代わりに、POSIX
は新しいアーカイブユーティリティを作ることにしました。
<command>pax</command>
は専用に開発された新しいフォーマットに加えて、いくつもの cpio
や tar のフォーマットの読み書きに対応しようと試みています。
コマンド群は <command>tar</command> よりも
<command>cpio</command> の方にいくぶん似ています。</para>
</sect2>
<sect2 id="backups-programs-amanda">
<title><application>Amanda</application></title>
<indexterm>
<primary>バックアッププログラム (backup software)</primary>
<secondary><application>Amanda</application></secondary>
</indexterm>
<indexterm><primary><application>Amanda</application></primary></indexterm>
<para>
<application>Amanda</application> (Advanced Maryland Network Disk Archiver)
は単一のプログラムではなくクライアント /
サーバ型のバックアップシステムです。Amanda サーバは、Amanda
クライアントであるネットワークで
サーバに接続された複数のコンピュータから
一つのテープドライブへバックアップをおこないます。
このような場合の一般的な問題はいくつもの大容量の
ディスクからデータディレクトリをテープにバックアップするには
時間がかかりすぎてしまうという事です。Amanda
はこの問題を解決します。Amanda
は同時に複数のファイルシステムのバックアップをおこなう時に
「ホールディングディスク」を使う事ができます。
Amanda の設定ファイルに書いたすべてのファイルシステムの
フルバックアップを特定の間隔でとるために「アーカイブセット」
と呼ばれるテープグループを作ります。
これには夜間に作られるすべてのファイルシステムの増分
(あるいは差分として) のバックアップも含みます。
障害の起きたファイルシステムの回復には最も新しい
フルバックアップと増分のバックアップが必要です。</para>
<para>設定ファイルでバックアップのコントロールと Amanda
によるネットワークトラフィック量を設定します。Amanda
はデータをテープに書くのにバックアッププログラムの
いずれかを使うでしょう。Amanda
はその一部分でもパッケージでも利用可能ですが、
デフォルトではインストールされません。</para>
</sect2>
<sect2>
<title>何もしない</title>
<para><quote>何もしない</quote>
というのはコンピュータのプログラムではありませんが、
バックアップの戦略として最も広く採用されている物です。
これには初期投資が必要ありません。
したがわなければならないバックアップスケジュールもありません。
ただ何もしないだけです。もしデータに何かが起きたら、
苦笑いして耐えてください。</para>
<para>あなたにとって時間やデータの価値が少ないか
あるいはまったくないのであれば <quote>何もしない</quote>
のはあなたのコンピュータに最も適した
バックアッププログラムでしょう。しかし注意してください。Unix
は便利なツールです。6 ヶ月も使っていれば価値のあるファイルの
山ができ上がっているでしょう。</para>
<para><quote>何もしないこと</quote> は
<filename>/usr/obj</filename> など、
コンピュータが同じものをもう一度作り直すことのできる
ディレクトリツリーに対して適した方法です。
一つの例として、このハンドブックの HTML 版、PostScript
版を構成するファイルが考えられます。
これらは両方とも SGML ファイルから生成されたものなので、
HTML 版と PostScript 版のバックアップをとる必要はありません。
一方、SGML ファイルは定期的にバックアップが行なわれています。</para>
</sect2>
<sect2>
<title>どのバックアッププログラムが最適でしょう?</title>
<indexterm>
<primary>LISA</primary>
</indexterm>
<para><emphasis>定期的に</emphasis> <command>dump</command> しましょう。
Elizabeth D. Zwicky はここで検討したプログラムすべてについて
拷問的なテストをおこないました。すべてのデータと
Unixファイルシステムの状態すべてを保存するには明らかに
&man.dump.8; でしょう。Elizabeth
は大きく変化に富んだ異常な状態
(いくつかはあまり異常でもない状態のものもあります)
になっているファイルシステムで、
それぞれのプログラムでファイルシステムの
バックアップとリストアを行ってテストしました。
特色のある状態には、ホールを持つファイル、
ホールとヌルブロックを持つファイル、
奇妙な文字をファイル名に持つファイル、読み出し不可、
書き込み不可のファイル、デバイスファイル、
バックアップ中にファイルのサイズを変更する、
バックアップ中にファイルの作成/削除をおこなうなどがあります。
彼女は 1991 年 10 月の LISA V で結果の発表をしています。<ulink
url="http://reality.sgi.com/zwicky_neu/testdump.doc.html">torture-testing Backup and Archive Programs</ulink> を参照してください。</para>
</sect2>
<sect2>
<title>緊急時のリストア手順</title>
<sect3>
<title>災難の起きる前に</title>
<para>起き得るどのような災難に対しても以下の
4 ステップだけが必要な準備です。</para>
<indexterm>
<primary><command>disklabel</command></primary>
</indexterm>
<para>ステップ 1 では、
ファイルシステムテーブル (<filename>/etc/fstab</filename>)
や起動メッセージで示されるすべてのディスクの
disklabel をそれぞれ 2 コピーづつプリント (例えば
<command>disklabel da0 | lpr</command> を実行します)
します。</para>
<indexterm><primary>fix-it floppies</primary></indexterm>
<para>ステップ 2 では、<filename>boot.flp</filename> と
<filename>fixit.flp</filename>
にそのシステムのすべてのデバイスドライバが
含まれているか確認します。最も簡単な確認の方法は、
フロッピディスクをドライブに入れて再起動し、
起動メッセージを確認することです。
あなたのシステムのデバイスがすべて含まれ、機能していれば、
step 3 へ飛んでください。</para>
<para>そうでないなら、
そのシステムのすべてのディスクをマウントでき、
テープドライブにもアクセスできる
2 種類のカスタム起動フロッピディスクを作る必要があります。
これらのフロッピディスクには <command>fdisk</command>、<command>disklabel</command>、
<command>newfs</command>、<command>mount</command>、
と利用したいバックアッププログラムが
入っていなければなりません。
これらのプログラムはスタティックリンクされた
プログラムである必要があります。<command>dump</command>
を使うのであればフロッピディスクに <command>restore</command>
を入れる必要があります。</para>
<para>ステップ 3 では、通常の方法でバックアップを作ります。
最新のバックアップの後でおこなわれた変更は
回復することはできません。
バックアップテープにライトプロテクトをしてください。</para>
<para>ステップ 4 では、フロッピディスク
(<filename>boot.flp</filename> と
<filename>fixit.flp</filename> あるいはステップ
2 で作った 2 枚のカスタム起動フロッピディスクです)
とバックアップテープのテストをします。
手順のノートを作りましょう。
このノートは起動フロッピディスク、
バックアップテープに入れておきプリントアウトしておきます。
あなたがリストアをおこなうような時は
おそらく錯乱状態でしょうからこのノートはバックアップを
破壊してしまうようなことを防ぐのに役立つでしょう
(どのようにして破壊するって? <command>tar xvf
/dev/rsa0</command> とするかわりに偶然 <command>tar cvf
/dev/rsa0</command>
とタイプしてバックアップテープに上書きしてしまうかも
しれません)。</para>
<para>訳注: 上書きはライトプロテクトをしておけば防げますが、
なんらかの原因でプロテクトがはずれているかもしれません。
ちなみに訳者の経験から言えば上のようなミスタイプは
結構起きます。</para>
<para>安全性を増すために、
毎回起動フロッピディスクを作り、2
巻のバックアップテープを取ります。
一方を離れた場所に保管します。
離れた場所は同じ建物の地下室ではいけません。
世界貿易センタービルにあった数多くの会社は
苦い経験よりこの教訓を得ました。
離れた場所とはコンピュータやディスクドライブから
かなり離れていて物理的に分離されていなければなりません。</para>
<example>
<title>起動フロッピディスクを作るスクリプトの一例</title>
<programlisting><![ CDATA [#!/bin/sh
#
# create a restore floppy リストアフロッピディスクの作成
#
# format the floppy フロッピディスクのフォーマット
#
PATH=/bin:/sbin:/usr/sbin:/usr/bin
fdformat -q fd0
if [ $? -ne 0 ]
then
echo "Bad floppy, please use a new one"
exit 1
fi
# place boot blocks on the floppy フロッピディスクに起動ブロックを書く
#
disklabel -w -B /dev/fd0c fd1440
#
# newfs the one and only partition ただ 1 つのパーティションを newfs
#
newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/fd0a
#
# mount the new floppy 新しいフロッピディスクをマウント
#
mount /dev/fd0a /mnt
#
# create required directories 必要なディレクトリの作成
#
mkdir /mnt/dev
mkdir /mnt/bin
mkdir /mnt/sbin
mkdir /mnt/etc
mkdir /mnt/root
mkdir /mnt/mnt # for the root partition
mkdir /mnt/tmp
mkdir /mnt/var
#
# populate the directories
#
# MINI カーネルがない場合は作ります
if [ ! -x /sys/compile/MINI/kernel ]
then
cat << EOM
The MINI kernel does not exist, please create one.
Here is an example config file:
# MINI カーネルの config file の例
# MINI -- A kernel to get FreeBSD onto a disk.
#
machine "i386"
cpu "I486_CPU"
ident MINI
maxusers 5
options INET # needed for _tcp _icmpstat _ipstat
# _udpstat _tcpstat _udb
options FFS #Berkeley Fast File System
options FAT_CURSOR #block cursor in syscons or pccons
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
options NCONS=2 #1 virtual consoles
options USERCONFIG #Allow user configuration with -c XXX
config kernel root on da0 swap on da0 and da1 dumps on da0
device isa0
device pci0
device fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
device fd0 at fdc0 drive 0
device ncr0
device scbus0
device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
device npx0 at isa? port "IO_NPX" irq 13 vector npxintr
device da0
device da1
device da2
device sa0
pseudo-device loop # required by INET
pseudo-device gzip # Exec gzipped a.out's
EOM
exit 1
fi
cp -f /sys/compile/MINI/kernel /mnt
gzip -c -best /sbin/init > /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 <<EOM
/dev/fd0a / ufs rw 1 1
EOM
#
# create minimum passwd file 最小限のパスワードファイル
#
cat > /mnt/etc/passwd <<EOM
root:*:0:0:Charlie &:/root:/bin/sh
EOM
cat > /mnt/etc/master.passwd <<EOM
root::0:0::0:0:Charlie &:/root:/bin/sh
EOM
chmod 600 /mnt/etc/master.passwd
chmod 644 /mnt/etc/passwd
/usr/sbin/pwd_mkdb -d/mnt/etc /mnt/etc/master.passwd
#
# umount the floppy and inform the user フロッピディスクを unmount
#
/sbin/umount /mnt
echo "The floppy has been unmounted and is now ready."]]></programlisting>
</example>
</sect3>
<sect3>
<title>災難の後に</title>
<para>重要な問題は、ハードウェアが生き残ったかどうかです。
定期的なバックアップを取っていれば
ソフトウェアについて心配する必要はありません。</para>
<para>ハードウェアがダメージを受けていたら、
最初にそのダメージを受けた部品を交換してください。</para>
<para>ハードウェアに問題がなければ、
フロッピディスクをチェックしてください。
カスタム起動フロッピディスクを使っているのであれば
シングルユーザ(<prompt>boot:</prompt> プロンプトの出た時に
<literal>-s</literal> とタイプしてください)
で起動してください。それから次の
「ファイルシステムを 1 つずつ回復する」
を読んでください。</para>
<para><filename>boot.flp</filename> と
<filename>fixit.flp</filename>
を使っているのであればこのまま読み続けてください。
<filename>boot.flp</filename> を入れて起動してください。
本来のインストールメニューが表示されるはずです。(ここで)
<literal>Fixit--Repair mode with CDROM or
floppy.</literal> オプションを選びます。指示の通り
<filename>fixit.flp</filename> を入れてください。
<command>restore</command> とその他の必要なプログラムは
<filename>/mnt2/stand</filename> に置かれています。</para>
<para>ファイルシステムを一つずつ回復する</para>
<indexterm>
<primary><command>mount</command></primary>
</indexterm>
<indexterm><primary>root partition</primary></indexterm>
<indexterm>
<primary><command>disklabel</command></primary>
</indexterm>
<indexterm>
<primary><command>newfs</command></primary>
</indexterm>
<para>最初のディスクの root パーティションを <command>mount</command>
(例えば <command>mount /dev/da0a /mnt</command> のように)
マウントしてみてください。
ディスクラベルが破壊されている場合は <command>disklabel</command>
を使ってあらかじめプリントしておいた通りに
パーティションを作り直しラベルをつけてセーブしてください。
<command>newfs</command> を使いファイルシステムを作り直します。
ルートパーティションを読み書き可能にマウント (<command>mount
-u -o rw /mnt</command>) しなおします。
バックアッププログラムとバックアップテープを使って
このファイルシステムのデータを回復します (例えば
<command>restore vrf /dev/sa0</command> とします)。
ファイルシステムをアンマウント (<command>umount
/mnt</command> など) して、
障害を受けたファイルシステムそれぞれについて
繰り返してください。</para>
<para>システムが動き出したら、
新しいテープにデータをバックアップしてください。
どのような理由で再び事故が起きたりデータが
失われるかはわかりません。これに時間を費す事で、
後々の災難から救われる事になります。</para>
</sect3>
<![ %not.published; [
<sect3>
<title>* 災難対策をしていませんでした。
どうしたらいいでしょう?</title>
<para></para>
</sect3>
]]>
</sect2>
</sect1>
<sect1 id="backups-floppybackups">
<title>フロッピディスクへのバックアップはどうですか?</title>
<sect2 id="floppies-using">
<title>データをフロッピディスクにバックアップすることはできますか?</title>
<indexterm><primary>backup floppies</primary></indexterm>
<indexterm><primary>floppy disks</primary></indexterm>
<para>実はフロッピディスクはバックアップ向きのメディアとは言えません。
というのは:</para>
<itemizedlist>
<listitem>
<para>特に長期間に渡って保存する場合、信頼性が低い。</para>
</listitem>
<listitem>
<para>バックアップ、リストアがとても遅い。</para>
</listitem>
<listitem>
<para>容量が小さい (ハードディスク全体の日々のバックアップに
1 ダース、長期間なら本当にたくさん)。</para>
</listitem>
</itemizedlist>
<para>けれども、データをバックアップする他の手段がない場合には、
まったくバックアップをしないよりもフロッピディスクを使うほうが良い
でしょう。</para>
<para>これを行う場合には、高品質のものを使うようにしてください。
まわりに何年も転がっていたフロッピディスクは使わない方よいでしょう。
評判のよいメーカの新品を使うことが理想です。</para>
</sect2>
<sect2 id="floppies-creating">
<title>どうやってデータをフロッピディスクにバックアップ
するのですか?</title>
<para>フロッピディスクへバックアップする最も良い方法は tar
<command>tar</command> コマンドに <option>-M</option> (マルチ・ボリューム)
オプションを付けて、複数のフロッピディスクにまたがるバックアップも
できるようにする方法です。</para>
<para>カレントディレクトリのすべてのファイルとサブディレクトリを
バックアップするには、以下のようにします (<username>root</username> で):</para>
<screen>&prompt.root; <userinput>tar Mcvf /dev/fd0 *</userinput></screen>
<para>1 枚目のフロッピディスクがいっぱいになると <command>tar</command> は
次のボリュームを入れるようプロンプトを表示します。
( <command>tar</command> は、さまざまなメディアを扱えるので
ボリュームと表示します。ここではフロッピディスクのことです)</para>
<screen>Prepare volume #2 for /dev/fd0 and hit return:</screen>
<para>これは (ボリューム番号が増えながら) 指定されたすべてのファイルが
保存されるまで繰り返されます。</para>
</sect2>
<sect2 id="floppies-compress">
<title>バックアップを圧縮することはできませんか?</title>
<indexterm>
<primary><command>tar</command></primary>
</indexterm>
<indexterm>
<primary><command>gzip</command></primary>
</indexterm>
<indexterm><primary>圧縮</primary></indexterm>
<para>残念ながら、<command>tar</command> はマルチ・ボリュームに保存する場合は
<option>-z</option> オプションを使うことができません。
もちろん、すべてのファイルを <command>gzip</command> してから、フロッピディスクに
<command>tar</command> して、ファイルを <command>gunzip</command>
することはできます!</para>
</sect2>
<sect2 id="floppies-restoring">
<title>リストアはどうしますか?</title>
<para>保存したファイルすべてをリストアするには:</para>
<screen>&prompt.root; <userinput>tar Mxvf /dev/fd0</userinput></screen>
<para>特定のファイルのみをリストアする方法は二つあります。
まず、一枚目のフロッピディスクを挿入して次のようにします。</para>
<screen>&prompt.root; <userinput>tar Mxvf /dev/fd0 <replaceable>filename</replaceable></userinput></screen>
<para><command>tar</command> は、必要なファイルを見つけるまで、続きのフロッピディスクを
セットするよう表示します。</para>
<para>別の方法として、どのフロッピディスクにファイルが入っているのかが
分かっているなら、そのフロッピディスクを挿入して上記と同じコマンドを
使うこともできます。最初のファイルが前のフロッピディスクから続いて
いる場合は、<command>tar</command> は、頼みもしないのに、そのファイルはリストア
できないと警告します!</para>
</sect2>
</sect1>
</chapter>

View file

@ -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"

View file

@ -1,688 +0,0 @@
<?xml version="1.0" encoding="euc-jp" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.472
$FreeBSD$
-->
<chapter id="contrib">
<chapterinfo>
<authorgroup>
<author>
<firstname>Jordan</firstname>
<surname>Hubbard</surname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>FreeBSD への貢献</title>
<!-- <para><emphasis>訳: &a.jp.iwasaki;,
1997 年 4 月 27 日.</emphasis></para> -->
<indexterm><primary>貢献</primary></indexterm>
<para>あなたも何か FreeBSD のために貢献したくなりましたか?
素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD
は生き残るためにユーザベースの貢献に<emphasis>頼る</emphasis>ようなシステムの一つです.
あなたの貢献は感謝されるだけではなく, FreeBSD
が成長し続けるために極めて重要なものな のです!</para>
<para>一部の人達が言っているのとは逆に,
貢献を受け付けてもらうために腕利 きのプログラマーになるとか
FreeBSD コアチームの人と親友になる必要はありません. FreeBSD
プロジェクトの開発は,
多くのそして益々増加する世界中の貢献者達によってなされており, 彼らの年齢,
専門技術分野は多岐に渡ります.
そして手の空いている人よりも成されるべき仕事の方が常に多いのです.</para>
<para>FreeBSD
プロジェクトがカーネルや散在しているユーティリティよりも,
オペレーティングシステム環境 (と, そのインストール)
に対して責任を持つ ようになったため,
私たちの <filename>TODO</filename> リストはドキュメンテーション,
ベータテスト,
高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に広い範囲のタスクに渡ります.
あなたの技能レベルに関わらず,
プロジェクトを支援できることが必ず何かあります!</para>
<para>FreeBSD
関連の事業に従事している商業団体が私たちにコンタクトすることも歓迎します.
あなたの製品を (FreeBSD 上で) 動作させるには,
特別な拡張が必要ではありませんか?
あまりにも風変わりな要求でなければ,
それを受け入れる用意が私たちにあるとわかるはずです.
付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは,
ある面において共同して作業をすることができるでしょう.
フリーソフトウェア界は,
ソフトウェアがそのライフサイクルを通してどのように開発され,
売られ, 保守されていくかについて, 既存の仮説に挑戦しています.
少なくとももう一度考慮してみることを私たちは強くお奨めします.</para>
<sect1 id="contrib-what">
<title>何が必要?</title>
<para>次のタスクとサブプロジェクトのリストは, コアチームの色々な
<filename>TODO</filename>
リストと最近2ヶ月で集めたユーザリクエストを合わせたものです.
可能なところでは, 緊急度によってタスクがランクづけされています.
もしここにあるタスクの実行に興味があるのでしたら,
コーディネータの名前をクリックしてメールを送ってください.
もしコーディネータが決まっていなければ,
あなたがボランティアしてみませんか?</para>
<sect2>
<title>進行中のタスク</title>
<para>次のタスクはやっておくべきではありますが,
特にさし迫っているわけではありません:</para>
<orderedlist>
<listitem>
<para>完全な KLD ベースのドライバのサポート /
コンフィグレーションマネージャ.</para>
<itemizedlist>
<listitem>
<para>穏やかな方法でハードウェアを検知するコンフィグレーションマネージャの作成
(第3ステージ・ブートの中に?). ハードウェアが必要とする
KLD だけを残す等.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>PCMCIA/PCCARD. コーディネータ: &a.msmith; と &a.imp;</para>
<itemizedlist>
<listitem>
<para>ドキュメンテーション!</para>
</listitem>
<listitem>
<para>pcic ドライバの信頼性のある操作 (テスト要).</para>
</listitem>
<listitem>
<para><filename>sio.c</filename>
のリコグナイザとハンドラ (ほぼ完了).</para>
</listitem>
<listitem>
<para><filename>ed.c</filename> のリコグナイザとハンドラ
(ほぼ完了).</para>
</listitem>
<listitem>
<para><filename>ep.c</filename> のリコグナイザとハンドラ
(ほぼ完了).</para>
</listitem>
<listitem>
<para>User-mode のリコグナイザとハンドラ
(部分的に完了).</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>先進的なパワーマネージメント. コーディネータ: &a.nate;
と &a.phk;</para>
<itemizedlist>
<listitem>
<para>APM サブドライバ (ほぼ完了).</para>
</listitem>
<listitem>
<para>IDE/ATA ディスクサブドライバ (部分的に完了).</para>
</listitem>
<listitem>
<para>syscons/pcvt サブドライバ.</para>
</listitem>
<listitem>
<para>PCMCIA/PCCARD ドライバ群との統合 (サスペンド /
レジューム).</para>
</listitem>
</itemizedlist>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>優先度の低いタスク</title>
<para>次のタスクは全くのあら隠し,
または誰もすぐにおこないそうもない投資のような仕事を表します:</para>
<para>最初の N 項目は Terry Lambert
<email>terry@lambert.org</email> からのものです.</para>
<orderedlist>
<listitem>
<para>ネットワークカードと一緒に提供される ODI
カードドライバを使用できるようにする, NetWare サーバ
(プロテクトモードの ODI ドライバ) ローダとサブサービス.
NDIS ドライバと NetWare の SCSI ドライバについても同様.</para>
</listitem>
<listitem>
<para>前のリビジョンの FreeBSD マシンではなく, Linux
マシンで動作する 「アップグレードシステム」オプション.</para>
</listitem>
<listitem>
<para>カーネルのマルチスレッド化
(カーネルのプリエンプションが必要).</para>
</listitem>
<listitem>
<para>カーネルのプリエンプション付き対称マルチプロセッシング
(カーネルのプリエンプションが必要).</para>
</listitem>
<listitem>
<para>ポータブルコンピュータのサポートにおける協調の試み.
これは PCMCIA
ブリッジング規則と電源管理イベント処理の変更により,
いくらかは処理できます. しかし,
内蔵ディスプレイと外部ディスプレイの検出, この 2
種類のディスプレイがあるという事実に基づく異なる解像度の選択,
マシンがドックにある場合にはディスクのモータ停止を防止すること,
マシンのブート能力に影響を与えずにドックベースのカードの消滅を可能にすること
(PCMCIA と同じ問題) などの問題があります.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>もっと簡単なタスク</title>
<para>上のセクションで挙げたタスクは膨大な時間の投資または
FreeBSD のカーネルに関する深い知識を必要とします
(もしくはそのどちらも). しかしながら,
&quot;週末ハッカー&quot;やプログラミングのスキルを持たない人々に適した立派なタスクも数多くあります.</para>
<orderedlist>
<listitem>
<para>FreeBSD-current を運用しており,
状態の良いインターネット接続があるならば, <hostid
role="fqdn">current.FreeBSD.org</hostid>
という一日に一回フルリリースを行っているマシンがあります
&mdash; 時おり最新のリリースをそこからインストールし,
その過程で何か問題があるなら報告して下さい.</para>
</listitem>
<listitem>
<para>freebsd-bugs
メーリングリストを読んでください.
そこではあなたが建設的なコメントを付けたりテストできるパッチが提供されているような問題がある かもしれません.
もしくはそれらの問題の一つをあなた自身で修正することさえできるかもしれません.</para>
</listitem>
<listitem>
<para>定期的に FAQ とハンドブックを通して読んでみてください.
もしまずい説明や古い事柄や完全に間違っていることなどがあれば我々に知らせて下さい.
さらに良いのは我々に修正案を送ることです (SGML
は学ぶのにそれほど難しくありませんが,
プレインテキストでも問題はありません).</para>
</listitem>
<listitem>
<para>(もしまだないならば) FreeBSD
のドキュメントを自分の母国語に翻訳するのを手伝ってください &mdash;
作業している人がいるかどうか &a.doc; にメールを送って聞くだけです.
とはいっても,
そうすることによってあなたが全ての FreeBSD
ドキュメントの翻訳に携わるようになるというわけではないですからね
&mdash; 実際,
もっとも翻訳が必要とされているドキュメントはインストール方法です.</para>
</listitem>
<listitem>
<para>たまに(もしくは定期的に) freebsd-questions
メーリングリストや
<!-- hrs: use &ng.misc; and should be reflect delta between rev.1.469 to 1,472 -->
<literal>comp.unix.bsd.freebsd.misc</literal>
を読んでください. これは,
あなたの持っている専門知識を共有したり誰かが抱えている問題を解決するのに非常に有効なものになり得ることです.
時にはあなた自身で新しいことを学ぶことさえできるかもしれません.
これらのフォーラムはやるべきことのアイディアの源にもなり得るのです.</para>
</listitem>
<listitem>
<para>-current に正しく当てられるがしばらく経っても(通常は
2, 3 週間) -stable
に取り込まれてないようなバグフィックスがあるならばコミッターに丁寧に思い出させてください.</para>
</listitem>
<listitem>
<para>寄贈ソフトウェアをソースツリーの
<filename>src/contrib</filename>
に移動させてください.</para>
</listitem>
<listitem>
<para><filename>src/contrib</filename>
以下のコードが最新のものであるか確認してください.</para>
</listitem>
<listitem>
<para>警告を詳細に報告するようにして
ソースツリー全体(もしくはその一部)を構築してみてください.
そして警告が出ないようにしてください.</para>
</listitem>
<listitem>
<para>ports で, gets() を使っているとか malloc.h
をインクルードしているなどといった警告が出ないようにしてください.</para>
</listitem>
<listitem>
<para>もしなんらかの ports に関わっているなら,
あなたのパッチを作者にフィードバックしてください
(次のバージョンが出た時にあなたが楽になります).</para>
</listitem>
<listitem>
<para>このリストに追加するタスクを提案して下さい!</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>障害報告 (PR; Problem Report) データベースにおける作業</title>
<indexterm><primary>障害報告 (PR) データベース</primary></indexterm>
<para><ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi">
FreeBSD 障害報告リスト</ulink>では, 現在問題となっている報告と,
FreeBSD の利用者によって提出された改良の要望に関する全てのリストを公開しています.
open 状態の障害情報を見て, 興味を引く内容かどうか確かめて下さい.
本当に複雑なものも含まれているでしょうし,
例えば, 障害報告に対する修正がちゃんとしたものであるかどうか単にチェックするだけのとても簡単な作業もあるでしょう.</para>
<para>まず, まだ誰にも割り当てられていない障害報告から作業を始めて下さい.
もし, 誰か他の人に割り当てが決まっているけれども自分が作業可能だ,
というものがあれば, 作業ができるかどうか &mdash;
既にテスト用パッチが用意されているのかどうか, あるいは
その問題についてあなたが考えている,
より進んだ考えに関して議論ができるかどうか,
割り当てられている人に電子メールで問い合わせて下さい.
</para>
</sect2>
</sect1>
<sect1 id="contrib-how">
<title>貢献の仕方</title>
<para>一般的に, システムへの貢献は次の 6
つのカテゴリの1つ以上に分類されます:</para>
<sect2 id="contrib-general">
<title>バグ報告と一般的な論評</title>
<para>報告するべきバグがあったり, 提案したいことがあれば:</para>
<para><emphasis>一般的な</emphasis>
技術的関心事に関するアイデアや提案は &a.hackers;
へメールしてください. 同様に, このような事柄に興味のある
(そして<emphasis>膨大な</emphasis>メール! に耐えられる) 人は,
&a.majordomo; へメールを送って hackers
メーリングリストに参加すると良いでしょう. 情報については
<link linkend="eresources-mail">メーリングリスト</link>
を参照してください.</para>
<para>バグを発見したり変更を送付しようとしている場合は
&man.send-pr.1; プログラムか <ulink
url="../../../../ja/send-pr.html">ウェブベースの
send-pr</ulink> を使用して報告してください.
バグレポートの各項目を埋めるようにしてください. 65KB
を超えるのでなければ,
レポート中に直接パッチを入れてくださって結構です.
パッチがソースツリーにすぐ適用できるものならば,
報告の概要に <literal>[PATCH]</literal> と書いておいてください.
その場合, カット&ペーストは<emphasis>しないで</emphasis>ください.
カット&ペーストではタブがスペースに展開されてパッチが使い物にならなくなってしまいます.
20KB を超える場合は,
それらを compress して &man.uuencode.1;
することも検討してください. とても大きくなる場合は <ulink
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/">ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/</ulink>
を利用してください.
</para>
<para>レポートがファイリングされれば,
バグ報告の確認とトラッキング番号をメールで受け取るはずです.
このトラッキング番号を覚えておき, 問題に関する詳細情報を
<email>bug-followup@FreeBSD.org</email> に
メールで送って更新できるようにしてください. 例えば
<literal>"Re: kern/3377"</literal> のように,
この番号をサブジェクト行に使用してください.
すべてのバグレポートの追加情報は,
この方法で送付されなければいけません.</para>
<para>もしタイムリに (あなたの電子メール接続形態にもよりますが,
3日から 1週間) 確認を受けとれないとか, 何らかの理由で
&man.send-pr.1; コマンドが使用できない場合には, &a.bugs;
へメールを送り,
誰か代りにバグ報告を送付してもらうようたずねてください.</para>
</sect2>
<sect2>
<title>文書の変更</title>
<indexterm><primary>文書に関する提案</primary></indexterm>
<para>文書の変更は &a.doc; が監督しています. <link
linkend="contrib-general">バグ報告と一般的な論評</link>
に記述されているように <command>send-pr</command>
コマンドを使用して, 提案や変更
(どんな些細なものでも歓迎します!) を送ってください.</para>
</sect2>
<sect2>
<title>現存のソースコードの変更</title>
<indexterm><primary>FreeBSD-current</primary></indexterm>
<para>現存のソースコードへの追加または変更は,
いくらかトリッキーな仕事で あり, core の FreeBSD
開発の現状にあなたがどれだけ通じているかに大きく依存します.
<quote>FreeBSD-current</quote>として知られる FreeBSD
の特別な継続的リリースがあります. FreeBSD-current
は開発者の積極的な活動の便宜のために,
色々な方法で利用可能になっています. FreeBSD-current
の入手と使用方法についての詳しい情報については<link
linkend="current">最新の FreeBSD を追いかける</link>
を参照してください.</para>
<para>不幸にして古いソースをもとに仕事をすることは,
時々あなたの変更が時 代遅れ, または FreeBSD
への簡単な再統合に合わなくなっていることを意味します.
システムの現状に関する議論がおこなわれている &a.announce; と
&a.current; へ参加することで,
この可能性を最小限にすることができます.</para>
<para>完全な最新のソースを変更のベースにできることが確実になったと仮定して,
次のステップは FreeBSD
の保守担当者へ送る差分ファイルの生成です. これは &man.diff.1;
コマンドを使用しておこないますが, <quote>context
diff</quote>形式が好まれるようです. 例えば:</para>
<indexterm>
<primary><command>diff</command></primary>
</indexterm>
<screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen>
<para>または</para>
<screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen>
<para>これで指定されたソースファイルまたはディレクトリ階層に対するコンテキスト形式の差分が生成されます.
詳しい説明は
&man.diff.1; のマ ニュアルページを参照してください.</para>
<para>差分ファイル (&man.patch.1; コマンドでテストできます)
を作ったら, それらを FreeBSD
に含めてもらうようメールで送ってください. <link
linkend="contrib-general">バグ報告と一般的な論評</link>
に記述されているように &man.send-pr.1;
コマンドを使用してください. 差分ファイルだけを &a.hackers;
へ送ってはいけません. 途方にくれてしまいます!
私たちは多忙なので, あなたの提案に大変感謝します
(これはボランティアのプロジェクトです!).
すぐに取りかかることはできませんが, 処理されるまではちゃんと
PR データベースに残っています.
報告の概要に <literal>[PATCH]</literal>
と書いてあなたの提案を表明してください.
</para>
<indexterm>
<primary><command>uuencode</command></primary>
</indexterm>
<para>あなたがそうした方がいいと思う場合 (例えば,
ファイルの追加, 削除または名称変更など), 変更を
<command>tar</command> ファイルにまとめ, &man.uuencode.1;
プログラムにかけてください. shar
アーカイブも歓迎します.</para>
<para>例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良く分かっていないとか,
単に厳しいレビューをおこなっておらず,
リリースする準備ができていないなど,
あなたの変更が潜在的に不安定な性質をも つものである場合,
&man.send-pr.1; で送付するよりむしろ &a.core;
へ直接送ってください. コアチームメーリングリスト宛のメールは,
日々の仕事のほとんどを FreeBSD でおこなっている人たちの,
より小さなグルー プに届きます.
このグループもまた<emphasis>とても忙しい</emphasis>ことに注意して,
本当に必要な場合にコアチームの彼らにメールを送るだけにしてください.</para>
<para>コーディングスタイルに関する情報は
&man.intro.9; および &man.style.9;
を参照してください. コードを提出する前には,
少なくともこの情報を意識しておいてくださるようお願いします.
</para>
</sect2>
<sect2>
<title>新たなコードやメジャーな付加価値の高いパッケージ</title>
<para>重要な大きい仕事の寄贈や, 重要な新しい機能を
FreeBSD に追加する場合には, 変更点を tar/uuencode
したファイルにして送るか, それらを web や FTP
サイトへアップロードしてアクセスできるようにすることのどちらかが通常必要になります.
web や FTP サイトへのアクセスができないときは適切な FreeBSD
のメーリングリストで誰かに変更を受け取って貰ってください.</para>
<para>大量のコードを伴った仕事の場合,
コピーライトの神経過敏な問題が常に出てきます. FreeBSD
に含めるコードのコピーライトとして受け入れることができるのは,
以下の二つです:</para>
<orderedlist>
<indexterm><primary>BSD copyright</primary></indexterm>
<listitem>
<para>BSD コピーライト.
このコピーライトは<quote>権利に縛られない</quote>性格と商用企業にとって一般的な魅力をもつために最も好まれます.
FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを
FreeBSD
へ投資する気になった商業関係者による参加を積極的に奨励します.</para>
</listitem>
<indexterm><primary>GPL</primary><see>GNU General Public License</see></indexterm>
<indexterm><primary>GNU General Public License</primary></indexterm>
<listitem>
<para>GNU一般公有使用許諾, または<quote>GPL</quote>.
このライセンスはコードを商用目的に使用する場合に余分な努力が求められるため,
私たちにあまり評判が良いというわけではありません. しかし,
私たちは既に GPL 下の高品質なコード (コンパイラ,
アセンブラ, テキストフォーマッタ等) の提供を受けており,
私たちは現在それを必要としています. そのため,
このライセンスによる新たな貢献を拒絶するというのは愚かなことでしょう. GPL
下のコードはソースツリー の別の部分, 現在のところ
<filename>/sys/gnu</filename> か
<filename>/usr/src/gnu</filename> に入っています.
そのため, GPL が問題となるような人は,
誰でも簡単にそれとわかるようになっています.</para>
</listitem>
</orderedlist>
<para>これ以外のタイプのコピーライトによる寄贈は, FreeBSD
へ含めることを考慮する前に,
注意深いレビューを受けなければなりません.
作者が独自のチャネルを通して配布しており,
そのような変更をおこなうことを常に奨励している場合でも,
特に限定的な商用のコピーライトが適用される寄贈は一般に拒否されます.</para>
<para>あなたの作品に <quote>BSD-
スタイル</quote>のコピーライトを付けるには,
保護したいソースコードファイルすべての一番最初に以下のテキストを入れて,
<literal>%%</literal>
の間を適切な情報に置き換えください.</para>
<programlisting>Copyright (c) %%適切な年%%
%%あなたの名前%%, %%あなたの州%% %%郵便番号%%.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer as
the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
&#36;Id&#36;</programlisting>
<para>便宜をはかるため,
このテキストのコピーは次の場所に置いてあります.
<filename>/usr/share/examples/etc/bsd-style-copyright</filename>.
</para>
<para>(訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright
の日本語訳です.
ソースファイルに含めるものは原文の方であることに注意してご利用ください.
また, 原文との間に趣旨の差異が生じた場合,
原文の内容が FreeBSD プロジェクトの意思であるものとします.)</para>
<programlisting>
Copyright (C) [年]
[あなたの名前] All rights reserved.
ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の
条件を満たす場合に限り許可される:
1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の
否認声明文を保持しなければならない.
2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の
否認声明文を, 配布物と共に提供される文書および/または他の資料の中に
含めなければならない.
(訳注:ここから「否認声明文」です)
このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態''
で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま
らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献
者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代
替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務
中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし
て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ
生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過
失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も,
たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た
ない.
翻訳: 神田敏広
御協力 (五十音順・敬称略):
池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう
杢野 雅一, 横田@宇都宮
</programlisting>
</sect2>
<sect2>
<title>金銭, ハードウェアまたはインターネットアクセス</title>
<para>FreeBSD プロジェクトの目的を進めるための寄付や,
私たちと同じような ボランティアの細く長い!努力を,
私たちは常に喜んで受け入れています.
また一般的に私たちは自分達で周辺機器を買う資金が不足しているため,
周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です.</para>
<sect3 id="donations">
<title>資金の寄付</title>
<para>FreeBSD財団は, FreeBSD
プロジェクトの目標を推進するために確立された非営利的で税金を免除された財団です.
501(c)3 の実体として, 財団はコロラド州所得税ならびに,
アメリカ連邦主義者所得税を一般に免除されています.
免税実体への寄付は,
しばしば有税の連邦政府の所得から差し引くことができます.</para>
<para>寄付は以下に送ってください.
<address>
The FreeBSD Foundation
<street>7321 Brockway Dr.</street>
<city>Boulder</city>, <state>CO</state> <postcode>80303</postcode>
<country>USA</country>
</address>
財団はまだクレジットカード,
およびPayPalといった他の形式の支払いを受け入れることができません.</para>
<para>FreeBSD 財団に関するこれ以上の情報は
<ulink
url="http://people.FreeBSD.org/~jdp/foundation/announcement.html">The
FreeBSD Foundation -- an Introduction</ulink> を見てください.
財団への email での連絡は
<email>bod@FreeBSDFoundation.org</email>
へどうぞ.</para>
</sect3>
<sect3>
<title>ハードウェアの寄贈</title>
<indexterm><primary>寄贈</primary></indexterm>
<para>FreeBSD プロジェクトは,
次の3つのカテゴリのどんなハードウェアの寄贈も,
喜んで受け付けます:</para>
<itemizedlist>
<listitem>
<para>ディスクドライブ,
メモリまたは完全なシステムといった一般用途のハードウェアは,
<emphasis>資金の寄付</emphasis>の節にある
FreeBSD, Inc. の住所まで送っ てください.</para>
</listitem>
<listitem>
<para>進行中の受け入れテストのためのハードウェアが必要とされています.
新たなリリース毎に適切な逆行テストができるように,
私たちは現在, FreeBSD
がサポートするすべてのコンポーネントのテストラボを設置しよう としています.
私たちにはまだ,
たくさんの重要な部品 (ネットワークカード,
マザーボードなど) が不足していますので,
このような寄贈をしたいと思っているならば, &a.dg;
へコンタクトしてどの部品がまだ必要とされているかの情報を得てください.</para>
</listitem>
<listitem>
<para>現在 FreeBSD にサポートされていないハードウェアで,
サポートに追加して欲しいもの.
私たちが新しいハードウェアを受けとる前にそのタスクを引き受けてくれる開発者を探す必要があるため,
その部品を送る前に &a.core;
にコンタクトを取ってください.</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>インターネットアクセスの寄付</title>
<para>私たちは常に FTP, WWW や <command>cvsup</command>
の新しいミラーサイトを募集しています.
ミラーサイトになりたい場合には &a.hubs;
にコンタクトを取って, 詳しい情報を手に入れてください.</para>
</sect3>
</sect2>
</sect1>
</chapter>

File diff suppressed because it is too large Load diff

File diff suppressed because it is too large Load diff

View file

@ -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"

View file

@ -1,719 +0,0 @@
<?xml version="1.0" encoding="euc-jp" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.33
$FreeBSD$
-->
<chapter id="kerneldebug">
<title>カーネルデバッグ</title>
<para><emphasis>原作 &a.paul; and &a.joerg;</emphasis></para>
<para><emphasis>訳: &a.jp.yoshiaki;. 1997 年 3 月 18 日.</emphasis></para>
<sect1>
<title><command>gdb</command>
によるカーネルのクラッシュダンプのデバッグ</title>
<para>ここではクラッシュダンプ (crash dump : 訳注 この文脈では
kernel 自身
の異常によって停止した場合に出力されるイメージを指します)
によるカーネルデバッグの方法を示します。</para>
<para>ここではダンプするための十分なスワップ
(swap) の容量があるものとします。
もし複数のスワップパーティションを持ち、
最初のパーティションがダンプ
を保持するのに十分な大きさを持たない場合は
別のダンプデバイスを使うよ
うに (<literal>config kernel</literal> 行で)
カーネルのコンフィグをおこなうか、&man.dumpon.8;
コマンドを使って別のデバイスを示すことができます。&man.dumpon.8;
を使うもっともよい方法は変数 <literal>dumpdev</literal> を
<filename>/etc/rc.conf</filename> で設定することです。一般的には
<filename>/etc/fstab</filename> で設定されているスワップデバイスが
使われるでしょう。
スワップに使えないデバイスへのダンプ、
例えばテープへのダンプは現在サポートさ
れていません。カーネルのコンフィグは
<command>config <option>-g</option></command> によって行ってください。
<link linkend="kernelconfig"> FreeBSD
カーネルのコンフィグレーション </link>
には FreeBSD のカーネルの設定の詳細がありますので
参照してください。</para>
<para>&man.dumpon.8; コマンドを使ってどこへダンプするか
カーネルに伝えてください
(&man.swapon.8; によってそのパーティションが
スワップとして設定された
後でなければならないことに注意してください)。これは普通は
<filename>/etc/rc.conf</filename> や <filename>/etc/rc</filename>
で設定されます。あるいは
別の方法としてカーネルコンフィグレーションファイルの
<literal>config</literal> 行の <literal>dump</literal> 節で
ダンプデバイスをハードコードすることができます。
この方法はあまりよくは
ありません。カーネルがブート時に crash
する場合のクラッシュダンプを取り
たい時だけ使うべきです。</para>
<note>
<para>以下では <command>gdb</command>という用語は
<command>gdb</command>
を<quote>カーネルデバッグモード</quote>で動かしていることを意味します。
<command>gdb</command> を
<option>-k</option>オプションをつけて起動することで、
このモードになります。
カーネルデバッグモードでは、プロンプトが
<prompt>(kgdb)</prompt> に変わります。</para>
</note>
<tip>
<para>FreeBSD 3 およびそれ以前のシステムを使っているなら、
巨大なデバッグカーネルをそのままインストールするのではなく
strip されたデバッグ用カーネルをつくるべきでしょう。</para>
<screen>&prompt.root; <userinput>cp kernel kernel.debug</userinput>
&prompt.root; <userinput>strip -g kernel</userinput></screen>
<para>この手順は必須ではありませんが、ぜひ行なうことをおすすめします
(FreeBSD 4 およびそれ以降では、カーネルの <command>make</command>
の段階で自動的にこれが行なわれます)。
自動的に、あるいは上のコマンドを手動で実行してカーネルが strip
されたら、普通に <command>make install</command>
と実行し、カーネルをインストールして構いません。</para>
<para>FreeBSD の古いリリース (3.1 を含まない以前のもの) は、
標準で a.out カーネルを使っていることに注意してください。
これはシンボルテーブルが常に物理メモリ上に存在することを要求するため、
strip されていないデバッグカーネルに含まれる大きなシンボルテーブルは非常に無駄になります。
ELF カーネルを使った FreeBSD の最近のリリースでは、
そのような問題がなくなりました。</para>
</tip>
<para>カーネルを作った時にそのコピーを
<filename>kernel.debug</filename> という名前で作りましょう。
また、オリジナルに対して <command>strip
-g</command>を実行します。
オリジナルを普通にインストールします。また strip
していないカーネルも同様にインストールすることができますが、
シンボルテーブルの参照時間
がいくつかのプログラムでは劇的に増加するでしょう。また、
カーネル全体はブート時に読み込まれ
スワップアウトされないため数メガバイトの物理メ
モリが無駄になります。</para>
<para>例えばブートプロンプトで
新しいカーネルの名前をタイプすることによって、
新しいカーネルをテストした場合で、
再びシステムを動かすのに別のカーネ
ルで立ち上げることが必要な場合はブートプロンプトで
<option>-s</option>フラグ
を使いシングルユーザの状態にしてください。
そして以下のような操作をおこないます。</para>
<screen>&prompt.root; <userinput>fsck -p</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput> # /var/crash 用のファイルシステムを書き込み可能にする
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
&prompt.root; <userinput>exit</userinput> # ...マルチユーザモードへ移行</screen>
<para>ここに示した &man.savecore.8; は (現在動いているものとは別の)
カーネルのシンボル名の抽出をおこなうために使っています。
抽出はデフォルトで
は現在動いているカーネルに対しておこなわれ、
クラッシュダンプとカーネルシンボ
ルのくい違いのためにまったく何もしません
(訳注: そのためにオプション
で実際にダンプをおこしたカーネルを指定します)。</para>
<para>クラッシュダンプの起きた後に
<filename>/sys/compile/WHATEVER</filename>へ行き
<command>gdb</command>を動かします。<command>gdb</command>
より次のようにします。</para>
<screen><userinput>symbol-file kernel.debug</userinput>
<userinput>exec-file /var/crash/kernel.0</userinput>
<userinput>core-file /var/crash/vmcore.0</userinput></screen>
<para>こうすると、
クラッシュダンプを使ってカーネルソースを他のプログラムと同様に
デバッグすることができます。</para>
<para>次に <command>gdb</command>
での手順のセッションのログを示します。長い行は読
みやすくするために改行しました。また、
参照のために行番号を入れてあります。ただし、これは実際の
pcvt コンソールドライバの開発中の実際のエ
ラーのトレースです。</para>
<screen> 1:Script started on Fri Dec 30 23:15:22 1994
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
3:&prompt.root; <userinput>gdb -k kernel /var/crash/vmcore.1 </userinput>
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:<prompt>(kgdb)</prompt> <userinput>where</userinput>
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:<prompt>(kgdb)</prompt> <userinput>up 10</userinput>
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(&amp;frame, FALSE);
36:<prompt>(kgdb)</prompt> <userinput>frame frame-&gt;tf_ebp frame-&gt;tf_eip</userinput>
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-&gt;t_line].l_open)(dev, tp));
41:<prompt>(kgdb)</prompt> <userinput>list</userinput>
42:398
43:399 tp-&gt;t_state |= TS_CARR_ON;
44:400 tp-&gt;t_cflag |= CLOCAL; /* cannot be a modem (:-) */
45:401
46:402 #if PCVT_NETBSD || (PCVT_FREEBSD &gt;= 200)
47:403 return ((*linesw[tp-&gt;t_line].l_open)(dev, tp));
48:404 #else
49:405 return ((*linesw[tp-&gt;t_line].l_open)(dev, tp, flag));
50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD &gt;= 200) */
51:407 }
52:<prompt>(kgdb)</prompt> <userinput>print tp</userinput>
53:Reading in symbols for ../../i386/i386/cons.c...done.
54:$1 = (struct tty *) 0x1bae
55:<prompt>(kgdb)</prompt> <userinput>print tp-&gt;t_line</userinput>
56:$2 = 1767990816
57:<prompt>(kgdb)</prompt> <userinput>up</userinput>
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
62:#2 0xf0132c34 in spec_open ()
63:<prompt>(kgdb)</prompt> <userinput>up</userinput>
64:#3 0xf012d014 in vn_open ()
65:<prompt>(kgdb)</prompt> <userinput>up</userinput>
66:#4 0xf012a183 in open ()
67:<prompt>(kgdb)</prompt> <userinput>up</userinput>
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-&gt;sy_call)(p, args, rval);
74:<prompt>(kgdb)</prompt> <userinput>up</userinput>
75:Initial frame selected; you cannot go up.
76:<prompt>(kgdb)</prompt> <userinput>quit</userinput>
77:&prompt.root; <userinput>exit</userinput>
78:exit
79:
80:Script done on Fri Dec 30 23:18:04 1994</screen>
<para>上の出力についてのコメントをします。</para>
<variablelist>
<varlistentry><term>line 6:</term>
<listitem>
<para>これは DDB (後述) からのダンプです。このため
<quote>because you said to!</quote> という
panicコメントがつき、ページフォルトのトラップによって
DDBに入ったことが原因の、やや長いスタックトレー
スがあります。</para>
</listitem>
</varlistentry>
<varlistentry><term>line 20:</term>
<listitem>
<para>スタックトレースでのこれは
<function>trap()</function>関数の位置です。</para>
</listitem>
</varlistentry>
<varlistentry><term>line 36:</term>
<listitem>
<para>新しいスタックフレームを使用するように指定しています。
ただし、ここでこれを指定する必要ありません。
trap の場合、スタックフレームは正しい場所を指していると考えられるからです。
ソースコードの 403 行を見ると、<quote>tp</quote>
ポインタのアクセスが失敗しているか、
配列のアクセスが範囲外である可能性が高いことがわかります。</para>
</listitem>
</varlistentry>
<varlistentry><term>line 52:</term>
<listitem>
<para>怪しいポインタですが、
アクセスは正常におこなえました。</para>
</listitem>
</varlistentry>
<varlistentry><term>line 56:</term>
<listitem>
<para>ところが、明らかにポインタはゴミを指しています。これで
エラーを見つけました! (ここのコードの部分からはよくわかり
ませんが、
<literal>tp-&gt;t_line</literal>はコンソールデバイスの規定
する行を参照しているので、
もっと小さな整数でなければなりません。)</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1>
<title>DDD によるクラッシュダンプのデバッグ</title>
<para>カーネルのクラッシュダンプは <command>ddd</command>
のようなグラフィカルなデバッガで調べることもできます。
通常はコマンドラインで <option>-k</option> オプションをつけて
<command>ddd</command> を起動します。たとえば:</para>
<screen>&prompt.root; <userinput>ddd -k /var/crash/kernel.0 /var/crash/vmcore.0</userinput></screen>
<para>クラッシュダンプを <command>ddd</command>
のグラフィカルなインタフェースを使って
見ることができます。</para>
</sect1>
<sect1>
<title>突然ダンプした場合の解析</title>
<para>カーネルが予想もしない時にコアダンプして <command>config
-g</command>
を行ってコンパイルされていなかった場合にはどうしたら
よいでしょう。すべてが失われるわけではありません。
パニックを起こさないでください。</para>
<para>もちろん、クラッシュダンプを使えるようにする必要があります。
使い方は前述の部分を見てください。</para>
<para>カーネルのコンパイルディレクトリ
(<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>)
で、設定ファイルを編集します。以下の行のコメントを外します
(行が存在しなければ追加します):</para>
<programlisting>makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols</programlisting>
<para>カーネルを再構築しましょう。
Makefileのタイムスタンプの変更により、例えば <!-- kuriyama -
should be filename --> <emphasis remap=tt> trap.o
</emphasis>などのいくつかの他のオブジェクトファイルも作り直さ
れます。少しの幸運があれば、
<option>-g</option>オプションが追加されても作ら
れるコードは変更されず、いくらかのデバッグシンボル以外には
問題を
起こしたコードとそっくりな新しいカーネルを手に入れることが
できます。少なくとも &man.size.1;
コマンドで古い方と新しい方のサイズを比較すべきです。
これが食い違っていれば、
多分あきらめなければならないでしょう。</para>
<para>ダンプを使って前述のように動かして調べます。
デバッグシンボルは 必ずしも十分ではありません。
上の例ではスタックトレースでいくつかの関
数の行番号や引数リストが表示されないかもしれません。
もしより多くのデバッグシンボルが必要であれば、十分になるまで
適切なオブジェクトファイ ルを消して (makeして)
<command>gdb <option>-k</option></command> セッションを繰り返してください。</para>
<para>これは必ずしもうまく動くと保証はできません。
しかしほとんどの場合でうまくいくでしょう。</para>
</sect1>
<sect1>
<title>DDBを使ったオンラインカーネルデバッグ</title>
<para><command>gdb <option>-k</option></command>
は非常に高レベルのユーザインタフェースを提
供するオフラインデバッガですが、いくつかのことはできません。
(できないことの中で)
極めて重要なことはカーネルコードへのブレークポイ
ントの設定とシングルステップ実行です。</para>
<para>カーネルの低レベルデバッグが必要であれば、DDBと呼ばれる
on-lineデバッガが使えます。ブレークポイントの設定、
シングルステップのカーネルの実行、
変数の検査と変更などができます。
ただし、これはカーネルのソースファ
イルにアクセスすることはできません。
<command>gdb</command>のようにすべてのデ
バッグ情報にはアクセスできず、global と
static のシンボルにアクセスすることができるだけです。</para>
<para>カーネルに DDB
を含めるためにはコンフィグファイルに次のようなオプショ
ンを加えて、</para>
<programlisting>options DDB</programlisting>
<para>再構築をおこないます。(
FreeBSD のカーネルの設定の詳細については <link
linkend="kernelconfig">FreeBSD
カーネルのコンフィグレーション</link>を参照してくださ
い。</para>
<note>
<para>古いバージョンの起動ブロックを使っている場合、ですと、
デバッガのシンボルが完全にはロードされないかもしれません。
その時は起動ブロックを最新のものに更新してください。
新しい起動ブロックは、DDB シンボルを自動的にロードします。</para>
</note>
<para>DDB カーネルの実行において、
DDB に入るいくつかの方法があります。最初の、
最も早い方法はブートプロンプトが出ている時に
<option>-d</option>のブートフラグをタイプすることです。
カーネルはデバッグモードで起動し、デバイスのプローブ以前に
DDB に入ります。したがって、デバイスのプローブ/初期
設定ファンクションのデバッグができます。</para>
<para>2 つ目のシナリオはキーボードのホットキーで、通常は
Ctrl-Alt-ESC です。syscons ではホットキーは再設定することができ、
配付されているいくつかのキーマッピングでは別のキーに
再設定されていますので確認しておいてください。シリアルラインの
BREAK を使ってシリアルコンソールから DDB へ入ることを可
能にするオプションもあります
(カーネルコンフィグレーションファイルの <literal>options
BREAK_TO_DEBUGGER</literal>)。これは多くのつまらないシリ
アルアダプタが、例えばケーブルを引き抜いた時に
BREAK 状態を意味もなく
作り出してしまうのでデフォルトでは無効になっています。</para>
<para>3つ目は、DDB
を使うようになっているカーネルがパニック状態になると DDB
へ入るというものです。このため、
無人運転するマシンのカーネルに DDB を
入れるのは賢明ではありません。</para>
<para>DDB のコマンドはおおまかには <command>gdb</command>
のいくつかのコマンドと似て
います。おそらく最初にブレークポイントを
設定する必要があるでしょう。</para>
<screen><userinput>b function-name</userinput>
<userinput>b address</userinput></screen>
<para>数値はデフォルトでは 16 進数で、
シンボル名とはまったく異なります。16 進数で <literal>a-f</literal>
の文字で始まる場合は、先頭に <literal>0x</literal>
をつける必要があります(それ以外の数字の場合はどちらでもか
まいません)。<literal>function-name +
0x103</literal>のような単純な式を使うことができます。</para>
<para>割り込みされたカーネルから処理を続行するためには、</para>
<screen><userinput>c</userinput></screen>
<para>とタイプするだけです。
スタックのトレースには</para>
<screen><userinput>trace</userinput></screen>
<para>とします。</para>
<note>
<para>DDB にホットキーで入った場合は、カーネルはその
(ホットキーの) 割り込み
の処理を行っていますのでスタックトレースは
あまり役にたたないことに注意してください。</para>
</note>
<para>ブレークポイントを削除したい場合は、</para>
<screen><userinput>del</userinput>
<userinput>del address-expression</userinput></screen>
<para>とします。
最初の形式はブレークポイントにヒットしたすぐ後で使うことができ、
現在のブレークポイントを削除します。2 番目の形式では任意のブレー
クポイントを削除することができますが、
次の形式で得られるような正確な
アドレスを与えることが必要です。</para>
<screen><userinput>show b</userinput></screen>
<para>カーネルをシングルステップ実行させるには</para>
<screen><userinput>s</userinput></screen>
<para>としてみてください。これは関数呼出し先までステップ実行 (step
into function) するでしょう。
次のステートメントが終了するまでの DDBトレースは</para>
<screen><userinput>n</userinput></screen>
<para>によっておこなうことができます。</para>
<note>
<para>これは <command>gdb</command> の <command>next</command>
命令とは異ります。<command>gdb</command>の
<command>finish</command> 命令と似ています。</para>
</note>
<para>メモリ上のデータを調べるには (例として) 次のようにします。
<screen><userinput>x/wx 0xf0133fe0,40</userinput>
<userinput>x/hd db_symtab_space</userinput>
<userinput>x/bc termbuf,10</userinput>
<userinput>x/s stringbuf</userinput></screen>
word/halfword/byte 単位でアクセスをおこない、hex (16進)
/dec (10進) /
char (文字) /string (文字列) で表示します。
カンマの後ろの数字はオブジェク
トカウントです。次の 0x10 個の要素を表示するには、単純に</para>
<screen><userinput>x ,10</userinput></screen>
<para>とします。同様に次のように使うことができます。
<screen><userinput>x/ia foofunc,10</userinput></screen>
<function>foofunc</function>
の最初の 0x10 個の命令語をディスアセンブルし、
<function>foofunc</function>
の先頭からのオフセットとともに表示します。</para>
<para>メモリの内容を変更するには write コマンドを使います。</para>
<screen><userinput>w/b termbuf 0xa 0xb 0</userinput>
<userinput>w/w 0xf0010030 0 0</userinput></screen>
<para>コマンドモディファイアの
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>)
はデータを 書くサイズを定義し、
これに続く最初の式は書き込むアドレス、残りがこれ
に続く連続するメモリアドレスに書き込まれるデータになります。
</para>
<para>現在のレジスタ群の内容を知りたい場合は</para>
<screen><userinput>show reg</userinput></screen>
<para>とします。また、単一のレジスタの値を表示するには、例えば
<screen><userinput>p $eax</userinput></screen>
とします。また値の変更は</para>
<screen><userinput>set $eax new-value</userinput></screen>
<para>とします。</para>
<para>DDBからカーネルの関数を呼び出す必要がある場合は、単に</para>
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
<para>とします。return 値が出力されます。</para>
<para>動いているプロセスの &man.ps.1; スタイルの概要は</para>
<screen><userinput>ps</userinput></screen>
<para>です。</para>
<para>カーネルの失敗の原因の調査が終わったら、ここで再起動すべきです。
それまでの不具合により、カーネルのすべての部分が期待するような
動作をしているわけではないということを忘れないでください。
以下のうちいずれかの方法でシステムのシャットダウンおよび再起動を行ってください。</para>
<screen><userinput>panic</userinput></screen>
<para>カーネルをコアダンプしてリブートしますので、後で
<command>gdb</command>によってコアの高レベル解析をすることができます。
このコマンドは通常、一度
<command>continue</command>命令を使った後に
使うことになるでしょう。</para>
<screen><userinput>call boot(0)</userinput></screen>
<para> は動いているシステムを `clean' に shut
down するよい方法です。すべてのディスクを
<function>sync()</function> して最後にリブートします。
ディスクとカー
ネルのファイルシステムインタフェースが破損していない限り、
ほぼ完全に `clean' にシャットダウンするよい方法でしょう。</para>
<!-- kuriyama - ldquo? -->
<screen><userinput>call cpu_reset()</userinput></screen>
<para>は大惨事を防ぐための最後の手段で 「赤い大きなボタン」
を押すのとほとんど同じです (訳注:
リセットボタンを押すのとほぼ同じであるという意味です)。</para>
<para>短いコマンドの要約は</para>
<screen><userinput>help</userinput></screen>
<para>をタイプします。ただし、デバッグセッションのために
&man.ddb.4; の
マニュアルページのプリントアウトを用意しておくことを
強くお奨めします。
カーネルのシングルステップ中にオンラインマニュアルを
読むことは難しいということを覚えておいてください。</para>
</sect1>
<sect1>
<title>リモート GDB を使ったオンラインカーネルデバッグ</title>
<para>この機能は FreeBSD 2.2 からサポートされました。
これは本当にすばらし い機能です。</para>
<para>GDB はすでにかなり以前より
<emphasis>リモートデバッグ</emphasis> をサポートしてい ます。
これはシリアル回線を使い非常に単純なプロトコルで行ないます。
もちろん、この方法では今までに示した方法とは違い、
2 台のマシンが必要になります。1 台はデバッグ環境のためのホストで、
すべてのソースとす
べてのシンボルを含んだバイナリのコピーを持っています。もう 1 台は
ターゲットマシンで、同一のカーネルのコピー (ただしデバッグ情報は
取り除いてあるもの) を単に実行するためのものです。</para>
<para>この場合、カーネルのコンフィグレーションは <command>config
-g</command> で行な い、<option>DDB</option>
を含めなくてはなりません。そうして通常通りコンパイルし ます。
こうして作ったバイナリファイルはデバッグ情報のために非常に大き
くなります。このカーネルをターゲットマシンにコピーして
<command>strip -x</command> でデバッグシンボルを取り除きます。
そして <option>-d</option> ブートオプションを使いブートします。
sio デバイスにフラグ 0x80 が設定されているターゲットマシンの
シリアル回線を、デバッグホストのいずれかのシリアル回線に
つないでください。
それからデバッグ (訳注:ホスト) マシン上で、ターゲットとなって
いるカーネルのコンパイルディレクトリで <command>gdb</command> を起動します:</para>
<screen>&prompt.user; <userinput>gdb -k kernel</userinput>
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...
<prompt>(kgdb)</prompt> </screen>
<para>リモートデバッグセッションの初期化
(1 番目のシリアルポートを使用することの設定)
を以下のように行ないます。</para>
<screen><prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput></screen>
<para>次にターゲットマシン (デバイスのプローブ直前で DDB
に入っています) で次のように入力します:</para>
<screen>Debugger("Boot flags requested debugger")
Stopped at Debugger+0x35: movb $0, edata+0x51bc
<prompt>db&gt;</prompt> <userinput>gdb</userinput></screen>
<para>DDB は次のような出力を返すでしょう。</para>
<screen>Next trap will enter GDB remote protocol mode</screen>
<para><command>gdb</command>と入力するたびにリモート GDB
とローカル DDB が交互に切り替わります。
トラップをすぐに起こすために単に ``s'' (step) と入力して下さい。
そうするとホストの GDB はターゲットのカーネルの制御を行なうよ
うになります。</para>
<screen>Remote debugging using /dev/cuaa0
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
at ../../i386/i386/db_interface.c:257
<prompt>(kgdb)</prompt></screen>
<para>このセッションではソースコードへのフルアクセスや Emacs の
window 上 の gud-mode (これは別の Emacs window
に自動的にソースコードを表示します) で動かすなど、通常の GDB
セッションでできることのほとんどのことができます。</para>
</sect1>
<sect1>
<title>GDB を使ったローダブルモジュールのデバッグ</title>
<para>モジュール内部で発生する panic のデバッグや、
動的モジュールを使っているマシンを GDB
でリモートデバッグしている場合、
モジュールのシンボル情報を得る方法を
GDB に伝える必要があります。</para>
<para>まず、モジュールをデバッグ情報を含めて構築する必要があります。</para>
<screen>&prompt.root; <userinput>cd /sys/modules/linux</userinput>
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
<para>リモート GDB を使っている場合は、
ターゲットマシンで <command>kldstat</command> を実行することで
モジュールがどこにロードされたか調べることが可能です。</para>
<screen>&prompt.root; <userinput>kldstat</userinput>
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</screen>
<para>クラッシュダンプをデバッグしている場合、
<literal>linker_files->tqh_first</literal> から始まる
<literal>linker_files</literal> リストを調べ、
探している <literal>filename</literal> が見つかるまで
<literal>link.tqe_next</literal> ポインタをたどる必要があります。
エントリ中の <literal>address</literal> メンバが、
モジュールのロードアドレスです。</para>
<para>次に、モジュール内の text セクションのオフセットを調べます。</para>
<screen>&prompt.root; <userinput>objdump --section-headers /sys/modules/linux/linux.ko | grep text</userinput>
3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2
10 .text 00007f34 000062d0 000062d0 000062d0 2**2</screen>
<para>必要なのは <literal>.text</literal> セクションで、
上の例では 10 にあたります。その 4 番目の 16 進数フィールド
(全部で 6 フィールドあります) が、ファイル中の text
セクションのオフセットになります。
そして、このオフセットをモジュールのロードアドレスに加算すると
モジュールのコードの再配置アドレスを求めることができます。
この例では 0xc0adc000 + 0x62d0 = 0xc0ae22d0 です。
GDB コマンド <command>add-symbol-file</command> を使い、
得られたモジュールの情報をデバッガに伝えるには、次のようにします。</para>
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0</userinput>
add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0?
(y or n) <userinput>y</userinput>
Reading symbols from /sys/modules/linux/linux.ko...done.
<prompt>(kgdb)</prompt></screen>
<para>これで、モジュール内のすべてのシンボルにアクセスできるようになります。</para>
</sect1>
<sect1>
<title>コンソールドライバのデバッグ</title>
<para>DDBを動かすためにはコンソールドライバが必要ですから、
コンソールドラ イバ自身に不具合のある場合は複雑になります。
シリアルコンソールを利 用する方法 (ブートブロックを変更するか
<prompt>Boot:</prompt>プロンプトで
<option>-h</option>と入力する) を思い出してください。
そして標準ター ミナルを最初のシリアルポートに設定します。DDBは、
もちろんシリアルコンソールを含むいずれの
コンソールドライバの設定でも動作します。</para>
</sect1>
</chapter>

View file

@ -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"

View file

@ -1,202 +0,0 @@
<?xml version="1.0" encoding="euc-jp" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.23
$FreeBSD$
-->
<chapter id="kernelopts">
<chapterinfo>
<authorgroup>
<author>
<firstname>J&ouml;rg</firstname>
<surname>Wunsch</surname>
<contrib>原作</contrib>
</author>
</authorgroup>
</chapterinfo>
<title>カーネルコンフィグレーションの
新しいオプションを追加する</title>
<para><emphasis>訳: &a.jp.yoshiaki;, 1996 年 12 月 29 日.</emphasis></para>
<note>
<para>この章をお読みになる前に <link
linkend="kernelconfig">FreeBSD
カーネルのコンフィグレーション</link> の章の内容を
理解しておいてください.</para>
</note>
<sect1>
<title>そもそも<emphasis>カーネル
オプション</emphasis>って何?</title>
<para>カーネルオプションの使い方は基本的には
<link linkend="kernelconfig-options"> FreeBSD
カーネルのコンフィグレーション </link>
の章に書いてあります.
そこには<quote>伝統的な形式</quote>と<quote>新しい形式</quote>のオプションの説明があります.
すべてのカーネルのオプションを新しい形式のものに置き換え,
コンフィグファイル
を修正して &man.config.8; を実行した後に
カーネルのコンパイルディレクトリで
<command>make depend</command> を実行すれば,
ビルドプロセスが自動的に変更された
オプションを検出し, 必要なファイルだけを
再コンパイルするようにすることが
最終的な目的です. &man.config.8;
を実行するたびに古いコンパイルディレクトリ
を消してしまう現在のやりかたは,
やがておこなわれなくなるでしょう.</para>
<para>基本的に, カーネルオプションはカーネルのコンパイルプロセスの
C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make
できる ようにするためには, 対応する部分のカーネルソース
(またはカーネルの <filename>.h</filename> ファイル)
がオプションを使えるようにあらかじめ書かれていなければ
なりません.
つまりデフォルト値をコンフィグファイルのオプションで置き換え
られるようになっていなければなりません.
これは普通は次のようになっています.</para>
<programlisting>#ifndef THIS_OPTION
#define THIS_OPTION (some_default_value)
#endif /* THIS_OPTION */</programlisting>
<para>この場合,
管理者がコンフィグファイルのオプションに別の値を記述すれば,
デフォルトの設定を打ち消して新しい値に置き換えられます. 当然,
新しい値はプリプロセッサによってソースコード中で
置き換えられるため, デフォルトの値が使われていた場所において C
の式として有効な値でなければ なりません.</para>
<para>また, 単に特定のコードを有効にするか
無効にするかを設定するための
値を持たないオプションも作ることができます.</para>
<programlisting>#ifdef THAT_OPTION
[あなたのコードが入ります]
#endif</programlisting>
<para>コンフィグファイルに <literal>THAT_OPTION</literal>
と記述するだけで (値の有無 にかかわらず)
対応する部分のコードが組み込まれます.</para>
<para>C 言語にくわしい人であれば
<quote>コンフィグオプション</quote>とされているもの
は少なくとも一つの <literal>#ifdef</literal>
で参照されているということはすぐに理解 できるでしょう. ところで,
ごく一部の人たちは次のようなものを試して
みようとするかもしれません.</para>
<programlisting>options notyet,notdef</programlisting>
<para>このようにコンフィグファイルをしておくと,
カーネルのコンパイルは うまく行きません.</para>
<para>(訳注: たとえば MATH_EMULATE のように
有効/無効のためのパラメータを 持たないオプションの場合,
無効とするためのパラメータをつけて, オプション
で「無効とする」と明示することはできないという意味です)</para>
<para>明らかに,
任意のオプション名がカーネルソースツリー全体でどのように
使われているかを追いかけることは非常に難しいことです. このことが
<emphasis>新しい形式</emphasis>
のオプションの機構を採り入れる理由の背景です.
ここではそれぞれのオプションは
カーネルコンパイルディレクトリにある別々の
<filename>.h</filename> ファイルとなり,
<filename>opt_<replaceable>foo</replaceable>.h</filename>
という名前に されます. この方法では, 通常の Makefile
の依存関係が適用され, <command>make</command>
プログラムはオプションが変更された時に再コンパイルが必要な
ものを見つけることができます.</para>
<para>古い形式のオプションの機構は,
局部的なオプションや実験的なオプション
のような一時的に利用されると考えられるオプションにおいては
有効です. つまり <emphasis remap=tt>#ifdef</emphasis>
をカーネルのソースに追加するのは簡単であり,
それがそのままカーネルコンフィグオプションになります. この場合,
管理者はオプションの利用において
依存関係を把握しておく責任があります (また,
手動でカーネルの一部分を
強制的に再コンパイルする必要があるかもしれません).
サポートされている
オプションのすべてについて一つでも変更があると, &man.config.8;
は サポートされていないオプションがコンフィグファイルの中に
あるという警告 を出しますが, カーネルの Makefile
内にはそれを含めます.</para>
</sect1>
<sect1>
<title>ではどのようにして追加するのでしょう?</title>
<para>最初に <filename>sys/conf/options</filename> (または
<filename>sys/<replaceable>&lt;arch&gt;</replaceable>/conf/options.<replaceable>&lt;arch&gt;</replaceable></filename>, たとえば <filename>sys/i386/conf/options.i386</filename>)
を編集し, 新しいオプション を含めるのに最適な
<filename>opt_<replaceable>foo</replaceable>.h</filename>
ファイルを選びます.</para>
<para>新しいオプションの必要がなくなったとしたら,
これを取り除きます. たとえば, SCSI
サブシステムに関するすべてのふるまいについてのオプション
の変更は <filename>opt_scsi.h</filename> に入れられます.
デフォルトでは, 適切 なオプションファイルに単に記述されます.
たとえば <literal>FOO</literal> であれば 値は対応するファイルの
<filename>opt_foo.h</filename> に格納されます. これは右端に別
のファイル名を書いて置き換えることができます.</para>
<para>新しいオプションを加えるのに使えそうな
<filename>opt_<replaceable>foo</replaceable>.h</filename>
がない場合は新しい名前を作ってください. 意味のある名前を作り
<filename>options[<replaceable>.&lt;arch&gt;</replaceable>]</filename>
ファイル に新しいセクションのコメントをつけてください.
&man.config.8; は自動的
に変更を検出して, 次の実行からは (訳注: 新しい
<filename>.h</filename>) ファイル を作ります.
ほとんどのオプションはヘッダファイルに入れられます.</para>
<para>大量のオプションを一つの
<filename>opt_<replaceable>foo</replaceable>.h</filename>
にまとめると
コンフィグファイルの一つのオプションを変更したときに
多くのファイルが 再コンパイルされる原因になります.</para>
<para>新しいオプションに依存するカーネルファイルは
最終的には見つけ出されます.
ただし, オプションを作っただけで対応するソースがどこにもない場合は別です.
<screen>&prompt.user; <userinput>find /usr/src/sys -type f | xargs fgrep NEW_OPTION</userinput></screen>
オプションに対応するソースを見つけるのに上記のコマンドは便利です.
見つけたすべてのファイルで編集, 追加をおこないます.
<programlisting>#include "opt_foo.h"</programlisting>
<emphasis>ファイルの先頭の</emphasis>, すべての
<literal>#include &lt;xxx.h&gt;</literal> より前に入れます.
この場合, オプションによって次のようにしてデフォルト値
を持たせている標準のヘッダファイル内の値を置き換えるため,
順番は非常に 重要です.
<programlisting>#ifndef NEW_OPTION
#define NEW_OPTION (something)
#endif</programlisting>
システムヘッダファイル (たとえば
<filename>/usr/include/sys/</filename> にある ファイル)
をオプションで置き換えることは, ほとんどの場合で失敗します.
そうすると, ヘッダファイルを深刻な状態に破壊してしまうので,
include しないとオプションの値によって
不整合が起きてしまう場合を除き, それらの ファイルに
<filename>opt_<replaceable>foo</replaceable>.h</filename>
を include しないでください.
そう, 現在このような例がいくつか存在していますが,
必ずしも正しい方法 ではありません.</para>
</sect1>
</chapter>

View file

@ -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"

View file

@ -1,506 +0,0 @@
<?xml version="1.0" encoding="euc-jp" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.28
$FreeBSD$
-->
<chapter id="policies">
<chapterinfo>
<authorgroup>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
<contrib>寄稿: </contrib>
</authorgroup>
</chapterinfo>
<title>ソースツリーのガイドラインおよび方針</title>
<para><emphasis>訳者: &a.jp.mihoko;、1996 年 9 月 6 日</emphasis></para>
<para>本章は、FreeBSD
のソースツリーについてのさまざまなガイドラインや
ポリシーについて書かれています。</para>
<sect1 id="policies-maintainer">
<title>Makefile 中の <makevar>MAINTAINER</makevar></title>
<indexterm><primary>port 保守担当 (ports maintainer)</primary></indexterm>
<para>1996 年 6 月</para>
<para>FreeBSD 配布物の特定の部分が、一人の人やグループによって保守
されている場合は、ソースツリーの当該
<filename>Makefile</filename> に
<programlisting>MAINTAINER= email-addresses</programlisting>
が付け加えられています。これを記述することによって、
この部分が誰によって保守管理されているかを世界中のユーザに
伝えることができます。</para>
<para>この意味は次のとおりです:</para>
<para>保守担当者がそのコードを所有し、そのコードに対する責任を持っ
ています。すなわち、
その人がそのコードに関するバグの修正やトラブル報告
に対する回答をします。また、
そのコードが寄贈ソフトウェアの場合には、そのソフトウェアの
新しいバージョンに適切に追従させる作業をその人が行い
ます。</para>
<para>保守担当者が決められているディレクトリに対して
変更をおこなう場合は、変更をおこなう前に、
その変更内容を保守担当者に送って、
保守担当者にレビューをしてもらってください。保守担当者が、
電子メールに一定期間応答しない場合にのみ、
保守担当者がレビューすることなしに、
変更をおこなうことが認められます。しかしながら、
そのような場合でも可能な限り、変更点を第三者にレビュー
してもらうようにしてください。</para>
<para>もちろん、この義務を引き受けることができない人やグループを
保守管理者として追加することはできません。また、
保守管理者がソースツリー管理者 ("committer") である必要は
ありません。</para>
</sect1>
<sect1 id="policies-contributed">
<sect1info>
<authorgroup>
<author>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
<contrib>寄稿: </contrib>
</author>
<author>
<firstname>David</firstname>
<surname>O'Brien</surname>
</author>
</authorgroup>
<!-- June 1996 -->
</sect1info>
<title>寄贈ソフトウェア</title>
<indexterm><primary>寄贈ソフトウェア</primary></indexterm>
<para><emphasis>訳者: &a.jp.mihoko;</emphasis></para>
<para>FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD
プロジェクト以外のところで保守されています。歴史的な経緯から、
私たちはこれを <emphasis>寄贈</emphasis> ソフトウェアと
呼んでいます。<command>perl</command> や <command>gcc</command>
<command>patch</command> などがその例です。</para>
<para>ここ数年来、この種のソフトウェアの取り扱いには、
さまざまな方法が 取られてきましたが、
どの方法にもいくつかの利点と欠点があります。
これまで欠点のない明確な方法はありませんでした。</para>
<para>議論した結果、これらの方法のうちの一つが
<quote>公式な</quote> 方法として選択されました。その方法が、今後、
この種のソフトウェアを取り込む場合に、使用されます。その上、
この方法では、だれもが (cvs
にアクセス権のない人でさえ) <quote>公式</quote>
バージョンのソースに対する差分を簡単に得ることができます。
これは古い方法にはなかった大きな利点です。ですから、
既存の寄贈ソフトウェアも、
この方法に収束していくことを強く望んでいます。
この方法を使用することにより、寄贈ソフトウェアの主な開発者に、
変更点を返すのがとても容易になります。</para>
<para>しかしながら結局、寄贈ソフトウェアの取扱は、
実際に作業を行っている人々に委ねられています。
もしこの方法を使用することが、その人が扱っているパッケージには
極端に合わないような場合には、コアチームの承認さえあれば、
これらのルールに反しても、
他の開発者の一般的な合意は得られるでしょう。
将来にわたってパッケージを保守できるということは、
大変重要な事柄に なってきます。</para>
<note>
<para>RCS のファイルフォーマットと CVS
のベンダブランチの使用には不幸な設計上の制限があります。
したがって、
ベンダブランチの内容をいまだに引きずっているファイルに
対して小さな、些細な変更、そして / あるいは
膨大な変更を加えることには、
<emphasis>強い反対があります</emphasis>。
<quote>誤字訂正</quote> はもちろんこの中に入りますし、<!--
kuriyama - cosmetic? -->
しかも <quote>膨大な</quote> の範疇に入るので、リビジョンが
1.1.x.x
であるファイルに対する誤字訂正は避けられることになっています。
一文字の変更したことによるリポジトリの肥大は、
非常に劇的なものになり得るのです。</para>
</note>
<para>プログラミング言語 <application>Tcl</application> は、
この方法が活用されているよい例になっています:</para>
<para><filename>src/contrib/tcl</filename> には、
このパッケージの保守管理者が配布したソースが含まれています。
この中からは FreeBSD に完全には適用
できない部分が削除されています。Tcl の場合は、
<filename>mac</filename>、<filename>win</filename>、
<filename>compat</filename> というサブディレクトリは、FreeBSD
に取り込む前に削除されていました。</para>
<para><filename>src/lib/libtcl</filename> には、
ライブラリを生成したり、ドキュ
メントをインストールする際に使用される、標準の
<filename>bsd.lib.mk</filename> の規則を使用した
<command>bmake</command> スタイルの
<filename>Makefile</filename> だけが含まれています。</para>
<para><filename>src/usr.bin/tclsh</filename> には、
<filename>bsd.prog.mk</filename> 規則を使用して、
<command>tclsh</command>
プログラムや関連するマニュアルページを生成 / インストールする
bmake スタイルの <filename>Makefile</filename>
だけが含まれています。</para>
<para><filename>src/tools/tools/tcl_bmake</filename> には、Tcl
ソフトウェアを更新する必要が生じたときの助けになる 2 つのシェルス
クリプトが含まれています。これらは、
ソフトウェアを構築するのに使用したり、
インストール対象になるソフトウェアではありません。</para>
<para>ここ重要なのは、<filename>src/contrib/tcl</filename>
ディレクトリが、規則にしたがっ て作られているということです。
つまり、できるだけ FreeBSD に特化した
変更をおこなわないようにしたソースを (RCS
のキーワードを拡張しないで、CVS のベンダブランチに) おくようにし
ています。<!-- kuriyama - easyimport -->
<hostid>freefall</hostid> 上の「簡易取り込み」ツールは、
寄贈ソフトウェアを取り込む手助けとなります。けれども、
このツールの実行方法に疑問が生じた場合は、まずはじめに質問して、
失敗をしないようにしてください。そして、
その疑問を <quote>解決して</quote> からツールを使用してください。
CVS に寄贈ソフトウェアを取り込む際には、
事故があってはいけません。
よくあるような間違いをおかさないように、
十分注意してください。</para>
<para>先ほど述べたように、残念なことに CVS
にはベンダブランチという設計制限があります。このため、CVS
に寄贈ソフトウェアを取り込むには、オリジナル配布ソースに
適用されるベンダからの <quote>公式</quote> パッチと、
ベンダブランチに逆輸入された 結果が必要です。
ベンダブランチの一貫性を破壊したり、将来、
新しいバージョンを取り込む
時に衝突を起こしてしまったりというような
困難な事態に陥らないようにしなければなりません。そのために、
FreeBSD が管理しているバージョンに対して、
公式パッチを決して当ててはいけませんし、公式パッチを "commit"
してはいけません。</para>
<para>多くのパッケージが、他のアーキテクチャや他の環境と FreeBSD
との互換性を保ためのファイルをいくつか含んでいます。そこで、
スペースを節約するために、FreeBSD
にとっては無意味な配布ツリー上の一
部を削除することが許されています。けれども、
削除されずに残ったファイルに対する、著作権の通知やリリース
ノートのような情報を含んだファイルは、決して削除しては
<emphasis>いけません</emphasis>。</para>
<para><command>bmake</command> <filename>Makefile</filename>
が何らかのユーティリティによって、配布ツリー
から自動的に生成できると、うまくいけば、新しいバージョンへの
アップグレードをより簡単におこなうことができます。
もしこのようなユーティリティを作成できた場合には、将来の管理者に
とって便利になるように、移植の際に、
<filename>src/tools</filename> ディレクトリ上に、(必要に応じて)
そのユーティリティを必ずチェックインしてください。</para>
<para><filename>src/contrib/tcl</filename>
レベルのディレクトリには、<filename>FREEBSD-upgrade</filename>
と 呼ばれるファイルが追加されており、そのファイルでは
次のような内容が記述されています。</para>
<itemizedlist>
<listitem>
<para>ディレクトリ上に存在するファイル</para>
</listitem>
<listitem>
<para>オリジナルの配布物をどこから入手すればよいか また、
公式配布 サイトはどこか</para>
</listitem>
<listitem>
<para>オリジナルの作者にパッチを送り返すためには、
どこに送ればよいか</para>
</listitem>
<listitem>
<para>FreeBSD に特化した変更点の概要</para>
</listitem>
</itemizedlist>
<para>しかしながら、寄贈ソースと一緒に
<filename>FREEBSD-upgrade</filename> ファイルを
取り込まないでください。それよりむしろ、
(訳注: このファイルを) 初回に取り込んだ後は、コマンド <command>cvs
add FREEBSD-upgrade ; cvs ci</command> を実行してください。
<filename>src/contrib/cpio</filename> を例にすると、
次のようになります:</para>
<programlisting>このディレクトリは「ベンダ」ブランチ上のオリジナル配布ファイル
の初期ソースが含まれています。いかなる事情があっても、
パッチや 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&lt;version&gt;' \
src/contrib/cpio GNU v&lt;version&gt;
たとえば、バージョン 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</programlisting>
</sect1>
<sect1 id="policies-encumbered">
<title>ソース管理上注意が必要なファイル (Encumbered Files)</title>
<para> 場合によっては FreeBSD のソースツリーの中にソース管理上
注意が必要なファイルを含む必要があるかも知れません。例えば、デバイス
を操作する前に、そのデバイスに小さなバイナリコードをダウンロード
する必要があり、しかも我々が そのソースコードを持っていない場合、
そのバイナリファイルのことをソース管理上注意が必要である (encumbered)
と言います。
以下に挙げるガイドラインでは、ソース管理上注意が必要なファイルを
FreeBSD ソースツリーにいれる方法を示します。
</para>
<orderedlist>
<listitem>
<para>システムの CPU(s) によってインタプリタされたり
実行されたりするファイルで、しかもソース形式でないファイルは
すべて、ソース管理上注意が必要なファイルです。</para>
</listitem>
<listitem>
<para>BSD または GNU よりも制限されたライセンスを持つファイルは
すべて ソース管理上注意が必要なファイルです。</para>
</listitem>
<listitem>
<para>ハードウェアによって使用されるダウンロード可能な
バイナリコードを含むファイルは、(1) または (2) の条件が
当てはまらなければ、ソース管理上注意が必要なファイル
ではありません。
そのようなファイルはアーキテクチュアに依存しない
ASCII 形式 (file2c または uuencode が推奨されます) で保存
します。</para>
</listitem>
<listitem>
<indexterm><primary>コアチーム (core team)</primary></indexterm>
<para>ソース管理上注意が必要なファイルはすべて、CVS リポジトリ
に加える前に、
<link linkend="staff-core">コアチーム (core team)</link> からの特別な承認
が必要です。</para>
</listitem>
<listitem>
<para>ソース管理上注意が必要なファイルは <filename>src/contrib</filename>
または <filename>src/sys/contrib</filename> に入ります。</para>
</listitem>
<listitem>
<para>すべてのモジュールは一緒に置きます。ソース管理上とくに注意
を必要としないコードとコードを共有していない限りは、
モジュールの置場を分ける必要はありません。</para>
</listitem>
<listitem>
<para>オブジェクトファイルは
<filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename> と命名されます。</para>
</listitem>
<listitem>
<para>カーネルファイル</para>
<orderedlist>
<listitem>
<para>必ず
<filename>conf/files.*</filename> (構築を簡単にするため)
に記述するようにして下さい。</para>
</listitem>
<listitem>
<para>必ず <filename>LINT</filename> に記述して下さい、
ただし、それをコメントアウトすべきかどうかは
<link linkend="staff-core">Core team</link> がその都度
判断します。
もちろん <link linkend="staff-core">Core team</link> は
あとでそれを変更することもできます。</para>
</listitem>
<listitem>
<indexterm><primary>リリースエンジニア (release engineer)</primary></indexterm>
<para><link linkend="staff-who">リリースエンジニア</link>
は、それをそのリリースにいれるかどうかを決定します。</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>ユーザランドのファイル</para>
<orderedlist>
<listitem>
<para><link linkend="staff-core">Core team</link> は、そ
のコードが <command>make world</command> の中で構築される
べきかどうかを決定します。</para>
</listitem>
<listitem>
<para><link linkend="staff-who">リリースエンジニア</link>
は、それをそのリリースにいれるかどうかを決定します。</para>
</listitem>
</orderedlist>
</listitem>
</orderedlist>
</sect1>
<sect1 id="policies-shlib">
<sect1info>
<authorgroup>
<author>
<firstname>Satoshi</firstname>
<surname>Asami</surname>
<contrib>寄稿: </contrib>
</author>
<author>
<firstname>Peter</firstname>
<surname>Wemm</surname>
</author>
<author>
<firstname>David</firstname>
<surname>O'Brien</surname>
</author>
</authorgroup>
<!-- 9 Dec 1996 -->
</sect1info>
<title>共有ライブラリ</title>
<para>もしあなたが共有ライブラリをサポートする機能を port
に追加した り、
共有ライブラリをサポートしていない他のソフトウェアに追加する
場合には、共有ライブラリのバージョン番号を次の規則にしたがって
つけてください。一般的には、この規則は、
ソフトウェアのリリースバージョンとは全く関係ありません。</para>
<para>共有ライブラリを作成する三つの重要な規則は
次の通りです:</para>
<itemizedlist>
<listitem>
<para><literal>1.0</literal> から始める</para>
</listitem>
<listitem>
<para>過去のバージョンに互換性のある変更の場合は、
マイナー番号を増やす (ELF システムでは
マイナー番号が無視されることに注意して下さい)</para>
</listitem>
<listitem>
<para>互換性のない変更の場合は、メジャー番号を増やす</para>
</listitem>
</itemizedlist>
<para>例えば、機能追加とバグ吸収の場合は、
マイナー番号を増やします。機能削除、
関数呼び出しのシンタックスなどが変更された場合は、
強制的にメジャー番号を変更します。</para>
<para>メジャー.マイナーー
(<replaceable>x</replaceable>,<replaceable>y</replaceable>)
の形式のバージョン番号を使用します。FreeBSD における
a.out 形式のダイナミックリンカは、<replaceable>
x</replaceable>.<replaceable>y</replaceable>.<replaceable>z
</replaceable> という形式のバージョン番号 は扱えません。
この場合、<replaceable>y</replaceable> の後のバージョン番号
(つまり三つ目の数字) は、
どのライブラリがリンクされているかを決めるために、共有ライブラ
リ番号を比較する際に、すべて無視されます。
<quote>小さな</quote> リビジョンだけが
異なる二つの共有ライブラリが指定 されると、
<command>ld.so</command> は、
リビジョンの大きい方の共有ライブラリを リンクします。すなわち、
もしあなたが <filename>libfoo.so.3.3.3</filename> をリンク
していたとすると、リンカは頭の <literal>3.3</literal>
という部分だけを認識し、<replaceable>libfoo.so.3</replaceable>
ではじまり その後に <replaceable>3
以上の数字</replaceable>が続くもののうち、
<replaceable>最も大きい番号</replaceable>
の付いているライブラリをリンクします。</para>
<note>
<para><command>ld.so</command> はいつも最も大きい
<quote>マイナー</quote> リビジョンのものを使うことに
注意してください。例えば、プログラムがはじめ
<filename>libc.so.2.0</filename> を リンクしていたとしても、
<filename>libc.so.2.0</filename> よりも
<filename>libc.so.2.2</filename> を優先して使用します。</para>
</note>
<para>さらに、ELF ダイナミックリンカはマイナーバージョンを全く扱いません。
しかし、作成した <filename>Makefile</filename> がそのようなシステムでも
「きちんと動作できる」ように、メジャー番号およびマイナー番号を
指定する必要があります。
</para>
<para>移植されていないライブラリに対しては、
共有ライブラリのバージョン番号はリリースごとに一度だけ変更し、
また、主要な共有ライブラリのバージョン番号は、OS の主リリースごとに
一度だけ変更する、というのが私たちのポリシーです。
つまり、X.0 は (X+1).0 になります。
あなたがシステムライブラリのバージョン番号を上げた場合は、
<filename>Makefile</filename> の commit ログを確認してください。
結果としてそのリリースには、共有ライブラリのバージョン番号が
アップデートされた <filename>Makefile</filename>
に入るので、最初にその変更を 確かめるのがソースツリー管理者
("committer") の責務です。その後のどんな変更も、
そのリリースには入りません。</para>
</sect1>
</chapter>

View file

@ -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"

File diff suppressed because it is too large Load diff

View file

@ -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"

File diff suppressed because it is too large Load diff