訳: &a.iwasaki;. 現在, FreeBSD の
リリースを構築するには三つのことが必要です:
まず, 次に, CVS リポジトリ全体を手元においておく必要があります.
これを入手するには
そして 最後に, ビルド用にかなりの空き領域を用意する必要があります.
そのディレクトリを /some/big/filesystem として,
上の例で CVS リポジトリを /home/ncvs に置いたものとすると,
以下のようにしてリリースを構築します:
処理が終了すると, リリース全体が /some/big/filesystem/release
に構築され, 完全な FTP インストール用の配布物が
/some/big/filesystem/release/R/ftp に作成されます.
-current 以外の開発ブランチの SNAP を自分で構築したい場合は,
/usr/src/release/Makefile のいろいろなターゲットとして
インストールディスク, ソース, バイナリアーカイブを作る完全な処理を
自動的におこなうようになっています. Makefile に十分な情報があります.
しかし, 実行には ``make world'' が必要で,
多くの時間とディスクの容量が必要です.
ええ, それが一般的な考え方です. 名前が示しているように
``make world'' はすべてのシステムのバイナリを一から作り直しますので,
結果としてクリーンで一貫性のある環境を得ることができます
(これがそれだけ長い時間がかかる理由です).
環境変数 ${DESTDIR}を root とみなした
ディレクトリツリーにインストールされます.
あるでたらめな共有ライブラリの変更やプログラムの再構築によって
``
アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に
バスアクセス速度の設定をおこなうことができます. 以前のバージョンの
1542 ドライバは使用可能な最大の速度を求めてアダプタを
その設定にしようとしました. これは特定のユーザのシステムでは
問題がある事がわかり, 現在ではカーネルコンフィグオプションに
``
はい, 比較的新しい BSDベースのシステムでは split に任意のバイト境界で
分割する ``以下は /usr/src/Makefile からの例です.
あなたのアイディアに感謝します!
要点は, ホストが認識されていないボードを探す時に, すべての
PnP ボードが応答することのできる少数の I/O ポートがあるという
ことです. それにより, PnP プローブルーチンが開始したとき, PnP
ボードが存在するなら, すべての PnP ボードは自分のモデル番号を
返します. そのポートを I/O read するとプローブルーチンは
問いに対するワイアード-OR された ``yes'' を得ます. この場合は
少なくとも 1ビットが ON になります. そして, プローブルーチンは
モデル ID (Microsoft/Intel によって割り当てられています)
が X より小さいボードを ``オフライン'' にすることができます.
この操作をおこない, 問い合わせに応答しているボードがまだ
残っているかどうかを調べます. もし ``ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit
チェックサムからなります. 最初の 32 bits はベンダの識別子です.
これは公表されてはいませんが, 同一のベンダから供給されている
異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことが
できるように考えられます. 製造元を特定するだけのために 32 bits
はいくらか過剰です.
下位の 32 bits はシリアル番号, イーサネットアドレスなどの
ボードを特定するものです. ベンダは上位 32 bits が異なっていない
のであれば下位 32 bits が同一である 2枚目のボードを製造することは
ありません. したがって, 同じタイプの複数のボードをマシンに
いれることができ, この場合でも 64 bits 全体ではユニークです.
32 bit のフィールドはすべてを 0 にすることはできません.
これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない
ビットを参照するからです.
システムがすべてのボードの与えられた ID を認識すると,
それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して)
おこないます. そして, 利用できる割り込みの選択などのボードが必要
とするリソースを検出します. すべてのボードについてこの情報を集めます.
この情報はハードディスク上の ECU ファイルなどの情報とまとめられ,
マザーボードの BIOS にも結合されます. マザーボード上のハードウェア
への ECU と BIOS PnP のサポートは通常は統合されていますが,
周辺機器については真の PnPであるとはいえません.
しかし, BIOS の情報に ECU の情報を加えて調査することで,
プローブルーチンは PnP デバイスが再配置できなくなることを
避けることができます.
それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ,
メモリマップアドレスの設定をします. デバイスはこのアドレスに
見えるようになり, 次にリブートするまでこの位置を占めます. しかし,
あなたの望む時に移動させることが不可能であるといっている
わけではありません.
以上の話では大きく単純化をしてありますが, 基本的な考え方は得
られたでしょう.
マイクロソフトはボードのロジックが 対立するI/O サイクルでは
デコードしていない (訳注: おそらく read 時しかデコードされていず
write 時はポートが空いているという意味でしょう)
プライマリプリンタのステータスポートのいくつかを PnP のために
占有しました. 私は初期の PnP の提案レビュー時に IBM 純正の
プリンタボードでステータスポートの write のデコードがされている
ということに気がつきましたが, MS は ``tough (頑固, 不運,
無法な)'' と言っています. そしてプリンタのステータスポートへ
アドレスの設定のために write をおこなっています. また,
そのアドレス +
いくつかのグループが, FreeBSD の他のアーキテクチャのサポートに関心を
示しており, 現在数人が DEC の協力を得て FreeBSD の ALPHA アーキテクチャへの
移植に取り組んでいます. 新しいアーキテクチャに関する一般的な議論は
<platforms@FreeBSD.ORG> をご利用ください.
これは, 開発したドライバを公開するかどうかに依存します.
公開するのであれば, ドライバのソースコード, files.i386 の変更,
コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する