os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/ja/FAQ/misc.sgml
Motoyuki Konno 9b1b0ab67d Merge the following changes in the English version: 
hardware.sgml : 1.13 -> 1.15
    misc.sgml     : 1.8  -> 1.10
    serial.sgml   : 1.2  -> 1.4
    x.sgml        : 1.5  -> 1.6
1999-02-04 17:17:17 +00:00

332 lines
16 KiB
Text
Raw Blame History

<!-- $Id: misc.sgml,v 1.10 1999-02-04 17:17:16 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.10 -->
<sect>
<heading>その他の質問<label id="misc"></heading>
<p><em>訳: &a.yoshiaki;.<newline>10 November 1997.</em>
<sect1>
<heading>
FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか?
</heading>
<p>そうではありません. 本当は「なぜスワップが全部使われてる
ように見えるのか」と聞きたいのでしょう. そういうことであれば,
その理由は, 実行プログラムのクリーンな (無変更の) ブロックを,
終了後すぐに捨ててしまわずにスワップ領域に残しておけば,
そのプログラムが再実行される際にファイルシステムから読み直すよりも
迅速に実行することができるからです.
<p>メモリ中に同時に保持する事のできるダーティページの実際の量は
減少しません. クリーンなページが必要に応じて置き換えられます.
<sect1>
<heading>
FreeBSD の実行フォーマットの a.out はどのようなものですか, a.out を使う理由, ELFを使う理由は何でしょう?
</heading>
<p>FreeBSD の <tt>a.out</tt>フォーマットを理解するためには,
まず UNIXにおいて現在 「優勢」な 3種類の実行フォーマットについて
いくらか知っておく必要があります:
<itemize>
<item><htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
name="a.out">
<p>最も古く 「由緒正しい」 unix オブジェクトフォーマットです.
マジックナンバを含む短くてコンパクトなヘッダが先頭にあり,
これがフォーマットの特徴とされています (参照
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
name="a.out(5)">
より詳細な内容があります). ロードされる 3種類のセグメント:
.text, .data, .bss と加えてシンボルテーブルと文字列テーブルを
含みます.
<item><bf>COFF</bf>
<p>SVR3 のオブジェクトフォーマットです. ヘッダは単一の
セクションテーブルから成り, .text, .data, .bss セクション以外
の部分を持つことができます. </item>
<item><bf>ELF</bf>
<p> <tt/COFF/の後継です. 複数のセクションをサポートし, 32-bit
と 64-bitのいずれの値も可能です. 大きな欠点の一つは, <tt/ELF/
はそれぞれのシステムアーキテクチャ毎に単一の ABI のみが存在する
という仮定で設計されていることです. この仮定はまったく
正しくありません. 商用の SYSV の世界でさえそうです
(少なくとも SVR4, Solaris, SCO の 3種類の ABI があります).
<p>FreeBSD はこの問題を解決するための試みとして, 既知の <tt/ELF/
実行ファイルに ABI に応じた情報を <em>書き加える</em>
ユーティリティを提供しています.
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?brandelf"
name="brandelf"> のマニュアルページ
を参照してください. より多くの情報があります.
</itemize>
<p>FreeBSD は伝統的な立場をとり, 数多くの世代の BSD のリリース
で試され, 実証されてきた
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
name="a.out">フォーマットを伝統的に使用しています.
いつかは FreeBSDシステムでネイティブ <tt/ELF/ バイナリを作り,
実行することができるようになるかもしれませんが, 初期の頃 FreeBSD
では <tt/ELF/ をデフォルトのフォーマットに変更するという動きは
ありませんでした. なぜでしょうか? ところで Linux においては,
<tt/ELF/ への苦痛をともなった変更は, その時に <tt/a.out/
実行フォーマットから逃れたというよりは, ジャンプテーブルベース
の共有ライブラリのメカニズムの柔軟性の低さからの脱却でした.
これはベンダや開発者全体にとって共有ライブラリの作成が非常に
難しかった原因でした.
<tt/ELF/のツールには共有ライブラリの問題を
解決することができるものが提供されており, またいずれにせよ
一般的に「進歩」していると考えられます. このため移行のコストは
必要なものとして容認され, 移行はおこなわれました.
<p>FreeBSDの場合は, 共有ライブラリのメカニズムは Sun の
<tt>SunOS</tt>スタイルの共有ライブラリのメカニズムに極めて近い
ものになっていて非常に使いやすいものになっています.
しかしながら, FreeBSD では 3.0 から <tt/ELF/ バイナリをデフォルトの
フォーマットとして公式にサポートしています. <tt/a.out/
実行フォーマットはよいものを私達に提供してくれているものの, 私達の
使っているコンパイラの作者である GNU の人々は <tt/a.out/ フォーマット
のサポートをやめてしまったのでした. このことは, 私達に別バージョンの
コンパイラとリンカを保守することを余儀なくされることとなり, 最新の
GNU 開発の努力による恩恵から遠ざかることになります. その上, ISO-C++
の, とくにコンストラクタやデストラクタがらみの要求もあって, 今後の
FreeBSD のリリースでネイティブの <tt/ELF/ のサポートされる方向へと
話が進んでいます.
<sect1>
<heading>それにしても, なぜそんなに多くのフォーマットがあるのですか?</heading>
<p>もうおぼろげになってしまった暗い過去に, 単純なハードウェアが
ありました. この単純なハードウェアは, 単純で小さなシステムを
サポートしていました. a.out はこの単純なシステム (PDP-11) での
作業を行なうバイナリとして完全に適したものだったのです.
人々はこの単純なシステムから UNIX を移植する際に, a.out
フォーマットをそのまま使いました. というのは Motorola 68k, VAXen,
といったアーキテクチャへの UNIX の初期の移植ではこれで十分だったからです.
<p>やがてある聡明なエンジニアがソフトウェアでちょっとした
トリックを使うことを決めました. 彼はいくつかのゲートを削り取って
CPU のコアをより速く走らせることができたのです. これは
新しい種類のハードウェア (今日では RISC として知られています) で
動いたのです. <tt/a.out/ はこのハードウェアには
適していなかったので, このハードウェア上で多くのフォーマットが,
限定された単純な <tt/a.out/ フォーマットでのものよりもより良い
パフォーマンスを出すことを目指して開発されたのです.
<tt/COFF/, <tt/ECOFF/, そしていくつかの有名でないフォーマットが
<tt/ELF/ が標準になる前に開発され, それらの限界が探求されたのです.
<p>さらに, プログラムサイズは巨大になり, ディスク (および物理メモリ)
は依然として相対的に小さかったため, 共用ライブラリのコンセプトが
誕生しました.
また, VM システムはより複雑なものになりました.
これらの個々の進歩は <tt/a.out/ フォーマットを使用して遂げられましたが,
その有用性は新しい機能とともにどんどん広がってきました.
これらに加え, 実行時に必要なものを動的にロードする, または
初期化コードの実行後にプログラムの一部を破棄し, コアメモリおよび /
またはスワップ空間を節約するという要望が高まりました.
プログラミング言語はさらに複雑になり, main 関数の前に自動的に
コールされるコードの要望が高まりました.
多くの機能拡張がおこなわれ, <tt/a.out/ フォーマットがこれらすべてを
実現できるようになり, それらはしばらくは基本的に動作していました.
やがて, <tt/a.out/ はコードでのオーバヘッドと複雑さを増大させずに
これらの問題すべてを処理することに無理がでてきました.
一方, <tt/ELF/ はこれらの問題の多くを解決しますが, 現状稼働している
システムからの切替えは厄介なものになるでしょう.
そのため <tt/ELF/ は, <tt/a.out/ のままでいることが<tt/ELF/ への
移行よりももっと厄介なものになるまで待つ必要がありました.
<p>しかし時が経つにつれ, FreeBSD のビルドツールの元となったツー
ル群(特にアセンブラとローダ)と FreeBSD のビルドツール群は異なっ
た進化の経路をたどりました. FreeBSD のツリーでは, 共有ライブラ
リが追加され, バグフィックスも行われました. もともとのツール群
を作成した GNU の人たちは, プログラムを書き直し, クロスコンパ
イラのサポート, 異なるフォーマットを任意に取り込む機能などを追
加していきました. 多くの人々が FreeBSD をターゲットとしたクロ
スコンパイラの構築を試みましたが, FreeBSD の使っている as と
ld の古いプログラムコードはクロスコンパイルをサポートしておら
ず, うまくいきませんでした. 新しい GNU のツール群 (binutils)
は, クロスコンパイル, 共有ライブラリ, C++ 拡張などの機能をサポー
トしています. さらに数多くのベンダが <tt/ELF/ バイナリをリリー
スしています. FreeBSD にとって <tt/ELF/ バイナリが実行できる
ことは, 非常にメリットがあります. <tt/ELF/ バイナリが FreeBSD
で動くのなら, <tt/a.out/ を動かすのに手間をかける必要はありま
せんね. 長い間忠実によく働いた老いた馬は, そろそろ牧草地で休ま
せてあげましょう.
<p><tt/ELF/ は a.out に比べてより表現力があり, ベースのシステム
に対してより幅広い拡張性を提供できます. <tt/ELF/ 用のツールは
よりよく保守されています. また多くの人にとって重要なクロスコン
パイルもサポートしています. <tt/ELF/ の実行速度は, ほんの少し
a.out より遅いかもしれませんが, 実際に速度の差をはかるのは困難
でしょう. <tt/ELF/ と a.out の間には, ページマッピング, 初期化
コードの処理など多くの違いがありますが, とりたてて重要なものは
ありません. しかし違いがあるのは確かです. ほどなく, GENERIC カー
ネルから <tt/a.out/ のサポートが外さます. <tt/a.out/ のプログ
ラムを実行する必要性がなくなれば, 最終的に <tt/a.out/ のサポー
トはカーネルから削除されます.
<sect1>
<heading>なぜシンボリックリンクのパーミッションは chmod で変えられないのですか?</heading>
<p>この場合, ``<tt/-H/'' か ``<tt/-L/'' のどちらかのオプションを
``<tt/-R/'' と同時に使う必要があります.
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod"
name="chmod"> と
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?symlink"
name="symlink"> のマニュアルページにはもっと詳しい情報があります.
<p><bf/注意/ ``<tt/-R/'' オプションは <bf/再帰的に/ <tt/chmod/
を実行します. ディレクトリやディレクトリへのシンボリックリンクを
<tt/chmod/ する場合は気をつけてください. シンボリックリンクで
参照されている単一のディレクトリのパーミッションを変更したい場合は,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod">
をオプションをつけずにシンボリックリンクの名前の後ろにスラッシュ
(``<tt>/</tt>'') をつけて使います. 例えば, ``<tt/foo/'' がディレクトリ
``<tt/bar/'' へのシンボリックリンクである場合, ``<tt/foo/'' (実際には
``<tt/bar/'') のパーミッションを変更したい場合にはこのようにします:
<verb>
chmod 555 foo/
</verb>
<p>後ろにスラッシュをつけると,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod"
name="chmod"> はシンボリックリンク
``<tt/foo/'' を追いかけてディレクトリ ``<tt/bar/''
のパーミッションを変更します.
<sect1>
<heading>
login 名が<bf/いまだに/ 8文字に制限されているのはなぜですか
</heading>
<p> <bf/UT_NAMESIZE/を変更して全体を作り直せば十分で, それだけで
うまくいくだろうとあなたは考えるかもしれません.
残念ながら多くのアプリケーションやユーティリティ
(システムツールも含めて) は小さな数値を構造体やバッファなどに
使っています ( 必ずしも "8" や "9" ではなく, "15" や "20"
などの変った値を使うものもあります). (固定長のレコードを期待
するところで可変長レコードになるために) 台無しになった
ログファイルを得ることになるということだけでなく, Sun の NIS の
クライアントの場合は問題が起きますし, 他の UNIX システムとの関連
においてこれら以外の問題も起きる可能性があります.
<p>しかし, FreeBSD 3.0 以降では 16文字となり, 多くのユーティリティ
のハードコードされた名前の長さの問題も解決されます. 実際には
システムのあまりに多くの部分を修正するために, 3.0 になるまでは
変更が行われませんでした.
<p>それ以前のバージョンでは, これらの問題が起こった場合に, 問題
を自分自身で発見し, 解決できることに絶対的な自信がある場合は
/usr/include/utmp.h を編集し, UT_NAMESIZE の変更にしたがって,
長いユーザ名を使うことができます.
また, UT_NAMESIZE の変更と一致するように
/usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません.
最後に, ソースからビルドする場合は /usr/include を毎回
アップデートする必要があることを忘れないように!
/usr/src/.. 上のファイルを変更しておいて置き換えましょう.</p>
<sect1>
<heading>FreeBSD 上で DOS のバイナリを動かすことはできますか? </heading>
<p>はい, 3.0 からは, 統合と改良が重ねられた BSDI の <tt/rundos/
DOS エミュレーションサブシステムを使ってできるようになりました.
今なお続けられているこの努力に興味を持って参加していただけるなら
<url url="mailto:freebsd-emulation@freebsd.org"
name="The FreeBSD emulation discussion list">
へメールを送ってください.
<p>3.0 以前のシステムでは,
<htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^pcemu"
name="pcemu"> という巧妙なユーティリティが ports
コレクションにあり, 8088 のエミュレーションと DOS の
テキストモードアプリケーションを動かすに十分な BIOS
サービスをおこないます. これは X ウィンドウシステムが必要です
(XFree86 として提供されています)
<sect1>
<heading>
``<tt/sup/'' とは何で, どのようにして使うものなのでしょうか?
</heading>
<p><htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^sup"
name="SUP">
とはソフトウェアアップデートプロトコル (Software Update
Protocol) で CMU で開発ツリーの同期のために開発されました.
私たちの中心開発ツリーをリモートサイトで同期させるために
使っていました.
<p>SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードの
アップデートの現在のおすすめの方法は <url
url="../handbook/cvsup.html" name="ハンドブックの CVSup の項">
にあります.
<sect1>
<heading>FreeBSD をクールに使うには?</heading>
<p>Q. FreeBSD を動かす時に温度測定をおこなった人はいますか? Linux
は dos よりも温度が下がるということは知っていますが, FreeBSD
についてはこのようなことに触れたものを見たことはありません.
実際熱くなっているように見えます.
<p>A. いいえ. 私たちは 250 マイクログラムの LSD-25 をあらかじめ
与えておいたボランティアに対する目隠し味覚テストを大量に
おこなっています.
35% のボランティアは FreeBSD はオレンジのような味
がすると言っているのに対し Linux は紫煙のような味わいがある
と言っている人もいます. 私の知る限り両方のグループとも温度の
不一致については触れていません. この調査で, 非常に多くの
ボランティアがテストをおこなった部屋から不思議そうに出てきて,
このようなおかしな結果を示したことに私たちは当惑させられました.
私は, ほとんどのボランティアは Apple にいて彼らの最新の
「引っかいて匂いをかぐ」 GUI を使っているのではないかと
考えています. 私たちは奇妙な古い仕事をしているのでしょう!
<p>真面目に言うと, FreeBSD も Linux も ``<tt/HLT/'' (停止)
命令をシステムのアイドル時に使い, エネルギーの消費を押えて
いますので熱の発生も少なくなります. また, APM (automatic power
management) を設定してあるなら FreeBSD は CPU をローパワーモード
にすることができます.
<sect1>
<heading>誰かが私のメモリカードをひっかいているのですか??</heading>
<p>Q. FreeBSDでカーネルのコンパイルをしている時にメモリから
引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか?
コンパイルをしている時 (あるいは起動時にフロッピドライブを
認識した後の短い間など), 奇妙な引っかくような音がメモリカードの
あたりから聞こえてきます.
<p>A. その通りです. BSDのドキュメントでしばしば「デーモン」に
ついて述べられている理由がわかるでしょう. しかし多くの人は本当の
事については触れていません. 非物質的な存在があなたのコンピュータ
にあるのです. メモリからの引っかいたような音は, 実際に色々な
システム管理タスクの扱いをいかに最善なものにするかという内容を交わす,
デーモンたちのかん高いささやきなのです.
<p>「雑音」があなたに DOS プログラムの ``<tt>fdisk /mbr</tt>''
を使ってうまくささやきを取り除かせようとしているように聞こえても,
彼らは逆にそうすることをやめさせようとしているのかもしれません.
本当は内蔵スピーカからのビル ゲイツの悪魔的な声が
あなたに影響を与えているのかもしれません.
実行するのは止めましょう, そして振り返ってはいけません!
BSD の守護神 (daemon) の力により,
繰り返しあなたのマシンを支配下に置こうとし, あなたの魂を
無限地獄に突き落そうとする DOSと Windows の双子の悪鬼 (demon) の
影響から自由になりましょう.
選択の機会は与えられました. 私自身はこの引っかくような音が
聞こえていたことを嬉しく思っています.
<sect1>
<heading>'MFC' とはどういう意味ですか</heading>
<p>MFC とは 'CURRENT との合流(Merged From -CURRENT.)'の
頭文字をとったものです. CVS ログで CURRENT から STABLE ブランチ
への合流を示します.
</sect>
Reference in a new issue View git blame Copy permalink