diff options
Diffstat (limited to 'ja_JP.eucJP/FAQ/hackers.sgml')
| -rw-r--r-- | ja_JP.eucJP/FAQ/hackers.sgml | 269 |
1 files changed, 0 insertions, 269 deletions
diff --git a/ja_JP.eucJP/FAQ/hackers.sgml b/ja_JP.eucJP/FAQ/hackers.sgml deleted file mode 100644 index c0add046b0..0000000000 --- a/ja_JP.eucJP/FAQ/hackers.sgml +++ /dev/null @@ -1,269 +0,0 @@ -<!-- $Id: hackers.sgml,v 1.2 1997-12-21 23:02:14 max Exp $ --> -<!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.2 --> - - <sect> - <heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading> - <p><em>訳: &a.iwasaki;.<newline>8 November 1997.</em> - - <sect1> - <heading> - SNAP とか RELEASE とかは何? - </heading> - - <p>現在, FreeBSD の - <url url="http://www.freebsd.org/cgi/cvsweb.cgi" name="CVS リポジトリ"> - には, 三つのアクティブ/準アクティブなブランチがあります. - - <itemize> - <item><bf/RELENG_2_1_0/ 通称 <bf/2.1-stable/ または <bf/"2.1 branch"/ - <item><bf/RELENG_2_2/ 通称 <bf/2.2-stable/ または <bf/"2.2 branch"/ - <item><bf/HEAD/ 通称 <bf/-current/ または <bf/3.0-current/ - </itemize> - - <p><bf/HEAD/ は他の二つと違って実際のブランチ tag ではなく, - <em/「current, 分岐していない開発本流」/のための単なるシンボリック - な定数です. 私たちはこれを <bf/-current/ と呼んでいます. - - <p>現在, <bf/-current/ は 3.0 の開発本流であり, - <bf/2.2-stable/ ブランチ, つまり <bf/RELENG_2_2/ は - 1996年11月に<bf/-current/ から分岐しています. - - <p><bf/2.1-stable/ ブランチ, <bf/RELENG_2_1_0/ は 1994年9月に - -current から分岐しました. - - <sect1> - <heading> - 自分用のカスタムリリースを構築するには?<label id="custrel"> - </heading> - - <p>リリースを構築するには三つのことが必要です: - まず, <htmlurl url="http://www.freebsd.org/cgi/man.cgi?vn" - name="vn"> ドライバが組み込まれたカーネルを実行させている必要があります. - 以下をカーネルコンフィグレーションファイルに追加し, - カーネルを作り直してください: - - <verb> - pseudo-device vn #Vnode driver (turns a file into a device) - </verb> - - <p>次に, CVS リポジトリ全体を手元においておく必要があります. - これを入手するには - <url url="../handbook/cvsup.html" name="CVSUP"> - が使用できますが, supfile で release の名称を cvs にして - 他のタグや date フィールドを削除する必要があります: - - <verb> - *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 - </verb> - - <p>そして <tt/cvsup -g supfile/ を実行して自分のマシンに - CVS リポジトリ全体をコピーします... - - <p>最後に, ビルド用にかなりの空き領域を用意する必要があります. - そのディレクトリを <tt>/some/big/filesystem</tt> として, - 上の例で CVS リポジトリを <tt>/home/ncvs</tt> に置いたものとすると, - 以下のようにしてリリースを構築します: - - <verb> - setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs - cd /usr/src/release - make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release - </verb> - - <p>処理が終了すると, リリース全体が <tt>/some/big/filesystem/release</tt> - に構築され, 完全な FTP インストール用の配布物が - <tt>/some/big/filesystem/release/R/ftp</tt> に作成されます. - -current 以外の開発ブランチの SNAP を自分で構築したい場合は, - <tt/RELEASETAG=SOMETAG/ を上の make release のコマンドラインに追加します. - 例えば, <tt/RELEASETAG=RELENG_2_2/ とすると最新の 2.2 GAMMA snapshot - が構築されます. - - <sect1> - <heading>カスタムのインストールディスクを作るにはどうすればいいのですか? </heading> - - <p><tt>/usr/src/release/Makefile</tt> のいろいろなターゲットとして - インストールディスク, ソース, バイナリアーカイブを作る完全な処理を - 自動的におこなうようになっています. Makefile に十分な情報があります. - しかし, 実行には ``make world'' が必要で, - 多くの時間とディスクの容量が必要です. - - <sect1> - <heading> - ``make world'' をおこなうと既存のバイナリを上書きしてしまうのですが. - </heading> - - <p>ええ, それが一般的な考え方です. 名前が示しているように - ``make world'' はすべてのシステムのバイナリを一から作り直しますので, - 結果としてクリーンで一貫性のある環境を得ることができます - (これがそれだけ長い時間がかかる理由です). - - <p>環境変数 <tt/DESTDIR/ を ``<tt/make world/'' や ``<tt/make - install/'' を実行する時に定義しておくと, 新しく作られたバイナリは - <tt>${DESTDIR}</tt>を root とみなした - ディレクトリツリーにインストールされます. - あるでたらめな共有ライブラリの変更やプログラムの再構築によって - ``<tt/make world/'' は失敗することもあります. - - <sect1> - <heading> - システムブート時に ``(bus speed defaulted)'' とメッセージが出ます. - </heading> - - <p>アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に - バスアクセス速度の設定をおこなうことができます. 以前のバージョンの - 1542 ドライバは使用可能な最大の速度を求めてアダプタを - その設定にしようとしました. これは特定のユーザのシステムでは - 問題がある事がわかり, 現在ではカーネルコンフィグオプションに - ``<tt/TUNE_1542/'' が加えられています. これを使用すると, - これが働くシステムではディスクが速くなりますが, - データの衝突が起きて速くはならないシステムもあるでしょう. - - <sect1> - <heading> - インターネットアクセスに制限があっても current を追いかけられますか? <label id="ctm"> - </heading> - - <p>はい, <url url="../handbook/ctm.html" name="CTM システム ">を使って - ソースツリー全体のダウンロードを<tt/おこなわず/に追いかけることができます. - - <sect1> - <heading>どのようにして配布ファイルを 240kバイトに分割しているのですか?</heading> - - <p>比較的新しい BSDベースのシステムでは split に任意のバイト境界で - 分割する ``<tt/-b/'' オプションがあります. - - <p>以下は <tt>/usr/src/Makefile</tt> からの例です. - - <verb> - bin-tarball: - (cd ${DISTDIR}; \ - tar cf - . \ - gzip --no-name -9 -c | \ - split -b 240640 - \ - ${RELEASEDIR}/tarballs/bindist/bin_tgz.) - </verb> - - <sect1> - <heading>私はカーネルに拡張をおこないました. 誰に送ればいいですか? </heading> - - <p><url url="../handbook/contrib.html" - name="ハンドブックの「貢献の仕方 (Contributing to FreeBSD)」の章"> - を参照してください. - - <p>あなたのアイディアに感謝します! - - <sect1> - <heading>PnP ISA カードの検出と初期化はどのようにおこなうのですか? </heading> - - <p><url url="mailto:uhclem@nemesis.lonestar.org" - name="Frank Durda IV"> 氏より: - - <p>要点は, ホストが認識されていないボードを探す時に, すべての - PnP ボードが応答することのできる少数の I/O ポートがあるという - ことです. それにより, PnP プローブルーチンが開始したとき, PnP - ボードが存在するなら, すべての PnP ボードは自分のモデル番号を - 返します. そのポートを I/O read するとプローブルーチンは - 問いに対するワイアード-OR された ``yes'' を得ます. この場合は - 少なくとも 1ビットが ON になります. そして, プローブルーチンは - モデル ID (Microsoft/Intel によって割り当てられています) - が X より小さいボードを ``オフライン'' にすることができます. - この操作をおこない, 問い合わせに応答しているボードがまだ - 残っているかどうかを調べます. もし ``<tt/0/'' が返ってくるなら X - より大きな ID を持つボードはないことになります. 今度は ``X'' - よりも小さな値を持つボードについて問い合わせます. もしあるのであれば, - プローブルーチンはモデル番号が X より小さいことを知ります. - 今度は, X-(limit/4) より大きな値を持つボードをオフラインにして - 問い合わせを繰り返します. この ID の範囲による準バイナリサーチを - 十分繰り返すことにより, プローブルーチンはマシンに存在するすべての - PnP ボードの値を最終的に得ることができます. その繰り返しの回数は - 2^64 よりはるかに少ない回数です. - - <p>ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit - チェックサムからなります. 最初の 32 bits はベンダの識別子です. - これは公表されてはいませんが, 同一のベンダから供給されている - 異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことが - できるように考えられます. 製造元を特定するだけのために 32 bits - はいくらか過剰です. - - <p>下位の 32 bits はシリアル番号, イーサネットアドレスなどの - ボードを特定するものです. ベンダは上位 32 bits が異なっていない - のであれば下位 32 bits が同一である 2枚目のボードを製造することは - ありません. したがって, 同じタイプの複数のボードをマシンに - いれることができ, この場合でも 64 bits 全体ではユニークです. - - <p>32 bit のフィールドはすべてを 0 にすることはできません. - これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない - ビットを参照するからです. - - <p>システムがすべてのボードの与えられた ID を認識すると, - それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して) - おこないます. そして, 利用できる割り込みの選択などのボードが必要 - とするリソースを検出します. すべてのボードについてこの情報を集めます. - - <p>この情報はハードディスク上の ECU ファイルなどの情報とまとめられ, - マザーボードの BIOS にも結合されます. マザーボード上のハードウェア - への ECU と BIOS PnP のサポートは通常は統合されていますが, - 周辺機器については真の PnPであるとはいえません. - しかし, BIOS の情報に ECU の情報を加えて調査することで, - プローブルーチンは PnP デバイスが再配置できなくなることを - 避けることができます. - - <p>それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ, - メモリマップアドレスの設定をします. デバイスはこのアドレスに - 見えるようになり, 次にリブートするまでこの位置を占めます. しかし, - あなたの望む時に移動させることが不可能であるといっている - わけではありません. - - <p>以上の話では大きく単純化をしてありますが, 基本的な考え方は得 - られたでしょう. - - <p>マイクロソフトはボードのロジックが 対立するI/O サイクルでは - デコードしていない (訳注: おそらく read 時しかデコードされていず - write 時はポートが空いているという意味でしょう) - プライマリプリンタのステータスポートのいくつかを PnP のために - 占有しました. 私は初期の PnP の提案レビュー時に IBM 純正の - プリンタボードでステータスポートの write のデコードがされている - ということに気がつきましたが, MS は ``tough (頑固, 不運, - 無法な)'' と言っています. そしてプリンタのステータスポートへ - アドレスの設定のために write をおこなっています. また, - そのアドレス + <tt/0x800/と read のための 3番目の I/O ポートが - <tt/0x200/ から <tt/0x3ff/ の間のどこかに置かれるでしょう. - - <sect1> - <heading>FreeBSD は, Intel 以外のアーキテクチャをサポートしないんですか? </heading> - - <p>いくつかのグループが, FreeBSD の他のアーキテクチャのサポートに関心を - 示しており, 現在数人が DEC の協力を得て FreeBSD の ALPHA アーキテクチャへの - 移植に取り組んでいます. 新しいアーキテクチャに関する一般的な議論は - <tt><platforms@FreeBSD.ORG></tt> をご利用ください. - - <sect1> - <heading>デバイスドライバを開発したので, メジャー番号が必要です. </heading> - - <p>これは, 開発したドライバを公開するかどうかに依存します. - 公開するのであれば, ドライバのソースコード, <tt>files.i386</tt> の変更, - コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?MAKEDEV" name="MAKEDEV"> - のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの - 問題により公開できない場合は, キャラクタメジャー番号 32 もしくは - ブロックメジャー番号 8 が, このような目的のために予約されています. - これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を - <tt><hackers@FreeBSD.ORG></tt> に流して頂けると助かります. - - </sect> - |