DragonFly BSD
出典: フリー百科事典『ウィキペディア（Wikipedia）』
| 公式サイト: | dragonflybsd.org |
| 開発者: | Matt Dillon |
| OSの系統: | BSD |
| ソースコード: | オープンソース |
| 最新リリース: | 1.12.0 / 2008年2月26日 |
| カーネル種別: | ハイブリッドカーネル |
| ライセンス: | BSDライセンス |
| 開発状況: | Current |
DragonFly BSDは、UNIXライクなオープンソースのオペレーティングシステムである。Matthew Dillonがプロジェクトリーダーとなり、2003年にFreeBSD 4.8-STABLEから分岐する形で開発が始まった。
FreeBSD 4.x系列の後継のOSというだけでなく、DragonFly BSDはFreeBSD 5と全く違った開発方針で開発されている。この例として、軽量カーネルスレッド (LWKT) や軽量メッセージシステムがある。このようなDragonFly BSDに実装される多くの概念はAmigaOSに触発されている。
2004年7月12日に初のメジャーバージョンとなる1.0 RELEASEが公開された。
目次 |
[編集] カーネルの設計
最近のほとんどのカーネルのように、DragonFly BSDはハイブリッドカーネルを採用している。 これはつまり、モノリシックカーネルとマイクロカーネルの両方の性質を併せ持ち、 必要に応じて両方の良いところを使うということである。 たとえば、マイクロカーネルのメッセージシステムにあるようなメモリー保護の恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。 DragonFly BSDのメッセージサブシステムはMachのようなマイクロカーネルのデザインと似ており、あまり複雑ではない設計になっている。 また、DragonFly BSDのメッセージサブシステムは同期通信、非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。
デバイスI/OやVFSはメッセージサブシステムを使うように変更されている。 これらの新しい機構により、カーネルの様々な部分をユーザーランドで実行することが出来るようになる。 ユーザーランドでカーネルの一部を実行すると、その部分はカーネルという大きなプログラムの一部ではなく、小さく、独立した1つのプログラムとなる。 こうすることで、ユーザーランドで動いているドライバがクラッシュしても、カーネル全体はクラッシュしなくなるという利点もある。
システムコールはユーザーランド版とカーネル版に分けられ、メッセージとしてカプセル化されるようになった。 これにより、標準システムコールの実体をユーザーランドにある互換レイヤーに移すときのプログラム量と複雑さを軽減することができる。 また、これにより新旧のDragonFly BSDの互換性を保つのも容易になった。 さらに、同様にすることでLinuxやその他のUNIX系オペレーティングシステム（OS）のアプリケーションを動かすための機構もユーザーランドに移すことが出来る。 このようなFreeBSD jail上に作られたネイティブなユーザーランド互換レイヤーを使うことで、DragonFly BSDはUser-Mode Linux（UML）と同等のことができるようになる。 しかし、UMLと異なり、DragonFly BSDの仮想化は実際のハードウェアと通信するための特別なデバイスドライバを必要としない。 なお、UMLはLinuxをポーティングしたもので、ホストOSカーネルを別のハードウェアプラットホームと見なす実装になっている。
[編集] CPU 局所化
DragonFly BSDでは、スレッドはCPUに強く結びつけられるというデザインになっている。 そして、各々のCPUはそれぞれLWKTスケジューラを持っている。 DragonFly BSDではスレッドが勝手に動作するプロセッサを変えることは出来ず、 CPUの間の"プロセッサ間割り込み"（IPI）メッセージを使った場合のみ別のCPUへとスレッドが移される。 そして、CPUをまたぐスレッドスケジューリングも非同期のIPIメッセージを送ることで行われる。 この方法を使うとスレッドサブシステムをきれいに区切ることが出来るが、 その利点はSMPシステムにて複数のCPUのキャッシュに同一データが乗らないということである。 これにより、システムの各プロセッサがスレッドの実行のために異なったデータをキャッシュできるようになり、 高い性能を出すことが出来る。
LWKTサブシステムでは複数のカーネルスレッドに処理を分けるように実装された。 （たとえば、ネットワークコードでは、プロトコルごとに1スレッドとなる） これにより、複数のカーネル内タスクでリソースを共有することで生じる競合状態をなくすことが出来る。 このように、CPUごとの局所性を保つようにするアルゴリズムでスレッドを分ける実装は、ほぼ間違いなくDragonFly BSDに特有のデザインである。
[編集] 共有資源の保護
マルチプロセッサマシンで安全に動作させるために、共有資源（ファイル、データ構造体など）へのアクセスは直列化されなくてはならない。 直列化することで、スレッドやプロセスは同時に同じ資源を変更できなくなる。 アトミック操作、スピンロック、クリティカルセクション、ミューテックス、直列化トークン、メッセージキューはすべて同じ資源への同時アクセスを防ぐのに使える方法である。 LinuxもFreeBSD 5も粒度の細かいミューテックスを使ったモデルを用いることでより高性能なマルチプロセッサシステムを構成しているが、DragonFly BSDはそうではない。 複数のスレッドが共有リソースを同時にアクセスしたり、変更したりするのを防ぐため、DragonFly BSDではクリティカルセクションと直列化トークンを用いている。 最近まで、DragonFly BSDもSPLを使っていたが、その部分はクリティカルセクションで置き換えられた。
LWKTサブシステム、IPIメッセージサブシステム、新しいメモリーアロケータなどを含むシステムの中心的な部分の多くはロックしない。 これはつまり、ミューテックス無しで動き、CPUごとに処理を行う。 クリティカルセクションは局所的な割り込みから守るために使われ、CPUごとに処理を行う。 これにより、現在動かされているスレッドはCPUを横取りされないことが保証されている。
直列化トークンは他のCPUからの並列アクセスを防ぐために使われ、複数のスレッドで同時に保持される。 この結果、それらのスレッドの一つが与えられた時間処理を行うことが保証される。 それゆえ、ミューテックスを持っているスレッドと違い、ブロックされているスレッドやスリープしているスレッドは他のスレッドが共有リソースにアクセスすることを禁止しない。 直列化トークンを使うことで、ミューテックスを使った場合のようなデッドロックや優先度の逆転を引き起こす状況を防ぐことが出来る。 これに加え、直列化トークンを使うことで複数のスレッドで共有するような資源を要求する長いプロシージャの設計や実装をずっと単純にすることが出来る。 直列化トークンの実装は最近のLinuxにあるリード・コピー・アップデート（RCU）機能によく似たものに発展している。 しかし、Linuxの現在のRCUとは異なり、DragonFly BSDの実装では計算機内のすべてのプロセッサではなく、同じトークンで競合しているプロセッサ同士が影響を受けるという実装になっている。
[編集] そのほかの機能
開発の初期段階でDragonFly BSDはスラブ・アロケータを採用し、FreeBSD 4 のカーネルメモリアロケータから置き換えた。 この新しいスラブ・アロケータはメモリを割り当てるときに排他制御やブロック操作を必要としない。 また、FreeBSD 4のカーネルメモリアロケータと違い、このアロケータはマルチプロセッサ・セーフである。
DragonFly BSDはSFBUF (Super-Fast BUFfer)とMSFBUF (Multi-SFBUF)を使う。 SFBUFは短い時間しか使わない単一ページのマッピングを操作するのに用い、必要ならそれらのマッピングをキャッシュする。 これらの機構は単一のVMページで保持されているデータへの参照を補うために使われる。 この単純で、かといって強力な、抽象化により、様々なことが出来るようになる。 たとえば、これを用いることでsendfile(2)システムコールでのゼロコピーが実現されている。
SFBUFはカーネルの様々な箇所で用いられる。たとえば、vnodeオブジェクトのページャやパイプサブシステム (XIOを用いた間接転送の場合) で広帯域な転送を行うために用いられる。 SFBUFは単一のVMページでしか使えない。そのため、MSFBUFSが短い時間しか使わない複数のページのマッピングを操作するのに用いられる。
SFBUFの概念はFreeBSDプロジェクトのDavid Greenmanがsendfile(2)システムコールを書いたときに考えられた。 そして、この概念はAlan L. Cox博士とMattew Dillonにより書き直された。 また、MSFBUFはHiten PandyaとMatthew Dillonにより考案された。
[編集] 開発の方向性
[編集] 対応プロセッサ
現在ではDragonFly BSDはx86(インテルおよびAMD)ベースの計算機で動作する。 これは単一プロセッサもSMPも両方対応している。 x86-64アーキテクチャへの移植は始まったばかりで、安定していない。 PowerPCアーキテクチャへの移植はx86-64の移植の後に移植するよう予定されている。
[編集] パッケージ管理
DragonFly BSDではかつてFreeBSDのportsシステムを追加ソフトウェアのインストールに使っており、NetBSDの"pkgsrc"はオプションとして使えるに過ぎなかった。 しかし、1.4リリースからpkgsrcがシステムの公式なパッケージ管理システムとなった [1] 。 pkgsrcを使えるようになったことで、DragonFly BSDの開発者は追加インストールされるソフトウェアのアップデート作業から解放されることになった。 また、この変更はpkgsrcの開発者がpkgsrcの移植性を高めるのにも役立った。
[編集] スレッドとメッセージング
システムコールとデバイス I/Oの実装はDragonFly BSDのスレッドメッセージシステムを使うように変更されたが、これらは未だに同期して動作している。 最終的には、すべてのメッセージサブシステムを同期、非同期のどちらでも動くようにする予定である。
ユーザーランドスレッドのサポートも今後のリリースの重要な課題である。 今のところ、DragonFly BSDではマルチプロセッサシステムの利点を生かせない基本的なユーザーランドスレッド (N:1スレッド) しか持っていない。 DragonFly BSDの開発当初からこれについては取り組んでおり、2.0リリースでは近代的なスレッド実装になる予定である。 Mattによると、理想的にはM:Nスレッド (M個のカーネルスレッドをより多いN個のユーザーランドスレッドで利用) の実装をしたいが、2.0では1:1スレッド (1個のカーネルスレッドを1個のユーザーランドスレッドが占有して利用) にする予定とのことだ。
[編集] 関連項目
[編集] 外部リンク
- オフィシャルページ （英語）
|
|
|---|
| A/UX · IBM AIX · BSD · BKUNIX · Darwin · DEMOS · DragonFly BSD · FreeBSD · GNU Hurd · HP-UX · IRIX · Linux · Mac OS X · MNOS · NetBSD · NEXTSTEP · OpenBSD · Plan 9 · QNX · Research Unix · SCO OpenServer · SINIX · Solaris · System V · Tru64 · Xenix · more |
