diff --git a/ja/handbook/booting.sgml b/ja/handbook/booting.sgml index 3679b55c79..e975c5fad1 100644 --- a/ja/handbook/booting.sgml +++ b/ja/handbook/booting.sgml @@ -1,183 +1,183 @@ - + - + FreeBSDのブート処理の流れ

原作: &a.phk;. v1.1, April 26th.

訳: &a.nakai; September 6 1996. FreeBSDのブートには基本的に3つの段階があります: カーネルの読み込み, ルートのファイルシステムの決定, そして ユーザ領域にあるものの初期化です. このことは下に述べる いくつかの興味深い可能性につながっています。 カーネルの読み込み

現在, カーネルの読み込みには基本的に下に挙げる3つの方法が あります: これらはカーネルが次に何をしたらいいのかという情報をカーネルに 与えます. Biosboot Biosbootは「ブートブロック」に相当するもので, 2つのファイル から構成されており, フロッピーディスクやハードディスクのブートを 開始する側の 8K バイトにインストールされています。 Biosboot は FreeBSD のファイルシステムからカーネルを 読み込むことができます. Dosboot Dosbootは DI. Christian Gusenbauerによって書かれましたが, 不幸にしてこの場合には、コードのある一部分がマイクロソフトの コンパイラ向けに書かれているため、FreeBSD 単体ではコンパイル することはできません. Dosboot は MS-DOS のファイルから、またはディスクの FreeBSD ファイルシステムのパーティションからカーネルをブートします。 これは MS-DOS システムのハイメモリ領域に潜んでいるメモリマネージャ等の さまざまな怪しい代物とメモリの取り合いをして、なんとかブートしています. Netboot Netboot はサポートされているイーサネットカードを検出し、 BOOTP や TFTP、NFS を使ってブートするカーネルを探そうとします。 ルートファイルシステムの決定

カーネルが読み込まれ、ブートプログラムがカーネルに移行したら, カーネルは自身の初期化をし, どんなハードウェアが組み込まれいるか を決定し、それからルートファイルシステムを探さなくてはなりません。 現在サポートされているルートファイルシステムは次の通りです : UFS UFS は, もっとも一般的なタイプのルートシステムです。 フロッピーディスクやハードディスク上に存在します。 MSDOS 技術的に可能ですが、あまり有用ではありません。なぜならば、 ``FAT''ファイルシステムではリンクやデバイスノードなどの ``UNIX 主義''を実現できないからです。 MFS MFS はカーネル内部に組み込みになっている UFS ファイルシステムです。つまり MFS を機能させるのに ディスクやフロッピーディスクなどのハードウェアは 必要ではありません. CD9660 CD9660 は CD-ROM をルートファイルシステムに使用したものです。 NFS これはルートシステムにファイルサーバを使用していて、基本的に ディスクレスのマシンのためにあります。 ユーザ領域にあるものの初期化

ユーザ領域で動作させるようにするために、カーネルが初期化を終えると、 カーネルは``/sbin/init'' です。 /sbin/init を別なプログラム置き換えてしまうことは可能ですが、そのプロセス には以下のような制約があります: pid が 1 のプロセスには stdin/stdout/stderr は割り当てられていませんので、 プログラムは自分でこれらをオープンしないとなりません。 このプロセスが終了するとカーネルはパニックメッセージを表示して 停止します。 また、このプロセスに対するシグナル処理は特殊です。 この例として、インストール用のフロッピーディスクにある ``/stand/sysinstall''があります。 興味深い連係

カーネルを MFS でブートするのには次のような特別の/sbin/init を使います。 /C: にマウントします。 C:/freebsd.fs を /dev/vn0 にアタッチします。 /dev/vn0 を /rootfs にマウントします。 シンボリックリンクを作ります。 /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin (etc...) これでハードディスクのパーティションを切り直さずに FreeBSD を 使うことができます。 サーバ:˜you/FreeBSD を /nfsにマウントし、ルートディレクトリを /nfs に変更して, そこで/sbin/initを実行します。 これで FreeBSD をディスクレスで実行できますが、NFS サーバを コントロールできないままです... /dev/rwd0 のコピーを取って、リモートにあるテープ ステーションやファイルサーバに書き込んでください。 これで一年前に取っておくべきだったバックアップをやっと 取ることができました。 E -- ファイアウォール/Web サーバとして動作させる場合 (私の知っている範囲で...) これは特に面白いもので、書き込み禁止のフロッピーディスクから ブートができて、ルートのファイルシステムに書き込むことができる というものです。 diff --git a/ja/handbook/cvsup.sgml b/ja/handbook/cvsup.sgml index 4af9e1f6ef..76f27d738b 100644 --- a/ja/handbook/cvsup.sgml +++ b/ja/handbook/cvsup.sgml @@ -1,597 +1,597 @@ - + - + CVSup

原作: &a.jdp;.

訳: &a.iwasaki;.27 February 1997. CVSup の紹介

CVSup は, リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するためのソフトウェアパッケージです. FreeBSD のソースは, カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています. CVSup を使用することで, FreeBSD ユーザは 簡単に自分のソースツリーを最新の状態にしておくことができます.

CVSup は pull モデルとよばれる更新のモデルを採用しています. pull モデルでは, 各クライアントが更新したい場合に更新したい時点で, サーバに更新の問い合わせをおこないます. サーバはクライアントからの 更新の要求を受け身の状態で待ちます. したがって, すべての更新は クライアント主導でおこなわれます. サーバは頼まれもしない更新情報を 送るようなことはしません. ユーザは CVSup クライアントを手動で実行して 更新をおこなうか, cron ジョブを設定して定期的に自動実行する必要があります.

用語 "CVSup" のように大文字で表記しているものは, ソフトウェアパッケージ 全体を指します. 主な構成物は, 各ユーザマシンで実行するクライアントである "cvsup", FreeBSD の各ミラーサイトで実行するサーバ "cvsupd" です.

FreeBSD の文書やメーリングリストを読んだ際に, sup についての言及を 見かけたかもしれません. sup は CVSup の前に存在していたもので, 同様の 目的で使われていました. CVSup は sup と同じように使用されており, 実際, sup と互換性のあるコンフィグレーションファイルを使用します. CVSup の方がより高速で柔軟性もあるので, もはや sup は FreeBSD プロジェクトでは使用されていません. CVSup のインストール

FreeBSD 2.2 以降を使用している場合, CVSup をインストールするもっとも 簡単な方法は, FreeBSD の または対応する を使うことです. どちらを使うかは, CVSupを自分で作りたいかどうかによります.

FreeBSD-2.1.6 または 2.1.7 を使用している場合は, 残念ながら FreeBSD-2.1.{6,7} には存在しないバージョンの C ライブラリが必要となるため バイナリ package は使用できません. しかし, は FreeBSD 2.2 とまったく同じように簡単に使うことができます. 単に tar ファイルを展開し, cvsup ディレクトリへ cd して "make install" とタイプするだけです.

CVSup は で書かれているため, package と port 両方とも Modula-3 ランタイムライブラリがインストールされていることが必要です. これらは port の および package の にあります. これらのライブラリの port や package に対して cvsup と同じ管理方法を取っていれば, CVSup の port や package をインストールする際に, これらのライブラリも自動的に コンパイルそして/またはインストールされます.

Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに 終わるものではありません. この理由から, 三つめの選択肢が提供されています. 以下のアメリカ合衆国にある配布サイトのどちらからでも, FreeBSD 用の スタティックリンクされた CVSup 実行形式が入手可能です: (クライアント). (サーバ). また, ドイツのミラーサイトは以下の通りです: (クライアント). (サーバ). 訳注: 日本国内のミラーサイトは以下の通りです: (クライアント). (サーバ).

ほとんどのユーザはクライアントのみが必要になるでしょう. これらの 実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current までの, どのバージョンでも動作します.

まとめると, CVSup をインストールするための選択肢は以下の通りです: FreeBSD-2.2以降: スタティックバイナリ, port, package FreeBSD-2.1.6, 2.1.7: スタティックバイナリ, port FreeBSD-2.1.5 以前: スタティックバイナリ CVSup のコンフィグレーション

CVSup の動作は, "supfile" と呼ばれるコンフィグレーションファイルで 制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ の下にあります. 2.2 以前のシステムを使用している場合は, これらの サンプルを から入手することができます.

supfile には以下の cvsup に関する質問への答えを記述します:

次のセクションで, これらの質問に順番に答えながら典型的な supfile を組み立てていきます. 最初に supfile の全体構造を説明します.

supfile はテキストファイルです. コメントは "#" から行末までです. 空行とコメントだけの行は無視します.

残りの各行には, ユーザが受け取りたいファイル群について記述します. 行の始めは, サーバ側で定義した論理的なファイルのグループである 「コレクション」の名称です. コレクションの名称を指定して, 欲しいファイル群を サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた 0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する 答えになります. フィールドには 2種類あります: flag フィールドと value フィールドです. flag フィールドは "delete" や "compress" のような 単独のキーワードから成ります. また, value フィールドもキーワードで 始まりますが, キーワードの後にはホワイトスペースは入らず, "=" と 二つめの単語が続きます. 例えば, "release=cvs" は value フィールドです.

通常, supfile には受け取りたいコレクションを一つ以上指定します. supfile を組み立てる一つの方法として, コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります. しかし, これでは supfile のすべてのコレクションに対してほとんどのフィールドが同じになるため, 行が非常に長くなってしまい不便になります. これらの問題を避けるため, CVSup ではデフォルトを指定することのできるメカニズムが提供されています. 特殊な擬似コレクション名 "*default" で始まる行は, supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドの デフォルトを設定するために利用できます. 個々のコレクションで固有の値を 指定すると, デフォルト値を無効にできます. また "*default" 行を追加すると, supfile の途中からデフォルト値の変更や追加が可能になります.

これまでの予備知識を基に, のメインのソースツリーを受け取って更新するための supfile を 組み立ててみましょう. どのファイルを受け取りたいのか?

CVSup を通して入手できるファイルは 「コレクション」と呼ばれる名前の付けられたグループにまとめられています. 利用可能なコレクションについては で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体 を受け取るための設定例を紹介します. 輸出規制されている暗号化サポートのコード以外のすべてを含む "src-all" という 単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か カナダにいるものと仮定します. その場合, "cvs-crypto" という一つの付化的な コレクションで暗号化コードを入手することができます. supfile を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ 記述します: src-all cvs-crypto

どのバージョンのものが欲しいのか?

CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. "tag=" および "date=" の value フィールドを使用して, 欲しいバージョンの 一つを指定します.

注意: "tag=" のフィールドの指定は正確に行うように十分注意 してください. いくつかのタグは特定のコレクションに対してのみ有効です. タグの綴りが違っていたり不適切なタグを指定すると, CVSupはユーザが消し たくないファイルまで削除してしまいます. 特に "ports-*" のコレクション に対しては "tag=." だけ を指定するようにしてください.

"tag=" フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません.

以下はユーザが興味を持っていると思われる branch tag です:

以下はユーザが興味を持っていると思われる revision tag です:

注意: tag 名を示した通りにタイプされているか十分注意してく ださい. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが削 除されるでしょう.

branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, "date=" の value フィールドを使って日付を指定することで, これを実現することが できます. cvsup(1) のマニュアルページで, その方法を説明しています.

例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=.

"tag=" フィールドも "date=" フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのもののコピーを維持することで, リビジョン履歴を閲覧し過去のバージョンのファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります.

どこから入手したいのか?

更新情報をどこから入手するかを cvsup に伝えるために "host=" フィールドを使用します。 のどこからでも入手できますが、最寄りのサイトを選ぶべきでしょう。 この例では、第一の FreeBSD 配布サイト "cvsup.FreeBSD.org" を使用します: *default host=cvsup.FreeBSD.org

どのように cvsup を実行しても, この設定は "-h hostname" を 使用してコマンドラインで変更することができます.

自分のマシンのどこに置きたいのか?

"prefix=" フィールドは, cvsup に受け取ったファイルをどこに置くかを 伝えます. この例では, ソースファイルを直接メインのソースツリー "/usr/src" に置きます. "src" ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので, これは正しい仕様となります: *default prefix=/usr

どこに status ファイルを置きたいのか?

cvsup クライアントは "base" ディレクトリと呼ばれる場所に, ある status ファイルを維持しています. すでに受け取った更新情報を追従し続け ることで, これらのファイルは CVSup がより効果的に動作することを支援し ます. 標準の base ディレクトリ "/usr/local/etc/cvsup" を使用します: *default base=/usr/local/etc/cvsup

supfile に指定がない場合は, この設定をデフォルトで使用しますので, 実際には上の行は必要ありません.

base ディレクトリが存在しない場合は作成しておきましょう. base ディレクトリが存在しない場合, cvsup クライアントは実行を拒否します.

その他もろもろの supfileの設定:

通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress

"release=cvs" は, サーバがメインの FreeBSD CVS リポジトリから その情報を取得するように指示します. ほとんどの場合はこのようにしておきますが, ここでの説明の範疇をこえるような状況では他の指定をすることも可能です.

"delete" は CVSup にファイルを削除することを許可します. CVSup が ソースツリーを完全に最新の状態に保てるようにするためには, これは常に 指定しておくべきでしょう. CVSup は, これらの責任範囲のファイルだけを 慎重に削除します. たまたま存在する他の余分なファイルについては, まったく手をつけずに残しておきます.

"use-rel-suffix" は ... 神秘的なものです. これについて本当に 知りたい人は, cvsup(1) のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください.

"compress" は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を 使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます.

supfile の例のまとめ:

以下は supfile の例の全体です: *default tag=. *default host=cvsup.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all cvs-crypto CVSup の実行

さて, 更新の準備ができました. これを実行するコマンドラインは 実に簡単です: cvsup supfile

もちろん, ここでの "supfile" は作成したばかりの supfile のファイル名です. X11 環境で実行するものと仮定して, cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します. "go" ボタンを押して, 実行を監視してください.

この例では実際の "/usr/src" ツリーを更新しているので, cvsup にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root で実行する必要があります. コンフィグレーションファイルを作ったばかりで, しかも以前にこのプログラムを実行したことがないので, 神経質になるのは 無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な 方法があります. どこか適当な場所に空のディレクトリを作成して, コマンドラインの引数で指定するだけです: mkdir /var/tmp/dest cvsup supfile /var/tmp/dest

指定したディレクトリは, すべての更新されるファイルの 更新先ディレクトリとして使用します. CVSup は "/usr/src" の下の ファイルを検査しますが, 変更や削除はまったくおこないません. かわりに "/var/tmp/dest/usr/src" に更新されたすべてのファイルが 置かれるようになります. この方法で実行した場合は, CVSup は base ディレクトリの status ファイルを更新せずにそのままにします. これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます. "/usr/src" の読み取り許可がある限り, このような 試し実行のためにユーザ root になる必要はありません.

X11 を利用していないとか単に GUI が気に入らない場合は, cvsup 起動時にコマンドラインに二つほどオプションを追加する必要があります: cvsup -g -L 2 supfile

"-g" オプションは cvsup に GUI を使用しないように伝えます. X11 を利用していない場合には自動的に指定されますが, そうでない場合は 明示的に指定します.

"-L 2" オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます. 冗長性には "-L 0" から "-L 2" までの三つのレベル があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力 しません.

たくさんの他のオプション変数があります. それらの簡単な一覧は "cvsup -H" で表示されます. より詳しい説明はマニュアルページをご覧ください.

動作している更新の方法に満足したら, cron(8) を使って cvsup を定期的に 実行させる準備をすることができます. cron から起動する際には, 明示的に cvsup が GUI を使わないようにする必要があります. CVSup ファイルコレクション

CVSup 経由で入手できるファイルコレクションは階層的に組織化されています. いくつか大きなコレクションがあり, それらは小さなサブコレクションに 分割されています. 大きなコレクションは, そのサブコレクション毎に 受信することと同じことになります. 下の一覧ではコレクション間の階層関係を 字下げして表現します.

最も一般的に使用するコレクションは cvs-all release=cvs メインの FreeBSD CVS リポジトリであり, 輸出規制された暗号化コードは含まれていません.

distrib release=cvs FreeBSD の配布とミラーに関連するファイルです. doc-all release=cvs FreeBSD ハンドブックおよびその他のドキュメントのソースです. ports-all release=cvs FreeBSD の ports コレクションです.

ports-archivers release=cvs アーカイビングのツール. ports-astro release=cvs 天文学関連の ports. ports-audio release=cvs サウンドサポート. ports-base release=cvs /usr/ports のトップにあるその他のファイル. ports-benchmarks release=cvs ベンチマークプログラム. ports-cad release=cvs CAD ツール. ports-chinese release=cvs 中国語サポート. ports-comms release=cvs 通信ソフトウェア. ports-converters release=cvs 文字コードコンバータ. ports-databases release=cvs データベース. ports-devel release=cvs 開発ユーティリティ. ports-editors release=cvs エディタ. ports-emulators release=cvs 他の OS のエミュレータ. ports-games release=cvs ゲーム. ports-german release=cvs ドイツ語サポート. ports-graphics release=cvs グラフィックユーティリティ. ports-japanese release=cvs 日本語サポート. ports-korean release=cvs 韓国語サポート. ports-lang release=cvs プログラミング言語. ports-mail release=cvs メールソフトウェア. ports-math release=cvs 数値計算ソフトウェア. ports-mbone release=cvs MBone アプリケーション. ports-misc release=cvs 色々なユーティリティ. ports-net release=cvs ネットワーキングソフトウェア. ports-news release=cvs USENET ニュースのソフトウェア. ports-plan9 release=cvs Plan9 からの色々なプログラム. ports-print release=cvs 印刷ソフトウェア. ports-russian release=cvs ロシア語サポート. ports-security release=cvs セキュリティユーティリティ. ports-shells release=cvs コマンドラインシェル. ports-sysutils release=cvs システムユーティリティ. ports-textproc release=cvs 文書処理ユーティリティ(デスクトップパブリッシングは含まない). ports-vietnamese release=cvs ベトナム語サポート. ports-www release=cvs World Wide Web 関連のソフトウェア. ports-x11 release=cvs X11 のソフトウェア. src-all release=cvs メインの FreeBSD ソース群であり, 輸出規制された暗号化コードは含まれていません.

src-base release=cvs /usr/src のトップにあるその他のファイル. src-bin release=cvs シングルユーザモードで必要なユーザユーティリティ (/usr/src/bin). src-contrib release=cvs FreeBSD プロジェクト外部からのユーティリティおよびライブラリ, 比較的無修正 (/usr/src/contrib). src-etc release=cvs システムコンフィグレーションファイル (/usr/src/etc). src-games release=cvs ゲーム(/usr/src/games). src-gnu release=cvs GNU Public License 下にあるユーティリティ (/usr/src/gnu). src-include release=cvs ヘッダファイル (/usr/src/include). src-kerberosIV release=cvs KerberosIV セキュリティパッケージ (/usr/src/kerberosIV). src-lib release=cvs ライブラリ (/usr/src/lib). src-libexec release=cvs システムプログラムであり, 通常は他のプログラムから実行される (/usr/src/libexec). src-release release=cvs FreeBSD の release を構築するために必要なファイル (/usr/src/release). src-sbin release=cvs シングルユーザモード用のシステムユーティリティ(/usr/src/sbin). src-share release=cvs 多様なシステム間で共有可能なファイル (/usr/src/share). src-sys release=cvs カーネル (/usr/src/sys). src-tools release=cvs FreeBSD の保守用の色々なツール (/usr/src/tools). src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin). src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin). www release=cvs World Wide Web のデータ用のソースです. cvs-crypto release=cvs 輸出規制された暗号化コードです.

src-crypto release=cvs 輸出規制された FreeBSD プロジェクト外部からのユーティリティおよび ライブラリ, 比較的無修正 (/usr/src/crypto). src-eBones release=cvs Kerberos および DES (/usr/src/eBones). src-secure release=cvs DES (/usr/src/secure). distrib release=self CVSup サーバ自身のコンフィグレーションファイルです. CVSup ミラーサイトが使用します. gnats release=current GNATS バグトラッキングデータベースです. mail-archive release=current FreeBSD 関連メーリングリストのアーカイブ. www release=current インストールされた World Wide Web のデータです. WWW ミラーサイトが使用します. CVSup のアナウンス, 質問およびバグ報告

CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます.

質問とバグ報告はプログラムの作者, へ 送ってください. diff --git a/ja/handbook/kernelconfig.sgml b/ja/handbook/kernelconfig.sgml index c59bb80293..5daabe73b5 100644 --- a/ja/handbook/kernelconfig.sgml +++ b/ja/handbook/kernelconfig.sgml @@ -1,1252 +1,1252 @@ - + - + FreeBSDカーネルのコンフィグレーション

原作: &a.jehamby;. 6 October 1995.

訳: &a.tomo;, &a.yoshiaki;. 2 November 1996. この章はシステムに合わせたカーネルの再構築の基礎について 述べたものです. この章は, システム管理の初心者から Unixシステム管理に十分な経験を積んだ人までを対象としています. なぜカスタムカーネルを作るか?

システムに合わせたカーネルの構築はすべての Unixシステム管理者が 避けて通ることのできない最も重要な通過儀礼の1つです. この作業は, 多くの時間を必要としますが, あなたの FreeBSD システムに多くの利益をもたらします. GENERICカーネルは, めったに使われることのないハードウェアをサポートするとともに, 考えられるすべての SCSIカードやネットワークカードをサポート しなければなりませんが, システムに合わせたカーネルは あなたの PC のハードウェアのみをサポートします. これは, 次にあげるような利益をもたらします. あなたが持っていないハードウェアについては検出をおこなわな いので, ブートにかかる時間が短くなります. システムに合わせたカーネルは多くの場合メモリ使用量が 減ります. カーネルはいつもメモリ上に存在するので, 不必要なコードがあると本来プログラムが利用できるはずの RAM (実メモリ) を占めてしまいますのでこれは重要なことだ といえます. したがって, メモリが少ないシステムでは, カーネルの再構築は大変重要です. 必要に応じていくつかのカーネルオプションは調整すること ができ, またサウンドカードのような GENERICカーネルには ないデバイスドライバをカーネルに含めることが できます.

カスタムカーネルの構築とインストール

まず, カーネル再構築に必要なディレクトリをざっと見てみましょう. ここではディレクトリはすべて /usr/src/sys以下の相対位 置で示します. また, /sysからもアクセス可能です. ここには, カーネルの各部分を構成するサブディレクトリが いくつもあります. しかし, 私たちの目的では 最も重要なのは i386/confです. ここで, あなたの システムに合わせてカーネル コンフィグレーションを編集します. それから compileディレクトリ, ここはカーネルが作られる 場所です. サポートされているデバイスやファイルシステムのディレ クトリツリーがオプション毎にサブディレクトリに分かれている論理 的構成に注意してください. また, i386のディレクトリは PCのハードウェアのみを扱い, i386以外のディレクトリは FreeBSDが他のプラットフォームに移植される際には共有されるコー ドです. /usr/src/sys 以下のディレクトリがなければ, カーネルのソースが インストールされていません. パッケージのインストール手順にしたがっ て, システムにインストールしてください. つぎに, i386/confに移動して, GENERIC コンフィグレーションファイルをカーネルに与えたい名前に コピーしてください. たとえば： # cd /usr/src/sys/i386/conf # cp GENERIC MYKERNEL 慣習として, この名前はすべて大文字でつづられます. もし, いくつかの異なるハードウェアの FreeBSDマシンを扱うなら, この名前にホスト名を含めるとよいでしょう. ここでは, 例として MYKERNEL と呼ぶことにします. では, MYKERNELをあなたの好きなエディタで編集してください. もし, システムをインストールしたばかりならば, 利用できる エディタは viだけかもしれません. ここでは使い方 の説明はしませんが, にあるような多くの本で詳しく説明 されていますので, そちらを参照してください. まずファイルの最初の方のコメント行を編集し, あなたのコンフィグ レーションに合せて変更した点などを記述して GENERICと区別がつく ようにしておきましょう. もし SunOSや他の BSDオペレーティングシステムでカーネルの 再構築をしたことがあれば, このファイルはとても親しみ やすいでしょう. しかし, DOSのようなその他の オペレーティングシステムしか知らない人から見れば, GENERICコンフィグレーションファイルはとても なじみにくいものかもしれません. そのような場合は, の節をゆっくりと注意深く読んでください. config(8)を取ってくる必要があるかもしれません. これは /usr/src/usr. sbinにあります. したがってこれらのソースをダ ウンロードする必要があります. 次のコマンドを実行する前に (configを)作りインストールをしておいてください. 編集し終ったら, 次のコマンドによってコンパイル, インストール を行ってください. # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # make depend # make # make install 新しいカーネルはルートディレクトリに /kernelという 名前でコピーされ, 今までのカーネルは /kernel.old という名前へ変更されます. では, システムをシャットダウン, リブー トして新しいカーネルを使ってください. うまく行かない場合は, この章の終りの を参照してください. この章の新しい 場合のリカバリの方法を注意深く読んでおいてください. /devディレクトリで デバイスノードを追加しなければならないかもしれません. 詳しくは, を読んでください. コンフィグレーション ファイル

コンフィグレーション ファイルの一般的なフォーマット はとてもシンプルです. 各行は1つのキーワードと1つ以上の 引数を含んでいます. 見やすくするために, ほとんどのキーワードは 引数を1つしか書いてありません. #に続くものはすべてコメントとして扱われ, 無視されます. ここでは, それぞれのキーワードについて だいたい GENERICに出てくる順番で説明します. しかし, お互いに関係のあるキーワードは, 実際には GENERICファイル上に バラバラに現れていても, (ネットワーキングのように)1つにまとめ てあります.

カーネルは現在, オプションを扱う方法をよりよい機構に移行しよ うとしています. 従来は, 各々のオプションは単純にカーネルの Makefile中の CFLAGS行の -Dスイッチに変換されて いました. 自然とオプションは際限なく増えて行きます. だれも実際に はどのオプションがどのファイルで参照されているかは知りません.

新しい方法では、すべてのオプション依存の #ifdefは当該オプショ ンを opt_foo.h (これらのファイルはconfigによって compileディレ クトリに作られます) から読み込むように変わりました. config の有効なオプションのリストは2つのファイルにお かれます. アーキテクチャに依存しないオプションは /sys/conf/optionsに置かれ, アーキテクチャ依存のオプショ ンは/sys/arch/conf/optionsに置かれま す. archの部分は例えば i386となります. 必須キーワード

ここにあるキーワードはカーネルの構築に必要不可欠です. machine ``i386''

最初のキーワードは machineです. FreeBSDは Intelの 386とその互換チップ上でしか 動かないので, i386を指定します. 注: 数字を含むキーワードはすべて クォーテーションマークで囲む必要があります. そうしないと, configは混乱し, 386を実際の数値として扱ってしまいます. cpu ``cpu_type''

次のキーワードは cpuです. FreeBSDでサポートしている CPUの中から記述します. cpu_typeとして指定可能な値は 次の通りです. I386_CPU I486_CPU I586_CPU I686_CPU GENERICカーネルのように cpuの行の cpu_typeが異なった値を持つものが 複数あってもかまいません. カスタムカーネルでは, あなたが持っている cpuを1つだけ指定するのが 一番です. 例えば, もし Intelの Pentiumを持っていれば, cpu_typeには, I586_CPU を使ってください. ident machine_name

次は, カーネルの識別名となるidentです. GENERICからあなたがカーネルに与えたい名前に 変えてください. ここでは, MYKERNELとします. identに与えた名前はカーネルの ブート時に表示されるので, 普段のカーネルとは別に カーネルに違う名前を与えたいとき(例えば, 実験用のカーネルを作りたい時など), 便利でしょう. 数字を含む名前にしたい場合は machineや cpuの時と同じようにクォーテーションマークで 囲む必要があります. Cコンパイラに -Dスイッチで渡されるので, DEBUGのような名前にしたり, vax といった他のCPUの名前など紛らわしい名前にしないで ください. maxusers number

これは, 重要なシステムテーブルのサイズを決めます. ここ で与えられる数字はマシンに同時にログインすると考えられ るおよそのユーザ数です. しかし, 通常の使用環境であれば, 特に X Window System を立ち上げたり, ソフトウェアを コンパイルするような使用であれば maxusersには少 なくとも4以上を指定したほうがいいでしょう. その理由は, maxusersで決るテーブルで最も重要なものはプロセス の最大数であるからです. プロセス最大数は 20 + 16 * maxusersで与えられ, maxusersを1 にすると36プロセスしか同時には持てません. この中にはブー ト時にシステムによって起動する18個ぐらいのプロセス, Xを 起動する時の15程度のプロセスも含みます. manページを読むという1つのタスクでさえ, フィ ルタやファイル伸長や表示のために9つのプロセスを起動し ます. maxusersを4にすれば, 同時に84個のプロセ スを持つことができるのでどんな人でも十分な数だといえる でしょう. それでも他のプログラムを起動した場合に, あるいは, (Walnut Creek CDROMのFTPサイトのように) 同時に多くの ユーザを抱えるサーバを走らせた場合に ``proc table full''というおぞましいエラーが起きる場合はこの値を増や し, カーネルを再構築してください. maxuserはあなたのマシン にログインできるユーザの数を制限するものでは ありません. 単に, あなたのシステムに ログインするユーザ数の最大値と各々のユーザが いくつのプロセスを走らせるかを考慮することに よってさまざまなテーブルの値を適切な値に設定 するだけです. これに対し, の remote loginsというキーワードは 同時にリモートログインできるユーザ数を制限 します. config kernel_name root on root_device

これはカーネルの位置と名前を特定します. 伝統的にカーネルは vmunixと呼ばれますが, FreeBSDでは kernelとふさわしい名前になりました. kernel_nameにはいつも kernelを 使ってください. 名前を変えると多くのシステム ユーティリティが使えなくなります. 2番目の部分は ルートファイルシステムとカーネルのあるディスクと パーティションを指定してください. SCSIドライブでなければ, wd0を, SCSIドライブならば sd0です. 一般的なオプション

以下はカーネルのサポートするさまざまなファイルシステムおよ びその他のオプションです.

これは, 数値演算コプロセッサがない コンピュータ (386や486SX) で数値演算コプロセッサ のエミュレーションを可能にします. もし, Pentiumや 486DX, あるいは387や487があれば, コメントアウト できます. 注: FreeBSD付属の数値演算 コプロセッサエミュレータはあまり正確では ありません. 非常に正確な計算をおこないたい ならば, より優れた GNUのエミュレータである GPL_MATH_EMULATEに変えることを おすすめします. これはライセンスの関係でデフォルトでは 含まれていません. options ``COMPAT_43''

4.3BSDとの互換性のためのオプションです. そのままにしておいてください. コメントアウトすると, いくつかのプログラムで動作がおかしくなります. options BOUNCE_BUFFERS

ISAデバイスやISA互換モードで動作する EISAデバイス では DMA (Direct Memory Access) は16MB以下のメモリに対し てのみ動作します. このオプションによりメモリが16MB以上 のシステムでDMAを使うデバイスを動作させることができます. options UCONSOLE

ユーザがコンソールを横取り (grab) できるようにします. これは X Window System 上で便利です. 例えば, コ ンソール xtermを xterm -Cとタイプして作ると, そこに `write', `talk'などのメッセージがカーネルからコ ンソールへ送られるメッセージと同じように表示されます. options SYSVSHM

このオプションは System V の共有メモリを提供します. X Window System の XSHM拡張での利用がもっとも一般に見 られる例で, 多くのグラフィックを多用したプログラム (movie player の Xanimや Linux DOOMなど) ではこれを 利用することで速度が増加するというメリットがあります. X Window System を利用するのであればこれは間違いな く含めたくなるでしょう. options SYSVSEM

System V のセマフォをサポートします. 一般的に利用される ことは少ないですがカーネルサイズの増加は数百バイトだ けです. options SYSVMSG

System V のメッセージをサポートします. これを指定した場 合もカーネルサイズの増加は数百バイトだけです. ipcs(1) コマンドは これらの System V の機構を利用しているプロセスを表示し ます. 訳注: 共有メモリ, セマフォ, メッセージ(メッ セージキュー) は System V系 で一般的なプロセス間通信の機 構です. くわしくは System Vのプロセス間通信に関する文 献, 「詳解 UNIXプログラミング」 (ソフトバンク) , 「UNIXネッ トワークプログラミング」 (トッパン) などを参照してくださ い. ファイルシステムオプション

これらのオプションはさまざまなファイルシステムへのサポート を追加します. 少なくともブートするためのデバイスのサポートを含 める必要があります. 標準的にはハードディスクからブートするので あれば FFS , ディスクレスワークステーションとしてイー サネットからブートするのであれば NFSです. 一般的に利用される他のファイルシステムをカーネルに含め, あまり 利用しないファイルシステム (多分 MS-DOSファイルシステム?) のサポー トをコメントアウトすることができます. これは Loadable Kernel Module ディレクトリ /lkm から, 最初にそのタイプのファイ ルシステムがマウントされる時に動的にドライバがロードされるからです. options FFS

基本的なハードドライブ ファイルシステムです. ハードディ スクからブートする場合は残しておいてください. options NFS

ネットワーク ファイルシステムです. Ethernet経由で Unixファ イルサーバからパーティションをマウントする予定がない場 合はコメントアウトすることができます. options MSDOSFS

MS-DOS ファイルシステムです. ブート時に DOSフォーマット のハード ドライブをマウントする予定のない場合はコメン トアウトしても安全です. 先に示したように, DOSパーティ ションをマウントする時に自動的にロードされます. また (ports コレクションにある) mtools という素晴 らしいソフトウェアにより mount , unmountなしで DOSフロッ ピーにアクセスすることができます (これは MSDOSFSも必要 ありません). options ``CD9660''

CD-ROMのための ISO 9660 ファイルシステムです. CD-ROMを 持っていないか, 時々 データ CDをマウントするだけならコ メントアウトしましょう (データ CDを最初にマウントする 時に動的にロードされます). オーディオ CDはこのファイル システムは必要ありません. options PROCFS

プロセス ファイルシステムです. これは疑似的なファイルシ ステムで /procにマウントされ, ps(1)などのプロ グラムがプロセスに関してより詳しい情報を与えてくれるよ うになります. options MFS

メモリマップド ファイルシステムです. これは基本的に一時 ファイルを記憶するための高速な RAMディスクで, 大きな swap領域がある場合に有効です. MFSパーティションをマウ ントするに適した場所は多くのプログラムが一時ファイルを 置く /tmpです. MFS RAMディスクを /tmp にマウントするには以下の内容を /etc/fstabに追 加してリブートするか mount /tmpとタイプします. /dev/wd1s2b /tmp mfs rw 0 0 /dev/wd1s2bをあなたが使用して いるswap パーティションに置き換えてください. これは以 下のように /etc/fstabに書かれているでしょう. /dev/wd1s2b none swap sw 0 0 /tmpデ バイスにアクセスすることはできません). そのためいまの ところは使わない方が無難です. --> また, MFSファ イルシステムは動的にロードすることはできません . したがって使いたい場合はコンパイル時に カーネルに含める必要があります. options QUOTA

ディスククォータを有効にします. アクセスが公開されてい るシステムで (一人のユーザが) /homeパーティショ ン (全体) をあふれさせることができないようにそれぞれのユーザ にディスククォータを発行することができます. ディスククォータについての詳しい内容はの章を見てください. 基本的なコントローラとデバイス

この節では FreeBSDでサポートされているディスク, テー プ, CD-ROMコントローラについて示します. コントローラと カードについ ては別の節になっています. controller isa0

FreeBSDのサポートするすべての PCで必要です. IBM PS/2 (マイ クロチャネルアーキテクチャ) では現時点では FreeBSDは動 きません. controller pci0

PCIバスを持つマザーボードの場合は含めます. これにより PCIカードの自動認識と PCIから ISAバスへのゲートウェイが 可能になります. controller fdc0

フロッピードライブコントローラです. fd0 は ``A:'' ドライブで fd1 は ``B:'' ドライブです. ft0 は フロッピーコントローラに接続する QIC-80 テープドライブで す. 対応するデバイスがない場合はそれぞれの行をコメント アウトしてください. ft(8)というフィルタプログラムが必要です. くわしくはマニュアルページを見てください. controller wdc0

プライマリIDEコントローラです. wd0 と wd1はそれぞれマスタ, スレーブドライブで す. wdc1 は セカンダリの IDEコントローラで3台 目, 4台目のハードディスクまたは IDE CD-ROMのある場合に 使います. 利用しない行はコメントアウトしてください (例え ば, SCSIハードディスクのみを使う場合は6行全部をコメント アウトしてもよいかもしれません). device wcd0

このデバイスは IDE CD-ROMのサポートをします. wdc0を有効にしておく必要があり, もし 2つ以上の IDE コントローラがあり, そのうちの 2つ目のカードに CD-ROMを接 続する場合 options ATAPIを書いておく必要もあります. device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr

npx0はFreeBSDハードウェアコプロセッサとソフト ウェアエミュレータ両方の浮動小数点演算ユニットへのインタ フェースです. これは device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr

Wangtek と Archive の QIC-02/QIC-36 テープドライブのサポートです. Proprietary CD-ROM support

以下のようなドライブを proprietary(独自の) CD-ROMドライブと呼ぶことにします. これらのドライブは専 用のコントローラを持つか, サウンドブラスタ16などのサウ ンドカードに接続します. これらは IDEでも SCSIでもあ りません. 多くの標準速や2倍速の古い CD-ROMはこれら のインタフェースを持っていますが, より新しい四倍速の ものは か でしょう. device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr

ミツミ製 CD-ROM (LU002, LU005, FX001D)です. device scd0 at isa? port 0x230 bio

ソニー製 CD-ROM (CDU31,CDU33A)です. controller matcd0 at isa? port ? bio

松下/パナソニック製 CD-ROM (サウンドブラスタ用 クリエィティブ ラボ製として販売されていました) です. SCSI デバイスのサポート

この節では FreeBSDのサポートするいろいろな SCSIコント ローラとデバイスのサポートについて書きます. SCSI コントローラ

以下の十数行は異る種類の SCSIコントローラのサポートです. 使用しているもの以外の部分はコメントアウトしてください. controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr

ほとんどの Buslogic社のコントローラです. controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr

UltraStor 14F と 34F です. controller ahc0

Adaptec 274x/284x/294x です. controller ahb0 at isa? bio irq ? vector ahbintr

Adaptec 174x です. controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr

Adaptec 154x です. controller aic0 at isa? port 0x340 bio irq 11 vector aicintr

Adaptec 152x や サウンドカードなどに使われている Adaptec AIC-6360 チップです. (slow!) controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr

NCR 5380を使っている ProAudioSpectrum や Trantor T130 で す. controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr

Seagate ST01/02 8 ビットコントローラです. (slow!) controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr

Western Digital WD7000コントローラです. controller ncr0

NCR 53C810, 53C815, 53C825, 53C860, 53C875 チップを使った PCI SCSI コントローラです. options ``SCSI_DELAY=15''

このオプションによりカーネルはそれぞれの SCSIデバイスを プローブする前に 15秒間待ちます. IDEドライブのみを使用 している場合は無視して構いません. ブートを速くするため にこの数値を 5秒ぐらいまで小さくしたいでしょう. そうし た場合, FreeBSDが SCSIデバイスを認識しにくくなるかもし れません. その時は、もちろんこのオプションの値は元に戻 さないといけません. controller scbus0

SCSIコントローラがある場合, この行で SCSI全般のサポー トを与えます. SCSIのない場合, この行と以下の3つの行をコメ ントにすることができます. device sd0

SCSIハードディスクのサポートです. device st0

SCSIテープドライブのサポートです. device cd0

SCSI CD-ROM のサポートです.

上のエントリについている 0はいくらか誤解を招き やすいかもしれません. これらのデバイスはすべてカーネルが 見つけた時に割り当てがおこなわれ, SCSIバスに何台つながってい るか, ターゲット IDが何番であるかはここの記述とは関係あ りません. 明示的に「固定的な」ターゲット IDの特定のデバイスへの 割り当てをおこないたい場合は LINT カーネルコンフィグレーションファイルの 該当する部分の説明を参照してください. コンソール, バスマウス, Xサーバのサポート

2つのタイプのコンソールからどちらか1つを選ぶ必要があります. 標準ではない方の vt220 コンソールを選んだ場合, X Window System を利用するには XSERVER オプションを有効にする必要があります (訳注: sc0 には XSERVER オプション相当の機能が始めから入っています). またバスマウスとPS/2マウスのオプションもあります. device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr

sc0 はデフォルトのコンソールドライバで SCOコン ソールに似ています. このデバイス, あるいは VT220コンパ チブルドライバの vt0いずれを使う場合もほとんど のフルスクリーンプログラムは termcapなどのターミ ナルデータベースライブラリを通してアクセスしますので, あまり違いはないでしょう. このコンソールを使う場合でフルスクリーンプログラムでト ラブルが起きる場合にはログインした時に TERM変数の値を ``scoansi''にしてください. device vt0 at isa? port ``IO_KBD'' tty irq 1 vector pcrint

これはVT-220コンパチブルコンソールドライバで VT100/102の 上位互換です. これは sc0の使えない種類のラッ プトップ機でもうまく動きます. ログイン時に TERM変数の値 を``vt100'' か ``vt220''にしてください. また, このドラ イバはネットワークを介して多くの異るマシンから接続する 場合も便利です. sc0デバイスのための termcapや terminfoエントリは必ずしも 利用できるわけではありませんが -- ``vt100''はいずれの プラットフォームでも利用可能でしょう. options ``PCVT_FREEBSD=210''

vt0 コンソールドライバを使う場合に必要で す. options XSERVER

vt0 コンソールドライバを使う時のみ有効です. これは vt0 コンソールドライバのもとで XFree86 X サーバを動かすのに必要なコードを含めます. device mse0 at isa? port 0x23c tty irq 5 vector ms

Logitech や ATIのバスマウス入力カードを利用する場合のデ バイスです. ポート(おそらくはCOM1)を有効にしてくだ さい. device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr

このデバイスは PS/2マウスポートにマウスを接続する場合に 使います. シリアル, パラレルポート

ほとんどすべてのシステムにこれらはあります. プリンタを接続す る場合は の章が非常 に役に立つでしょう. モデムを使う場合は に非常に詳しいシリアルポートの設定とデ バイスの使い方があります. device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr

sio0からsio3は MS-DOSにおける COM1から COM4に相当する4本のシリアルポートです. COM4に内蔵モデムがあり COM2を使う場合, FreeBSDからアク セスするためにはモデムのIRQを2へ変更する必要があるとい うことを注意しておきます (技術的な理由より IRQ 2 = IRQ 9となります). マルチポートシリアルカードを使う場合にマニュアルページ のsio(4)にはこのオプションで使う値などのよ り多くの情報があります. ビデオカードの中には (特に S3 チップベースのものには) IOアドレスの 0x*2e8から を利用するものがあり, また多くの安価なシリアルカードは IOアドレス空間を16-bitフルデコードしていませんので, こ れらのカードは衝突します. この場合 COM4ポートは実質上 利用できません. それぞれのシリアルポートは (割込みの共有をサポートした マルチポートカードを利用していないのであれば) 別々の IRQ を割り当てる必要がありますので COM3と COM4のデフォルトの IRQは利用できません. device lpt0 at isa? port? tty irq 7 vector lptintr

lpt0 から lpt2は利用可能な3本のプリン タポートです. 多くの場合は1本のみですので他の2本はない のであればコメントアウトして構いません. ネットワーク

FreeBSDでは他の一般的な Unixと同様にネットワークが 非常に 重視されています. イーサネットカードが なくても必須のオプションとダイヤルアップ ネットワークのサポー トに注意してください. options INET ネットワーキングのサポートです. ネットワークに接続する予定がな くても残しておいてください. 多くのプログラムは少なくともループ バックネットワーキングが必要です(つまり, PCの中でネットワーク コネクションをおこないます). したがってこのオプションは本質的 に不可欠です. Ethernet cards

以下にさまざまなイーサネットカードを有効にするオプショ ンを示します. ネットワークカードがなければこれらすべてを コメントアウトすることができます. そうでなければ利用す る特定のイーサネットカードをサポートするオプションを残 しておきます. device de0

DECの DC21040, DC21041, DC21140チップを使った PCIイー サネットアダプタです. device fxp0

Intel EtherExpress Pro/100B 高速イーサネットカード です. device vx0

3Com の 3C590, 3C595です (いくらか bugがあります). device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr

Cronyx/Sigma の マルチポート同期/非同期カードです. (with Cisco or PPP framing) device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr

Western Digital と SMC の 80xx, 8216 Elite Ultra ; ノベル NE1000, NE2000; 3Com の 3C503; HPの PC Lan Plus (HP27247B とHP27252A) です. device el0 at isa? port 0x300 net irq 9 vector elintr

3Com の 3C501 です. (slow!) device eg0 at isa? port 0x310 net irq 5 vector egintr

3Com の 3C505です. device ep0 at isa? port 0x300 net irq 10 vector epintr

3Com の 3C509 です(バグがあります). device fe0 at isa? port 0x240 net irq ? vector feintr

富士通 MB86960A/MB86965A ベースのイーサネットカード です. device fea0 at isa? net irq ? vector feaintr

DEC DEFEA EISA FDDI アダプタです. device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr

AT&T StarLAN 10 と EN100; 3Com の 3C507; NI5210 です. device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr

Intel の EtherExpress 16です. device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr

DEC の EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422)です. device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr

Lance/PCnet カード (Isolan, Novell NE2100, NE32-VL)です. device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr

IBM/ナショナルセミコンダクタの PCMCIA イーサネット コントローラです. device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr

3Com の PCMCIA Etherlink III です. pseudo-device loop

loop は TCP/IPの一般的なループバックデバイスで す. telnet や FTPを localhost (127.0.0.1) に対して行なうとこの疑似デバイスを通して帰ってきます. 不可欠です. pseudo-device ether

etherはイーサネットカードがある場合のみ必要で 一般的なイーサネットプロトコルを含めます. pseudo-device sl number

sl は SLIP (Serial Line Internet Protocol) をサポー トします. これはほとんど完全に, より簡単に設定ができ, モ デム to モデム接続に適した, よりパワフルな PPPに取って代 わられています. slの後の number は同 時にいくつの SLIPセッションをサポートするかを示します. SLIPの設定のより詳しい情報はこのハンドブックの 「PPPとSLIP」の章の と について書かれた節にあります。 pseudo-device ppp number

pppはダイヤルアップ インターネット接続のための カーネルモード PPP (Point-to-Point Protocol) をサポート します. ユーザアプリケーションとして tun を 利用する PPPの実装もあり, こちらはより柔軟性がありデマ ンドダイアリング(プログラムが接続要求を出した時に自動 的にダイヤルをおこなう)などの機能もあります. それでもこ の PPPドライバを利用したい場合は の節を読んでください. slデバイスと同じように numberは同時 に PPP接続できる数を示します. pseudo-device tun number

tun はユーザモード PPPソフトウェアが利用しま す. このプログラムは設定が簡単で非常に高速です. また自動ダイヤル オン デマンドなどの機能を持ちます. tunの後のnumber は同時におこなうことのできる PPPセッションの数を示します. の節により多くの情報があ ります. pseudo-device bpfilter number

バークレイ パケットフィルタです. この疑似デバイスはネッ トワークインタフェースを無差別 (promiscuous) モードにし てネットワーク (例えば単一のイーサネット) にブロードキャス トされるすべてのパケットを取り入れることを可能にします. こ れらのパケットはディスクに取り入れられたり tcpdump(1) によって検査されます. この機能の実現 はネットワーク全体のセキュリティとの微妙な妥協点であるこ とに注意してください. bpffilter の後の numberは同時に検査することの できるインタフェースの数を示します. 危険の可能性について十分解っている場合を除いてこのオプ ションは奨めません. すべてのネットワークカードでこの機能 をサポートをしてはいません. サウンドカード

ここは GENERICカーネルに含まれていない最初のセクションです. サウンドカードのサポートをするためには LINTコンフィグレーショ ンファイル(これにはすべてのデバイスが含まれています)か ら以下のような適切な行をコピーする必要があります. controller snd0

サウンドドライバ一般のコードです. pcaを除く以下のすべてのサウンドカードで必要で す. device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr

ProAudioSpectrum のオーディオ と MIDI です. device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr

SoundBlaster です. irq 7をirq 5に書き換え, キーワード conflictsを削除し てください. さらに options ``SBC_IRQ=5''の行を 加える必要があります. device sbxvi0 at isa? drq 5

SoundBlaster 16 の 16-bit オーディオです. drq 5を適切な値に書き直 して, (DMA 6の場合) options "SB16_DMA=6"を付け 加えてください. device sbmidi0 at isa? port 0x330

SoundBlaster 16 の MIDI インタフェースです. SoundBlaster 16を使う場合必ずこの行を含めてコンパイル してください. device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr

Gravis Ultrasound です. device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr

Microsoft Sound System です. device opl0 at isa? port 0x388 conflicts

AdLib FMシンセサイザオーディオです. AdLib, SoundBlaster, ProAudioSpectrum を使い playmidi (ports にあります) などのプログラムで MIDIの演奏をしたい場合にこの行を含めます. device mpu0 at isa? port 0x330 irq 6 drq 0

Roland MPU-401 カードです. device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''

MIDIインタフェースの 6850 UART です. device pca0 at isa? port ``IO_TIMER1'' tty

PC のスピーカーを使ったオーディオです. これは非常に品質 が悪く, CPUの性能, 負荷に強く依存します, と言っておき ます (サウンドカードは必要ありませんが). /usr/src/sys/i386/isa/sound/sound.docにあります. また, これらのデバイスを追加する場合は, サウンドを作る必要があり ます. 疑似デバイス

疑似デバイスドライバはデバイスドライバと同様に働きますがマ シン上に対応する実際のハードウェアがないカーネルの部分です. 関連の 疑似デバイスはそちらのセクションに示しました. ここでは残りにつ いて示します. pseudo-device gzip

gzipは gzipによって圧縮された FreeBSDの プログラムを実行できるようにします. /standにあるプログ ラムは圧縮されているのでカーネルにこのオプションをつけ ておくのはいい考えでしょう. pseudo-device log

log はカーネルエラーのログを取るのに使います. 不可欠です. pseudo-device pty number

pty は「仮想ターミナル」や仮想ログインポート です. 外部からの telnetや rloginセッ ション, xterm, emacsなどのアプリケーションが使います. numberは作ることのできる ptyの数を示 します. GENERICのデフォルトは16で, 同時の xtermウィンドウやリモー トログインのために増やす場合は最大で 64までです. pseudo-device snp number

スヌープデバイスです. この疑似デバイスはあるターミナル セッションが watch(8) commandによって他のター ミナルを監視することを可能にします. この機能の実現はセ キュリティとプライバシに対して極めて微妙な関係があり ます. snpの後の numberは同時におこなうことのでき るスヌープセッションの総数です. 選択可能です. pseudo-device vn

Vノードドライバです. ファイルを vnconfig(8)コマ ンドによってデバイスとして取り扱うことを可能にします. このドライバによりフロッピーディスクイメージを操作したりファ イルをスワップデバイスとして (MS Windowsのスワッ プファイルなどを)用いることができます. 選択可能です. pseudo-device ccd number

ccd (concatenated disk)デバイスはいくつかのディスクパーティ ションを融合して大きなディスクのように見せることができます. ccdの後の numberは同時に作ることのできる疑似ディスクの数です. (詳しいことは ccd(4)と ccdconfig(8)のマニュ アルを参照してください.) 選択可能です. ジョイスティック, スピーカー, その他

この節は FreeBSDのここまでに示した以外のハードウェア デバイスへのサポートについて示します. これらは GENERICカーネル には含まれませんのでこのハンドブックや LINT (このファイルには すべてのデバイスのサポートが含まれます) からコピーする必 要があります. device joy0 at isa? port ``IO_GAME''

PC のジョイスティックです. pseudo-device speaker

IBM BASIC スタイルの PC内蔵スピーカーのサポートです. シェルスクリプトで簡単な演奏をする /usr/sbin/spkrtest やキーボードを使って単純なピ アノのように演奏することができる /usr/games/piano (gamesパッケージをイ ンストールした場合にはあります) のようないくつかのプロ グラムで使われます. また素晴らしいテキストロールプレイ ングゲームである NetHack (ports コレクションにあります) はゲーム中の楽器の演奏でこのデバイスを使うように設定を することができます (訳注:日本語化されたJNetHackもportsに あります).

デバイスの 項も参照してください. デバイスノードを作る

カーネル内のほとんどすべてのデバイスは対応する ``node'' エント リが /dev ディレクトリにあります. これらのノードは普 通のファイルのように見えますが, 実際にはプログラムがデバイスに アクセスするのに用いるカーネル内への特別なエントリです. シェルスクリプトである /dev/MAKEDEVはオペレーティング システムを最初にインストールする時に実行され, サポートされてい る大部分のデバイスのノードを作ります. しかし, すべてのノードが作られるわけではありませんので 新しいデバイスのサポートを加える時は対応するエントリがこのディ レクトリにあるかどうか確認してもしなければ, 作ってください. 以下に例を示します. IDE CD-ROMのサポートをカーネルに加えるとします. 次の行 を加えます. controller wcd0 これにしたがって, /devディレクトリに wcd0で始ま るエントリを捜してください. 1文字が後ろにつくかもしれません. 後 ろについた文字が `c'であるか先に `r'のつくエントリは `raw'デバ イスを示します. それらのファイルがないことが明らかになったとします. そこで /dev ディレクトリに移動して次のようにタイプします. # sh MAKEDEV wcd0 スクリプトの実行が終ったら /devに wcd0c と rwcd0c エントリがあることを確認してください. これによ り正しく実行されたことがわかります. サウンドカードの場合のコマンドは次の通りです. # sh MAKEDEV snd0 これにより対応するエントリが作られます. 注: サウンドカードのようなデバイスのノードを作る場合で, もし他 の人がマシンにアクセスするようであれば, そのデバイスを /etc/fbtabファイルに追加して外部からのアクセスから 保護するのが望ましいでしょう. このファイルの詳細については man fbtab を参照してください. GENERICに含まれていないデバイスはエントリがありませんから,以上 の簡単な手順をおこなうことになります. /devの エントリを使用しますのでノードを作る必要はありません. またネッ トワークカードと SLIP/PPP疑似デバイスは /devにはエント リがありませんのでこれらについても作る必要がありません. 問題が起きた場合には

カスタムカーネルを作る場合に起きるトラブルは4種類に分けられま す. Config コマンドの失敗

カーネルにあなたの設定をおこなった場合で configコ マンドが失敗したのであれば, 多分どこかで単純な間違いを やっているのでしょう. さいわい, configはトラ ブルの起きた行番号を出力しますので viで素早く 見つけることができます. 例えばもし次のように出力されれ ば, config: line 17: syntax error viのコマンドモードで ``17G''とタイプすればあな たは問題のところへ飛ぶことができます. GENERIC カーネル のファイルや他のリファレンスと比較して注意深く修正して ください. Make コマンドの失敗

make コマンドが失敗した場合には, カーネル設定で configがとらえられなかったような間違いをして いることが多いようです. ふたたびコン フィグレーションを見直してください. それでも問題を解決 することができなければ &a.questions へあなたのカーネルのコンフィグレーションをつけてメー ルしてください. 誰かが素早く間違いを見つけてくれるで しょう. カーネルがブートしない

新しいカーネルがブートしなかったり, デバイスの認識をしな い場合でもあわてないでください! さいわい, BSDは利用で きないカーネルから復帰する優れたメカニズムがあります. FreeBSDの bootプロンプトでリターンキーを押すかわりに 単にブートさせたいカーネルの名前 (例えば ``kernel.old'') をタイプするだけです. カーネルの再設定 をおこなう場合に現在のカーネルを利用できるように取ってお くのはよい考えです. 問題のないカーネルでブートした後にあなたのコンフィグレー ションファイルを調べ, 再び構築を試みてください. /var/log/messages ファイルにはすべての成功した ブートのカーネルのメッセージやその他の記録があり, これ は助けになる情報の一つでしょう. また, dmesg(8)コマンドは現在のブート時のカーネルメッ セージを出力します. kernel. oldは新しいカーネルをインストールする 時に, その一つ前にインストールしたうまく動かないかもしれ ないカーネルで上書きされてしまいますので当てにできませ ん. またできる限り早く動作しているカーネルを本来の ``kernel''の位置に移動させてください. そうしないと ps(1)のようなコマンドが正しく動きません. make でインストールされたカーネルのファイルを (別のカーネルに戻すために) 「アンロック」するための特別 のコマンドは # chflags noschg /kernel です. また, 新しい置き換えたカーネルあるいは重要ファイ ルを動かしたり変更されないように「ロック」するには 次のようにします. # chflags schg /kernel カーネルは動くが ps は動かない!

システムユーティリティと異るバージョンのカーネルをインス トールした場合, 例えば 実験的に ``2.2.0''のカーネルを 2.1.0-RELEASEシステム上にインストールするような場合, ps(1)や vmstat(8)のような多くのシ ステムステータスコマンドは動かなくなります. libkvm を 再コンパイルしてこれらのユーティリティを作りなおす必要がありま す. これは, オペレーティングシステムのそれ以外の部分と異るバージョ ンのカーネルを使うことが普通はあまりよくない理由の一つです. diff --git a/ja/handbook/kernelopts.sgml b/ja/handbook/kernelopts.sgml index 94580dbac6..0df578742f 100644 --- a/ja/handbook/kernelopts.sgml +++ b/ja/handbook/kernelopts.sgml @@ -1,153 +1,153 @@ - + - + カーネルコンフィグレーションの新しいオプションを追加する

原作: &a.joerg;

訳: &a.yoshiaki; . 29 December 1996. の章の内容を 理解しておいてください. そもそもカーネル オプションって何?

カーネルオプションの使い方は基本的には の章に書いてあります. そこには「伝統的な形式」と「新しい形式」のオプションの説明があります. すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル を修正して 基本的に, カーネルオプションはカーネルのコンパイルプロセスの C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる ようにするためには, 対応する部分のカーネルソース (またはカーネルの #ifndef THIS_OPTION #define THIS_OPTION (some_default_value) #endif /* THIS_OPTION */

この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば, デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, 新しい値はプリプロセッサによってソースコード中で置き換えられるため, デフォルトの値が使われていた場所において C の式として有効な値でなければ なりません.

また, 単に特定のコードを有効にするか無効にするかを設定するための 値を持たないオプションも作ることができます. #ifdef THAT_OPTION [あなたのコードが入ります] #endif

コンフィグファイルに C 言語にくわしい人であれば「コンフィグオプション」とされているもの は少なくとも一つの options notyet,notdef

このようにコンフィグファイルをしておくと, カーネルのコンパイルは うまく行きません. :-)

(訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを 持たないオプションの場合, 無効とするためのパラメタをつけて, オプション で「無効とする」と明示することはできないという意味です)

明らかに, 任意のオプション名がカーネルソースツリー全体でどのように 使われているかを追いかけることは非常に難しいことです. このことが opt_foo.h という名前に されます. この方法では, 通常の Makefile の依存関係が適用され, 古い形式のオプションの機構は, 局部的なオプションや実験的なオプション のような一時的に利用されると考えられるオプションにおいては有効です. つまり ではどのようにして追加するのでしょう?

最初に sys/conf/options (または sys/i386/conf/options.<arch>, たとえば sys/i386/conf/options.i386) を編集し, 新しいオプション を含めるのに最適な opt_foo.h ファイルを選びます.

新しいオプションの必要がなくなったとしたら, これを取り除きます. たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション の変更は 新しいオプションを加えるのに使えそうな opt_foo.h がない場合は新しい名前を作ってください. 意味のある名前を作り options[.<arch>] ファイル に新しいセクションのコメントをつけてください. 大量のオプションを一つの opt_foo.h にまとめると コンフィグファイルの一つのオプションを変更したときに多くのファイルが 再コンパイルされる原因になります.

新しいオプションに依存するカーネルファイルは最終的には見つけ出 されます. ただし, オプションを作っただけで対応するソースがどこにも ない場合は別です. find /usr/src/sys -name type f | xargs fgrep NEW_OPTION

オプションに対応するソースを見つけるのに上記のコマンドは便利です. 見つけたすべてのファイルで編集, 追加をおこないます. #include "opt_foo.h"

ファイルの先頭の, すべての #ifndef NEW_OPTION #define NEW_OPTION (something) #endif

システムヘッダファイル (たとえば /usr/include/sys/ にある ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します. そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include しないとオプションの値によって不整合が起きてしまう場合を除き, それらの ファイルに opt_foo.h を include しないでください. そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法 ではありません. diff --git a/ja/handbook/linuxemu.sgml b/ja/handbook/linuxemu.sgml index c5132e2b9e..c8b204dfb9 100644 --- a/ja/handbook/linuxemu.sgml +++ b/ja/handbook/linuxemu.sgml @@ -1,713 +1,713 @@ - + - + Linux エミュレーション

原作: &a.handy and &a.rich;

訳: &a.kiroh;.24 September 1996. Linux エミュレータのインストール

FreeBSD での Linux エミュレーションは, 大部分の Linux バイナリ(a.out および ELF フォーマット)を実行できる状態になっています. 2.1-STABLE ブラン チでのエミュレーションでは, Linux DOOM や Mathematica が実行できます. FreeBSD 2.2-RELEASE でのエミュレーションは, さらに強化されており, Linux 用 の Quake, Abuse, IDL, netrek など, 多数のソフトウェアが実行できます. Linux オペレーティングシステムには、特有の機能がいくつかあり, FreeBSD でサポートされていないものもあります. Linux の /proc ファイルシステム を使ったバイナリは, FreeBSD では実行できません (FreeBSD で使用可能な /proc ファイルシステムとは仕様が異なっているためです). また仮想8086モー ドを有効にするなど, i386 に特有なシステムコールを使っている場合も実行 できません.

カーネルが Linux エミュレーションを使用するように構築されているかを調 べるには, Linux のバイナリを実行してみるのが簡単です. linux-executable: Exec format error. Wrong Architecture. このようなエラーメッセージが表示されるようであれば, Linux との互換性は サポートされていません. カーネルを再構築してインストールする必要があり ます. Linux エミュレーションの設定方法は, 使用している FreeBSD のバージョン によって多少異なっています. 2.1-STABLE への Linux エミュレーションのインストール

2.1-STABLE の GENERIC カーネルは, Linux との互換性を保つように構築 されていません. カーネルの再構築が必要です. 再構築をおこなうには, 2つの方 法があります. 1つは, エミュレータをカーネル自体にスタティックリンクす る方法. もう1つは, 動的に Linux ローダブルカーネルモジュール(LKM)をロー ドするようにする方法です.

エミュレータを有効にするには, 以下をコンフィグレーションファイル (/sys/i386/conf/LINT など) に追加します. options COMPAT_LINUX Linux DOOM などのアプリケーションを実行したい場合は, 共有メモリも有効 にしておかなければなりません. 以下を追加します. options SYSVSHM Linux のシステムコールを使用するには, 4.3BSD のシステムコールとの互換 性が保たれていることが必要です. 以下の行が含まれていることを確認してく ださい. options "COMPAT_43" LKM を使用せずエミュレータをカーネルにスタティックにリンクしたい場合は, 以下の行を追加します. options LINUX の節の記述に したがって config と, 新しいカーネルのインストールをおこなってください. LKM を使用する場合は, ローダブルモジュールをインストールしなければなり ません. カーネルとローダブルモジュールのバージョンが異なると, カーネル がクラッシュする場合がありますので, 安全を期すためには, カーネルをイン ストールするごとに, LKM も再インストールしてください. % cd /usr/src/lkm/linux % make all install カーネルと LKM のインストールが終了したら, root で `linux' コマンドを 実行することで LKM をロードできます. % linux Linux emulator installed Module loaded as ID 0 % LKM がロードされたかどうかを確認するには, `modstat' を実行します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator % システムブート時に, LKM をロードするようにするには, 2つの方法がありま す. FreeBSD 2.2.1-RELEASE または 2.1-STABLE では, /etc/sysconfig を, linux=YES のように, NO を YES に変更してください. FreeBSD 2.1 RELEASE およびそれ以 前のバージョンでは, そのような行はありませんので, /etc/rc.local に以下 の行を追加する必要があります. linux 2.2-RELEASE への Linux エミュレーションのインストール

``options LINUX'' や ``options COMPAT_LINUX'' を指定する必要 はなくなりました. Linux エミュレーションは LKM(「ローダブルカーネルモジュール」) を使用して, リブートせず簡単にインストールできます. スタートアッ プファイルで以下のように指定します. /etc/rc.conf に以下の行が必要です. linux_enable=YES これは結果的に, /etc/rc.i386 の以下の指定を有効にします. # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi

実行されたかどうかを確認するには, modstat を使用します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod % 2.2-RELEASE とそれ以降のシステムの中には, modstat の実行がうまくいかない ものがあるという報告もあります. 何らかの理由で, Linux LKM がロードできな い場合は, options LINUX をカーネルの設定ファイルに指定して, エミュレータをスタティックにリンク してください. の節の記述にしたがって config と, 新しいカーネルのインストールをおこ なってください. Linux ランタイムライブラリのインストール linux_lib port を使用してのインストール

多くの Linux アプリケーションはシェアードライブラリを使用しますので, シェアードライブラリのインストールが終了しなければ, エミュレータのイン ストールは終わったことになりません. 手動でもインストールできますが, linux_lib port を使用するのが簡単です. % cd /usr/ports-current/emulators/linux_lib % make all install これで, Linux エミュレータが動作するようになったはずです. 伝説(とメー ルのアーカイブ :-) によれば, Linux エミュレーションは, ZMAGIC ライブラ リとリンクされている Linux バイナリに対して, 最もうまく動作するようで す. Slackware V2.0 などに使われている QMAGIC ライブラリだと, エミュレー タが胸やけするかもしれません. これを書いている時点(1996年5月)で, ELF エミュレーションは依然実験段階ですが, かなりうまく動作しているようです. マイナーバージョンの不一致などを報告するプログラムもありますが, 普通は 問題にならないようです. 手動でのライブラリのインストール

``ports'' ディストリビューションが手元にない場合は, 手動でライブラ リをインストールする必要があります. プログラムが必要とする Linux のシェ アードライブラリとラインタイムリンカが必要です. また Linux ライブラリ の用の``shadow root'' ディレクトリ, /compat/linux, を作成する必要があ ります. FreeBSD で動作する Linux のプログラムが使用するシェアードライ ブラリは,まずこのファイルツリーから検索されます. 例えば, Linux のプロ グラムが/lib/libc.so をロードしようとした場合には, FreeBSD は, まず /compat/linux/lib/libc.so を開こうとします. 存在にしなかった場合には, 次に /lib/libc.so を試します. シェアードライブラリは, Linux の ld.so が参照するライブラリではなく, /compat/linux/lib 以下にインストールする 必要があります. FreeBSD 2.2-RELEASE 以降では, /compat/linux にかかわる動作が多少異なりま す. -CURRENT では, ライブラリだけでなくすべてのファイルが, ``shadow root'' /compat/linux から検索されます. Linux のプログラムが必要とするシェアードライブラリを探す必要があるのは, FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だ けでしょう. それが過ぎれば, 十分な Linux のシェアードライブラリがシス テムにインストールされ, 新しくインストールした Linux のバイナリも, 余 計な作業をせずに動作させることができるようになります. シェアードライブラリの追加

linux_port をインストールした後に, アプリケーションが必要なライブラリ が存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバ イナリがどのシェアードライブラリを必要とし, そしてどこで入手できるか, どのように探したらよいでしょうか? 基本的には, 以下の2種類の方法があり ます(以下の手順にしたがう場合には, 必要なインストール作業をおこなう FreeBSD シ ステム上で root として作業をおこなう必要があります).

Linux システムを使用でき, 必要なシェアードライブラリが調べられる場 合には, 単に FreeBSD のシステムにそのライブラリをコピーするだけで す. 例えば, DOOM の Linux バイナリを ftp で持ってきたとします. 使用で きる Linux システムの上に転送して, `ldd linuxxdoom' とやれば, 必要とす るシェアードライブラリがチェックできます. % ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

最後のカラムに表示されているすべてのファイルを持って来て, /compat/linux の下 に置き, 最初のカラムに示されるファイル名からシンボリックリンクを張る必 要があります. すなわち, FreeBSD のシステムで, 以下のようなファイルが必 要となります. /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

最初のカラムに表示されているファイルと, メジャーバージョンの同じ Linux シェアードライブラリを既にインストールしている場合は, 新たにコピーする 必要はありません. 既にあるライブラリで動作するはずです. ただ, 新しいバー ジョンのシェアードライブラリがある場合は, 新しいものをコピーすることを お奨めします. 新しいライブラリにシンボリックリンクを変更したら, 古いラ イブラリは削除してかまいません. /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 以上のようなライブラリがインストールされており, 新しいバイナリに対する ldd の出力が以下のようになる場合を考えます。 libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 このように最後の番号が1つか2つ古いだけならば, 普通は /lib/libc.so.4.6.29 をコピーする必要はありません. わずかに古いライブラ リでも, プログラムは動作するはずだからです. もちろん, 新しいライブラリ と置き換えて, 以下のようにしても構いません. /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

シンボリックリンクのメカニズムは, Linux バイナリにのみ必要 なことに注意してください. FreeBSD のランタイムリンカは, メジャーリビジョ ン番号の一致したライブラリを検索しますから, ユーザが気にする必要はあり ません. ld.so の設定 -- FreeBSD 2.2-RELEASE のみ

このセクションは, FreeBSD 2.2-CURRENT 以降にのみ当てはまります. 2.1-STABLE を使用している方は, 飛ばしてください.

最後に, FreeBSD 2.2-RELEASE を使われている場合は, Linux のランタイムリンカと その設定ファイルがシステムに導入されていることを確認してください. これらのファイルは, FreeBSD システムの適切な位置(/compat/linux ツリー以 下)にコピーされている必要があります. /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config

使用できる Linux システムがない場合は, 必要なファイルは近くの FTP サイ トから入手してください. 各種ファイルの入手先についての情報を, 後に付 けておきます. ここでは, 必要なファイルの入手先がわかっているものとしま す.

以下のファイルを取得します(バージョンの不一致を避けるために, すべて同一 の FTP サイトから入手してください). 取得したファイルを /compat/linux 以下にインストールしてください(例えば, /foo/bar は, /compat/linux/foo/bar にインストールされます). /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so

ldconfig と ldd は, /compat/linux の下にある必要はありません. システム のどこにあっても構いません. ただ, FreeBSD の同名のコマンドと間違えないように 注意してください. /usr/local/bin の中に, ldconfig-linux, ldd-linux とし てインストールするのもよいアイディアでしょう.

/compat/linux/etc/ld.so.conf ファイルを作成し, Linux ラインタイムリンカ がシェアードライブラリを検索するディレクトリを記述してください. このファ イルはプレインテキストファイルで, それぞれの行にディレクトリ名を含みま す. /lib と /usr/lib は標準ですから, 以下のようなディレクトリが追加できま す. /usr/X11/lib /usr/local/lib

Linux バイナリが, /lib/libc.so というライブラリを開いた場合, エミュレー タは内部で, ファイル名を /compat/linux/lib/libc.so にマップします. エ ミュレータがライブラリを検索するために, すべての Linux のライブラリ (/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so など) は, /compat/linux 以下にインストールされていなければなりません.

FreeBSD 2.2-RELEASE を使用している場合は, Linux の ldconfig プログラム を実行する必要があります. % cd /compat/linux/lib % /compat/linux/sbin/ldconfig

ldconfig はスタティックリンクされていますから, 実行するのにシェアードラ イブラリを必要としません. ldconfig は, /compat/linux/etc/ld.so.cache ファイルを作成し, すべてのシェアードライブラリの名前を格納します. ライ ブラリの追加をおこなった場合には, ldconfig を再実行して, このファイルを作り 直さなければなりません. 2.1-STABLE では, /compat/linux/etc/ld.so.cache をインストールしたり, ldconfig を実行したりしないでください. 2.1-STABLE では, システムコー ルの実装方法が異なるため, ldconfig は使用されません.

これで, libc シェアードライブラリを必要とする Linux バイナリを実行する設 定が終了しました. ldd を ldd 自身に実行してテストしてください. ldd-linux としてインストールしている場合は, 以下のような結果になるはず です. % ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

ここまで終了すれば, 新しい Linux のバイナリをインストールできます. 新しい Linux バイナリをインストールするときは, それがシェアードライブ ラリを必要とするかどうか確認してください. 必要とする場合は, /compat/linux 以下にインストールされているかどうか確認してください. こ れは, Linux の ldd を新しいプログラムに対して実行し, 出力を確認するこ とによりおこなえます. ldd(ldd(1)マニュアルページも参照してください)は, プ ログラムが必要とするシェアードライブラリのリストを, majorname (jumpversion) => fullname という形式で出力します.

fullname のかわりに ``not found'' と出力される場合は, ライブラリの追加をす る必要があります. 必要なライブラリの名前は, majorname に libXXXX.so.N.mm という形式で示されています. Linux の FTP サイトで libXXXX.so.N.mm を探し, インストールしてください. XXXX(名前)とN(メジャー リビジョン番号)は一致している必要があります. マイナー番号 mm は, それほ ど重要ではありませんが, なるべく最新のものをインストールするようにして ください. ホストネームリゾルバの設定

DNS がうまく動作しなかったり, 以下のようなエラーメッセージが表示され る場合は, /compat/linux/etc/host.conf ファイルを設定する必要があります. resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword ファイルの内容を以下のように設定してください. order hosts, bind multi on ここで, order は /etc/hosts を最初に検索し, 次にDNSを検索するように指定 します. /compat/linux/etc/host.conf がインストールされていない場合は, Linux のアプリケーションは, FreeBSD の /etc/host.conf を使用しようとして, 文法の違いによる警告を表示します. /etc/resolv.conf を使用してネームサー バを設定していない場合には, `bind' を削除してください.

最後になりますが, 2.1-STABLE を使用している場合は, RESOLV_HOST_CONF 環境変数を指定して, アプリケーションにホストテーブル の検索方法を指定する必要があります. FreeBSD 2.2-RELEASE を使用している場合 は, スキップしてください. /bin/csh を使っている場合は, 以下のようにし ます. setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf /bin/shの場合は, 以下のようにします. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF 必要なファイルを探すには

注意: 以下の情報は, この文書が書かれた時点では有効ですが, FTP サイトの 名前, ディレクトリ, 配布ファイル名などは, 変更されている可能性がありま す.

訳注: ここに取り上げられている FTP サイトは, 日本国内にもミラーサイト が多数存在します。なるべく近くの FTP サイトからファイルを入手してくだ さい.

Linux は, いくつかのグループが, それぞれ独自のバイナリ配布セットを作成 して配布しています. 配布セットは, ``Slackware'' や ``Yggdrasil'' など の名前がつけられています. これらの配布セットは, 多くの FTP サイトから 入手できます. ファイルが展開されており, 必要なファイルのみを取得できる 場合もありますが, 通常は圧縮された配布セットの形で入手できます. 配布 セットは, いくつかのサブディレクトリに, gzip で圧縮された tar ファイル として格納されています. それぞれの配布セットの一次配布先は, 以下の通り です. sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions

ヨーロッパのミラーサイトの例: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions

混乱を避けるために, ここでは Slackware だけを取り上げます. この配布セッ トは, 多くのサブディレクトリ内にある別々のパッケージから構成されていま す. 通常, パッケージはインストールプログラムにより自動的に制御されま すが, ``手動で''おこなうことも可能です. まず配布セットの中の, ``contents'' サブディレクトリの内容を書くにしてください. ここには多く の小さなテキストファイルが含まれおり, それぞれのパッケージの内容が記述 されています. 必要なファイルを探している場合は, まず contents 内のテキ ストファイルを取得し, そのファイルの中から grep を使用して検索するのが, 最も速い方法でしょう. 以下に必要となるであろうファイルを, grep を使用 して検索した例を示します. Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs

この場合は, ldso, shlibs, xf_lib, oldlibs というパッケージが必要なこと がわかります. それぞれのcontentsファイルの中で, ``PACKAGE LOCATION'' と書いてある行を探してください. その行に, パッケージが含まれているディ スク, 今回の場合はサブディレクトリ名が書かれています. たとえば, 以下の ようになります. Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9

``diskXX'' というのは, 配布セットの ``slackware/XX'' サブディレクトリ を示します. それ以外の場合は, ``contrib'' サブディレクトリに格納されて います. 今回の場合は, 以下のファイルを取得すればいいことがわかります (ファイル名は, 配布セットのルートディレクトリからの相対パスで示してあ ります). slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz

gzip で圧縮された tar ファイルから必要なファイルを /compat/linux ディ レクトリに格納してください(必要なファイルのみを展開するか, あるいは必 要でないファイルを後で削除してください). これで作業は終了です.

参照: ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 FreeBSD への Mathematica のインストール

原作: &a.rich and &a.chuck

訳: &a.kiroh;. この文書は, Mathematica 2.2 の Linux バイナリディストリビューションを, FreeBSD 2.1 にインストールする方法について説明します.

Mathematica は, そのままでは FreeBSD をサポートしていませんが, Linux は サポートしています. ですから, Linux エミュレータの設定が終わってしまえ ば, Mathematica を動作させる環境はほとんど整ったことになります.

DOS 用のスチューデント版 Mathematica から Linux バージョンへのアップグレー ド価格は, 執筆時点 (1996年5月) では, $45.00 です. 直接 Wolfram(電話番号(217) 398-6500)に注文して, 支払いはクレジットカー ドでおこなえます。 Mathematica ディストリビューションの展開

バイナリは, Wolfram から CDROM で配布されています. CDROM には, 1ダー スほどの tar ファイルが含まれており, それぞれサポートされているアーキテ クチャに対応しています. Linux 用のファイルは, LINUX.TAR です. 例えば /usr/local/Mathematica 以下にインストールする場合は, 以下のようにしま す. % cd /usr/local % mkdir Mathematica % cd Mathematica % tar -xvf /cdrom/LINUX.TAR Mathematica パスワードの取得

Mathematica を実行する前に, 使用するマシンに対応した `machine ID' を Wolfram から取得する必要があります.

Linux 互換ランタイムライブラリがインストールされており, mathematica の展 開が終了したら, Install ディレクトリで `mathinfo' プログラムを使用す ることで `machine ID' を得ることができます. % cd /usr/local/Mathematica/Install % mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 % ここで, `richc' の `machine ID' は, `9845-03452-90255' となります. ioctl のメッセージは無視してください. まだ FreeBSD では実装されていません. Mathematica を実行するたびに同様のメッセージが表示されますが, 実際の使 用に問題はありませんので, 無視してかまいません.

電子メールや電話, ファックスなどで Wolfram に `machine ID' を知らせ て登録すると, いくつかの番号のグループからなるパスワードが送り返されて きます. パスワードを, マシン名, ライセンス番号とともに, mathpass ファ イルに追加します. 追加は, 以下のようにおこないます. % cd /usr/local/Mathematica/Install % math.install ライセンス番号と, Wolfram から送られてきたパスワードを入力を求めます. 入力を間違えたりして, math.install の実行が失敗しても大丈夫です. `mathpass' ファイルを手動で編集して, 情報を訂正してください.

パスワードの入力後, math.install では, インストール方法を, デフォルト 設定でのインストールか、自分で方法を指定するインストールから選ぶことが できます. 筆者のようにインストールプログラムを信用していない場合は, 自 分でディレクトリを指定する方を選択するでしょう. 自分で指定するインストー ルを選んだ場合, math.install 自身ではディレクトリの作成はおこないません. 注意してください. 別のウィンドウでシェルを開いて, 指定するディレクトリ を作成してください. 存在しないディレクトリを指定して, math.install が インストールに失敗した場合には, ディレクトリを作成し, math.install を 再び実行してください. 筆者らがインストール先に選んだディレクトリは, 以 下の通りです. くれぐれもあらかじめ作成してから, math.install で指定す るようにしてください. /usr/local/Mathematica/bin バイナリファイル /usr/local/Mathematica/man/man1 マニュアルページ /usr/local/Mathematica/lib/X11 XKeysymbファイル また, システムレコードファイルとして, /tmp/math.record を使用するように 設定することもできます. このファイルには, セッションのログが記録されま す. この設定が終了すると, math.install は残りのファイルを展開して, 必 要な場所に格納します.

Mathematica ノートブックの機能は, X フロントエンドとして本体とは別に含 まれています. X フロントエンドを正しくインストールするには, /usr/local/Mathematica/FrontEnd ディレクトリに移動し, ./xfe.install シェ ルスクリプトを実行します. インストール先を指定しなければなりませんが, あらかじめ作成する必要はありません. 必要なディレクトリは, すべて math.install によって作成されているからです. インストールが終了したら, /usr/local/Mathematica/bin ディレクトリに, ``mathematica'' という名前の シェルスクリプトが新たに作成されているはずです.

最後に, Mathematica がインストールしたシェルスクリプトを修正する必要 があります. /usr/local/Mathematica/bin に含まれるすべてのシェルスクリプ トの先頭部分に以下の行を追加します. XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB これは, Mathematica が使用する Mathematica バージョンのキーマップファイル XKeysymDB の場所を指定するものです. 2.1-STABLE を使用している場合は, 以下の行も追加してください. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF これは, Mathematica に Linux バージョンの host.conf を使用するように指定し ます. FreeBSD の host.conf の文法は, Linux のものと異なっているため, この 指定をおこなわないと, /etc/host.conf に関わるエラーが発生します.

新しいマニュアルページを利用したい場合は, さらに /etc/manpath.config ファイ ルを修正する必要があります. また自分の~/.cshrcを変更して, /usr/local/Mathematica/bin をパスに追加してください.

これでインストール作業はすべて終了です. ``mathematica'' とタイプすれば, 見栄えのする Mathematica ノートブックが表示されるはずです. Mathematica には, Motif ユーザインタフェースが含まれますが, スタティックにリンクさ れているため, Motif のライブラリは必要ありあません. 頑張って Mathematica をインストールしてください. バグ

ノートブックフロントエンドは, 以下のようなエラーメッセージを表示して, ハングすることがあることが知られています. File .../Untitled-1.mb appears to be broken for OMPR.257.0 今のところ原因はわかっていませんが, このバグが影響を及ぼすのは, ノートブッ クの X window フロントエンドのみです. Mathematica エンジン本体に影響は ありません. そのため, ``math'' によって起動されるコマンドラインのインタ フェースを使用している場合は, このバグは関係ありません. 謝辞

&a.sosと&a.peterに深く感謝します. Linuxエミュレーションが現在の形に あるのは, 彼らのおかげです. そして, 彼ら二人にハッパをかけて, 犬のよう に働かせた Michael Smithに. 今やLinuxエミュレーションは, linuxよりうま くlinuxバイナリを実行できます！ :-) diff --git a/ja/handbook/memoryuse.sgml b/ja/handbook/memoryuse.sgml index 2935142e0f..fd46b80eb2 100644 --- a/ja/handbook/memoryuse.sgml +++ b/ja/handbook/memoryuse.sgml @@ -1,61 +1,61 @@ - + - + PC におけるメモリの利用

原作: &a.joerg;. 16 Apr 1995.

訳: &a.tomo;. 29 Oct 1996. FreeBSDがi386プラットフォーム上でどのようにメモリを使うかに ついての説明です. ブート部分は0:0x7c00にロードされ, すぐに自分自身を 0x7c0:0に移します. (これは手品ではなく, 単なる%cs セレクタのための調節であり, ljmpにより行われます. ) それから最初の15セクタを0x10000(biosbootのMakefileのなかの BOOTSEG部分)にロードし, 作業領域のスタックを0x1fff0以下に セットします. このあと, boot2 に飛びます. つまり, boot1 自身と (ダミーの) DOS パーティションテーブルを飛び越えて, %csセレクタを 調節します---この時点ではまだ16ビットモードです. boot2はブートファイルを要求し, a.outヘッダを調べます. 0x00ffffffによってファイルエントリポイントを (通常は0xf0100000に)マスクし, ロードします. このため, 通常のロードポイントは1MB(0x00100000)になります. ロードしている間, リアルモードでBIOSを使うため, ブートコードは, リアルモードとプロテクトモードの間を行ったり来たりします (訳注: これは, BIOSがリアルモード用に書かれていて, ロードすべき領域がリアルモードではアクセスできない1MBより上位の アドレスであることから, ブートコードがリアルモードと プロテクトモードを切り替えながら動作するためです). ブートコード自身はプロテクトモードで%csと%ds/%es用に セグメントセレクタ0x18と0x20を使い, リアルモードに戻るのに0x28を使います. 最終的にカーネルはアドレス空間全体をカバーできるようなダミーの ディスクリプタを参照して%cs 0x08と %ds/%es/%ss 0x10でスタートします. カーネルはそのロードポイントで起動されます. 別の(高位)アドレスにリンクされるので, ページテーブルやページディレクトリなどが適切に設定され, ページングが有効になり, カーネルがリンクされたアドレスで 動作するようになるまでは, カーネルはロードアドレスからの 相対アドレス (PIC: position independent code) を用いて 実行されなければなりません. 寄贈: &a.davidg;. 16 Apr 1995. カーネルの BSS セグメントの直後の物理ページ (実メモリ) に proc0 (訳注: プロセス番号 0, swapper) のページディレクトリや ページテーブル, Uページが配置されます. 仮想記憶機構が初期化された少しあと, 0x1000-0x9ffffの実メモリとカーネル (text + data + bss + 上記の proc0 に関わるもの + その他) の後ろの実メモリは, 通常の仮想記憶ページの形で利用可能となり, グローバルな空きページリストに追加されます. diff --git a/ja/handbook/policies.sgml b/ja/handbook/policies.sgml index 52c41dd2e5..ae31025ace 100644 --- a/ja/handbook/policies.sgml +++ b/ja/handbook/policies.sgml @@ -1,257 +1,257 @@ - + - + ソースツリーのガイドラインおよび方針

原作: &a.phk;.

訳者: &a.mihoko; 6 September 1996 . 本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや ポリシーについて書かれています. Makefile 中の MAINTAINER

1996年6月.

FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守 されている場合は, ソースツリーの当該 Makefile に MAINTAINER= email-addresses

が付け加えられています. これを記述することによって, この部分が誰 に保守管理されているかを世界中のユーザに伝えることができます.

この意味は次のとおりです:

保守担当者がそのコードを所有し, そのコードに対する責任を持っ ています. すなわち, その人がそのコードに関するバグの修正やトラブル報告 に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, そのソフトウェアの新しいバージョンに適切に追従させる作業をその人が行い ます.

保守担当者が決められているディレクトリに対して変更をおこなう場合は, 変更をおこなう前に, その変更内容を保守担当者に送って, 保守担当者にレビューをしてもらってください. 保守担当者が, 電子メールに一定期間応答しない場合にのみ, 保守担当者がレビューすることなしに, 変更をおこなうことが認められます. しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー してもらうようにしてください.

もちろん, この義務を引き受けることができない人やグループを 保守管理者として追加することはできません. また, 保守管理者がソースツリー管理者 ("committer") である必要は ありません. 寄贈ソフトウェア

1996年6月.

FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト 以外のところで保守されています. 歴史的な経緯から, 私たちはこれを 寄贈 ソフトウェアと 呼んでいます. perl や gcc, patch などがその例です.

ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が 取られてきましたが, どの方法にもいくつかの利点と欠点があります. これまで欠点のない明確な方法はありませんでした.

議論した結果, これらの方法のうちの一つが「公式な」方法として選択され ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用 されます. その上, この方法では, だれもが(cvs にアクセス権のない人でさえ)「公式」 バージョンのソースに対する差分を簡単に得ることができます. これは古い方法にはなかった大きな利点です. ですから, 既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更 点を返すのがとても容易になります.

しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って いる人々に委ねられています. もしこの方法を使用することが, その人が扱っているパッケージには 極端に合わないような場合には, コアチームの承認さえあれば, これらの ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 将来にわたってパッケージを保守できるということは, 大変重要な事柄に なってきます.

プログラミング言語 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 に特化した 変更をおこなわないようにしたソースを(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 コミットによってこのディレクトリ上のファイルを アップグレードしてはいけません. (訳注:ベンダから配布された)新しいバージョンや公式パッチだけが (訳注:このディレクトリに)取り込まれなくてはいけません. GNU cpio 2.4.2 を取り込むためには, 以下のファイルが削除されました: INSTALL cpio.info mkdir.c Makefile.in cpio.texi mkinstalldirs cpio を新しいバージョンにアップデートするためには, 次の作業を おこないます: 1. 空のディレクトリに新しいバージョンを取り出します. [ファイルに「いかなる変更」も加えてはいけません] 2. 上記にリストされたファイルと, FreeBSD には無意味な ファイルを削除します. 3. 次のコマンドを実行します: cvs import -m 'Virgin import of GNU cpio v' \ src/contrib/cpio GNU v 例えば, バージョン 2.4.2 を取り込むためには, 次のように タイプします: cvs import -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 共有ライブラリ

Contributed by &a.asami;, &a.peter;, and &a.obrien;. 9 December 1996.

もしあなたが共有ライブラリをサポートする機能を port に追加した り, 共有ライブラリをサポートしていない他のソフトウェアに追加する 場合には, 共有ライブラリのバージョン番号を次の規則にしたがって つけてください. 一般的には, この規則は, ソフトウェアのリリースバージョンとは 全く関係ありません.

共有ライブラリを作成する三つの重要な規則は次の通りです: 1.0 から始める 過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす 互換性のない変更の場合は, メジャー番号を増やす

例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします. 機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 強制的にメジャー番号を変更します.

メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. FreeBSD のダイナミックリンカは, 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 を優先 して使用します.

移植されていないライブラリに対しては, リリースごとに共有ライブラリの バージョン番号を一度だけ変更するのが私たちのポリシーです. あなたがシステムライブラリのバージョン番号を上げた場合は, Makefile の commit ログを確認してください. 結果としてそのリリースには, 共有ライブラリのバージョン番号が アップデートされた Makefile に入るので、最初にその変更を 確かめるのがソースツリー管理者 ("committer") の責務です. その後のどんな変更も, そのリリースには入りません. diff --git a/ja/handbook/porting.sgml b/ja/handbook/porting.sgml index fb8b75b678..73f42bd61e 100644 --- a/ja/handbook/porting.sgml +++ b/ja/handbook/porting.sgml @@ -1,1728 +1,1728 @@ - + - + フリーソフトウェアの移植

原作: &a.jkh;, &a.gpalmer;, &a.asami;, &a.obrien;. 28 August 1996.

訳: &a.simokawa;, &a.asami;. 10 November 1996.

フリーで手に入るソフトウェアを移植することは, 何かをゼロから自分で 作ることほどは人に感謝されないにしても, どこに手を入れれば動くのかわから ないような人でも使えるようにするという意味で, FreeBSDの発展のためにとて も重要なことです. 移植されたすべてのソフトウェアは「Portsコレク ション」(the Ports Collection) と呼ばれ, 階層的に分類されて集められ ています. これによって, 新しいユーザでも, 何がすぐに簡単にコンパイルで きる状態で手に入るのか, についての概要をつかむことができます. また, 移 植されるソースコードについては, そのほとんどを実際には含まず, FreeBSD で動かすためのほんのちょっとの差分ファイルといくつかの定義ファイルだけ をソースツリーに入れることで, かなりのディスクスペースが節約できます.

これから, FreeBSD 3.x用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は /usr/share/mk/bsd.port.mkというファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらの ファイルを参照してください. これにはコメントが細かく書いてありますので, Makefile を読むのにあまり慣れていない人でも, 得るものはとても大きいで しょう. 移植を始める前に

注意: ここでは, 変更可能な変数の一部についてのみ記述してい ます. ほとんどの変数はbsd.port.mkの始めに記述があり ます. また, このファイルは非標準のタブの設定になっていま す. Emacs や Vim はファイルのロード時にこれ を認識しますが, viやexでは, ファイルをロード したら `:set tabstop=4'のようにして正しい値を設定する ことができます.

Portの過程で, 修正や, どのバージョンのUNIXで動くかによる条件 つきコンパイルなどが必要なコードに出会うかもしれません. その ような条件つきコンパイルなどのための変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD などの他のBSDシステムへの移植が可能な ように, できるだけ普遍的な変更をおこなうことを心がけてください.

4.3BSD/Reno (1990) およびそれより新しいBSD版を古いバージョン と区別するには `BSD' マクロを利用するのがよいでしょう. これは <sys/param.h> で定義されています. このファ イルがすでにインクルードされていればよいのですが, もしそうでな い場合には以下のコードを, その.c ファイルの適当な場所 に加えてください. #ifdef (defined(__unix__) || defined(unix)) && !defined(USG) #include #endif

これらのシンボルが定義されているすべてのシステムには sys/param.h があるはずです. もし, そうでないシステムを発見した ら我々にも教えてください. &a.ports; までメールを送ってください.

あるいは, GNU の Autoconf のスタイルを使用することもできます, #ifdef HAVE_SYS_PARAM_H #include #endif この方法を使用するときには, Makefile 中のCFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてく ださい. いったん<sys/param.h>がインクルードされると, #if (defined(BSD) && (BSD >= 199103)) このようにしてそのコードが4.3 Net2コードベース, または それより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルさ れているかどうかを検出するために使用します. 4.4BSD-Lite2 コードベースでは, BSD マクロの値は 199506 になっ ています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされた バージョンとを区別するのに使用するべきものではありません. この目的のためには, __FreeBSD__ マクロをかわりに使用してくださ い.

以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されてい ます. 変更がFreeBSDだけに適用されるとき以外は使用しないでく ださい. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSDの流儀です. FreeBSD 2.xでは__FreeBSD__が2と定義されていま す. それ以前の版では1になっています. その後の版では, そのメジャー番号に合うように上がっていきます. もし, FreeBSD 1.x システムと FreeBSD 2.x あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であ れば (`ld' を使うときのシェアードライブラリ用のな オプションなど), __FreeBSD__を使い `#if __FreeBSD__ > 1' のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif __FreeBSD_version の値は以下の通りです: 2.0-RELEASE: 199411 2.1-current's: 199501, 199503 2.0.5-RELEASE: 199504 2.2-current (2.1以前): 199508 2.1.0-RELEASE: 199511 2.2-current (2.1.5以前): 199512 2.1.5-RELEASE: 199607 2.2-current (2.1.6以前): 199608 2.1.6-RELEASE: 199612 2.1.7-RELEASE: 199612 2.2-RELEASE: 220000 2.2.1-RELEASE: 220000 (2.2-RELEASE と同じです) 2.2-STABLE (2.2.1-RELEASE 以後): 220000 (これも同じです) 2.2-STABLE (texinfo-3.9 以後): 221001 2.2-STABLE (top 導入以後): 221002 2.2.2-RELEASE: 222000 2.2-STABLE (2.2.2-RELEASE 以後): 222001 3.0-current (1997年5月現在): 300000 見ての通り, これは年・月というフォーマットになっていましたが, バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う ように変更になりました. 並行していくつかのブランチ(枝分かれし たバージョン)を開発する場合には, リーリスされた日付でそれらの リリースを分類することが不可能だからです. (あなたが今 port を作成するときに, 古い -current 達について心配 する必要はありません. これは参考のために挙げられているにすぎま せん.)

これまで, 何百ものportが作られてきましたが, __FreeBSD__が正しく使われたのは, 1つか2つの場合だけで しょう. 以前のportが誤った場所でそのマクロが使っているからと いって, それをまねする理由はありません. 3分porting

この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う.

まず, 元のtarファイルを${DISTDIR}に置きます. デフォルトは/usr/ports/distfilesです.

注: 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. Makefileの作成

最小限のMakefileは次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG USE_IMAKE= yes .include

おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, の節をご覧ください. Package記述ファイルの作成

どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それにPLISTです. COMMENT

これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen DESCR

これは, そのソフトウェアについての, すこし長い説明を記述しま す. そのportが何をするのかについての数段落程度の簡潔な解説があれば 十分です. 注: このファイルはマニュアルでもなければ, 使用方 法やコンパイル方法についての細かい説明書でもありません. 特 に, READMEファイルを何も考えずにここにコピー するようなことはしないでください. (もちろん, READMEが そのソフトウェアの簡潔な説明になっている場合は別ですが.)

このファイルの最後にあなたの名前を書くことが推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) - Satoshi asami@cs.berkeley.edu PLIST

このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は /usr/local か /usr/X11R6) からの 相対パスです. また, マニュアルは圧縮されているものとします.

簡単な例を載せておきましょう: bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm

'Packing list'の詳細については, pkg_create(1)の マニュアルを参照してください. チェックサムファイルの作成

ただ, `make makesum' と入力するだけです. bsd.port.mkにルールがあるので, 自動的にfiles/md5が 生成されます. Portのテスト

そのportが正しく動くことを, package化を含めて確認してく ださい. まず, `make install', `make package' を試してください. また, `pkg_delete <pkgname>' をして,すべてのファイルとディレクトリ が正しく消去されているかどうかを確認してください. それから, `pkg_add <pkgname>.tgz' をおこない, すべての ファイルが再び現れ, 正しく動作することを確認してください. そ して再度 `pkg_delete <pkgname>' を実行してか ら, `make reinstall; make package' を実行して, packing list にあなたの作ったportがインストールする以外のファ イルが含まれていないことを確認してください. Portの送付

さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. そのた めには, 必要なファイル (この節で述べたすべてのファイル -- た だし, オリジナルのソースファイル, `work' サブディレ クトリ, およびpackageは含みません) をまとめて .tar.gz ファイルにし, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ へ置き, send-pr(1) を使って私たちのところにメールを送っ てください (categoryは `ports', classは `change-request' を 使ってください). 私たちは, 何か不明な点があったらあなたに確 認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの `Additional FreeBSD contributors' のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport

残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細

まず, あなたがportのディレクトリで `make' とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mkも開いておくとよいかもしれません.

しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetchというターゲットが実行されます. このfetchターゲッ トはローカルディスクの${DISTDIR}に配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルを${DISTDIR}に見つけることができなけ れば, Makefileに指定されているURL ${MASTER_SITES}, そして私たちのFTPサイトで ある (ここ には, 私たちが取ってきたファイルをバックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに直接接続されている場合には, ${FETCH} を使って, その名前のファイルを取っ てきて, ${DISTDIR}に保存します. 次に実行されるのはextractターゲットです. これは, ${DISTDIR}にある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリ${WRKDIR} (デフォルトは work) に展開します. 次に, patchというターゲットが実行されます. まず, ${PATCHFILES}に定義されている, すべてのパッ チをあてます. 次にもし${PATCHDIR} (デフォ ルトはpatches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットはconfigureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, ${HAS_CONFIGURE} あるいは ${GNU_CONFIGURE} がセットされていれば, ${WRKSRC}/configure が実行されます. もし, ${USE_IMAKE} がセットされていれば, ${XMKMF} (デフォルト: `xmkmf -a') が実行されます. 最後に, buildというターゲットが実行されます. これは, そのport の専用の作業ディレクトリ (${WRKSRC}) にい き, コンパイルするのが役目です. もし ${USE_GMAKE} がセットされていれば, GNU makeが使用されます. さもなければFreeBSDの makeが使用されます.

上記はデフォルトのルールです. さらに, `pre-<何とか >や `post-<何とか>' というターゲット が定義してあったり, そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それ らはデフォルトの動作の前後に実行されます.

たとえば, post-extractというターゲットがMakefile で定義されていて, pre-buildというファイルが, scriptsサブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-buildスクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefileのターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に理解しやす いからです.

デフォルトの動作はbsd.port.mk の `do-<何とか>' というターゲットでおこなわれます. たとえば, portを展開するコマンドは, `do-extract' というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, `do-<something>' というターゲッ トを再定義することによって, どのようにでも直すことができます.

「メイン」のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください.

これで, ユーザが `make' と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手

オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 (<foo>.tar.gzあるいは <foo>.tar.Z) で入手して, それを ${DISTDIR} にコピーします. 可能なかぎり, 広 く使われている主流のソースを使用するようにしてください.

もし, ネットワークへの接続のよいFTP/HTTPサイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 最後の手段として, 私たち 自身で, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/LOCAL_PORTS/ に置くことができます. この場所は, 変数 ${MASTER_SITE_LOCAL} を使って参照してください. これについての問い合わせのメールは &a.ports へお願いします.

もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, ${DISTDIR} に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のをご覧ください). Portの修正

適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルでおこなえるようになっ ていないといけません.

もし, あなたのportのコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wallの模範的な Configureスクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ「プラグ & プレ イ」の状態でmakeできることをめざしています.

注意: あなたが作成しFreeBSDのportsに寄付されたパッチファイル, スクリプトおよびその他のファイルは，明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます． パッチをあてる

portの過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, `patch-<xx>' という名前のファイルに入れてくだ さい. <xx>はパッチが適用される順番を示します -- これらは, アルファベット順, つまり `aa' が 最初, つぎに `ab' などとなります. これらのファイル を${PATCHDIR}に置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは ${WRKSRC} (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共に${WRKSRC}/foobar.c を修正する, など.) コンフィグレーション

カスタマイズのために追加したいコマンドがあれば, configureという名前のスクリプトに入れて `scripts' サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいはpost-configure というMakefileのターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い

もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVEの定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とするportのみコンパイルされま す). Makefileの作成

Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックには があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります.

では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース

ソースは${DISTDIR}に, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 ${EXTRACT_CMD}, ${EXTRACT_BEFORE_ARGS}, ${EXTRACT_AFTER_ARGS}, ${EXTRACT_SUFX}, ${DISTFILES}を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, `EXTRACT_SUFX=.tar.Z' とするだけです.)

最悪の場合には, 自分で `do-extract' ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. DISTNAME

${DISTNAME}にはportの名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (${DISTFILES}) は ${DISTNAME}${EXTRACT_SUFX}という名前 になっています. 例えば, `DISTNAME=foozolix-1.0'の場 合, 通常のtarファイルだと, foozolix-1.0.tar.gz のようになります. さらにデフォルトのルールでは, tarファイルは work/${DISTNAME}というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, portが複 数の配布ファイルを必要とするときには, 単に明示的に ${DISTFILES}を設定してください. もし, ${DISTFILES}の一部だけが実際に展開される場合 には, それらを${EXTRACT_ONLY} に設定してくだ さい. この変数が定義されている場合には, 展開時に ${DISTFILES}に優先して利用されます. 残りのファ イルも${DISTDIR}に取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. CATEGORIES (分類)

完成したpackageの実体は/usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packagesのサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が ${CATEGORIES}という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在するカテゴリを見て, そ のportに適したもを選んでください. (などが参考になるでしょう). もしそのportが本当 に現在存在するすべてのものとは異なっている場合には, 新しいカテ ゴリ名を作ることもできます. MASTER_SITES

オリジナルの配布ファイルを指し示すFTPまたはHTTPのURLのディ レクトリ部分までを${MASTER_SITES}に記録しま す. スラッシュ (/) を最後につけることをお忘れなく.

配布ファイルがシステム上に存在しないときに, makeマクロは ${FETCH}でこの変数に指定されたサイトから取っ てきます.

複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています.

オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications

ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブのミラーの中で好みのものを使用することが可能 です. PATCHFILES

もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, ${PATCHFILES}にファ イル名を, ${PATCH_SITES}にサイトとディレクト リの名前を${MASTER_SITES}と同様に設定してく ださい.

そのパッチ内のファイル名ががソースツリーの一番上のディレク トリ (${WKRSRC}) からの相対パスになっていな い場合には, ${PATCH_DIST_STRIP}を指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な `foozolix-1.0/' がついている場合には, `PATCH_DIST_STRIP=-p1'としてください.

これらのパッチは圧縮されていても大丈夫です. ファイル名が `.gz' か `.Z' で終わる場合には自動的に復元 されるようになっています.

もしパッチが, 文書などその他のファイルと一緒にgzipされた tarファイルで配布されている場合には，単純に ${PATCHFILES} を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を ${DISTFILES} と ${MASTER_SITES} に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを ${PATCHDIR} ディレクトリに patch-<xx>という名前でコピーするかして, パッチを適用するようにします．(普通の gzip か compress された tar ファイルであれば，通常のソースファイルと一緒にその時までに 展開されていますので，明示的に展開する必要はありません．) もし，後者の方法を使用する場合には，すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. MAINTAINER

あなたのメールアドレスをここに入れてください. お願いします. :)

保守担当者(maintainer)の責任についての詳細は， の節をご覧ください． 依存関係

このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. LIB_DEPENDS

Portが必要とする非標準の共有ライブラリをこの変数で指定 します. これは `lib:dir' という組のリストで, うち lib が共有ライブラリの名前, そしてdir がそのライブラリが見つからない場合にインストールするport のあるディレクトリです. 例えば, LIB_DEPENDS= jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg と指定してあれば, まずメジャーバージョンが6のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ からインストールしようとします. 前半のlib 部分はそのまま `ldconfig -r | grep' へ引数として渡されることに注意してください. 特 に, ピリオド (.) の前には上記の例のようにバックスラッシュ を連続してつける必要があります. この依存関係はextract ステージのはじめでチェック されます. また, packageを作るときに必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. RUN_DEPENDS

Portを使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは`path:dir' とい う組のリストで, path がファイルまたはプログラムの 名前, そしてdir がそれが見つからない場合に作成する ためのディレクトリ名です. Path の最初の文字がスラッ シュ (/) の場合にはファイルとみなし, その存在を `test -e' でチェックします; そうでない場合にはプ ログラムであると仮定し, `which -s' を使ってそのプ ログラムがユーザのサーチパス上にあるかどうか確認します.

例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish:${PORTSDIR}/x11/tk まず, `/usr/local/etc/innd' というファイルが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, `wish' というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11/tk というサブディレクトリから作られます. (この例で, `innd' は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください.) この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. BUILD_DEPENDS

Portのコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは `path:dir' という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は `unzip' という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは「コンパイル」と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで全部をま とめて面倒を見てくれます. この依存関係はextract ステージからチェックされます. FETCH_DEPENDS

この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは `path:dir' という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, `ncftp2' という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係はfetchステージからチェックされます. DEPENDS

上の四つのいずれにもあてはまらないような依存関係がある場 合, または他のportのソースが展開されている必要がある場合 (インストールされているだけでは不十分な場合) にはこの変数 を使います. これはディレクトリ名のリストです (上の四つと違っ て特に「確認」するものがありませんので). コンパイル時の特別な指定

GNUのmakeを使う場合には, `USE_GMAKE=yes' と指定してください. PortにGNUのconfigureが含まれ ている場合には, `GNU_CONFIGURE=yes' を使います. GNU configureにデフォルトの `--prefix=${PREFIX}' 以外の引数を渡したい場 合には追加部分を${CONFIGURE_ARGS}で指定して ください.

X Window Systemのアプリケーションなど, imakeを 使ってImakefileからMakefileを作成するportの場合には `USE_IMAKE=yes' を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し `-a' フラグが問題をもたらすなら, さらに `XMKMF=xmkmf'としてください.

PortのMakefileが `all' 以外のものをメインのター ゲットとしている場合には, ${ALL_TARGET} でそ れを指定してください. `install' と ${INSTALL_TARGET} も同様です. NO_INSTALL_MANPAGES

あなたのportがimakeは使うものの `install.man' ターゲットを持っていない場合, `NO_INSTALL_MANPAGES=yes' を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) Motifを必要とするport

最近はコンパイルにMotifを必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 無料の互換ライブラリを作ろうとしているグループが少なくと も一つあります.) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的/静的にリンクできるようなしくみが用意されています. REQUIRES_MOTIF

MotifがないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. ${MOTIFLIB}

この変数はbsd.port.mkによってMotifライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motifライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください.

代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが `-lXm' として使われている場合には, かわりに `${MOTIFLIB}' と書いてください. Imakefileの中で `XmClientLibs' が使われている 場合には, それを `${MOTIFLIB} ${XTOOLLIB} ${XLIB}' と書きかえてください.

${MOTIFLIB} は通常 `-L/usr/X11R6/lib -lXm' か `/usr/X11R6/lib/libXm.a' に置き換えら れます. したがって前に `-L' や `-l' をつけ る必要はありません. Info ファイル

新しい版の texinfo(2.2.2-RELEASE およびそれ以降に入っています) には, `&dollar{PREFIX}/info/dir ファイル を更新するようにしてください. (この節は, とても長くてすいません, しかし info ファイルを作りあげるためには, これらは不可欠 です. 正しく行なえば, 美しい リストができますので, 辛抱してください! まず, これを知っておかなければなりません: % install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. (訳注: Info ディレクトリの INO-FILE を DIR-FILE にインストールする) Options: --delete Delete existing entries in INFO-FILE; don't insert any new entries. (訳注: INFO-FILE の中の項目を削除, 新しい項目は一切追加しない.) : --entry=TEXT Insert TEXT as an Info directory entry. (訳注: TEXT を Info ディレクトリの項目として追加する.) : --section=SEC Put this file's entries in section SEC of the directory. (訳注: このファイルの項目を Info ディレクトリの SEC という節に置く.) :

このプログラムは, 実際には info ファイルをこれから, editors/emacsを 使用します. まず, texinfo のソースを見て, --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout :

フォーマットについては見ればわかると思います. 1つのファイルに対して1つの info の項目しか書けないことに注 意してください, これは, `install-info --delete' が, そのバグにより, texinfo のソースにパッチをあてるかわりに, japanese/skk の portのディレクトリに戻って, `make clean; make' をして, info ファイルが texinfo ソースファイルから再び生成さ れることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので, --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@ # Subdirectories to make recursively. `lisp' is not included # because the compiled lisp files are part of the distribution # and you cannot remake them without installing Emacs first. -SUBDIR = lib-src src +SUBDIR = lib-src src man # The makefiles of the directories in $SUBDIR. SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@ ${srcdir}/gnu1.texi \ ${srcdir}/glossary.texi +all: info info: $(INFO_TARGETS) dvi: $(DVI_TARGETS)

/usr/share/info にあるからです. (このパッチはここにはありません.) もし, --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@ if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \ then \ (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \ for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \ (cd $${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ chmod a+r ${infodir}/$$f); \ (これは, 既存のportを修正するときのみ必要です.) pkg/PLIST を見て, info/dir にパッチをあて ようとするものすべてを削除します. これらは, pkg/INSTALL やその他のファイルにもあるかもしれない ので, いろいろさがしてみてください. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2 Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + sed -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include

新しい info ファイルを作成するのに, /usr/share/info/dir と上のコマンド, 以外は使用しな いでください. 実際のところ, もし port する人がこれに関して info/dir を削除する必 要はありません. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc

@unexec install-info --delete' コマンドは, info ファイル自身より先に置き, コマンドがファイルを読めるようにし ておかなければならないことに注意してください. また, `@exec install-info' コマンドは info ファイルおよび テストをして, 出来栄えに感服しましょう ライセンス上の問題

ソフトウェアによっては制限の厳しいライセンスがついてきたり, 法律的に問題があるかもしれません. (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によってさまざまな場合があり ます.

ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSDプロジェクトがFTPまたはCD-ROMで配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください.

よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに「有償再配布を禁ずる」という趣旨のライセン スがついてきた場合にはNO_CDROMという変数をセットして ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数を設定してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または「商用利用を禁ずる」とライセンスに書い てある場合にはRESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません.

注: GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません.

注: もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGALファイルを書き換えるのを忘れないようにし てください. アップグレード

Portのバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトのports-currentというディレクトリにあります) であることを確認してください.

次に, portのMakefileにMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備をしているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません.

保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff をとって送ってください. (例えば, 変更前のディレクトリが `superedit.bak' という名前でとってあり, 変更後のもの が `superedit' に入っているなら, `diff -ruN superedit.bak superedit' の結果を送ってください. ) diff の出力を見て, すべての変更が正しくなされているか確認して ください. 変更箇所については, send-pr (カテゴリーは, `ports')に diff の出力結果を添えて, 私たちに送ってもらうのが一 番よいです. commit する際に CVS に明確に記述しなければならない ので, 付け加えたり削除したりしたファイルがあったら, それについ て書いておいてください. やっていいことといけないこと

この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. WRKDIR

大事なファイルをworkサブディレクトリに置き忘れな いようにしてください. うっかり `make clean' とやっ たらこのディレクトリはその下のファイルとともにあとかたも なく消え去ってしまいます! スクリプトやパッチ以外に必要 なファイルがある場合には, ${FILESDIR}という サブディレクトリ(デフォルトでは, files)に入れ, post-extractターゲットでworkサブディレクト リにコピーするようにしてください. Package情報

Package情報, すなわちpkgディレクトリ内の COMMENT, DESCR, PLIST は必ず用意してください. これらはpackageを作る以 外にもいろいろ使われていますので, ${NO_PACKAGE}が指定してあってpackageを作 るのが禁止してあるportの場合でも常に必要です. マニュアルの圧縮, バイナリのstrip

マニュアルは圧縮し, バイナリはstripしてください. オリジナル のソースがバイナリを stripしてくれる場合は良いですが, そうでない場合には post-installターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になりま す: post-install: strip ${PREFIX}/bin/xdl

インストールされた実行形式がすでにstripされているかどうか はfileコマンドで確認できます. これが`not stripped' と言わなければ, stripされているということです.

MAN[1-9LN] 変数を使用すると, マニュアルの圧縮を自動的に行う ことができます. この方法を使うと, ユーザが /etc/make.conf中でNOMANCOMPRESSを設定し, マニュアルの圧縮を無効にしているかどうかを確認できます. これらの変数の指定は, MAINTAINER の指定の後 のセクションの一番最後で行ってください. こんな風に指定します: MAN1= foo.1 bar.1 MAN5= foo.conf.5 MAN8= baz.8

なお, 普通 Imake を使ってコンパイルされる X アプリケーショ ンの場合はこの指定は必要ありません.

PREFIX以外のディレクトリの下にマニュアルを置く ようなportではMANPREFIXを指定することが できます. さらに, 特定のセクションのマニュアルだけ, 標準では ない場所にインストールする場合(例えば多くの Perl のモ ジュールの ports の場合)には, 個々のマニュアルのパスを MANsectPREFIX (sectは, 1 から 9 または, L か N を表わします) によって指定できます. INSTALL_* マクロ

あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです． ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです． ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです． ${INSTALL_MAN} はマニュアルとその他のドキュメ ントをインストールするコマンドです．(圧縮はしません)

これらは基本的にinstallコマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. INSTALL package スクリプト

バイナリパッケージが pkg_add でインストールされるときに, 実行 される必要があるコマンドがあれば, pkg/INSTALL スクリプトを使っ て実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは `INSTALL ${PKGNAME} PRE-INSTALL' と実行され, 2度目 には, '`INSTALL ${PKGNAME} POST-INSTALL' と実行され ます. どちらのモードで実行されているかは, `$2' を調べることによってわかります. 環境変数 `PKG_PREFIX' には package がインストールさ れる directory が設定されます. 詳細は man pkg_add(1) を見てください. 注意すべきことは, port を `make install' で インストールするときには, このスクリプトは自動的に実行されな いということです. もし, 実行される必要があるならば, port の Makefile で明示的に呼ぶ必要があります. REQ package スクリプト

port が(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要があると きには, 「要件(requirements)」スクリプト pkg/REQ を作ること ができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべ きかを決定します. 詳細は, man pkg_create(1) と man pkg_add(1) を見てください. 付加的ドキュメント

普通のマニュアルやinfoファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, ${PREFIX}/share/docの下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう.

まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は${PKGNAME}からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想されるportの場合 には, ${PKGNAME}をそのまま使ってかまいません.

ユーザが/etc/make.confでこの部分を禁止するために NOPORTDOCSという変数をセットしている場合には， これらのドキュメントがインストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR} -p ${PREFIX}/share/doc/xv ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif

これらのファイルをpkg/PLISTに入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCSについては気にしないでください.)

(Packageの)インストールを行っているユーザに対してメッセージ を表示したい場合には, そのメッセージを pkg/MESSAGE に置くこともできます. この機能は, pkg_add したあとの 追加のインストール手順や, ライセンス情報を表示するのに便利で す. (注意: MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. DIST_SUBDIR

/usr/ports/distfilesディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (`Makefile' など) がある場合には, ${DIST_SUBDIR}にportの名前 (${PKGNAME}からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, ${DISTDIR}がデフォルトの /usr/ports/distfilesから /usr/ports/distfiles/${DIST_SUBDIR}に変更さ れ, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります.

また, ファイルを取ってくるときにバックアップサイトとして使わ れるftp.freebsd.orgのディレクトリ名にもこの変数の 値が使われます. (${DISTDIR}を明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず ${DIST_SUBDIR}を使うようにしてください.)

この変数はMakefile中で明示的に指定された ${MASTER_SITES}には影響しないことに注意して ください. フィードバック

Portを作るためにソフトウェアに変更を加えたら, なるべく原 作者にその旨を伝えてパッチ等を送ってください. これらが次のリ リースに取り入れられれば, アップグレードが楽になります. RCS文字列

RCSが特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 (`$') で囲まれており, `$Id' や `$RCS' などで始まり ます. パッチ作成上の注意

diffの再帰 (`-r') フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が 入っている場合などです. また, ファイルをまるごと消す場合には パッチを使わずにpost-extractターゲットで消す方が簡 単です. できあがった差分に満足したら, それらをソースのfileご とに別々のパッチファイルに分割してください. PREFIX

なるべくportは${PREFIX}に対する相対パス にインストールすることができるように心がけてください. この変数の値は${USE_IMAKE}か ${USE_X11}が指定してある時には ${X11BASE} (デフォルト/usr/X11R6), そうでない場合には${LOCALBASE} (デフォルト/usr/local) にセットされます.

サイトによってフリーソフトウェアがインストールされる場所が 違いますので, ソース内で `/usr/local' や `/usr/X11R6' を明示的に書かないようにしてくださ い. Xのプログラムでimakeを使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで `/usr/local' (imakeを使わないXのプログラ ムは `/usr/X11R6') と書いてあるところを `${PREFIX}' に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます.

変数${PREFIX}の値はportのMakefileやユー ザの環境で変更することもできます. しかし, 個々のportが Makefileでこの変数の値を明示的に設定することはなるべくしない でください. (X のプログラムでimakeを使用しないport の場合は, USE_X11=yesとしてください; これは PREFIX=/usr/X11R6とするのとはかなり違います.)

また, 他のportからインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, lessのフルパスをPAGERというマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\"と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使う portの時は -DPAGER=\"${LOCALBASE}/bin/less\") を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成

インストール時には${PREFIX}の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを `lib'というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. `etc' にセッ トアップ/コンフィグレーションファイル, `libexec' に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), `sbin' に管理者用のコマンド, `info' に GNU Info 用のドキュメント, そして `share' にアーキテクチャに依存しないファイルが入り ます. 詳細については man hier(7) を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. USENET ニュースを 扱う ports は例外です. これらは, ファイルのインストール先として ${PREFIX}/news を使用します. ldconfig

共有ライブラリをインストールするときには, 共有ライブラリのキャッ シュを更新するためにportのMakefileのpost-install target から`/sbin/ldconfig -m' を走らせてください. このコマンドの引数は共有ライブラリのインストールしてあるディ レクトリ (通常 ${PREFIX}/lib) です.

また, pkg/PLISTに@exec行を入れ, package をインストールした場合にも共有ライブラリがすぐ使えるように してください. この行は共有ライブラリを指定する行のすぐ後に書 くのがいいでしょう: lib/libtcl80.so.1.0 @exec /sbin/ldconfig -m %D/lib

絶対に引数なしでただ `ldconfig'とだけ書い てある行をMakefileやpkg/PLISTファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/libの内容のみとなり, ユーザのマシンにさまざま な問題をもたらします (「ぎゃぁ! このportをインストールした らxinitが使えなくなっちゃった!」). この掟を破った者は, 永久 に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. UID

もしあなたの portがインストールされるシステム上に特定のユー ザIDを必要とする場合は, pkg/INSTALL スクリプトから pwコマンドを実行して自動的にそのユーザを追加するよ うにしてください. japanese/Wnn や net/cvsup-mirror の portが参考になるでしょう. この ような場合には2桁の後半 (つまり50前後から 99まで) の数字を UIDとして利用するのが一般的です.

既にシステムや他の portで利用されている UIDを使わないように 十分注意してください. 現在の 50から 99までの間の UIDは以下の とおりです. majordom:*:54:1024:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:248:the cyrus mail server:/nonexistent:/nonexistent uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner:/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent pgsql:*:71:246:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh msql:*:80:249:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh

このリストを最新の状態に保つためにもこの範囲の UIDを利用する portを作った場合には, &a.ports; までご連絡ください. 困ったら....

私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;)

それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) Makefileのお手本

これはportのMakefileを作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください.

変数の順番, 段落の間の空行など, Makefileを作るときはなるべくこ の形式にしたがってください. 既存のportのMakefileがすべてこの形 式にしたがっているわけではありませんが, 今後はなるべく統一していき たいと考えています. この形式は重要な情報が簡単に見つけられるよ うに設計されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] [この Makefile の最初の版が作成された日付です] # Date created: 26 May 1995 [このソフトウェアを最初に FreeBSD に port した人の名前, つまり, この Makefile の最初の版を書いた人です. 今後この port をアップグレー ドするとき, このヘッダは変えるべきではありません.] # Whom: Satoshi Asami # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [MASTER_SITE_* マクロを使用しない場合は, 最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい ない場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include Packageの名前

Packageの名前は以下のルールにしたがってつけてください. こ れはpackageのディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのではという心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.)

Packageの名前は以下のようにしてください. [<言語>-]<名前>[[-]<オプション>]-<バージョン.番号>; ${DISTNAME} が上記の形式になっていない場合に は, ${PKGNAME} をそのようにしてください. FreeBSDはユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には `<言語>' に ISO-639 で定義されている言語名の略称を入れ てください. 例えば, 日本語なら `ja', ロシア語なら `ru', ベト ナム語なら `vi', 中国語なら `zh', 韓国語ならば `ko', ドイツ 語なら `de', といった具合です. `<名前>' の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (`kinput2' など). コンパイル時に環境変数やmakeの引数などでいくつ か別のオプションをつけてコンパイルできる場合, `<compiled.specifics>' にそのオプションを入れてくださ い (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する `pl' で, それ 以外にバージョン番号がまったくついていない場合にのみ使うことがで きます.

では, ${DISTNAME}を正しい ${PKGNAME}に直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2 mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.02 xmris-4.02 同上 rdist-1.3alpha rdist-1.3a `alpha'のような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 `pl' が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 jp-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage

オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として `1.0' を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 (`年. 月.日') を使うなどしてください. やっとおしまい!

いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _)

さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja/handbook/stable.sgml b/ja/handbook/stable.sgml index 5c72157f91..76c3e0cc9f 100644 --- a/ja/handbook/stable.sgml +++ b/ja/handbook/stable.sgml @@ -1,108 +1,108 @@ - + - + FreeBSD の安定状態の持続

原作: &a.jkh;.

訳: &a.iwasaki;. FreeBSD-stable ってなに?

FreeBSD-stable は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更 はこの支流には取り入れられません ( 参照). 誰が FreeBSD-stable を必要としているの?

もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安 定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stableの支流は前のリリースに関して効果的にバグフィッ クスされた流れであるため, 最新のリリース ( 執筆時点) をインストールしているのであれば, 特に そうです.

stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィック スに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでした ら, 私たちにすぐに教えてください (次の節参照). FreeBSD-stable を使う

&a.stable へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更 を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会をユーザに与えます. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable オプションとして本文に `help' と書けば, Majordomo は私たちがサポー トする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘ ルプを送付します. ftp.FreeBSD.ORG からのソースの入手. 以下の 3つの方法で おこなうことができます : 機能を使用する. 転送レートが 安定している TCP/IP 接続でない場合は, この方法が適して います. を を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2番目に推奨される方法で す. 多くの人が cron から cvsup を実行し, 自動的にソースコー ドを最新の状態に保っています. ftp を使用する. FreeBSD-stable 用のソースツリーは 常に次のところで「公開」されています :

私たちはまた, tar/compress でツリー全体を入手できる `wu-ftpd' を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体を compress された tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として 最初に `make world' を実行するべきでしょう. &a.stable を読めば, 次 のリリースに移行するに当たって時々必要となる既存システムからの新シ ステムの構築手順についての最新情報が得られるでしょう. diff --git a/ja_JP.EUC/handbook/booting.sgml b/ja_JP.EUC/handbook/booting.sgml index 3679b55c79..e975c5fad1 100644 --- a/ja_JP.EUC/handbook/booting.sgml +++ b/ja_JP.EUC/handbook/booting.sgml @@ -1,183 +1,183 @@ - + - + FreeBSDのブート処理の流れ

原作: &a.phk;. v1.1, April 26th.

訳: &a.nakai; September 6 1996. FreeBSDのブートには基本的に3つの段階があります: カーネルの読み込み, ルートのファイルシステムの決定, そして ユーザ領域にあるものの初期化です. このことは下に述べる いくつかの興味深い可能性につながっています。 カーネルの読み込み

現在, カーネルの読み込みには基本的に下に挙げる3つの方法が あります: これらはカーネルが次に何をしたらいいのかという情報をカーネルに 与えます. Biosboot Biosbootは「ブートブロック」に相当するもので, 2つのファイル から構成されており, フロッピーディスクやハードディスクのブートを 開始する側の 8K バイトにインストールされています。 Biosboot は FreeBSD のファイルシステムからカーネルを 読み込むことができます. Dosboot Dosbootは DI. Christian Gusenbauerによって書かれましたが, 不幸にしてこの場合には、コードのある一部分がマイクロソフトの コンパイラ向けに書かれているため、FreeBSD 単体ではコンパイル することはできません. Dosboot は MS-DOS のファイルから、またはディスクの FreeBSD ファイルシステムのパーティションからカーネルをブートします。 これは MS-DOS システムのハイメモリ領域に潜んでいるメモリマネージャ等の さまざまな怪しい代物とメモリの取り合いをして、なんとかブートしています. Netboot Netboot はサポートされているイーサネットカードを検出し、 BOOTP や TFTP、NFS を使ってブートするカーネルを探そうとします。 ルートファイルシステムの決定

カーネルが読み込まれ、ブートプログラムがカーネルに移行したら, カーネルは自身の初期化をし, どんなハードウェアが組み込まれいるか を決定し、それからルートファイルシステムを探さなくてはなりません。 現在サポートされているルートファイルシステムは次の通りです : UFS UFS は, もっとも一般的なタイプのルートシステムです。 フロッピーディスクやハードディスク上に存在します。 MSDOS 技術的に可能ですが、あまり有用ではありません。なぜならば、 ``FAT''ファイルシステムではリンクやデバイスノードなどの ``UNIX 主義''を実現できないからです。 MFS MFS はカーネル内部に組み込みになっている UFS ファイルシステムです。つまり MFS を機能させるのに ディスクやフロッピーディスクなどのハードウェアは 必要ではありません. CD9660 CD9660 は CD-ROM をルートファイルシステムに使用したものです。 NFS これはルートシステムにファイルサーバを使用していて、基本的に ディスクレスのマシンのためにあります。 ユーザ領域にあるものの初期化

ユーザ領域で動作させるようにするために、カーネルが初期化を終えると、 カーネルは``/sbin/init'' です。 /sbin/init を別なプログラム置き換えてしまうことは可能ですが、そのプロセス には以下のような制約があります: pid が 1 のプロセスには stdin/stdout/stderr は割り当てられていませんので、 プログラムは自分でこれらをオープンしないとなりません。 このプロセスが終了するとカーネルはパニックメッセージを表示して 停止します。 また、このプロセスに対するシグナル処理は特殊です。 この例として、インストール用のフロッピーディスクにある ``/stand/sysinstall''があります。 興味深い連係

カーネルを MFS でブートするのには次のような特別の/sbin/init を使います。 /C: にマウントします。 C:/freebsd.fs を /dev/vn0 にアタッチします。 /dev/vn0 を /rootfs にマウントします。 シンボリックリンクを作ります。 /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin (etc...) これでハードディスクのパーティションを切り直さずに FreeBSD を 使うことができます。 サーバ:˜you/FreeBSD を /nfsにマウントし、ルートディレクトリを /nfs に変更して, そこで/sbin/initを実行します。 これで FreeBSD をディスクレスで実行できますが、NFS サーバを コントロールできないままです... /dev/rwd0 のコピーを取って、リモートにあるテープ ステーションやファイルサーバに書き込んでください。 これで一年前に取っておくべきだったバックアップをやっと 取ることができました。 E -- ファイアウォール/Web サーバとして動作させる場合 (私の知っている範囲で...) これは特に面白いもので、書き込み禁止のフロッピーディスクから ブートができて、ルートのファイルシステムに書き込むことができる というものです。 diff --git a/ja_JP.EUC/handbook/cvsup.sgml b/ja_JP.EUC/handbook/cvsup.sgml index 4af9e1f6ef..76f27d738b 100644 --- a/ja_JP.EUC/handbook/cvsup.sgml +++ b/ja_JP.EUC/handbook/cvsup.sgml @@ -1,597 +1,597 @@ - + - + CVSup

原作: &a.jdp;.

訳: &a.iwasaki;.27 February 1997. CVSup の紹介

CVSup は, リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するためのソフトウェアパッケージです. FreeBSD のソースは, カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています. CVSup を使用することで, FreeBSD ユーザは 簡単に自分のソースツリーを最新の状態にしておくことができます.

CVSup は pull モデルとよばれる更新のモデルを採用しています. pull モデルでは, 各クライアントが更新したい場合に更新したい時点で, サーバに更新の問い合わせをおこないます. サーバはクライアントからの 更新の要求を受け身の状態で待ちます. したがって, すべての更新は クライアント主導でおこなわれます. サーバは頼まれもしない更新情報を 送るようなことはしません. ユーザは CVSup クライアントを手動で実行して 更新をおこなうか, cron ジョブを設定して定期的に自動実行する必要があります.

用語 "CVSup" のように大文字で表記しているものは, ソフトウェアパッケージ 全体を指します. 主な構成物は, 各ユーザマシンで実行するクライアントである "cvsup", FreeBSD の各ミラーサイトで実行するサーバ "cvsupd" です.

FreeBSD の文書やメーリングリストを読んだ際に, sup についての言及を 見かけたかもしれません. sup は CVSup の前に存在していたもので, 同様の 目的で使われていました. CVSup は sup と同じように使用されており, 実際, sup と互換性のあるコンフィグレーションファイルを使用します. CVSup の方がより高速で柔軟性もあるので, もはや sup は FreeBSD プロジェクトでは使用されていません. CVSup のインストール

FreeBSD 2.2 以降を使用している場合, CVSup をインストールするもっとも 簡単な方法は, FreeBSD の または対応する を使うことです. どちらを使うかは, CVSupを自分で作りたいかどうかによります.

FreeBSD-2.1.6 または 2.1.7 を使用している場合は, 残念ながら FreeBSD-2.1.{6,7} には存在しないバージョンの C ライブラリが必要となるため バイナリ package は使用できません. しかし, は FreeBSD 2.2 とまったく同じように簡単に使うことができます. 単に tar ファイルを展開し, cvsup ディレクトリへ cd して "make install" とタイプするだけです.

CVSup は で書かれているため, package と port 両方とも Modula-3 ランタイムライブラリがインストールされていることが必要です. これらは port の および package の にあります. これらのライブラリの port や package に対して cvsup と同じ管理方法を取っていれば, CVSup の port や package をインストールする際に, これらのライブラリも自動的に コンパイルそして/またはインストールされます.

Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに 終わるものではありません. この理由から, 三つめの選択肢が提供されています. 以下のアメリカ合衆国にある配布サイトのどちらからでも, FreeBSD 用の スタティックリンクされた CVSup 実行形式が入手可能です: (クライアント). (サーバ). また, ドイツのミラーサイトは以下の通りです: (クライアント). (サーバ). 訳注: 日本国内のミラーサイトは以下の通りです: (クライアント). (サーバ).

ほとんどのユーザはクライアントのみが必要になるでしょう. これらの 実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current までの, どのバージョンでも動作します.

まとめると, CVSup をインストールするための選択肢は以下の通りです: FreeBSD-2.2以降: スタティックバイナリ, port, package FreeBSD-2.1.6, 2.1.7: スタティックバイナリ, port FreeBSD-2.1.5 以前: スタティックバイナリ CVSup のコンフィグレーション

CVSup の動作は, "supfile" と呼ばれるコンフィグレーションファイルで 制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ の下にあります. 2.2 以前のシステムを使用している場合は, これらの サンプルを から入手することができます.

supfile には以下の cvsup に関する質問への答えを記述します:

次のセクションで, これらの質問に順番に答えながら典型的な supfile を組み立てていきます. 最初に supfile の全体構造を説明します.

supfile はテキストファイルです. コメントは "#" から行末までです. 空行とコメントだけの行は無視します.

残りの各行には, ユーザが受け取りたいファイル群について記述します. 行の始めは, サーバ側で定義した論理的なファイルのグループである 「コレクション」の名称です. コレクションの名称を指定して, 欲しいファイル群を サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた 0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する 答えになります. フィールドには 2種類あります: flag フィールドと value フィールドです. flag フィールドは "delete" や "compress" のような 単独のキーワードから成ります. また, value フィールドもキーワードで 始まりますが, キーワードの後にはホワイトスペースは入らず, "=" と 二つめの単語が続きます. 例えば, "release=cvs" は value フィールドです.

通常, supfile には受け取りたいコレクションを一つ以上指定します. supfile を組み立てる一つの方法として, コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります. しかし, これでは supfile のすべてのコレクションに対してほとんどのフィールドが同じになるため, 行が非常に長くなってしまい不便になります. これらの問題を避けるため, CVSup ではデフォルトを指定することのできるメカニズムが提供されています. 特殊な擬似コレクション名 "*default" で始まる行は, supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドの デフォルトを設定するために利用できます. 個々のコレクションで固有の値を 指定すると, デフォルト値を無効にできます. また "*default" 行を追加すると, supfile の途中からデフォルト値の変更や追加が可能になります.

これまでの予備知識を基に, のメインのソースツリーを受け取って更新するための supfile を 組み立ててみましょう. どのファイルを受け取りたいのか?

CVSup を通して入手できるファイルは 「コレクション」と呼ばれる名前の付けられたグループにまとめられています. 利用可能なコレクションについては で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体 を受け取るための設定例を紹介します. 輸出規制されている暗号化サポートのコード以外のすべてを含む "src-all" という 単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か カナダにいるものと仮定します. その場合, "cvs-crypto" という一つの付化的な コレクションで暗号化コードを入手することができます. supfile を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ 記述します: src-all cvs-crypto

どのバージョンのものが欲しいのか?

CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. "tag=" および "date=" の value フィールドを使用して, 欲しいバージョンの 一つを指定します.

注意: "tag=" のフィールドの指定は正確に行うように十分注意 してください. いくつかのタグは特定のコレクションに対してのみ有効です. タグの綴りが違っていたり不適切なタグを指定すると, CVSupはユーザが消し たくないファイルまで削除してしまいます. 特に "ports-*" のコレクション に対しては "tag=." だけ を指定するようにしてください.

"tag=" フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません.

以下はユーザが興味を持っていると思われる branch tag です:

以下はユーザが興味を持っていると思われる revision tag です:

注意: tag 名を示した通りにタイプされているか十分注意してく ださい. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが削 除されるでしょう.

branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, "date=" の value フィールドを使って日付を指定することで, これを実現することが できます. cvsup(1) のマニュアルページで, その方法を説明しています.

例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=.

"tag=" フィールドも "date=" フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのもののコピーを維持することで, リビジョン履歴を閲覧し過去のバージョンのファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります.

どこから入手したいのか?

更新情報をどこから入手するかを cvsup に伝えるために "host=" フィールドを使用します。 のどこからでも入手できますが、最寄りのサイトを選ぶべきでしょう。 この例では、第一の FreeBSD 配布サイト "cvsup.FreeBSD.org" を使用します: *default host=cvsup.FreeBSD.org

どのように cvsup を実行しても, この設定は "-h hostname" を 使用してコマンドラインで変更することができます.

自分のマシンのどこに置きたいのか?

"prefix=" フィールドは, cvsup に受け取ったファイルをどこに置くかを 伝えます. この例では, ソースファイルを直接メインのソースツリー "/usr/src" に置きます. "src" ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので, これは正しい仕様となります: *default prefix=/usr

どこに status ファイルを置きたいのか?

cvsup クライアントは "base" ディレクトリと呼ばれる場所に, ある status ファイルを維持しています. すでに受け取った更新情報を追従し続け ることで, これらのファイルは CVSup がより効果的に動作することを支援し ます. 標準の base ディレクトリ "/usr/local/etc/cvsup" を使用します: *default base=/usr/local/etc/cvsup

supfile に指定がない場合は, この設定をデフォルトで使用しますので, 実際には上の行は必要ありません.

base ディレクトリが存在しない場合は作成しておきましょう. base ディレクトリが存在しない場合, cvsup クライアントは実行を拒否します.

その他もろもろの supfileの設定:

通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress

"release=cvs" は, サーバがメインの FreeBSD CVS リポジトリから その情報を取得するように指示します. ほとんどの場合はこのようにしておきますが, ここでの説明の範疇をこえるような状況では他の指定をすることも可能です.

"delete" は CVSup にファイルを削除することを許可します. CVSup が ソースツリーを完全に最新の状態に保てるようにするためには, これは常に 指定しておくべきでしょう. CVSup は, これらの責任範囲のファイルだけを 慎重に削除します. たまたま存在する他の余分なファイルについては, まったく手をつけずに残しておきます.

"use-rel-suffix" は ... 神秘的なものです. これについて本当に 知りたい人は, cvsup(1) のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください.

"compress" は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を 使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます.

supfile の例のまとめ:

以下は supfile の例の全体です: *default tag=. *default host=cvsup.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all cvs-crypto CVSup の実行

さて, 更新の準備ができました. これを実行するコマンドラインは 実に簡単です: cvsup supfile

もちろん, ここでの "supfile" は作成したばかりの supfile のファイル名です. X11 環境で実行するものと仮定して, cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します. "go" ボタンを押して, 実行を監視してください.

この例では実際の "/usr/src" ツリーを更新しているので, cvsup にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root で実行する必要があります. コンフィグレーションファイルを作ったばかりで, しかも以前にこのプログラムを実行したことがないので, 神経質になるのは 無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な 方法があります. どこか適当な場所に空のディレクトリを作成して, コマンドラインの引数で指定するだけです: mkdir /var/tmp/dest cvsup supfile /var/tmp/dest

指定したディレクトリは, すべての更新されるファイルの 更新先ディレクトリとして使用します. CVSup は "/usr/src" の下の ファイルを検査しますが, 変更や削除はまったくおこないません. かわりに "/var/tmp/dest/usr/src" に更新されたすべてのファイルが 置かれるようになります. この方法で実行した場合は, CVSup は base ディレクトリの status ファイルを更新せずにそのままにします. これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます. "/usr/src" の読み取り許可がある限り, このような 試し実行のためにユーザ root になる必要はありません.

X11 を利用していないとか単に GUI が気に入らない場合は, cvsup 起動時にコマンドラインに二つほどオプションを追加する必要があります: cvsup -g -L 2 supfile

"-g" オプションは cvsup に GUI を使用しないように伝えます. X11 を利用していない場合には自動的に指定されますが, そうでない場合は 明示的に指定します.

"-L 2" オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます. 冗長性には "-L 0" から "-L 2" までの三つのレベル があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力 しません.

たくさんの他のオプション変数があります. それらの簡単な一覧は "cvsup -H" で表示されます. より詳しい説明はマニュアルページをご覧ください.

動作している更新の方法に満足したら, cron(8) を使って cvsup を定期的に 実行させる準備をすることができます. cron から起動する際には, 明示的に cvsup が GUI を使わないようにする必要があります. CVSup ファイルコレクション

CVSup 経由で入手できるファイルコレクションは階層的に組織化されています. いくつか大きなコレクションがあり, それらは小さなサブコレクションに 分割されています. 大きなコレクションは, そのサブコレクション毎に 受信することと同じことになります. 下の一覧ではコレクション間の階層関係を 字下げして表現します.

最も一般的に使用するコレクションは cvs-all release=cvs メインの FreeBSD CVS リポジトリであり, 輸出規制された暗号化コードは含まれていません.

distrib release=cvs FreeBSD の配布とミラーに関連するファイルです. doc-all release=cvs FreeBSD ハンドブックおよびその他のドキュメントのソースです. ports-all release=cvs FreeBSD の ports コレクションです.

ports-archivers release=cvs アーカイビングのツール. ports-astro release=cvs 天文学関連の ports. ports-audio release=cvs サウンドサポート. ports-base release=cvs /usr/ports のトップにあるその他のファイル. ports-benchmarks release=cvs ベンチマークプログラム. ports-cad release=cvs CAD ツール. ports-chinese release=cvs 中国語サポート. ports-comms release=cvs 通信ソフトウェア. ports-converters release=cvs 文字コードコンバータ. ports-databases release=cvs データベース. ports-devel release=cvs 開発ユーティリティ. ports-editors release=cvs エディタ. ports-emulators release=cvs 他の OS のエミュレータ. ports-games release=cvs ゲーム. ports-german release=cvs ドイツ語サポート. ports-graphics release=cvs グラフィックユーティリティ. ports-japanese release=cvs 日本語サポート. ports-korean release=cvs 韓国語サポート. ports-lang release=cvs プログラミング言語. ports-mail release=cvs メールソフトウェア. ports-math release=cvs 数値計算ソフトウェア. ports-mbone release=cvs MBone アプリケーション. ports-misc release=cvs 色々なユーティリティ. ports-net release=cvs ネットワーキングソフトウェア. ports-news release=cvs USENET ニュースのソフトウェア. ports-plan9 release=cvs Plan9 からの色々なプログラム. ports-print release=cvs 印刷ソフトウェア. ports-russian release=cvs ロシア語サポート. ports-security release=cvs セキュリティユーティリティ. ports-shells release=cvs コマンドラインシェル. ports-sysutils release=cvs システムユーティリティ. ports-textproc release=cvs 文書処理ユーティリティ(デスクトップパブリッシングは含まない). ports-vietnamese release=cvs ベトナム語サポート. ports-www release=cvs World Wide Web 関連のソフトウェア. ports-x11 release=cvs X11 のソフトウェア. src-all release=cvs メインの FreeBSD ソース群であり, 輸出規制された暗号化コードは含まれていません.

src-base release=cvs /usr/src のトップにあるその他のファイル. src-bin release=cvs シングルユーザモードで必要なユーザユーティリティ (/usr/src/bin). src-contrib release=cvs FreeBSD プロジェクト外部からのユーティリティおよびライブラリ, 比較的無修正 (/usr/src/contrib). src-etc release=cvs システムコンフィグレーションファイル (/usr/src/etc). src-games release=cvs ゲーム(/usr/src/games). src-gnu release=cvs GNU Public License 下にあるユーティリティ (/usr/src/gnu). src-include release=cvs ヘッダファイル (/usr/src/include). src-kerberosIV release=cvs KerberosIV セキュリティパッケージ (/usr/src/kerberosIV). src-lib release=cvs ライブラリ (/usr/src/lib). src-libexec release=cvs システムプログラムであり, 通常は他のプログラムから実行される (/usr/src/libexec). src-release release=cvs FreeBSD の release を構築するために必要なファイル (/usr/src/release). src-sbin release=cvs シングルユーザモード用のシステムユーティリティ(/usr/src/sbin). src-share release=cvs 多様なシステム間で共有可能なファイル (/usr/src/share). src-sys release=cvs カーネル (/usr/src/sys). src-tools release=cvs FreeBSD の保守用の色々なツール (/usr/src/tools). src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin). src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin). www release=cvs World Wide Web のデータ用のソースです. cvs-crypto release=cvs 輸出規制された暗号化コードです.

src-crypto release=cvs 輸出規制された FreeBSD プロジェクト外部からのユーティリティおよび ライブラリ, 比較的無修正 (/usr/src/crypto). src-eBones release=cvs Kerberos および DES (/usr/src/eBones). src-secure release=cvs DES (/usr/src/secure). distrib release=self CVSup サーバ自身のコンフィグレーションファイルです. CVSup ミラーサイトが使用します. gnats release=current GNATS バグトラッキングデータベースです. mail-archive release=current FreeBSD 関連メーリングリストのアーカイブ. www release=current インストールされた World Wide Web のデータです. WWW ミラーサイトが使用します. CVSup のアナウンス, 質問およびバグ報告

CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます.

質問とバグ報告はプログラムの作者, へ 送ってください. diff --git a/ja_JP.EUC/handbook/kernelconfig.sgml b/ja_JP.EUC/handbook/kernelconfig.sgml index c59bb80293..5daabe73b5 100644 --- a/ja_JP.EUC/handbook/kernelconfig.sgml +++ b/ja_JP.EUC/handbook/kernelconfig.sgml @@ -1,1252 +1,1252 @@ - + - + FreeBSDカーネルのコンフィグレーション

原作: &a.jehamby;. 6 October 1995.

訳: &a.tomo;, &a.yoshiaki;. 2 November 1996. この章はシステムに合わせたカーネルの再構築の基礎について 述べたものです. この章は, システム管理の初心者から Unixシステム管理に十分な経験を積んだ人までを対象としています. なぜカスタムカーネルを作るか?

システムに合わせたカーネルの構築はすべての Unixシステム管理者が 避けて通ることのできない最も重要な通過儀礼の1つです. この作業は, 多くの時間を必要としますが, あなたの FreeBSD システムに多くの利益をもたらします. GENERICカーネルは, めったに使われることのないハードウェアをサポートするとともに, 考えられるすべての SCSIカードやネットワークカードをサポート しなければなりませんが, システムに合わせたカーネルは あなたの PC のハードウェアのみをサポートします. これは, 次にあげるような利益をもたらします. あなたが持っていないハードウェアについては検出をおこなわな いので, ブートにかかる時間が短くなります. システムに合わせたカーネルは多くの場合メモリ使用量が 減ります. カーネルはいつもメモリ上に存在するので, 不必要なコードがあると本来プログラムが利用できるはずの RAM (実メモリ) を占めてしまいますのでこれは重要なことだ といえます. したがって, メモリが少ないシステムでは, カーネルの再構築は大変重要です. 必要に応じていくつかのカーネルオプションは調整すること ができ, またサウンドカードのような GENERICカーネルには ないデバイスドライバをカーネルに含めることが できます.

カスタムカーネルの構築とインストール

まず, カーネル再構築に必要なディレクトリをざっと見てみましょう. ここではディレクトリはすべて /usr/src/sys以下の相対位 置で示します. また, /sysからもアクセス可能です. ここには, カーネルの各部分を構成するサブディレクトリが いくつもあります. しかし, 私たちの目的では 最も重要なのは i386/confです. ここで, あなたの システムに合わせてカーネル コンフィグレーションを編集します. それから compileディレクトリ, ここはカーネルが作られる 場所です. サポートされているデバイスやファイルシステムのディレ クトリツリーがオプション毎にサブディレクトリに分かれている論理 的構成に注意してください. また, i386のディレクトリは PCのハードウェアのみを扱い, i386以外のディレクトリは FreeBSDが他のプラットフォームに移植される際には共有されるコー ドです. /usr/src/sys 以下のディレクトリがなければ, カーネルのソースが インストールされていません. パッケージのインストール手順にしたがっ て, システムにインストールしてください. つぎに, i386/confに移動して, GENERIC コンフィグレーションファイルをカーネルに与えたい名前に コピーしてください. たとえば： # cd /usr/src/sys/i386/conf # cp GENERIC MYKERNEL 慣習として, この名前はすべて大文字でつづられます. もし, いくつかの異なるハードウェアの FreeBSDマシンを扱うなら, この名前にホスト名を含めるとよいでしょう. ここでは, 例として MYKERNEL と呼ぶことにします. では, MYKERNELをあなたの好きなエディタで編集してください. もし, システムをインストールしたばかりならば, 利用できる エディタは viだけかもしれません. ここでは使い方 の説明はしませんが, にあるような多くの本で詳しく説明 されていますので, そちらを参照してください. まずファイルの最初の方のコメント行を編集し, あなたのコンフィグ レーションに合せて変更した点などを記述して GENERICと区別がつく ようにしておきましょう. もし SunOSや他の BSDオペレーティングシステムでカーネルの 再構築をしたことがあれば, このファイルはとても親しみ やすいでしょう. しかし, DOSのようなその他の オペレーティングシステムしか知らない人から見れば, GENERICコンフィグレーションファイルはとても なじみにくいものかもしれません. そのような場合は, の節をゆっくりと注意深く読んでください. config(8)を取ってくる必要があるかもしれません. これは /usr/src/usr. sbinにあります. したがってこれらのソースをダ ウンロードする必要があります. 次のコマンドを実行する前に (configを)作りインストールをしておいてください. 編集し終ったら, 次のコマンドによってコンパイル, インストール を行ってください. # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # make depend # make # make install 新しいカーネルはルートディレクトリに /kernelという 名前でコピーされ, 今までのカーネルは /kernel.old という名前へ変更されます. では, システムをシャットダウン, リブー トして新しいカーネルを使ってください. うまく行かない場合は, この章の終りの を参照してください. この章の新しい 場合のリカバリの方法を注意深く読んでおいてください. /devディレクトリで デバイスノードを追加しなければならないかもしれません. 詳しくは, を読んでください. コンフィグレーション ファイル

コンフィグレーション ファイルの一般的なフォーマット はとてもシンプルです. 各行は1つのキーワードと1つ以上の 引数を含んでいます. 見やすくするために, ほとんどのキーワードは 引数を1つしか書いてありません. #に続くものはすべてコメントとして扱われ, 無視されます. ここでは, それぞれのキーワードについて だいたい GENERICに出てくる順番で説明します. しかし, お互いに関係のあるキーワードは, 実際には GENERICファイル上に バラバラに現れていても, (ネットワーキングのように)1つにまとめ てあります.

カーネルは現在, オプションを扱う方法をよりよい機構に移行しよ うとしています. 従来は, 各々のオプションは単純にカーネルの Makefile中の CFLAGS行の -Dスイッチに変換されて いました. 自然とオプションは際限なく増えて行きます. だれも実際に はどのオプションがどのファイルで参照されているかは知りません.

新しい方法では、すべてのオプション依存の #ifdefは当該オプショ ンを opt_foo.h (これらのファイルはconfigによって compileディレ クトリに作られます) から読み込むように変わりました. config の有効なオプションのリストは2つのファイルにお かれます. アーキテクチャに依存しないオプションは /sys/conf/optionsに置かれ, アーキテクチャ依存のオプショ ンは/sys/arch/conf/optionsに置かれま す. archの部分は例えば i386となります. 必須キーワード

ここにあるキーワードはカーネルの構築に必要不可欠です. machine ``i386''

最初のキーワードは machineです. FreeBSDは Intelの 386とその互換チップ上でしか 動かないので, i386を指定します. 注: 数字を含むキーワードはすべて クォーテーションマークで囲む必要があります. そうしないと, configは混乱し, 386を実際の数値として扱ってしまいます. cpu ``cpu_type''

次のキーワードは cpuです. FreeBSDでサポートしている CPUの中から記述します. cpu_typeとして指定可能な値は 次の通りです. I386_CPU I486_CPU I586_CPU I686_CPU GENERICカーネルのように cpuの行の cpu_typeが異なった値を持つものが 複数あってもかまいません. カスタムカーネルでは, あなたが持っている cpuを1つだけ指定するのが 一番です. 例えば, もし Intelの Pentiumを持っていれば, cpu_typeには, I586_CPU を使ってください. ident machine_name

次は, カーネルの識別名となるidentです. GENERICからあなたがカーネルに与えたい名前に 変えてください. ここでは, MYKERNELとします. identに与えた名前はカーネルの ブート時に表示されるので, 普段のカーネルとは別に カーネルに違う名前を与えたいとき(例えば, 実験用のカーネルを作りたい時など), 便利でしょう. 数字を含む名前にしたい場合は machineや cpuの時と同じようにクォーテーションマークで 囲む必要があります. Cコンパイラに -Dスイッチで渡されるので, DEBUGのような名前にしたり, vax といった他のCPUの名前など紛らわしい名前にしないで ください. maxusers number

これは, 重要なシステムテーブルのサイズを決めます. ここ で与えられる数字はマシンに同時にログインすると考えられ るおよそのユーザ数です. しかし, 通常の使用環境であれば, 特に X Window System を立ち上げたり, ソフトウェアを コンパイルするような使用であれば maxusersには少 なくとも4以上を指定したほうがいいでしょう. その理由は, maxusersで決るテーブルで最も重要なものはプロセス の最大数であるからです. プロセス最大数は 20 + 16 * maxusersで与えられ, maxusersを1 にすると36プロセスしか同時には持てません. この中にはブー ト時にシステムによって起動する18個ぐらいのプロセス, Xを 起動する時の15程度のプロセスも含みます. manページを読むという1つのタスクでさえ, フィ ルタやファイル伸長や表示のために9つのプロセスを起動し ます. maxusersを4にすれば, 同時に84個のプロセ スを持つことができるのでどんな人でも十分な数だといえる でしょう. それでも他のプログラムを起動した場合に, あるいは, (Walnut Creek CDROMのFTPサイトのように) 同時に多くの ユーザを抱えるサーバを走らせた場合に ``proc table full''というおぞましいエラーが起きる場合はこの値を増や し, カーネルを再構築してください. maxuserはあなたのマシン にログインできるユーザの数を制限するものでは ありません. 単に, あなたのシステムに ログインするユーザ数の最大値と各々のユーザが いくつのプロセスを走らせるかを考慮することに よってさまざまなテーブルの値を適切な値に設定 するだけです. これに対し, の remote loginsというキーワードは 同時にリモートログインできるユーザ数を制限 します. config kernel_name root on root_device

これはカーネルの位置と名前を特定します. 伝統的にカーネルは vmunixと呼ばれますが, FreeBSDでは kernelとふさわしい名前になりました. kernel_nameにはいつも kernelを 使ってください. 名前を変えると多くのシステム ユーティリティが使えなくなります. 2番目の部分は ルートファイルシステムとカーネルのあるディスクと パーティションを指定してください. SCSIドライブでなければ, wd0を, SCSIドライブならば sd0です. 一般的なオプション

以下はカーネルのサポートするさまざまなファイルシステムおよ びその他のオプションです.

これは, 数値演算コプロセッサがない コンピュータ (386や486SX) で数値演算コプロセッサ のエミュレーションを可能にします. もし, Pentiumや 486DX, あるいは387や487があれば, コメントアウト できます. 注: FreeBSD付属の数値演算 コプロセッサエミュレータはあまり正確では ありません. 非常に正確な計算をおこないたい ならば, より優れた GNUのエミュレータである GPL_MATH_EMULATEに変えることを おすすめします. これはライセンスの関係でデフォルトでは 含まれていません. options ``COMPAT_43''

4.3BSDとの互換性のためのオプションです. そのままにしておいてください. コメントアウトすると, いくつかのプログラムで動作がおかしくなります. options BOUNCE_BUFFERS

ISAデバイスやISA互換モードで動作する EISAデバイス では DMA (Direct Memory Access) は16MB以下のメモリに対し てのみ動作します. このオプションによりメモリが16MB以上 のシステムでDMAを使うデバイスを動作させることができます. options UCONSOLE

ユーザがコンソールを横取り (grab) できるようにします. これは X Window System 上で便利です. 例えば, コ ンソール xtermを xterm -Cとタイプして作ると, そこに `write', `talk'などのメッセージがカーネルからコ ンソールへ送られるメッセージと同じように表示されます. options SYSVSHM

このオプションは System V の共有メモリを提供します. X Window System の XSHM拡張での利用がもっとも一般に見 られる例で, 多くのグラフィックを多用したプログラム (movie player の Xanimや Linux DOOMなど) ではこれを 利用することで速度が増加するというメリットがあります. X Window System を利用するのであればこれは間違いな く含めたくなるでしょう. options SYSVSEM

System V のセマフォをサポートします. 一般的に利用される ことは少ないですがカーネルサイズの増加は数百バイトだ けです. options SYSVMSG

System V のメッセージをサポートします. これを指定した場 合もカーネルサイズの増加は数百バイトだけです. ipcs(1) コマンドは これらの System V の機構を利用しているプロセスを表示し ます. 訳注: 共有メモリ, セマフォ, メッセージ(メッ セージキュー) は System V系 で一般的なプロセス間通信の機 構です. くわしくは System Vのプロセス間通信に関する文 献, 「詳解 UNIXプログラミング」 (ソフトバンク) , 「UNIXネッ トワークプログラミング」 (トッパン) などを参照してくださ い. ファイルシステムオプション

これらのオプションはさまざまなファイルシステムへのサポート を追加します. 少なくともブートするためのデバイスのサポートを含 める必要があります. 標準的にはハードディスクからブートするので あれば FFS , ディスクレスワークステーションとしてイー サネットからブートするのであれば NFSです. 一般的に利用される他のファイルシステムをカーネルに含め, あまり 利用しないファイルシステム (多分 MS-DOSファイルシステム?) のサポー トをコメントアウトすることができます. これは Loadable Kernel Module ディレクトリ /lkm から, 最初にそのタイプのファイ ルシステムがマウントされる時に動的にドライバがロードされるからです. options FFS

基本的なハードドライブ ファイルシステムです. ハードディ スクからブートする場合は残しておいてください. options NFS

ネットワーク ファイルシステムです. Ethernet経由で Unixファ イルサーバからパーティションをマウントする予定がない場 合はコメントアウトすることができます. options MSDOSFS

MS-DOS ファイルシステムです. ブート時に DOSフォーマット のハード ドライブをマウントする予定のない場合はコメン トアウトしても安全です. 先に示したように, DOSパーティ ションをマウントする時に自動的にロードされます. また (ports コレクションにある) mtools という素晴 らしいソフトウェアにより mount , unmountなしで DOSフロッ ピーにアクセスすることができます (これは MSDOSFSも必要 ありません). options ``CD9660''

CD-ROMのための ISO 9660 ファイルシステムです. CD-ROMを 持っていないか, 時々 データ CDをマウントするだけならコ メントアウトしましょう (データ CDを最初にマウントする 時に動的にロードされます). オーディオ CDはこのファイル システムは必要ありません. options PROCFS

プロセス ファイルシステムです. これは疑似的なファイルシ ステムで /procにマウントされ, ps(1)などのプロ グラムがプロセスに関してより詳しい情報を与えてくれるよ うになります. options MFS

メモリマップド ファイルシステムです. これは基本的に一時 ファイルを記憶するための高速な RAMディスクで, 大きな swap領域がある場合に有効です. MFSパーティションをマウ ントするに適した場所は多くのプログラムが一時ファイルを 置く /tmpです. MFS RAMディスクを /tmp にマウントするには以下の内容を /etc/fstabに追 加してリブートするか mount /tmpとタイプします. /dev/wd1s2b /tmp mfs rw 0 0 /dev/wd1s2bをあなたが使用して いるswap パーティションに置き換えてください. これは以 下のように /etc/fstabに書かれているでしょう. /dev/wd1s2b none swap sw 0 0 /tmpデ バイスにアクセスすることはできません). そのためいまの ところは使わない方が無難です. --> また, MFSファ イルシステムは動的にロードすることはできません . したがって使いたい場合はコンパイル時に カーネルに含める必要があります. options QUOTA

ディスククォータを有効にします. アクセスが公開されてい るシステムで (一人のユーザが) /homeパーティショ ン (全体) をあふれさせることができないようにそれぞれのユーザ にディスククォータを発行することができます. ディスククォータについての詳しい内容はの章を見てください. 基本的なコントローラとデバイス

この節では FreeBSDでサポートされているディスク, テー プ, CD-ROMコントローラについて示します. コントローラと カードについ ては別の節になっています. controller isa0

FreeBSDのサポートするすべての PCで必要です. IBM PS/2 (マイ クロチャネルアーキテクチャ) では現時点では FreeBSDは動 きません. controller pci0

PCIバスを持つマザーボードの場合は含めます. これにより PCIカードの自動認識と PCIから ISAバスへのゲートウェイが 可能になります. controller fdc0

フロッピードライブコントローラです. fd0 は ``A:'' ドライブで fd1 は ``B:'' ドライブです. ft0 は フロッピーコントローラに接続する QIC-80 テープドライブで す. 対応するデバイスがない場合はそれぞれの行をコメント アウトしてください. ft(8)というフィルタプログラムが必要です. くわしくはマニュアルページを見てください. controller wdc0

プライマリIDEコントローラです. wd0 と wd1はそれぞれマスタ, スレーブドライブで す. wdc1 は セカンダリの IDEコントローラで3台 目, 4台目のハードディスクまたは IDE CD-ROMのある場合に 使います. 利用しない行はコメントアウトしてください (例え ば, SCSIハードディスクのみを使う場合は6行全部をコメント アウトしてもよいかもしれません). device wcd0

このデバイスは IDE CD-ROMのサポートをします. wdc0を有効にしておく必要があり, もし 2つ以上の IDE コントローラがあり, そのうちの 2つ目のカードに CD-ROMを接 続する場合 options ATAPIを書いておく必要もあります. device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr

npx0はFreeBSDハードウェアコプロセッサとソフト ウェアエミュレータ両方の浮動小数点演算ユニットへのインタ フェースです. これは device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr

Wangtek と Archive の QIC-02/QIC-36 テープドライブのサポートです. Proprietary CD-ROM support

以下のようなドライブを proprietary(独自の) CD-ROMドライブと呼ぶことにします. これらのドライブは専 用のコントローラを持つか, サウンドブラスタ16などのサウ ンドカードに接続します. これらは IDEでも SCSIでもあ りません. 多くの標準速や2倍速の古い CD-ROMはこれら のインタフェースを持っていますが, より新しい四倍速の ものは か でしょう. device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr

ミツミ製 CD-ROM (LU002, LU005, FX001D)です. device scd0 at isa? port 0x230 bio

ソニー製 CD-ROM (CDU31,CDU33A)です. controller matcd0 at isa? port ? bio

松下/パナソニック製 CD-ROM (サウンドブラスタ用 クリエィティブ ラボ製として販売されていました) です. SCSI デバイスのサポート

この節では FreeBSDのサポートするいろいろな SCSIコント ローラとデバイスのサポートについて書きます. SCSI コントローラ

以下の十数行は異る種類の SCSIコントローラのサポートです. 使用しているもの以外の部分はコメントアウトしてください. controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr

ほとんどの Buslogic社のコントローラです. controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr

UltraStor 14F と 34F です. controller ahc0

Adaptec 274x/284x/294x です. controller ahb0 at isa? bio irq ? vector ahbintr

Adaptec 174x です. controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr

Adaptec 154x です. controller aic0 at isa? port 0x340 bio irq 11 vector aicintr

Adaptec 152x や サウンドカードなどに使われている Adaptec AIC-6360 チップです. (slow!) controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr

NCR 5380を使っている ProAudioSpectrum や Trantor T130 で す. controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr

Seagate ST01/02 8 ビットコントローラです. (slow!) controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr

Western Digital WD7000コントローラです. controller ncr0

NCR 53C810, 53C815, 53C825, 53C860, 53C875 チップを使った PCI SCSI コントローラです. options ``SCSI_DELAY=15''

このオプションによりカーネルはそれぞれの SCSIデバイスを プローブする前に 15秒間待ちます. IDEドライブのみを使用 している場合は無視して構いません. ブートを速くするため にこの数値を 5秒ぐらいまで小さくしたいでしょう. そうし た場合, FreeBSDが SCSIデバイスを認識しにくくなるかもし れません. その時は、もちろんこのオプションの値は元に戻 さないといけません. controller scbus0

SCSIコントローラがある場合, この行で SCSI全般のサポー トを与えます. SCSIのない場合, この行と以下の3つの行をコメ ントにすることができます. device sd0

SCSIハードディスクのサポートです. device st0

SCSIテープドライブのサポートです. device cd0

SCSI CD-ROM のサポートです.

上のエントリについている 0はいくらか誤解を招き やすいかもしれません. これらのデバイスはすべてカーネルが 見つけた時に割り当てがおこなわれ, SCSIバスに何台つながってい るか, ターゲット IDが何番であるかはここの記述とは関係あ りません. 明示的に「固定的な」ターゲット IDの特定のデバイスへの 割り当てをおこないたい場合は LINT カーネルコンフィグレーションファイルの 該当する部分の説明を参照してください. コンソール, バスマウス, Xサーバのサポート

2つのタイプのコンソールからどちらか1つを選ぶ必要があります. 標準ではない方の vt220 コンソールを選んだ場合, X Window System を利用するには XSERVER オプションを有効にする必要があります (訳注: sc0 には XSERVER オプション相当の機能が始めから入っています). またバスマウスとPS/2マウスのオプションもあります. device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr

sc0 はデフォルトのコンソールドライバで SCOコン ソールに似ています. このデバイス, あるいは VT220コンパ チブルドライバの vt0いずれを使う場合もほとんど のフルスクリーンプログラムは termcapなどのターミ ナルデータベースライブラリを通してアクセスしますので, あまり違いはないでしょう. このコンソールを使う場合でフルスクリーンプログラムでト ラブルが起きる場合にはログインした時に TERM変数の値を ``scoansi''にしてください. device vt0 at isa? port ``IO_KBD'' tty irq 1 vector pcrint

これはVT-220コンパチブルコンソールドライバで VT100/102の 上位互換です. これは sc0の使えない種類のラッ プトップ機でもうまく動きます. ログイン時に TERM変数の値 を``vt100'' か ``vt220''にしてください. また, このドラ イバはネットワークを介して多くの異るマシンから接続する 場合も便利です. sc0デバイスのための termcapや terminfoエントリは必ずしも 利用できるわけではありませんが -- ``vt100''はいずれの プラットフォームでも利用可能でしょう. options ``PCVT_FREEBSD=210''

vt0 コンソールドライバを使う場合に必要で す. options XSERVER

vt0 コンソールドライバを使う時のみ有効です. これは vt0 コンソールドライバのもとで XFree86 X サーバを動かすのに必要なコードを含めます. device mse0 at isa? port 0x23c tty irq 5 vector ms

Logitech や ATIのバスマウス入力カードを利用する場合のデ バイスです. ポート(おそらくはCOM1)を有効にしてくだ さい. device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr

このデバイスは PS/2マウスポートにマウスを接続する場合に 使います. シリアル, パラレルポート

ほとんどすべてのシステムにこれらはあります. プリンタを接続す る場合は の章が非常 に役に立つでしょう. モデムを使う場合は に非常に詳しいシリアルポートの設定とデ バイスの使い方があります. device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr

sio0からsio3は MS-DOSにおける COM1から COM4に相当する4本のシリアルポートです. COM4に内蔵モデムがあり COM2を使う場合, FreeBSDからアク セスするためにはモデムのIRQを2へ変更する必要があるとい うことを注意しておきます (技術的な理由より IRQ 2 = IRQ 9となります). マルチポートシリアルカードを使う場合にマニュアルページ のsio(4)にはこのオプションで使う値などのよ り多くの情報があります. ビデオカードの中には (特に S3 チップベースのものには) IOアドレスの 0x*2e8から を利用するものがあり, また多くの安価なシリアルカードは IOアドレス空間を16-bitフルデコードしていませんので, こ れらのカードは衝突します. この場合 COM4ポートは実質上 利用できません. それぞれのシリアルポートは (割込みの共有をサポートした マルチポートカードを利用していないのであれば) 別々の IRQ を割り当てる必要がありますので COM3と COM4のデフォルトの IRQは利用できません. device lpt0 at isa? port? tty irq 7 vector lptintr

lpt0 から lpt2は利用可能な3本のプリン タポートです. 多くの場合は1本のみですので他の2本はない のであればコメントアウトして構いません. ネットワーク

FreeBSDでは他の一般的な Unixと同様にネットワークが 非常に 重視されています. イーサネットカードが なくても必須のオプションとダイヤルアップ ネットワークのサポー トに注意してください. options INET ネットワーキングのサポートです. ネットワークに接続する予定がな くても残しておいてください. 多くのプログラムは少なくともループ バックネットワーキングが必要です(つまり, PCの中でネットワーク コネクションをおこないます). したがってこのオプションは本質的 に不可欠です. Ethernet cards

以下にさまざまなイーサネットカードを有効にするオプショ ンを示します. ネットワークカードがなければこれらすべてを コメントアウトすることができます. そうでなければ利用す る特定のイーサネットカードをサポートするオプションを残 しておきます. device de0

DECの DC21040, DC21041, DC21140チップを使った PCIイー サネットアダプタです. device fxp0

Intel EtherExpress Pro/100B 高速イーサネットカード です. device vx0

3Com の 3C590, 3C595です (いくらか bugがあります). device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr

Cronyx/Sigma の マルチポート同期/非同期カードです. (with Cisco or PPP framing) device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr

Western Digital と SMC の 80xx, 8216 Elite Ultra ; ノベル NE1000, NE2000; 3Com の 3C503; HPの PC Lan Plus (HP27247B とHP27252A) です. device el0 at isa? port 0x300 net irq 9 vector elintr

3Com の 3C501 です. (slow!) device eg0 at isa? port 0x310 net irq 5 vector egintr

3Com の 3C505です. device ep0 at isa? port 0x300 net irq 10 vector epintr

3Com の 3C509 です(バグがあります). device fe0 at isa? port 0x240 net irq ? vector feintr

富士通 MB86960A/MB86965A ベースのイーサネットカード です. device fea0 at isa? net irq ? vector feaintr

DEC DEFEA EISA FDDI アダプタです. device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr

AT&T StarLAN 10 と EN100; 3Com の 3C507; NI5210 です. device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr

Intel の EtherExpress 16です. device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr

DEC の EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422)です. device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr

Lance/PCnet カード (Isolan, Novell NE2100, NE32-VL)です. device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr

IBM/ナショナルセミコンダクタの PCMCIA イーサネット コントローラです. device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr

3Com の PCMCIA Etherlink III です. pseudo-device loop

loop は TCP/IPの一般的なループバックデバイスで す. telnet や FTPを localhost (127.0.0.1) に対して行なうとこの疑似デバイスを通して帰ってきます. 不可欠です. pseudo-device ether

etherはイーサネットカードがある場合のみ必要で 一般的なイーサネットプロトコルを含めます. pseudo-device sl number

sl は SLIP (Serial Line Internet Protocol) をサポー トします. これはほとんど完全に, より簡単に設定ができ, モ デム to モデム接続に適した, よりパワフルな PPPに取って代 わられています. slの後の number は同 時にいくつの SLIPセッションをサポートするかを示します. SLIPの設定のより詳しい情報はこのハンドブックの 「PPPとSLIP」の章の と について書かれた節にあります。 pseudo-device ppp number

pppはダイヤルアップ インターネット接続のための カーネルモード PPP (Point-to-Point Protocol) をサポート します. ユーザアプリケーションとして tun を 利用する PPPの実装もあり, こちらはより柔軟性がありデマ ンドダイアリング(プログラムが接続要求を出した時に自動 的にダイヤルをおこなう)などの機能もあります. それでもこ の PPPドライバを利用したい場合は の節を読んでください. slデバイスと同じように numberは同時 に PPP接続できる数を示します. pseudo-device tun number

tun はユーザモード PPPソフトウェアが利用しま す. このプログラムは設定が簡単で非常に高速です. また自動ダイヤル オン デマンドなどの機能を持ちます. tunの後のnumber は同時におこなうことのできる PPPセッションの数を示します. の節により多くの情報があ ります. pseudo-device bpfilter number

バークレイ パケットフィルタです. この疑似デバイスはネッ トワークインタフェースを無差別 (promiscuous) モードにし てネットワーク (例えば単一のイーサネット) にブロードキャス トされるすべてのパケットを取り入れることを可能にします. こ れらのパケットはディスクに取り入れられたり tcpdump(1) によって検査されます. この機能の実現 はネットワーク全体のセキュリティとの微妙な妥協点であるこ とに注意してください. bpffilter の後の numberは同時に検査することの できるインタフェースの数を示します. 危険の可能性について十分解っている場合を除いてこのオプ ションは奨めません. すべてのネットワークカードでこの機能 をサポートをしてはいません. サウンドカード

ここは GENERICカーネルに含まれていない最初のセクションです. サウンドカードのサポートをするためには LINTコンフィグレーショ ンファイル(これにはすべてのデバイスが含まれています)か ら以下のような適切な行をコピーする必要があります. controller snd0

サウンドドライバ一般のコードです. pcaを除く以下のすべてのサウンドカードで必要で す. device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr

ProAudioSpectrum のオーディオ と MIDI です. device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr

SoundBlaster です. irq 7をirq 5に書き換え, キーワード conflictsを削除し てください. さらに options ``SBC_IRQ=5''の行を 加える必要があります. device sbxvi0 at isa? drq 5

SoundBlaster 16 の 16-bit オーディオです. drq 5を適切な値に書き直 して, (DMA 6の場合) options "SB16_DMA=6"を付け 加えてください. device sbmidi0 at isa? port 0x330

SoundBlaster 16 の MIDI インタフェースです. SoundBlaster 16を使う場合必ずこの行を含めてコンパイル してください. device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr

Gravis Ultrasound です. device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr

Microsoft Sound System です. device opl0 at isa? port 0x388 conflicts

AdLib FMシンセサイザオーディオです. AdLib, SoundBlaster, ProAudioSpectrum を使い playmidi (ports にあります) などのプログラムで MIDIの演奏をしたい場合にこの行を含めます. device mpu0 at isa? port 0x330 irq 6 drq 0

Roland MPU-401 カードです. device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''

MIDIインタフェースの 6850 UART です. device pca0 at isa? port ``IO_TIMER1'' tty

PC のスピーカーを使ったオーディオです. これは非常に品質 が悪く, CPUの性能, 負荷に強く依存します, と言っておき ます (サウンドカードは必要ありませんが). /usr/src/sys/i386/isa/sound/sound.docにあります. また, これらのデバイスを追加する場合は, サウンドを作る必要があり ます. 疑似デバイス

疑似デバイスドライバはデバイスドライバと同様に働きますがマ シン上に対応する実際のハードウェアがないカーネルの部分です. 関連の 疑似デバイスはそちらのセクションに示しました. ここでは残りにつ いて示します. pseudo-device gzip

gzipは gzipによって圧縮された FreeBSDの プログラムを実行できるようにします. /standにあるプログ ラムは圧縮されているのでカーネルにこのオプションをつけ ておくのはいい考えでしょう. pseudo-device log

log はカーネルエラーのログを取るのに使います. 不可欠です. pseudo-device pty number

pty は「仮想ターミナル」や仮想ログインポート です. 外部からの telnetや rloginセッ ション, xterm, emacsなどのアプリケーションが使います. numberは作ることのできる ptyの数を示 します. GENERICのデフォルトは16で, 同時の xtermウィンドウやリモー トログインのために増やす場合は最大で 64までです. pseudo-device snp number

スヌープデバイスです. この疑似デバイスはあるターミナル セッションが watch(8) commandによって他のター ミナルを監視することを可能にします. この機能の実現はセ キュリティとプライバシに対して極めて微妙な関係があり ます. snpの後の numberは同時におこなうことのでき るスヌープセッションの総数です. 選択可能です. pseudo-device vn

Vノードドライバです. ファイルを vnconfig(8)コマ ンドによってデバイスとして取り扱うことを可能にします. このドライバによりフロッピーディスクイメージを操作したりファ イルをスワップデバイスとして (MS Windowsのスワッ プファイルなどを)用いることができます. 選択可能です. pseudo-device ccd number

ccd (concatenated disk)デバイスはいくつかのディスクパーティ ションを融合して大きなディスクのように見せることができます. ccdの後の numberは同時に作ることのできる疑似ディスクの数です. (詳しいことは ccd(4)と ccdconfig(8)のマニュ アルを参照してください.) 選択可能です. ジョイスティック, スピーカー, その他

この節は FreeBSDのここまでに示した以外のハードウェア デバイスへのサポートについて示します. これらは GENERICカーネル には含まれませんのでこのハンドブックや LINT (このファイルには すべてのデバイスのサポートが含まれます) からコピーする必 要があります. device joy0 at isa? port ``IO_GAME''

PC のジョイスティックです. pseudo-device speaker

IBM BASIC スタイルの PC内蔵スピーカーのサポートです. シェルスクリプトで簡単な演奏をする /usr/sbin/spkrtest やキーボードを使って単純なピ アノのように演奏することができる /usr/games/piano (gamesパッケージをイ ンストールした場合にはあります) のようないくつかのプロ グラムで使われます. また素晴らしいテキストロールプレイ ングゲームである NetHack (ports コレクションにあります) はゲーム中の楽器の演奏でこのデバイスを使うように設定を することができます (訳注:日本語化されたJNetHackもportsに あります).

デバイスの 項も参照してください. デバイスノードを作る

カーネル内のほとんどすべてのデバイスは対応する ``node'' エント リが /dev ディレクトリにあります. これらのノードは普 通のファイルのように見えますが, 実際にはプログラムがデバイスに アクセスするのに用いるカーネル内への特別なエントリです. シェルスクリプトである /dev/MAKEDEVはオペレーティング システムを最初にインストールする時に実行され, サポートされてい る大部分のデバイスのノードを作ります. しかし, すべてのノードが作られるわけではありませんので 新しいデバイスのサポートを加える時は対応するエントリがこのディ レクトリにあるかどうか確認してもしなければ, 作ってください. 以下に例を示します. IDE CD-ROMのサポートをカーネルに加えるとします. 次の行 を加えます. controller wcd0 これにしたがって, /devディレクトリに wcd0で始ま るエントリを捜してください. 1文字が後ろにつくかもしれません. 後 ろについた文字が `c'であるか先に `r'のつくエントリは `raw'デバ イスを示します. それらのファイルがないことが明らかになったとします. そこで /dev ディレクトリに移動して次のようにタイプします. # sh MAKEDEV wcd0 スクリプトの実行が終ったら /devに wcd0c と rwcd0c エントリがあることを確認してください. これによ り正しく実行されたことがわかります. サウンドカードの場合のコマンドは次の通りです. # sh MAKEDEV snd0 これにより対応するエントリが作られます. 注: サウンドカードのようなデバイスのノードを作る場合で, もし他 の人がマシンにアクセスするようであれば, そのデバイスを /etc/fbtabファイルに追加して外部からのアクセスから 保護するのが望ましいでしょう. このファイルの詳細については man fbtab を参照してください. GENERICに含まれていないデバイスはエントリがありませんから,以上 の簡単な手順をおこなうことになります. /devの エントリを使用しますのでノードを作る必要はありません. またネッ トワークカードと SLIP/PPP疑似デバイスは /devにはエント リがありませんのでこれらについても作る必要がありません. 問題が起きた場合には

カスタムカーネルを作る場合に起きるトラブルは4種類に分けられま す. Config コマンドの失敗

カーネルにあなたの設定をおこなった場合で configコ マンドが失敗したのであれば, 多分どこかで単純な間違いを やっているのでしょう. さいわい, configはトラ ブルの起きた行番号を出力しますので viで素早く 見つけることができます. 例えばもし次のように出力されれ ば, config: line 17: syntax error viのコマンドモードで ``17G''とタイプすればあな たは問題のところへ飛ぶことができます. GENERIC カーネル のファイルや他のリファレンスと比較して注意深く修正して ください. Make コマンドの失敗

make コマンドが失敗した場合には, カーネル設定で configがとらえられなかったような間違いをして いることが多いようです. ふたたびコン フィグレーションを見直してください. それでも問題を解決 することができなければ &a.questions へあなたのカーネルのコンフィグレーションをつけてメー ルしてください. 誰かが素早く間違いを見つけてくれるで しょう. カーネルがブートしない

新しいカーネルがブートしなかったり, デバイスの認識をしな い場合でもあわてないでください! さいわい, BSDは利用で きないカーネルから復帰する優れたメカニズムがあります. FreeBSDの bootプロンプトでリターンキーを押すかわりに 単にブートさせたいカーネルの名前 (例えば ``kernel.old'') をタイプするだけです. カーネルの再設定 をおこなう場合に現在のカーネルを利用できるように取ってお くのはよい考えです. 問題のないカーネルでブートした後にあなたのコンフィグレー ションファイルを調べ, 再び構築を試みてください. /var/log/messages ファイルにはすべての成功した ブートのカーネルのメッセージやその他の記録があり, これ は助けになる情報の一つでしょう. また, dmesg(8)コマンドは現在のブート時のカーネルメッ セージを出力します. kernel. oldは新しいカーネルをインストールする 時に, その一つ前にインストールしたうまく動かないかもしれ ないカーネルで上書きされてしまいますので当てにできませ ん. またできる限り早く動作しているカーネルを本来の ``kernel''の位置に移動させてください. そうしないと ps(1)のようなコマンドが正しく動きません. make でインストールされたカーネルのファイルを (別のカーネルに戻すために) 「アンロック」するための特別 のコマンドは # chflags noschg /kernel です. また, 新しい置き換えたカーネルあるいは重要ファイ ルを動かしたり変更されないように「ロック」するには 次のようにします. # chflags schg /kernel カーネルは動くが ps は動かない!

システムユーティリティと異るバージョンのカーネルをインス トールした場合, 例えば 実験的に ``2.2.0''のカーネルを 2.1.0-RELEASEシステム上にインストールするような場合, ps(1)や vmstat(8)のような多くのシ ステムステータスコマンドは動かなくなります. libkvm を 再コンパイルしてこれらのユーティリティを作りなおす必要がありま す. これは, オペレーティングシステムのそれ以外の部分と異るバージョ ンのカーネルを使うことが普通はあまりよくない理由の一つです. diff --git a/ja_JP.EUC/handbook/kernelopts.sgml b/ja_JP.EUC/handbook/kernelopts.sgml index 94580dbac6..0df578742f 100644 --- a/ja_JP.EUC/handbook/kernelopts.sgml +++ b/ja_JP.EUC/handbook/kernelopts.sgml @@ -1,153 +1,153 @@ - + - + カーネルコンフィグレーションの新しいオプションを追加する

原作: &a.joerg;

訳: &a.yoshiaki; . 29 December 1996. の章の内容を 理解しておいてください. そもそもカーネル オプションって何?

カーネルオプションの使い方は基本的には の章に書いてあります. そこには「伝統的な形式」と「新しい形式」のオプションの説明があります. すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル を修正して 基本的に, カーネルオプションはカーネルのコンパイルプロセスの C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる ようにするためには, 対応する部分のカーネルソース (またはカーネルの #ifndef THIS_OPTION #define THIS_OPTION (some_default_value) #endif /* THIS_OPTION */

この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば, デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, 新しい値はプリプロセッサによってソースコード中で置き換えられるため, デフォルトの値が使われていた場所において C の式として有効な値でなければ なりません.

また, 単に特定のコードを有効にするか無効にするかを設定するための 値を持たないオプションも作ることができます. #ifdef THAT_OPTION [あなたのコードが入ります] #endif

コンフィグファイルに C 言語にくわしい人であれば「コンフィグオプション」とされているもの は少なくとも一つの options notyet,notdef

このようにコンフィグファイルをしておくと, カーネルのコンパイルは うまく行きません. :-)

(訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを 持たないオプションの場合, 無効とするためのパラメタをつけて, オプション で「無効とする」と明示することはできないという意味です)

明らかに, 任意のオプション名がカーネルソースツリー全体でどのように 使われているかを追いかけることは非常に難しいことです. このことが opt_foo.h という名前に されます. この方法では, 通常の Makefile の依存関係が適用され, 古い形式のオプションの機構は, 局部的なオプションや実験的なオプション のような一時的に利用されると考えられるオプションにおいては有効です. つまり ではどのようにして追加するのでしょう?

最初に sys/conf/options (または sys/i386/conf/options.<arch>, たとえば sys/i386/conf/options.i386) を編集し, 新しいオプション を含めるのに最適な opt_foo.h ファイルを選びます.

新しいオプションの必要がなくなったとしたら, これを取り除きます. たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション の変更は 新しいオプションを加えるのに使えそうな opt_foo.h がない場合は新しい名前を作ってください. 意味のある名前を作り options[.<arch>] ファイル に新しいセクションのコメントをつけてください. 大量のオプションを一つの opt_foo.h にまとめると コンフィグファイルの一つのオプションを変更したときに多くのファイルが 再コンパイルされる原因になります.

新しいオプションに依存するカーネルファイルは最終的には見つけ出 されます. ただし, オプションを作っただけで対応するソースがどこにも ない場合は別です. find /usr/src/sys -name type f | xargs fgrep NEW_OPTION

オプションに対応するソースを見つけるのに上記のコマンドは便利です. 見つけたすべてのファイルで編集, 追加をおこないます. #include "opt_foo.h"

ファイルの先頭の, すべての #ifndef NEW_OPTION #define NEW_OPTION (something) #endif

システムヘッダファイル (たとえば /usr/include/sys/ にある ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します. そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include しないとオプションの値によって不整合が起きてしまう場合を除き, それらの ファイルに opt_foo.h を include しないでください. そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法 ではありません. diff --git a/ja_JP.EUC/handbook/linuxemu.sgml b/ja_JP.EUC/handbook/linuxemu.sgml index c5132e2b9e..c8b204dfb9 100644 --- a/ja_JP.EUC/handbook/linuxemu.sgml +++ b/ja_JP.EUC/handbook/linuxemu.sgml @@ -1,713 +1,713 @@ - + - + Linux エミュレーション

原作: &a.handy and &a.rich;

訳: &a.kiroh;.24 September 1996. Linux エミュレータのインストール

FreeBSD での Linux エミュレーションは, 大部分の Linux バイナリ(a.out および ELF フォーマット)を実行できる状態になっています. 2.1-STABLE ブラン チでのエミュレーションでは, Linux DOOM や Mathematica が実行できます. FreeBSD 2.2-RELEASE でのエミュレーションは, さらに強化されており, Linux 用 の Quake, Abuse, IDL, netrek など, 多数のソフトウェアが実行できます. Linux オペレーティングシステムには、特有の機能がいくつかあり, FreeBSD でサポートされていないものもあります. Linux の /proc ファイルシステム を使ったバイナリは, FreeBSD では実行できません (FreeBSD で使用可能な /proc ファイルシステムとは仕様が異なっているためです). また仮想8086モー ドを有効にするなど, i386 に特有なシステムコールを使っている場合も実行 できません.

カーネルが Linux エミュレーションを使用するように構築されているかを調 べるには, Linux のバイナリを実行してみるのが簡単です. linux-executable: Exec format error. Wrong Architecture. このようなエラーメッセージが表示されるようであれば, Linux との互換性は サポートされていません. カーネルを再構築してインストールする必要があり ます. Linux エミュレーションの設定方法は, 使用している FreeBSD のバージョン によって多少異なっています. 2.1-STABLE への Linux エミュレーションのインストール

2.1-STABLE の GENERIC カーネルは, Linux との互換性を保つように構築 されていません. カーネルの再構築が必要です. 再構築をおこなうには, 2つの方 法があります. 1つは, エミュレータをカーネル自体にスタティックリンクす る方法. もう1つは, 動的に Linux ローダブルカーネルモジュール(LKM)をロー ドするようにする方法です.

エミュレータを有効にするには, 以下をコンフィグレーションファイル (/sys/i386/conf/LINT など) に追加します. options COMPAT_LINUX Linux DOOM などのアプリケーションを実行したい場合は, 共有メモリも有効 にしておかなければなりません. 以下を追加します. options SYSVSHM Linux のシステムコールを使用するには, 4.3BSD のシステムコールとの互換 性が保たれていることが必要です. 以下の行が含まれていることを確認してく ださい. options "COMPAT_43" LKM を使用せずエミュレータをカーネルにスタティックにリンクしたい場合は, 以下の行を追加します. options LINUX の節の記述に したがって config と, 新しいカーネルのインストールをおこなってください. LKM を使用する場合は, ローダブルモジュールをインストールしなければなり ません. カーネルとローダブルモジュールのバージョンが異なると, カーネル がクラッシュする場合がありますので, 安全を期すためには, カーネルをイン ストールするごとに, LKM も再インストールしてください. % cd /usr/src/lkm/linux % make all install カーネルと LKM のインストールが終了したら, root で `linux' コマンドを 実行することで LKM をロードできます. % linux Linux emulator installed Module loaded as ID 0 % LKM がロードされたかどうかを確認するには, `modstat' を実行します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator % システムブート時に, LKM をロードするようにするには, 2つの方法がありま す. FreeBSD 2.2.1-RELEASE または 2.1-STABLE では, /etc/sysconfig を, linux=YES のように, NO を YES に変更してください. FreeBSD 2.1 RELEASE およびそれ以 前のバージョンでは, そのような行はありませんので, /etc/rc.local に以下 の行を追加する必要があります. linux 2.2-RELEASE への Linux エミュレーションのインストール

``options LINUX'' や ``options COMPAT_LINUX'' を指定する必要 はなくなりました. Linux エミュレーションは LKM(「ローダブルカーネルモジュール」) を使用して, リブートせず簡単にインストールできます. スタートアッ プファイルで以下のように指定します. /etc/rc.conf に以下の行が必要です. linux_enable=YES これは結果的に, /etc/rc.i386 の以下の指定を有効にします. # Start the Linux binary emulation if requested. if [ "X${linux_enable}" = X"YES" ]; then echo -n ' linux'; linux > /dev/null 2>&1 fi

実行されたかどうかを確認するには, modstat を使用します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod % 2.2-RELEASE とそれ以降のシステムの中には, modstat の実行がうまくいかない ものがあるという報告もあります. 何らかの理由で, Linux LKM がロードできな い場合は, options LINUX をカーネルの設定ファイルに指定して, エミュレータをスタティックにリンク してください. の節の記述にしたがって config と, 新しいカーネルのインストールをおこ なってください. Linux ランタイムライブラリのインストール linux_lib port を使用してのインストール

多くの Linux アプリケーションはシェアードライブラリを使用しますので, シェアードライブラリのインストールが終了しなければ, エミュレータのイン ストールは終わったことになりません. 手動でもインストールできますが, linux_lib port を使用するのが簡単です. % cd /usr/ports-current/emulators/linux_lib % make all install これで, Linux エミュレータが動作するようになったはずです. 伝説(とメー ルのアーカイブ :-) によれば, Linux エミュレーションは, ZMAGIC ライブラ リとリンクされている Linux バイナリに対して, 最もうまく動作するようで す. Slackware V2.0 などに使われている QMAGIC ライブラリだと, エミュレー タが胸やけするかもしれません. これを書いている時点(1996年5月)で, ELF エミュレーションは依然実験段階ですが, かなりうまく動作しているようです. マイナーバージョンの不一致などを報告するプログラムもありますが, 普通は 問題にならないようです. 手動でのライブラリのインストール

``ports'' ディストリビューションが手元にない場合は, 手動でライブラ リをインストールする必要があります. プログラムが必要とする Linux のシェ アードライブラリとラインタイムリンカが必要です. また Linux ライブラリ の用の``shadow root'' ディレクトリ, /compat/linux, を作成する必要があ ります. FreeBSD で動作する Linux のプログラムが使用するシェアードライ ブラリは,まずこのファイルツリーから検索されます. 例えば, Linux のプロ グラムが/lib/libc.so をロードしようとした場合には, FreeBSD は, まず /compat/linux/lib/libc.so を開こうとします. 存在にしなかった場合には, 次に /lib/libc.so を試します. シェアードライブラリは, Linux の ld.so が参照するライブラリではなく, /compat/linux/lib 以下にインストールする 必要があります. FreeBSD 2.2-RELEASE 以降では, /compat/linux にかかわる動作が多少異なりま す. -CURRENT では, ライブラリだけでなくすべてのファイルが, ``shadow root'' /compat/linux から検索されます. Linux のプログラムが必要とするシェアードライブラリを探す必要があるのは, FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だ けでしょう. それが過ぎれば, 十分な Linux のシェアードライブラリがシス テムにインストールされ, 新しくインストールした Linux のバイナリも, 余 計な作業をせずに動作させることができるようになります. シェアードライブラリの追加

linux_port をインストールした後に, アプリケーションが必要なライブラリ が存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバ イナリがどのシェアードライブラリを必要とし, そしてどこで入手できるか, どのように探したらよいでしょうか? 基本的には, 以下の2種類の方法があり ます(以下の手順にしたがう場合には, 必要なインストール作業をおこなう FreeBSD シ ステム上で root として作業をおこなう必要があります).

Linux システムを使用でき, 必要なシェアードライブラリが調べられる場 合には, 単に FreeBSD のシステムにそのライブラリをコピーするだけで す. 例えば, DOOM の Linux バイナリを ftp で持ってきたとします. 使用で きる Linux システムの上に転送して, `ldd linuxxdoom' とやれば, 必要とす るシェアードライブラリがチェックできます. % ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

最後のカラムに表示されているすべてのファイルを持って来て, /compat/linux の下 に置き, 最初のカラムに示されるファイル名からシンボリックリンクを張る必 要があります. すなわち, FreeBSD のシステムで, 以下のようなファイルが必 要となります. /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

最初のカラムに表示されているファイルと, メジャーバージョンの同じ Linux シェアードライブラリを既にインストールしている場合は, 新たにコピーする 必要はありません. 既にあるライブラリで動作するはずです. ただ, 新しいバー ジョンのシェアードライブラリがある場合は, 新しいものをコピーすることを お奨めします. 新しいライブラリにシンボリックリンクを変更したら, 古いラ イブラリは削除してかまいません. /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 以上のようなライブラリがインストールされており, 新しいバイナリに対する ldd の出力が以下のようになる場合を考えます。 libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 このように最後の番号が1つか2つ古いだけならば, 普通は /lib/libc.so.4.6.29 をコピーする必要はありません. わずかに古いライブラ リでも, プログラムは動作するはずだからです. もちろん, 新しいライブラリ と置き換えて, 以下のようにしても構いません. /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

シンボリックリンクのメカニズムは, Linux バイナリにのみ必要 なことに注意してください. FreeBSD のランタイムリンカは, メジャーリビジョ ン番号の一致したライブラリを検索しますから, ユーザが気にする必要はあり ません. ld.so の設定 -- FreeBSD 2.2-RELEASE のみ

このセクションは, FreeBSD 2.2-CURRENT 以降にのみ当てはまります. 2.1-STABLE を使用している方は, 飛ばしてください.

最後に, FreeBSD 2.2-RELEASE を使われている場合は, Linux のランタイムリンカと その設定ファイルがシステムに導入されていることを確認してください. これらのファイルは, FreeBSD システムの適切な位置(/compat/linux ツリー以 下)にコピーされている必要があります. /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config

使用できる Linux システムがない場合は, 必要なファイルは近くの FTP サイ トから入手してください. 各種ファイルの入手先についての情報を, 後に付 けておきます. ここでは, 必要なファイルの入手先がわかっているものとしま す.

以下のファイルを取得します(バージョンの不一致を避けるために, すべて同一 の FTP サイトから入手してください). 取得したファイルを /compat/linux 以下にインストールしてください(例えば, /foo/bar は, /compat/linux/foo/bar にインストールされます). /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so

ldconfig と ldd は, /compat/linux の下にある必要はありません. システム のどこにあっても構いません. ただ, FreeBSD の同名のコマンドと間違えないように 注意してください. /usr/local/bin の中に, ldconfig-linux, ldd-linux とし てインストールするのもよいアイディアでしょう.

/compat/linux/etc/ld.so.conf ファイルを作成し, Linux ラインタイムリンカ がシェアードライブラリを検索するディレクトリを記述してください. このファ イルはプレインテキストファイルで, それぞれの行にディレクトリ名を含みま す. /lib と /usr/lib は標準ですから, 以下のようなディレクトリが追加できま す. /usr/X11/lib /usr/local/lib

Linux バイナリが, /lib/libc.so というライブラリを開いた場合, エミュレー タは内部で, ファイル名を /compat/linux/lib/libc.so にマップします. エ ミュレータがライブラリを検索するために, すべての Linux のライブラリ (/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so など) は, /compat/linux 以下にインストールされていなければなりません.

FreeBSD 2.2-RELEASE を使用している場合は, Linux の ldconfig プログラム を実行する必要があります. % cd /compat/linux/lib % /compat/linux/sbin/ldconfig

ldconfig はスタティックリンクされていますから, 実行するのにシェアードラ イブラリを必要としません. ldconfig は, /compat/linux/etc/ld.so.cache ファイルを作成し, すべてのシェアードライブラリの名前を格納します. ライ ブラリの追加をおこなった場合には, ldconfig を再実行して, このファイルを作り 直さなければなりません. 2.1-STABLE では, /compat/linux/etc/ld.so.cache をインストールしたり, ldconfig を実行したりしないでください. 2.1-STABLE では, システムコー ルの実装方法が異なるため, ldconfig は使用されません.

これで, libc シェアードライブラリを必要とする Linux バイナリを実行する設 定が終了しました. ldd を ldd 自身に実行してテストしてください. ldd-linux としてインストールしている場合は, 以下のような結果になるはず です. % ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

ここまで終了すれば, 新しい Linux のバイナリをインストールできます. 新しい Linux バイナリをインストールするときは, それがシェアードライブ ラリを必要とするかどうか確認してください. 必要とする場合は, /compat/linux 以下にインストールされているかどうか確認してください. こ れは, Linux の ldd を新しいプログラムに対して実行し, 出力を確認するこ とによりおこなえます. ldd(ldd(1)マニュアルページも参照してください)は, プ ログラムが必要とするシェアードライブラリのリストを, majorname (jumpversion) => fullname という形式で出力します.

fullname のかわりに ``not found'' と出力される場合は, ライブラリの追加をす る必要があります. 必要なライブラリの名前は, majorname に libXXXX.so.N.mm という形式で示されています. Linux の FTP サイトで libXXXX.so.N.mm を探し, インストールしてください. XXXX(名前)とN(メジャー リビジョン番号)は一致している必要があります. マイナー番号 mm は, それほ ど重要ではありませんが, なるべく最新のものをインストールするようにして ください. ホストネームリゾルバの設定

DNS がうまく動作しなかったり, 以下のようなエラーメッセージが表示され る場合は, /compat/linux/etc/host.conf ファイルを設定する必要があります. resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword ファイルの内容を以下のように設定してください. order hosts, bind multi on ここで, order は /etc/hosts を最初に検索し, 次にDNSを検索するように指定 します. /compat/linux/etc/host.conf がインストールされていない場合は, Linux のアプリケーションは, FreeBSD の /etc/host.conf を使用しようとして, 文法の違いによる警告を表示します. /etc/resolv.conf を使用してネームサー バを設定していない場合には, `bind' を削除してください.

最後になりますが, 2.1-STABLE を使用している場合は, RESOLV_HOST_CONF 環境変数を指定して, アプリケーションにホストテーブル の検索方法を指定する必要があります. FreeBSD 2.2-RELEASE を使用している場合 は, スキップしてください. /bin/csh を使っている場合は, 以下のようにし ます. setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf /bin/shの場合は, 以下のようにします. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF 必要なファイルを探すには

注意: 以下の情報は, この文書が書かれた時点では有効ですが, FTP サイトの 名前, ディレクトリ, 配布ファイル名などは, 変更されている可能性がありま す.

訳注: ここに取り上げられている FTP サイトは, 日本国内にもミラーサイト が多数存在します。なるべく近くの FTP サイトからファイルを入手してくだ さい.

Linux は, いくつかのグループが, それぞれ独自のバイナリ配布セットを作成 して配布しています. 配布セットは, ``Slackware'' や ``Yggdrasil'' など の名前がつけられています. これらの配布セットは, 多くの FTP サイトから 入手できます. ファイルが展開されており, 必要なファイルのみを取得できる 場合もありますが, 通常は圧縮された配布セットの形で入手できます. 配布 セットは, いくつかのサブディレクトリに, gzip で圧縮された tar ファイル として格納されています. それぞれの配布セットの一次配布先は, 以下の通り です. sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions

ヨーロッパのミラーサイトの例: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions

混乱を避けるために, ここでは Slackware だけを取り上げます. この配布セッ トは, 多くのサブディレクトリ内にある別々のパッケージから構成されていま す. 通常, パッケージはインストールプログラムにより自動的に制御されま すが, ``手動で''おこなうことも可能です. まず配布セットの中の, ``contents'' サブディレクトリの内容を書くにしてください. ここには多く の小さなテキストファイルが含まれおり, それぞれのパッケージの内容が記述 されています. 必要なファイルを探している場合は, まず contents 内のテキ ストファイルを取得し, そのファイルの中から grep を使用して検索するのが, 最も速い方法でしょう. 以下に必要となるであろうファイルを, grep を使用 して検索した例を示します. Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs

この場合は, ldso, shlibs, xf_lib, oldlibs というパッケージが必要なこと がわかります. それぞれのcontentsファイルの中で, ``PACKAGE LOCATION'' と書いてある行を探してください. その行に, パッケージが含まれているディ スク, 今回の場合はサブディレクトリ名が書かれています. たとえば, 以下の ようになります. Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9

``diskXX'' というのは, 配布セットの ``slackware/XX'' サブディレクトリ を示します. それ以外の場合は, ``contrib'' サブディレクトリに格納されて います. 今回の場合は, 以下のファイルを取得すればいいことがわかります (ファイル名は, 配布セットのルートディレクトリからの相対パスで示してあ ります). slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz

gzip で圧縮された tar ファイルから必要なファイルを /compat/linux ディ レクトリに格納してください(必要なファイルのみを展開するか, あるいは必 要でないファイルを後で削除してください). これで作業は終了です.

参照: ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 FreeBSD への Mathematica のインストール

原作: &a.rich and &a.chuck

訳: &a.kiroh;. この文書は, Mathematica 2.2 の Linux バイナリディストリビューションを, FreeBSD 2.1 にインストールする方法について説明します.

Mathematica は, そのままでは FreeBSD をサポートしていませんが, Linux は サポートしています. ですから, Linux エミュレータの設定が終わってしまえ ば, Mathematica を動作させる環境はほとんど整ったことになります.

DOS 用のスチューデント版 Mathematica から Linux バージョンへのアップグレー ド価格は, 執筆時点 (1996年5月) では, $45.00 です. 直接 Wolfram(電話番号(217) 398-6500)に注文して, 支払いはクレジットカー ドでおこなえます。 Mathematica ディストリビューションの展開

バイナリは, Wolfram から CDROM で配布されています. CDROM には, 1ダー スほどの tar ファイルが含まれており, それぞれサポートされているアーキテ クチャに対応しています. Linux 用のファイルは, LINUX.TAR です. 例えば /usr/local/Mathematica 以下にインストールする場合は, 以下のようにしま す. % cd /usr/local % mkdir Mathematica % cd Mathematica % tar -xvf /cdrom/LINUX.TAR Mathematica パスワードの取得

Mathematica を実行する前に, 使用するマシンに対応した `machine ID' を Wolfram から取得する必要があります.

Linux 互換ランタイムライブラリがインストールされており, mathematica の展 開が終了したら, Install ディレクトリで `mathinfo' プログラムを使用す ることで `machine ID' を得ることができます. % cd /usr/local/Mathematica/Install % mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 % ここで, `richc' の `machine ID' は, `9845-03452-90255' となります. ioctl のメッセージは無視してください. まだ FreeBSD では実装されていません. Mathematica を実行するたびに同様のメッセージが表示されますが, 実際の使 用に問題はありませんので, 無視してかまいません.

電子メールや電話, ファックスなどで Wolfram に `machine ID' を知らせ て登録すると, いくつかの番号のグループからなるパスワードが送り返されて きます. パスワードを, マシン名, ライセンス番号とともに, mathpass ファ イルに追加します. 追加は, 以下のようにおこないます. % cd /usr/local/Mathematica/Install % math.install ライセンス番号と, Wolfram から送られてきたパスワードを入力を求めます. 入力を間違えたりして, math.install の実行が失敗しても大丈夫です. `mathpass' ファイルを手動で編集して, 情報を訂正してください.

パスワードの入力後, math.install では, インストール方法を, デフォルト 設定でのインストールか、自分で方法を指定するインストールから選ぶことが できます. 筆者のようにインストールプログラムを信用していない場合は, 自 分でディレクトリを指定する方を選択するでしょう. 自分で指定するインストー ルを選んだ場合, math.install 自身ではディレクトリの作成はおこないません. 注意してください. 別のウィンドウでシェルを開いて, 指定するディレクトリ を作成してください. 存在しないディレクトリを指定して, math.install が インストールに失敗した場合には, ディレクトリを作成し, math.install を 再び実行してください. 筆者らがインストール先に選んだディレクトリは, 以 下の通りです. くれぐれもあらかじめ作成してから, math.install で指定す るようにしてください. /usr/local/Mathematica/bin バイナリファイル /usr/local/Mathematica/man/man1 マニュアルページ /usr/local/Mathematica/lib/X11 XKeysymbファイル また, システムレコードファイルとして, /tmp/math.record を使用するように 設定することもできます. このファイルには, セッションのログが記録されま す. この設定が終了すると, math.install は残りのファイルを展開して, 必 要な場所に格納します.

Mathematica ノートブックの機能は, X フロントエンドとして本体とは別に含 まれています. X フロントエンドを正しくインストールするには, /usr/local/Mathematica/FrontEnd ディレクトリに移動し, ./xfe.install シェ ルスクリプトを実行します. インストール先を指定しなければなりませんが, あらかじめ作成する必要はありません. 必要なディレクトリは, すべて math.install によって作成されているからです. インストールが終了したら, /usr/local/Mathematica/bin ディレクトリに, ``mathematica'' という名前の シェルスクリプトが新たに作成されているはずです.

最後に, Mathematica がインストールしたシェルスクリプトを修正する必要 があります. /usr/local/Mathematica/bin に含まれるすべてのシェルスクリプ トの先頭部分に以下の行を追加します. XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB これは, Mathematica が使用する Mathematica バージョンのキーマップファイル XKeysymDB の場所を指定するものです. 2.1-STABLE を使用している場合は, 以下の行も追加してください. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF これは, Mathematica に Linux バージョンの host.conf を使用するように指定し ます. FreeBSD の host.conf の文法は, Linux のものと異なっているため, この 指定をおこなわないと, /etc/host.conf に関わるエラーが発生します.

新しいマニュアルページを利用したい場合は, さらに /etc/manpath.config ファイ ルを修正する必要があります. また自分の~/.cshrcを変更して, /usr/local/Mathematica/bin をパスに追加してください.

これでインストール作業はすべて終了です. ``mathematica'' とタイプすれば, 見栄えのする Mathematica ノートブックが表示されるはずです. Mathematica には, Motif ユーザインタフェースが含まれますが, スタティックにリンクさ れているため, Motif のライブラリは必要ありあません. 頑張って Mathematica をインストールしてください. バグ

ノートブックフロントエンドは, 以下のようなエラーメッセージを表示して, ハングすることがあることが知られています. File .../Untitled-1.mb appears to be broken for OMPR.257.0 今のところ原因はわかっていませんが, このバグが影響を及ぼすのは, ノートブッ クの X window フロントエンドのみです. Mathematica エンジン本体に影響は ありません. そのため, ``math'' によって起動されるコマンドラインのインタ フェースを使用している場合は, このバグは関係ありません. 謝辞

&a.sosと&a.peterに深く感謝します. Linuxエミュレーションが現在の形に あるのは, 彼らのおかげです. そして, 彼ら二人にハッパをかけて, 犬のよう に働かせた Michael Smithに. 今やLinuxエミュレーションは, linuxよりうま くlinuxバイナリを実行できます！ :-) diff --git a/ja_JP.EUC/handbook/memoryuse.sgml b/ja_JP.EUC/handbook/memoryuse.sgml index 2935142e0f..fd46b80eb2 100644 --- a/ja_JP.EUC/handbook/memoryuse.sgml +++ b/ja_JP.EUC/handbook/memoryuse.sgml @@ -1,61 +1,61 @@ - + - + PC におけるメモリの利用

原作: &a.joerg;. 16 Apr 1995.

訳: &a.tomo;. 29 Oct 1996. FreeBSDがi386プラットフォーム上でどのようにメモリを使うかに ついての説明です. ブート部分は0:0x7c00にロードされ, すぐに自分自身を 0x7c0:0に移します. (これは手品ではなく, 単なる%cs セレクタのための調節であり, ljmpにより行われます. ) それから最初の15セクタを0x10000(biosbootのMakefileのなかの BOOTSEG部分)にロードし, 作業領域のスタックを0x1fff0以下に セットします. このあと, boot2 に飛びます. つまり, boot1 自身と (ダミーの) DOS パーティションテーブルを飛び越えて, %csセレクタを 調節します---この時点ではまだ16ビットモードです. boot2はブートファイルを要求し, a.outヘッダを調べます. 0x00ffffffによってファイルエントリポイントを (通常は0xf0100000に)マスクし, ロードします. このため, 通常のロードポイントは1MB(0x00100000)になります. ロードしている間, リアルモードでBIOSを使うため, ブートコードは, リアルモードとプロテクトモードの間を行ったり来たりします (訳注: これは, BIOSがリアルモード用に書かれていて, ロードすべき領域がリアルモードではアクセスできない1MBより上位の アドレスであることから, ブートコードがリアルモードと プロテクトモードを切り替えながら動作するためです). ブートコード自身はプロテクトモードで%csと%ds/%es用に セグメントセレクタ0x18と0x20を使い, リアルモードに戻るのに0x28を使います. 最終的にカーネルはアドレス空間全体をカバーできるようなダミーの ディスクリプタを参照して%cs 0x08と %ds/%es/%ss 0x10でスタートします. カーネルはそのロードポイントで起動されます. 別の(高位)アドレスにリンクされるので, ページテーブルやページディレクトリなどが適切に設定され, ページングが有効になり, カーネルがリンクされたアドレスで 動作するようになるまでは, カーネルはロードアドレスからの 相対アドレス (PIC: position independent code) を用いて 実行されなければなりません. 寄贈: &a.davidg;. 16 Apr 1995. カーネルの BSS セグメントの直後の物理ページ (実メモリ) に proc0 (訳注: プロセス番号 0, swapper) のページディレクトリや ページテーブル, Uページが配置されます. 仮想記憶機構が初期化された少しあと, 0x1000-0x9ffffの実メモリとカーネル (text + data + bss + 上記の proc0 に関わるもの + その他) の後ろの実メモリは, 通常の仮想記憶ページの形で利用可能となり, グローバルな空きページリストに追加されます. diff --git a/ja_JP.EUC/handbook/policies.sgml b/ja_JP.EUC/handbook/policies.sgml index 52c41dd2e5..ae31025ace 100644 --- a/ja_JP.EUC/handbook/policies.sgml +++ b/ja_JP.EUC/handbook/policies.sgml @@ -1,257 +1,257 @@ - + - + ソースツリーのガイドラインおよび方針

原作: &a.phk;.

訳者: &a.mihoko; 6 September 1996 . 本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや ポリシーについて書かれています. Makefile 中の MAINTAINER

1996年6月.

FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守 されている場合は, ソースツリーの当該 Makefile に MAINTAINER= email-addresses

が付け加えられています. これを記述することによって, この部分が誰 に保守管理されているかを世界中のユーザに伝えることができます.

この意味は次のとおりです:

保守担当者がそのコードを所有し, そのコードに対する責任を持っ ています. すなわち, その人がそのコードに関するバグの修正やトラブル報告 に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, そのソフトウェアの新しいバージョンに適切に追従させる作業をその人が行い ます.

保守担当者が決められているディレクトリに対して変更をおこなう場合は, 変更をおこなう前に, その変更内容を保守担当者に送って, 保守担当者にレビューをしてもらってください. 保守担当者が, 電子メールに一定期間応答しない場合にのみ, 保守担当者がレビューすることなしに, 変更をおこなうことが認められます. しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー してもらうようにしてください.

もちろん, この義務を引き受けることができない人やグループを 保守管理者として追加することはできません. また, 保守管理者がソースツリー管理者 ("committer") である必要は ありません. 寄贈ソフトウェア

1996年6月.

FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト 以外のところで保守されています. 歴史的な経緯から, 私たちはこれを 寄贈 ソフトウェアと 呼んでいます. perl や gcc, patch などがその例です.

ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が 取られてきましたが, どの方法にもいくつかの利点と欠点があります. これまで欠点のない明確な方法はありませんでした.

議論した結果, これらの方法のうちの一つが「公式な」方法として選択され ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用 されます. その上, この方法では, だれもが(cvs にアクセス権のない人でさえ)「公式」 バージョンのソースに対する差分を簡単に得ることができます. これは古い方法にはなかった大きな利点です. ですから, 既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更 点を返すのがとても容易になります.

しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って いる人々に委ねられています. もしこの方法を使用することが, その人が扱っているパッケージには 極端に合わないような場合には, コアチームの承認さえあれば, これらの ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 将来にわたってパッケージを保守できるということは, 大変重要な事柄に なってきます.

プログラミング言語 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 に特化した 変更をおこなわないようにしたソースを(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 コミットによってこのディレクトリ上のファイルを アップグレードしてはいけません. (訳注:ベンダから配布された)新しいバージョンや公式パッチだけが (訳注:このディレクトリに)取り込まれなくてはいけません. GNU cpio 2.4.2 を取り込むためには, 以下のファイルが削除されました: INSTALL cpio.info mkdir.c Makefile.in cpio.texi mkinstalldirs cpio を新しいバージョンにアップデートするためには, 次の作業を おこないます: 1. 空のディレクトリに新しいバージョンを取り出します. [ファイルに「いかなる変更」も加えてはいけません] 2. 上記にリストされたファイルと, FreeBSD には無意味な ファイルを削除します. 3. 次のコマンドを実行します: cvs import -m 'Virgin import of GNU cpio v' \ src/contrib/cpio GNU v 例えば, バージョン 2.4.2 を取り込むためには, 次のように タイプします: cvs import -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 共有ライブラリ

Contributed by &a.asami;, &a.peter;, and &a.obrien;. 9 December 1996.

もしあなたが共有ライブラリをサポートする機能を port に追加した り, 共有ライブラリをサポートしていない他のソフトウェアに追加する 場合には, 共有ライブラリのバージョン番号を次の規則にしたがって つけてください. 一般的には, この規則は, ソフトウェアのリリースバージョンとは 全く関係ありません.

共有ライブラリを作成する三つの重要な規則は次の通りです: 1.0 から始める 過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす 互換性のない変更の場合は, メジャー番号を増やす

例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします. 機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 強制的にメジャー番号を変更します.

メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. FreeBSD のダイナミックリンカは, 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 を優先 して使用します.

移植されていないライブラリに対しては, リリースごとに共有ライブラリの バージョン番号を一度だけ変更するのが私たちのポリシーです. あなたがシステムライブラリのバージョン番号を上げた場合は, Makefile の commit ログを確認してください. 結果としてそのリリースには, 共有ライブラリのバージョン番号が アップデートされた Makefile に入るので、最初にその変更を 確かめるのがソースツリー管理者 ("committer") の責務です. その後のどんな変更も, そのリリースには入りません. diff --git a/ja_JP.EUC/handbook/porting.sgml b/ja_JP.EUC/handbook/porting.sgml index fb8b75b678..73f42bd61e 100644 --- a/ja_JP.EUC/handbook/porting.sgml +++ b/ja_JP.EUC/handbook/porting.sgml @@ -1,1728 +1,1728 @@ - + - + フリーソフトウェアの移植

原作: &a.jkh;, &a.gpalmer;, &a.asami;, &a.obrien;. 28 August 1996.

訳: &a.simokawa;, &a.asami;. 10 November 1996.

フリーで手に入るソフトウェアを移植することは, 何かをゼロから自分で 作ることほどは人に感謝されないにしても, どこに手を入れれば動くのかわから ないような人でも使えるようにするという意味で, FreeBSDの発展のためにとて も重要なことです. 移植されたすべてのソフトウェアは「Portsコレク ション」(the Ports Collection) と呼ばれ, 階層的に分類されて集められ ています. これによって, 新しいユーザでも, 何がすぐに簡単にコンパイルで きる状態で手に入るのか, についての概要をつかむことができます. また, 移 植されるソースコードについては, そのほとんどを実際には含まず, FreeBSD で動かすためのほんのちょっとの差分ファイルといくつかの定義ファイルだけ をソースツリーに入れることで, かなりのディスクスペースが節約できます.

これから, FreeBSD 3.x用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は /usr/share/mk/bsd.port.mkというファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらの ファイルを参照してください. これにはコメントが細かく書いてありますので, Makefile を読むのにあまり慣れていない人でも, 得るものはとても大きいで しょう. 移植を始める前に

注意: ここでは, 変更可能な変数の一部についてのみ記述してい ます. ほとんどの変数はbsd.port.mkの始めに記述があり ます. また, このファイルは非標準のタブの設定になっていま す. Emacs や Vim はファイルのロード時にこれ を認識しますが, viやexでは, ファイルをロード したら `:set tabstop=4'のようにして正しい値を設定する ことができます.

Portの過程で, 修正や, どのバージョンのUNIXで動くかによる条件 つきコンパイルなどが必要なコードに出会うかもしれません. その ような条件つきコンパイルなどのための変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD などの他のBSDシステムへの移植が可能な ように, できるだけ普遍的な変更をおこなうことを心がけてください.

4.3BSD/Reno (1990) およびそれより新しいBSD版を古いバージョン と区別するには `BSD' マクロを利用するのがよいでしょう. これは <sys/param.h> で定義されています. このファ イルがすでにインクルードされていればよいのですが, もしそうでな い場合には以下のコードを, その.c ファイルの適当な場所 に加えてください. #ifdef (defined(__unix__) || defined(unix)) && !defined(USG) #include #endif

これらのシンボルが定義されているすべてのシステムには sys/param.h があるはずです. もし, そうでないシステムを発見した ら我々にも教えてください. &a.ports; までメールを送ってください.

あるいは, GNU の Autoconf のスタイルを使用することもできます, #ifdef HAVE_SYS_PARAM_H #include #endif この方法を使用するときには, Makefile 中のCFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてく ださい. いったん<sys/param.h>がインクルードされると, #if (defined(BSD) && (BSD >= 199103)) このようにしてそのコードが4.3 Net2コードベース, または それより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルさ れているかどうかを検出するために使用します. 4.4BSD-Lite2 コードベースでは, BSD マクロの値は 199506 になっ ています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされた バージョンとを区別するのに使用するべきものではありません. この目的のためには, __FreeBSD__ マクロをかわりに使用してくださ い.

以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されてい ます. 変更がFreeBSDだけに適用されるとき以外は使用しないでく ださい. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSDの流儀です. FreeBSD 2.xでは__FreeBSD__が2と定義されていま す. それ以前の版では1になっています. その後の版では, そのメジャー番号に合うように上がっていきます. もし, FreeBSD 1.x システムと FreeBSD 2.x あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であ れば (`ld' を使うときのシェアードライブラリ用のな オプションなど), __FreeBSD__を使い `#if __FreeBSD__ > 1' のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif __FreeBSD_version の値は以下の通りです: 2.0-RELEASE: 199411 2.1-current's: 199501, 199503 2.0.5-RELEASE: 199504 2.2-current (2.1以前): 199508 2.1.0-RELEASE: 199511 2.2-current (2.1.5以前): 199512 2.1.5-RELEASE: 199607 2.2-current (2.1.6以前): 199608 2.1.6-RELEASE: 199612 2.1.7-RELEASE: 199612 2.2-RELEASE: 220000 2.2.1-RELEASE: 220000 (2.2-RELEASE と同じです) 2.2-STABLE (2.2.1-RELEASE 以後): 220000 (これも同じです) 2.2-STABLE (texinfo-3.9 以後): 221001 2.2-STABLE (top 導入以後): 221002 2.2.2-RELEASE: 222000 2.2-STABLE (2.2.2-RELEASE 以後): 222001 3.0-current (1997年5月現在): 300000 見ての通り, これは年・月というフォーマットになっていましたが, バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う ように変更になりました. 並行していくつかのブランチ(枝分かれし たバージョン)を開発する場合には, リーリスされた日付でそれらの リリースを分類することが不可能だからです. (あなたが今 port を作成するときに, 古い -current 達について心配 する必要はありません. これは参考のために挙げられているにすぎま せん.)

これまで, 何百ものportが作られてきましたが, __FreeBSD__が正しく使われたのは, 1つか2つの場合だけで しょう. 以前のportが誤った場所でそのマクロが使っているからと いって, それをまねする理由はありません. 3分porting

この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う.

まず, 元のtarファイルを${DISTDIR}に置きます. デフォルトは/usr/ports/distfilesです.

注: 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. Makefileの作成

最小限のMakefileは次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG USE_IMAKE= yes .include

おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, の節をご覧ください. Package記述ファイルの作成

どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それにPLISTです. COMMENT

これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen DESCR

これは, そのソフトウェアについての, すこし長い説明を記述しま す. そのportが何をするのかについての数段落程度の簡潔な解説があれば 十分です. 注: このファイルはマニュアルでもなければ, 使用方 法やコンパイル方法についての細かい説明書でもありません. 特 に, READMEファイルを何も考えずにここにコピー するようなことはしないでください. (もちろん, READMEが そのソフトウェアの簡潔な説明になっている場合は別ですが.)

このファイルの最後にあなたの名前を書くことが推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) - Satoshi asami@cs.berkeley.edu PLIST

このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は /usr/local か /usr/X11R6) からの 相対パスです. また, マニュアルは圧縮されているものとします.

簡単な例を載せておきましょう: bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm

'Packing list'の詳細については, pkg_create(1)の マニュアルを参照してください. チェックサムファイルの作成

ただ, `make makesum' と入力するだけです. bsd.port.mkにルールがあるので, 自動的にfiles/md5が 生成されます. Portのテスト

そのportが正しく動くことを, package化を含めて確認してく ださい. まず, `make install', `make package' を試してください. また, `pkg_delete <pkgname>' をして,すべてのファイルとディレクトリ が正しく消去されているかどうかを確認してください. それから, `pkg_add <pkgname>.tgz' をおこない, すべての ファイルが再び現れ, 正しく動作することを確認してください. そ して再度 `pkg_delete <pkgname>' を実行してか ら, `make reinstall; make package' を実行して, packing list にあなたの作ったportがインストールする以外のファ イルが含まれていないことを確認してください. Portの送付

さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. そのた めには, 必要なファイル (この節で述べたすべてのファイル -- た だし, オリジナルのソースファイル, `work' サブディレ クトリ, およびpackageは含みません) をまとめて .tar.gz ファイルにし, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ へ置き, send-pr(1) を使って私たちのところにメールを送っ てください (categoryは `ports', classは `change-request' を 使ってください). 私たちは, 何か不明な点があったらあなたに確 認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの `Additional FreeBSD contributors' のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport

残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細

まず, あなたがportのディレクトリで `make' とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mkも開いておくとよいかもしれません.

しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetchというターゲットが実行されます. このfetchターゲッ トはローカルディスクの${DISTDIR}に配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルを${DISTDIR}に見つけることができなけ れば, Makefileに指定されているURL ${MASTER_SITES}, そして私たちのFTPサイトで ある (ここ には, 私たちが取ってきたファイルをバックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに直接接続されている場合には, ${FETCH} を使って, その名前のファイルを取っ てきて, ${DISTDIR}に保存します. 次に実行されるのはextractターゲットです. これは, ${DISTDIR}にある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリ${WRKDIR} (デフォルトは work) に展開します. 次に, patchというターゲットが実行されます. まず, ${PATCHFILES}に定義されている, すべてのパッ チをあてます. 次にもし${PATCHDIR} (デフォ ルトはpatches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットはconfigureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, ${HAS_CONFIGURE} あるいは ${GNU_CONFIGURE} がセットされていれば, ${WRKSRC}/configure が実行されます. もし, ${USE_IMAKE} がセットされていれば, ${XMKMF} (デフォルト: `xmkmf -a') が実行されます. 最後に, buildというターゲットが実行されます. これは, そのport の専用の作業ディレクトリ (${WRKSRC}) にい き, コンパイルするのが役目です. もし ${USE_GMAKE} がセットされていれば, GNU makeが使用されます. さもなければFreeBSDの makeが使用されます.

上記はデフォルトのルールです. さらに, `pre-<何とか >や `post-<何とか>' というターゲット が定義してあったり, そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それ らはデフォルトの動作の前後に実行されます.

たとえば, post-extractというターゲットがMakefile で定義されていて, pre-buildというファイルが, scriptsサブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-buildスクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefileのターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に理解しやす いからです.

デフォルトの動作はbsd.port.mk の `do-<何とか>' というターゲットでおこなわれます. たとえば, portを展開するコマンドは, `do-extract' というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, `do-<something>' というターゲッ トを再定義することによって, どのようにでも直すことができます.

「メイン」のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください.

これで, ユーザが `make' と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手

オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 (<foo>.tar.gzあるいは <foo>.tar.Z) で入手して, それを ${DISTDIR} にコピーします. 可能なかぎり, 広 く使われている主流のソースを使用するようにしてください.

もし, ネットワークへの接続のよいFTP/HTTPサイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 最後の手段として, 私たち 自身で, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/LOCAL_PORTS/ に置くことができます. この場所は, 変数 ${MASTER_SITE_LOCAL} を使って参照してください. これについての問い合わせのメールは &a.ports へお願いします.

もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, ${DISTDIR} に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のをご覧ください). Portの修正

適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルでおこなえるようになっ ていないといけません.

もし, あなたのportのコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wallの模範的な Configureスクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ「プラグ & プレ イ」の状態でmakeできることをめざしています.

注意: あなたが作成しFreeBSDのportsに寄付されたパッチファイル, スクリプトおよびその他のファイルは，明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます． パッチをあてる

portの過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, `patch-<xx>' という名前のファイルに入れてくだ さい. <xx>はパッチが適用される順番を示します -- これらは, アルファベット順, つまり `aa' が 最初, つぎに `ab' などとなります. これらのファイル を${PATCHDIR}に置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは ${WRKSRC} (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共に${WRKSRC}/foobar.c を修正する, など.) コンフィグレーション

カスタマイズのために追加したいコマンドがあれば, configureという名前のスクリプトに入れて `scripts' サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいはpost-configure というMakefileのターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い

もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVEの定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とするportのみコンパイルされま す). Makefileの作成

Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックには があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります.

では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース

ソースは${DISTDIR}に, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 ${EXTRACT_CMD}, ${EXTRACT_BEFORE_ARGS}, ${EXTRACT_AFTER_ARGS}, ${EXTRACT_SUFX}, ${DISTFILES}を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, `EXTRACT_SUFX=.tar.Z' とするだけです.)

最悪の場合には, 自分で `do-extract' ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. DISTNAME

${DISTNAME}にはportの名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (${DISTFILES}) は ${DISTNAME}${EXTRACT_SUFX}という名前 になっています. 例えば, `DISTNAME=foozolix-1.0'の場 合, 通常のtarファイルだと, foozolix-1.0.tar.gz のようになります. さらにデフォルトのルールでは, tarファイルは work/${DISTNAME}というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, portが複 数の配布ファイルを必要とするときには, 単に明示的に ${DISTFILES}を設定してください. もし, ${DISTFILES}の一部だけが実際に展開される場合 には, それらを${EXTRACT_ONLY} に設定してくだ さい. この変数が定義されている場合には, 展開時に ${DISTFILES}に優先して利用されます. 残りのファ イルも${DISTDIR}に取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. CATEGORIES (分類)

完成したpackageの実体は/usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packagesのサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が ${CATEGORIES}という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在するカテゴリを見て, そ のportに適したもを選んでください. (などが参考になるでしょう). もしそのportが本当 に現在存在するすべてのものとは異なっている場合には, 新しいカテ ゴリ名を作ることもできます. MASTER_SITES

オリジナルの配布ファイルを指し示すFTPまたはHTTPのURLのディ レクトリ部分までを${MASTER_SITES}に記録しま す. スラッシュ (/) を最後につけることをお忘れなく.

配布ファイルがシステム上に存在しないときに, makeマクロは ${FETCH}でこの変数に指定されたサイトから取っ てきます.

複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています.

オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications

ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブのミラーの中で好みのものを使用することが可能 です. PATCHFILES

もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, ${PATCHFILES}にファ イル名を, ${PATCH_SITES}にサイトとディレクト リの名前を${MASTER_SITES}と同様に設定してく ださい.

そのパッチ内のファイル名ががソースツリーの一番上のディレク トリ (${WKRSRC}) からの相対パスになっていな い場合には, ${PATCH_DIST_STRIP}を指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な `foozolix-1.0/' がついている場合には, `PATCH_DIST_STRIP=-p1'としてください.

これらのパッチは圧縮されていても大丈夫です. ファイル名が `.gz' か `.Z' で終わる場合には自動的に復元 されるようになっています.

もしパッチが, 文書などその他のファイルと一緒にgzipされた tarファイルで配布されている場合には，単純に ${PATCHFILES} を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を ${DISTFILES} と ${MASTER_SITES} に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを ${PATCHDIR} ディレクトリに patch-<xx>という名前でコピーするかして, パッチを適用するようにします．(普通の gzip か compress された tar ファイルであれば，通常のソースファイルと一緒にその時までに 展開されていますので，明示的に展開する必要はありません．) もし，後者の方法を使用する場合には，すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. MAINTAINER

あなたのメールアドレスをここに入れてください. お願いします. :)

保守担当者(maintainer)の責任についての詳細は， の節をご覧ください． 依存関係

このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. LIB_DEPENDS

Portが必要とする非標準の共有ライブラリをこの変数で指定 します. これは `lib:dir' という組のリストで, うち lib が共有ライブラリの名前, そしてdir がそのライブラリが見つからない場合にインストールするport のあるディレクトリです. 例えば, LIB_DEPENDS= jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg と指定してあれば, まずメジャーバージョンが6のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ からインストールしようとします. 前半のlib 部分はそのまま `ldconfig -r | grep' へ引数として渡されることに注意してください. 特 に, ピリオド (.) の前には上記の例のようにバックスラッシュ を連続してつける必要があります. この依存関係はextract ステージのはじめでチェック されます. また, packageを作るときに必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. RUN_DEPENDS

Portを使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは`path:dir' とい う組のリストで, path がファイルまたはプログラムの 名前, そしてdir がそれが見つからない場合に作成する ためのディレクトリ名です. Path の最初の文字がスラッ シュ (/) の場合にはファイルとみなし, その存在を `test -e' でチェックします; そうでない場合にはプ ログラムであると仮定し, `which -s' を使ってそのプ ログラムがユーザのサーチパス上にあるかどうか確認します.

例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish:${PORTSDIR}/x11/tk まず, `/usr/local/etc/innd' というファイルが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, `wish' というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11/tk というサブディレクトリから作られます. (この例で, `innd' は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください.) この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. BUILD_DEPENDS

Portのコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは `path:dir' という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は `unzip' という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは「コンパイル」と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで全部をま とめて面倒を見てくれます. この依存関係はextract ステージからチェックされます. FETCH_DEPENDS

この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは `path:dir' という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, `ncftp2' という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係はfetchステージからチェックされます. DEPENDS

上の四つのいずれにもあてはまらないような依存関係がある場 合, または他のportのソースが展開されている必要がある場合 (インストールされているだけでは不十分な場合) にはこの変数 を使います. これはディレクトリ名のリストです (上の四つと違っ て特に「確認」するものがありませんので). コンパイル時の特別な指定

GNUのmakeを使う場合には, `USE_GMAKE=yes' と指定してください. PortにGNUのconfigureが含まれ ている場合には, `GNU_CONFIGURE=yes' を使います. GNU configureにデフォルトの `--prefix=${PREFIX}' 以外の引数を渡したい場 合には追加部分を${CONFIGURE_ARGS}で指定して ください.

X Window Systemのアプリケーションなど, imakeを 使ってImakefileからMakefileを作成するportの場合には `USE_IMAKE=yes' を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し `-a' フラグが問題をもたらすなら, さらに `XMKMF=xmkmf'としてください.

PortのMakefileが `all' 以外のものをメインのター ゲットとしている場合には, ${ALL_TARGET} でそ れを指定してください. `install' と ${INSTALL_TARGET} も同様です. NO_INSTALL_MANPAGES

あなたのportがimakeは使うものの `install.man' ターゲットを持っていない場合, `NO_INSTALL_MANPAGES=yes' を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) Motifを必要とするport

最近はコンパイルにMotifを必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 無料の互換ライブラリを作ろうとしているグループが少なくと も一つあります.) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的/静的にリンクできるようなしくみが用意されています. REQUIRES_MOTIF

MotifがないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. ${MOTIFLIB}

この変数はbsd.port.mkによってMotifライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motifライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください.

代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが `-lXm' として使われている場合には, かわりに `${MOTIFLIB}' と書いてください. Imakefileの中で `XmClientLibs' が使われている 場合には, それを `${MOTIFLIB} ${XTOOLLIB} ${XLIB}' と書きかえてください.

${MOTIFLIB} は通常 `-L/usr/X11R6/lib -lXm' か `/usr/X11R6/lib/libXm.a' に置き換えら れます. したがって前に `-L' や `-l' をつけ る必要はありません. Info ファイル

新しい版の texinfo(2.2.2-RELEASE およびそれ以降に入っています) には, `&dollar{PREFIX}/info/dir ファイル を更新するようにしてください. (この節は, とても長くてすいません, しかし info ファイルを作りあげるためには, これらは不可欠 です. 正しく行なえば, 美しい リストができますので, 辛抱してください! まず, これを知っておかなければなりません: % install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. (訳注: Info ディレクトリの INO-FILE を DIR-FILE にインストールする) Options: --delete Delete existing entries in INFO-FILE; don't insert any new entries. (訳注: INFO-FILE の中の項目を削除, 新しい項目は一切追加しない.) : --entry=TEXT Insert TEXT as an Info directory entry. (訳注: TEXT を Info ディレクトリの項目として追加する.) : --section=SEC Put this file's entries in section SEC of the directory. (訳注: このファイルの項目を Info ディレクトリの SEC という節に置く.) :

このプログラムは, 実際には info ファイルをこれから, editors/emacsを 使用します. まず, texinfo のソースを見て, --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout :

フォーマットについては見ればわかると思います. 1つのファイルに対して1つの info の項目しか書けないことに注 意してください, これは, `install-info --delete' が, そのバグにより, texinfo のソースにパッチをあてるかわりに, japanese/skk の portのディレクトリに戻って, `make clean; make' をして, info ファイルが texinfo ソースファイルから再び生成さ れることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので, --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@ # Subdirectories to make recursively. `lisp' is not included # because the compiled lisp files are part of the distribution # and you cannot remake them without installing Emacs first. -SUBDIR = lib-src src +SUBDIR = lib-src src man # The makefiles of the directories in $SUBDIR. SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@ ${srcdir}/gnu1.texi \ ${srcdir}/glossary.texi +all: info info: $(INFO_TARGETS) dvi: $(DVI_TARGETS)

/usr/share/info にあるからです. (このパッチはここにはありません.) もし, --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@ if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \ then \ (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \ for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \ (cd $${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ chmod a+r ${infodir}/$$f); \ (これは, 既存のportを修正するときのみ必要です.) pkg/PLIST を見て, info/dir にパッチをあて ようとするものすべてを削除します. これらは, pkg/INSTALL やその他のファイルにもあるかもしれない ので, いろいろさがしてみてください. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2 Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + sed -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include

新しい info ファイルを作成するのに, /usr/share/info/dir と上のコマンド, 以外は使用しな いでください. 実際のところ, もし port する人がこれに関して info/dir を削除する必 要はありません. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc

@unexec install-info --delete' コマンドは, info ファイル自身より先に置き, コマンドがファイルを読めるようにし ておかなければならないことに注意してください. また, `@exec install-info' コマンドは info ファイルおよび テストをして, 出来栄えに感服しましょう ライセンス上の問題

ソフトウェアによっては制限の厳しいライセンスがついてきたり, 法律的に問題があるかもしれません. (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によってさまざまな場合があり ます.

ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSDプロジェクトがFTPまたはCD-ROMで配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください.

よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに「有償再配布を禁ずる」という趣旨のライセン スがついてきた場合にはNO_CDROMという変数をセットして ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数を設定してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または「商用利用を禁ずる」とライセンスに書い てある場合にはRESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません.

注: GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません.

注: もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGALファイルを書き換えるのを忘れないようにし てください. アップグレード

Portのバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトのports-currentというディレクトリにあります) であることを確認してください.

次に, portのMakefileにMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備をしているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません.

保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff をとって送ってください. (例えば, 変更前のディレクトリが `superedit.bak' という名前でとってあり, 変更後のもの が `superedit' に入っているなら, `diff -ruN superedit.bak superedit' の結果を送ってください. ) diff の出力を見て, すべての変更が正しくなされているか確認して ください. 変更箇所については, send-pr (カテゴリーは, `ports')に diff の出力結果を添えて, 私たちに送ってもらうのが一 番よいです. commit する際に CVS に明確に記述しなければならない ので, 付け加えたり削除したりしたファイルがあったら, それについ て書いておいてください. やっていいことといけないこと

この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. WRKDIR

大事なファイルをworkサブディレクトリに置き忘れな いようにしてください. うっかり `make clean' とやっ たらこのディレクトリはその下のファイルとともにあとかたも なく消え去ってしまいます! スクリプトやパッチ以外に必要 なファイルがある場合には, ${FILESDIR}という サブディレクトリ(デフォルトでは, files)に入れ, post-extractターゲットでworkサブディレクト リにコピーするようにしてください. Package情報

Package情報, すなわちpkgディレクトリ内の COMMENT, DESCR, PLIST は必ず用意してください. これらはpackageを作る以 外にもいろいろ使われていますので, ${NO_PACKAGE}が指定してあってpackageを作 るのが禁止してあるportの場合でも常に必要です. マニュアルの圧縮, バイナリのstrip

マニュアルは圧縮し, バイナリはstripしてください. オリジナル のソースがバイナリを stripしてくれる場合は良いですが, そうでない場合には post-installターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になりま す: post-install: strip ${PREFIX}/bin/xdl

インストールされた実行形式がすでにstripされているかどうか はfileコマンドで確認できます. これが`not stripped' と言わなければ, stripされているということです.

MAN[1-9LN] 変数を使用すると, マニュアルの圧縮を自動的に行う ことができます. この方法を使うと, ユーザが /etc/make.conf中でNOMANCOMPRESSを設定し, マニュアルの圧縮を無効にしているかどうかを確認できます. これらの変数の指定は, MAINTAINER の指定の後 のセクションの一番最後で行ってください. こんな風に指定します: MAN1= foo.1 bar.1 MAN5= foo.conf.5 MAN8= baz.8

なお, 普通 Imake を使ってコンパイルされる X アプリケーショ ンの場合はこの指定は必要ありません.

PREFIX以外のディレクトリの下にマニュアルを置く ようなportではMANPREFIXを指定することが できます. さらに, 特定のセクションのマニュアルだけ, 標準では ない場所にインストールする場合(例えば多くの Perl のモ ジュールの ports の場合)には, 個々のマニュアルのパスを MANsectPREFIX (sectは, 1 から 9 または, L か N を表わします) によって指定できます. INSTALL_* マクロ

あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです． ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです． ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです． ${INSTALL_MAN} はマニュアルとその他のドキュメ ントをインストールするコマンドです．(圧縮はしません)

これらは基本的にinstallコマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. INSTALL package スクリプト

バイナリパッケージが pkg_add でインストールされるときに, 実行 される必要があるコマンドがあれば, pkg/INSTALL スクリプトを使っ て実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは `INSTALL ${PKGNAME} PRE-INSTALL' と実行され, 2度目 には, '`INSTALL ${PKGNAME} POST-INSTALL' と実行され ます. どちらのモードで実行されているかは, `$2' を調べることによってわかります. 環境変数 `PKG_PREFIX' には package がインストールさ れる directory が設定されます. 詳細は man pkg_add(1) を見てください. 注意すべきことは, port を `make install' で インストールするときには, このスクリプトは自動的に実行されな いということです. もし, 実行される必要があるならば, port の Makefile で明示的に呼ぶ必要があります. REQ package スクリプト

port が(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要があると きには, 「要件(requirements)」スクリプト pkg/REQ を作ること ができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべ きかを決定します. 詳細は, man pkg_create(1) と man pkg_add(1) を見てください. 付加的ドキュメント

普通のマニュアルやinfoファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, ${PREFIX}/share/docの下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう.

まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は${PKGNAME}からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想されるportの場合 には, ${PKGNAME}をそのまま使ってかまいません.

ユーザが/etc/make.confでこの部分を禁止するために NOPORTDOCSという変数をセットしている場合には， これらのドキュメントがインストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR} -p ${PREFIX}/share/doc/xv ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif

これらのファイルをpkg/PLISTに入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCSについては気にしないでください.)

(Packageの)インストールを行っているユーザに対してメッセージ を表示したい場合には, そのメッセージを pkg/MESSAGE に置くこともできます. この機能は, pkg_add したあとの 追加のインストール手順や, ライセンス情報を表示するのに便利で す. (注意: MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. DIST_SUBDIR

/usr/ports/distfilesディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (`Makefile' など) がある場合には, ${DIST_SUBDIR}にportの名前 (${PKGNAME}からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, ${DISTDIR}がデフォルトの /usr/ports/distfilesから /usr/ports/distfiles/${DIST_SUBDIR}に変更さ れ, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります.

また, ファイルを取ってくるときにバックアップサイトとして使わ れるftp.freebsd.orgのディレクトリ名にもこの変数の 値が使われます. (${DISTDIR}を明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず ${DIST_SUBDIR}を使うようにしてください.)

この変数はMakefile中で明示的に指定された ${MASTER_SITES}には影響しないことに注意して ください. フィードバック

Portを作るためにソフトウェアに変更を加えたら, なるべく原 作者にその旨を伝えてパッチ等を送ってください. これらが次のリ リースに取り入れられれば, アップグレードが楽になります. RCS文字列

RCSが特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 (`$') で囲まれており, `$Id' や `$RCS' などで始まり ます. パッチ作成上の注意

diffの再帰 (`-r') フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が 入っている場合などです. また, ファイルをまるごと消す場合には パッチを使わずにpost-extractターゲットで消す方が簡 単です. できあがった差分に満足したら, それらをソースのfileご とに別々のパッチファイルに分割してください. PREFIX

なるべくportは${PREFIX}に対する相対パス にインストールすることができるように心がけてください. この変数の値は${USE_IMAKE}か ${USE_X11}が指定してある時には ${X11BASE} (デフォルト/usr/X11R6), そうでない場合には${LOCALBASE} (デフォルト/usr/local) にセットされます.

サイトによってフリーソフトウェアがインストールされる場所が 違いますので, ソース内で `/usr/local' や `/usr/X11R6' を明示的に書かないようにしてくださ い. Xのプログラムでimakeを使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで `/usr/local' (imakeを使わないXのプログラ ムは `/usr/X11R6') と書いてあるところを `${PREFIX}' に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます.

変数${PREFIX}の値はportのMakefileやユー ザの環境で変更することもできます. しかし, 個々のportが Makefileでこの変数の値を明示的に設定することはなるべくしない でください. (X のプログラムでimakeを使用しないport の場合は, USE_X11=yesとしてください; これは PREFIX=/usr/X11R6とするのとはかなり違います.)

また, 他のportからインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, lessのフルパスをPAGERというマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\"と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使う portの時は -DPAGER=\"${LOCALBASE}/bin/less\") を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成

インストール時には${PREFIX}の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを `lib'というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. `etc' にセッ トアップ/コンフィグレーションファイル, `libexec' に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), `sbin' に管理者用のコマンド, `info' に GNU Info 用のドキュメント, そして `share' にアーキテクチャに依存しないファイルが入り ます. 詳細については man hier(7) を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. USENET ニュースを 扱う ports は例外です. これらは, ファイルのインストール先として ${PREFIX}/news を使用します. ldconfig

共有ライブラリをインストールするときには, 共有ライブラリのキャッ シュを更新するためにportのMakefileのpost-install target から`/sbin/ldconfig -m' を走らせてください. このコマンドの引数は共有ライブラリのインストールしてあるディ レクトリ (通常 ${PREFIX}/lib) です.

また, pkg/PLISTに@exec行を入れ, package をインストールした場合にも共有ライブラリがすぐ使えるように してください. この行は共有ライブラリを指定する行のすぐ後に書 くのがいいでしょう: lib/libtcl80.so.1.0 @exec /sbin/ldconfig -m %D/lib

絶対に引数なしでただ `ldconfig'とだけ書い てある行をMakefileやpkg/PLISTファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/libの内容のみとなり, ユーザのマシンにさまざま な問題をもたらします (「ぎゃぁ! このportをインストールした らxinitが使えなくなっちゃった!」). この掟を破った者は, 永久 に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. UID

もしあなたの portがインストールされるシステム上に特定のユー ザIDを必要とする場合は, pkg/INSTALL スクリプトから pwコマンドを実行して自動的にそのユーザを追加するよ うにしてください. japanese/Wnn や net/cvsup-mirror の portが参考になるでしょう. この ような場合には2桁の後半 (つまり50前後から 99まで) の数字を UIDとして利用するのが一般的です.

既にシステムや他の portで利用されている UIDを使わないように 十分注意してください. 現在の 50から 99までの間の UIDは以下の とおりです. majordom:*:54:1024:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:248:the cyrus mail server:/nonexistent:/nonexistent uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner:/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent pgsql:*:71:246:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh msql:*:80:249:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh

このリストを最新の状態に保つためにもこの範囲の UIDを利用する portを作った場合には, &a.ports; までご連絡ください. 困ったら....

私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;)

それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) Makefileのお手本

これはportのMakefileを作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください.

変数の順番, 段落の間の空行など, Makefileを作るときはなるべくこ の形式にしたがってください. 既存のportのMakefileがすべてこの形 式にしたがっているわけではありませんが, 今後はなるべく統一していき たいと考えています. この形式は重要な情報が簡単に見つけられるよ うに設計されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] [この Makefile の最初の版が作成された日付です] # Date created: 26 May 1995 [このソフトウェアを最初に FreeBSD に port した人の名前, つまり, この Makefile の最初の版を書いた人です. 今後この port をアップグレー ドするとき, このヘッダは変えるべきではありません.] # Whom: Satoshi Asami # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [MASTER_SITE_* マクロを使用しない場合は, 最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい ない場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include Packageの名前

Packageの名前は以下のルールにしたがってつけてください. こ れはpackageのディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのではという心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.)

Packageの名前は以下のようにしてください. [<言語>-]<名前>[[-]<オプション>]-<バージョン.番号>; ${DISTNAME} が上記の形式になっていない場合に は, ${PKGNAME} をそのようにしてください. FreeBSDはユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には `<言語>' に ISO-639 で定義されている言語名の略称を入れ てください. 例えば, 日本語なら `ja', ロシア語なら `ru', ベト ナム語なら `vi', 中国語なら `zh', 韓国語ならば `ko', ドイツ 語なら `de', といった具合です. `<名前>' の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (`kinput2' など). コンパイル時に環境変数やmakeの引数などでいくつ か別のオプションをつけてコンパイルできる場合, `<compiled.specifics>' にそのオプションを入れてくださ い (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する `pl' で, それ 以外にバージョン番号がまったくついていない場合にのみ使うことがで きます.

では, ${DISTNAME}を正しい ${PKGNAME}に直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2 mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.02 xmris-4.02 同上 rdist-1.3alpha rdist-1.3a `alpha'のような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 `pl' が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 jp-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage

オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として `1.0' を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 (`年. 月.日') を使うなどしてください. やっとおしまい!

いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _)

さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.EUC/handbook/stable.sgml b/ja_JP.EUC/handbook/stable.sgml index 5c72157f91..76c3e0cc9f 100644 --- a/ja_JP.EUC/handbook/stable.sgml +++ b/ja_JP.EUC/handbook/stable.sgml @@ -1,108 +1,108 @@ - + - + FreeBSD の安定状態の持続

原作: &a.jkh;.

訳: &a.iwasaki;. FreeBSD-stable ってなに?

FreeBSD-stable は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更 はこの支流には取り入れられません ( 参照). 誰が FreeBSD-stable を必要としているの?

もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安 定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stableの支流は前のリリースに関して効果的にバグフィッ クスされた流れであるため, 最新のリリース ( 執筆時点) をインストールしているのであれば, 特に そうです.

stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィック スに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでした ら, 私たちにすぐに教えてください (次の節参照). FreeBSD-stable を使う

&a.stable へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更 を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会をユーザに与えます. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable オプションとして本文に `help' と書けば, Majordomo は私たちがサポー トする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘ ルプを送付します. ftp.FreeBSD.ORG からのソースの入手. 以下の 3つの方法で おこなうことができます : 機能を使用する. 転送レートが 安定している TCP/IP 接続でない場合は, この方法が適して います. を を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2番目に推奨される方法で す. 多くの人が cron から cvsup を実行し, 自動的にソースコー ドを最新の状態に保っています. ftp を使用する. FreeBSD-stable 用のソースツリーは 常に次のところで「公開」されています :

私たちはまた, tar/compress でツリー全体を入手できる `wu-ftpd' を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体を compress された tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として 最初に `make world' を実行するべきでしょう. &a.stable を読めば, 次 のリリースに移行するに当たって時々必要となる既存システムからの新シ ステムの構築手順についての最新情報が得られるでしょう.