訳: Mitsuru IWASAKI、 1997 年 11 月 8 日
13.1. | SNAP とか RELEASE とかは何? |
現在、FreeBSD の CVS リポジトリ には、三つのアクティブ/準アクティブなブランチがあります (アクティブな開発ブランチは三つしか存在しないため、 おそらく RELENG_2 ブランチの変更は年に 2 回だけになるでしょう)。
HEAD
は他の二つと違って、
実際のブランチタグではなく、
「current、
分岐していない開発本流」のための単なるシンボリックな定数です。
私たちはこれを
現在、
「-CURRENT」 は 5.0 の開発本流であり、
| |
13.2. | 自分用のカスタムリリースを構築するには? |
リリースを構築するには三つのことが必要です。まず、 vn(4) ドライバが組み込まれたカーネルを実行させている必要があります。 以下をカーネルコンフィグレーションファイルに追加し、 カーネルを作り直してください。 pseudo-device vn #Vnode driver (turns a file into a device) 次に、CVS リポジトリ全体を手元においておく必要があります。 これを入手するには CVSUP が使用できますが、supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります。 *default prefix=/home/ncvs
*default base=/a
*default host=cvsup.FreeBSD.org
*default release=cvs
*default delete compress use-rel-suffix
## Main Source Tree
src-all
src-eBones
src-secure
# Other stuff
ports-all
www
doc-all
そして
最後に、ビルド用にかなりの空き領域を用意する必要があります。
そのディレクトリを # setenv CVSROOT /home/ncvs
# or export CVSROOT=/home/ncvs
# cd /usr/src
# make buildworld
# cd /usr/src/release
# make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
注記:ただし、すでに
処理が終了すると、
リリース全体が | |
13.3. | カスタムのインストールディスクを作るにはどうすればいいのですか? |
| |
13.4. | 「make world」 を行なうと既存のバイナリを上書きしてしまうのですが。 |
ええ、それが一般的な考え方です。名前が示しているように 「make world」 はすべてのシステムのバイナリを最初から作り直しますので、結果として、 クリーンで一貫性のある環境を得ることができます (これがそれだけ長い時間がかかる理由です)。
環境変数 | |
13.5. | システム起動時に
「( |
Adaptec の 1542 SCSI ホストアダプタは、 ユーザがソフトウェア的にバスアクセス速度の設定を行なうことができます。 以前のバージョンの 1542 ドライバは、 使用可能な最大の速度を求めてアダプタをその設定にしようとしました。 これは特定のユーザのシステムでは問題がある事がわかり、 現在ではカーネルコンフィグオプションに 「TUNE_1542」 が加えられています。 これを使用すると、これが働くシステムではディスクが速くなりますが、 データの衝突が起きて速くはならないシステムもあるでしょう | |
13.6. | インターネットアクセスに制限があっても current を追いかけられますか? |
はい、 CTM システムを使って、 ソースツリー全体のダウンロードを行なわずに追いかけることができます。 | |
13.7. | どのようにして配布ファイルを 240KB に分割しているのですか? |
比較的新しい BSD ベースのシステムでは、
以下は bin-tarball:
(cd ${DISTDIR}; \
tar cf - . \
gzip --no-name -9 -c | \
split -b 240640 - \
${RELEASEDIR}/tarballs/bindist/bin_tgz.) | |
13.8. | 私はカーネルに拡張を行ないました。 誰に送ればいいですか? |
FreeBSD ハンドブックの「FreeBSD への貢献」を参照してください。 あなたのアイディアに感謝します! | |
13.9. | PnP ISA カードの検出と初期化はどのように行なうのですか? |
Frank Durda IV 氏 より:
| |
13.10. | FreeBSD は、他のアーキテクチャをサポートしないんですか? |
いくつかのグループの人々が、FreeBSD
の他のアーキテクチャへの移植に関心を示しており、
FreeBSD/AXP (ALPHA) はこれらの成果としてはとても成功したものの一つです。
FreeBSD/AXP は現在
ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha
から入手できます。
ALPHA への移植版が現在動く機種は増えつつあり、
その中には AlphaStation、AXPpci、PC164、Miata そして Multia
といったモデルが含まれています。
現状についての情報を得るには
その他に FreeBSD の SPARC アーキテクチャへの移植があります。
プロジェクトへの参加に興味がある方は
| |
13.11. | デバイスドライバを開発したので、メジャー番号が欲しいのですが。 |
これは、開発したドライバを公開するかどうかに依存します。
公開するのであれば、ドライバのソースコード、
| |
13.12. | 代替のディレクトリ配置ポリシー |
現在使われているディレクトリの配置ポリシーは、 私が 1983 年に書いたものから全く変更されていません。 私は当初の配置ポリシーを、オリジナルの fast filesystem のために書き、 まったく改定していません。 このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいきましたが、 お気づきの方もいる通り find の動作には不適切です。 ほとんどのファイルシステムの内容は、 深さ優先検索 (ftw とも呼ばれます) によって作られたアーカイブから、 抽出 (restore) して作成されます。この際、 ディレクトリは、シリンダグループにまたがって配置され、 以降の深さ優先検索を行うには、 考え得る限り最悪の状態になります。 もし作成するディレクトリの総数がわかっていれば、 解決方法はあります。(総数/シリンダグループ数) 個のディレクトリを、 シリンダグループごとにまとめて作成すれば良いのです。 もちろん最適なディレクトリ配置になるように、 総数を予測する方法を考えなければなりません。 しかし仮にシリンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定してしまったとしても、 大幅な改善が望めるでしょう。 このポリシーを用いるべきリストア作業を、通常の作業 (おそらく既存のポリシーを使用したほうが良いでしょう) を区別するには、 10 秒間の間に作成されたディレクトリを最大 10 個までまとめて単一のシリンダグループに書き込むという手順が使えるでしょう。 とにかく私の結論は、そろそろ実験を始めて見る時期だろうということです。 | |
13.13. | カーネルパニックを最大限に利用する |
注記:この節は、freebsd-current メーリングリストに Bill Paul 氏が投稿したメールを、 Dag-Erling C. Smørgrav 氏が校正し、[] 内のコメントを追加して引用したものです。 From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Subject: Re: the fs fun never stops
To: ben@rosengart.com
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
Cc: current@FreeBSD.ORG [<ben@rosengart.com> が以下のパニックメッセージを投稿しました。] > Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x40
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xf014a7e5
^^^^^^^^^^
> stack pointer = 0x10:0xf4ed6f24
> frame pointer = 0x10:0xf4ed6f28
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 80 (mount)
> interrupt mask =
> trap number = 12
> panic: page fault このようなメッセージが表示された場合、問題が起きる状況を確認して、 情報を送るだけでは十分ではありません。 下線をつけた命令ポインタ値は重要な値ですが、 残念ながらこの値は構成に依存します。つまり、 この値は使っているカーネルのイメージに依存するのです。 もしスナップショットなどの GENERIC カーネルを使っているのであれば、 他の人間が問題のある関数について追試をすることができますが、 カスタマイズされたカーネルの場合は、 使っている本人にしか問題の起こった場所は特定できないのです。 何をすれば良いのでしょう?
このようなパニックメッセージを投稿している人はよく見掛けますが、 このように、命令ポインタ値を、 カーネルシンボルテーブルの中の関数とつき合わせて調べている人はまれです。 パニックの原因を突き止める最良の方法は、クラッシュダンプをとり、 gdb(1) でスタックトレースを行うことです。 どっちにしろ、私は普通以下のようにします。
make(1) プロセスは2つのカーネル、
確実にクラッシュダンプをとるには、 注記:FreeBSD のクラッシュダンプのサイズは、
ふつう物理メモリサイズと同じです。
つまり 64MB のメモリを積んでいれば、
64MB のクラッシュダンプが生成されることになります。
クラッシュダンプを取り出せたら、 以下のように gdb(1) を使ってスタックトレースをとります。 % gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
(gdb) where 必要な情報が 1 画面に収まらないことも多いので、できれば script(1) を使って出力を記録します。 strip していないカーネルイメージを使うことで、 すべてのデバッグシンボルが参照でき、 パニックの発生したカーネルのソースコードの行が表示されているはずです。 通常、正確なクラッシュへの過程を追跡するには、 出力を最後の行から逆方向に読まなければなりません。 また gdb(1) を使って、 変数や構造体の内容を表示させ、 クラッシュした時のシステムの状態を調べられます。 もしあなたがデバッグ狂で、同時に別のコンピュータを利用できる環境にあれば、 gdb(1) をリモートデバッグに使うこともできます。 リモートデバッグを使うと、あるコンピュータ上の gdb(1) を使って、 別のコンピュータのカーネルをデバッグできます。 ブレークポイントの設定、カーネルコードのステップ実行など、 ふつうのプログラムのデバッグと変わりません。 コンピュータを 2 台並べてデバッグするチャンスにはなかなか恵まれないので、 私はまだリモートデバッグを試したことはありません。 Bill による追記:
DDB を有効にしていてカーネルがデバッガに
落ちたら、ddb のプロンプトで " | |
13.14. |
|
ELF のツール類は、
デフォルトでは実行形式の中に定義されているシンボルを、
ダイナミックリンカから見えるようにはしません。
このため、
もし、あなたがプロセスの中心にあたる実行形式の中にあるシンボルを探索したければ、
ELF リンカ (ld(1)) に
| |
13.15. | カーネルアドレス空間を大きくしたり、 小さくするにはどうしたら良いのですか? |
カーネルアドレス空間は、FreeBSD 3.X 上で 256MB、FreeBSD 4.X 上で 1GB がデフォルトになっています。 負荷の高いネットワークサーバ (たとえば大きな FTP、HTTP サーバ) を運用する場合は、256MB では足りないことに気付くかも知れません。 では、アドレス空間を大きくするにはどうしたら良いのでしょうか? それには、二つの段階を踏みます。まず、 より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります。 次に、カーネルはアドレス空間の先頭にロードされるため、 アドレスの先頭が天井 (訳注:カーネルアドレス空間の最下端アドレスのこと) と ぶつかることのないように、ロードアドレスを今までより低位に設定する必要があります。
最初の段階は、 #ifndef NKPDE
#ifdef SMP
#define NKPDE 254 /* addressable number of page tables/pde's */
#else
#define NKPDE 255 /* addressable number of page tables/pde's */
#endif /* SMP */
#endif
正確な
次の段階を行なうには、ロードアドレスを正確に計算することが必要です。
単純に、アドレス空間の大きさ
(バイト単位) を 0x100100000 から引き算してください。
1GB アドレス空間の場合、その結果は 0xc0100000 になります。
そして、 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(btext)
SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0xc0100000 + SIZEOF_HEADERS;
.interp : { *(.interp) }
それが完了したら、 注記:カーネルアドレス空間の大きさは、4MB の倍数である必要があります。 David Greenman 氏による補足:カーネルアドレス空間は 2 の乗数である必要があると思いますが、 それが確かなことかどうかははっきりしていません。 昔の起動コードには、良く高位アドレスビットのトリックが使われていたため、 少なくとも 256MB の粒度であることが想定されていたと思います。 |
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、
ドキュメント を読んだ上で
<questions@FreeBSD.org> まで (英語で) 連絡してください。
本文書に関する質問については、
<doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。