DragonFly BSD

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
DragonFly BSD
開発元企業 / 開発者
OSの系統 BSD
開発状況 Current
ソースモデル オープンソース
最新安定版リリース 3.8.2 / 2014年08月8日(19日前) (2014-08-08
対応プラットフォーム
カーネル種別 ハイブリッドカーネル
ライセンス BSDライセンス
ウェブサイト

概要[編集]

DragonFly BSD(ドラゴンフライ ビーエスディー)は、NetBSDFreeBSDと同じくBSDの子孫の1つの、UNIXライクオープンソースオペレーティングシステムである。

マシュー・ディロン英語版プロジェクトリーダーとなり、2003年FreeBSD 4.8-STABLEから分岐する形で開発が始まり、2004年7月12日に初のメジャーバージョンであるDragonFly BSD 1.0が公開された[1]

DragonFly BSDは、FreeBSD 4.xの後継というだけでなく、FreeBSD 5.xとも全く異なる方針開発されている。この例として、LWKTや軽量メッセージシステムが有る。このような多くの、DragonFly BSD実装される、概念AmigaOSに触発されている。

カーネルの設計[編集]

DragonFly BSDには、最近の殆どのカーネルのように、ハイブリッドカーネルが採用されている。つまり、これは、モノリシックカーネルマイクロカーネルの両方の性質を併せ持ち、必要に応じて両方のメリットを使うということである。例えば、マイクロカーネルメッセージシステムにあるようなメモリ保護恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。メッセージサブシステムは、Machのようなマイクロカーネルデザインと似て、余り複雑ではないものになっている。さらに、これは同期通信と非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。

デバイスI/OVFSメッセージサブシステムを使うように変更されている。これらの新しい機構に拠り、カーネルの様々な部分をユーザーランドで実行可能になる。ユーザーランドカーネルの一部を実行すると、その部分はカーネルという大きなプログラムの一部ではなく、小さく独立した1つのプログラムとなる。こうすることで、ユーザーランドで動いているドライバークラッシュしても、カーネル全体はクラッシュしなくなるという利点も有る。

システムコールユーザーランド版とカーネルランド版に分けられ、メッセージとしてカプセル化されるようになった。これに拠って、標準システムコールの実体をユーザーランドにある互換レイヤーに移すときのプログラム量と複雑さを軽減可能になると同時に、新旧のDragonFly BSD互換性を保ち易くなった。さらに、Linuxやその他のUNIXOSアプリケーションを動かすための機構ユーザーランドに移せる。このようなFreeBSD jail上に作られたネイティブなユーザーランド互換レイヤーを使うことで、UMLと同等のことができる。しかし、UMLと異なり、仮想化には実際のハードウェア通信するための特別なドライバーを必要としない。なお、UMLLinuxポーティングしたもので、ホストOSカーネルを別のハードウェアプラットフォームと見なす実装になっている。

CPU局所化[編集]

スレッドCPUに強く結び付けられるというデザインになっていて、各々のCPUはそれぞれLWKTスケジューラーを持っている。なお、スレッドが勝手に動作するプロセッサーを変えることはできず、IPIメッセージを使った場合のみ別のCPUへとスレッドが移される。そして、CPUを跨ぐスレッドスケジューリングも非同期IPIメッセージを送ることで行われる。この方法を使うと、スレッドサブシステムを綺麗に区切れるが、その利点は、SMPシステムにて複数のCPUキャッシュに同一データが乗らない、ということである。これに拠り、システムの各プロセッサースレッドの実行のために異なったデータキャッシュできるようになり、高い性能を出せる。

LWKTサブシステムでは複数のカーネルスレッド処理を分けるように実装された[2]。これに拠り、複数のカーネルタスクリソース共有することで生じる競合状態を無くせる。このようにCPU毎の局所性を保つようにするアルゴリズムスレッドを分ける実装は略間違い無くDragonFly BSDに特有のデザインである。

共有資源の保護[編集]

共有資源(ファイルデータ構造体など)へのアクセスは、マルチプロセッサーマシーン安全に動作させるためには、直列化されなくてはならない。こうすることで、スレッドプロセスは同時に同じ資源を変更できなくなる。アトミック操作スピンロッククリティカルセクションミューテックス直列化トークンメッセージキューは全て同じ資源への同時アクセスを防ぐのに使える方法である。LinuxFreeBSD 5.xも粒度の細かいミューテックスを使ったモデルを用いることでより高性能マルチプロセッサーシステムを構成しているが、DragonFly BSDはそうではなく、複数のスレッド共有リソースに同時にアクセスしたり変更したりするのを防ぐために、クリティカルセクション直列化トークンを用いている。最近まで、DragonFly BSDSPLを使っていたが、その部分はクリティカルセクションで置き換えられた。

LWKTサブシステムIPIメッセージサブシステム・新しいメモリアロケーターなどを含むシステムの中心的な部分の多くはロックしない。つまり、ミューテックス無しで動き、CPU毎に処理を行う。クリティカルセクション局所的な割り込みから守るために使われ、CPU毎に処理を行う。これに拠り、動かされているスレッドCPUを横取りされないことが保証されている。

直列化トークンは他のCPUからの並列アクセスを防ぐために使われ、複数のスレッドで同時に保持される。この結果、それらのスレッドの一つが与えられた時間処理を行うことが保証される。それゆえ、ミューテックスを持っているスレッドと違い、ブロックされていたりスリープしているスレッドは他のスレッド共有リソースアクセスすることを禁止しない。直列化トークンを使うことで、ミューテックスを使った場合のようなデッドロック優先度の逆転を引き起こす状況を防げる。これに加え、複数のスレッド共有するようなリソースを要求する長いプロシージャー設計実装をずっと単純にできる。直列化トークン実装は最近のLinuxにあるRCUによく似たものに発展しているが、計算機内の全てのプロセッサーではなく同じトークン競合しているプロセッサー同士が影響を受ける、という実装になっている。

その他[編集]

開発の初期段階では、スラブアロケーターが採用され、FreeBSD 4.xのカーネルメモリアロケーターから置き換えられた。これはメモリを割り当てるときに排他制御やブロック操作を必要とせず、MPSAFEである。

SFBUF[3]MSFBUFが使われている。SFBUFは短い時間しか使わない単一ページのマッピングを操作するのに用い、必要ならそれらのマッピングキャッシュする。これらの機構は単一のVMページで保持されているデータへの参照を補うために使われる。この単純で強力な抽象化に拠って様々なことが可能になる。例えば、sendfile(2)[4]でのゼロコピーが実現されている。

SFBUFカーネルの様々な箇所で用いられる。例えば、vnodeオブジェクトページャーパイプサブシステム(XIO[5]を用いた間接転送の場合)で広帯域転送を行うために用いられる。SFBUFは単一のVMページでしか使えないために、MSFBUFSが短い時間しか使わない複数のページマッピングを操作するのに用いられる。

SFBUF概念FreeBSDプロジェクト英語版デイビッド・グリーンマン英語版がsendfile(2)[6]を書いたときに考案された。そして、この概念アラン・L.・コックス英語版マシュー・ディロン英語版によって書き直された。また、MSFBUFハイテン・パーンディヤ英語版マシュー・ディロン英語版により考案された。

開発の方向性[編集]

対応プロセッサー[編集]

DragonFly BSDは、現在では、x86(インテルAMD)及びx86-64アーキテクチャーベースの計算機で動作する。これは単一プロセッサーSMPも両方対応している。

パッケージ管理[編集]

初期のDragonFly BSDでは、FreeBSDportsパッケージ管理システムとして使っており、NetBSDpkgsrcオプションとして使えるに過ぎなかった。しかし、DragonFly BSD 1.4からpkgsrcシステムの公式なパッケージ管理システムとなった[7]。これで、開発者は追加でインストールされるソフトウェアアップデート作業から解放されることになった。また、この変更はpkgsrc開発者がpkgsrc移植性を高めるのにも役立った。

DragonFly BSD 3.4より、新たなパッケージ管理システムとしてDPortsが導入された[8]DPortsFreeBSDportsDragonFly BSDで使用できるようにする仕組みであるが、pkgsrcDPortsを同時には使えない。

スレッドとメッセージング[編集]

システムコールデバイスI/O実装DragonFly BSDスレッドメッセージングシステムを使うように変更されたが、これらは未だに同期して動作している。最終的には、全てのメッセージサブシステム同期又は非同期のどちらでも動作するようにする予定である。

ユーザーランドスレッドサポートも今後のリリースの重要な課題である。DragonFly BSDでは、今のところ、N:1スレッドしか持っていない。これについては、開発当初から取り組んでおり、近代的なスレッド実装になる予定である[9]

ファイルシステム[編集]

DragonFly BSD 2.0より、ファイルシステムとして、HAMMER[10]を採用している。

なお、HAMMER後継として、HAMMER2の開発マシュー・ディロン英語版によって主導されている。

その他[編集]

関連項目[編集]

外部リンク[編集]

注釈・出典[編集]

  1. ^ F.・ジュリアンフランス語版. “DragonFly-1.0 RELEASED!”. 2004年7月12日閲覧。
  2. ^ 例えば、ネットワークコードでは、プロトコル毎に1スレッドとなる。
  3. ^ マシュー・ディロン英語版. “sfbuf.h (TXT)”. 2011年2月14日閲覧。
  4. ^ DragonFly BSDプロジェクト英語版. “SENDFILE(2)”. 2014年8月22日閲覧。
  5. ^ マシュー・ディロン英語版. “xio.h (TXT)”. 2009年9月19日閲覧。
  6. ^ FreeBSDプロジェクト英語版. “SENDFILE(2)”. 2014年8月22日閲覧。
  7. ^ イェルーン・ラウフロック・ヴァン・デル・ウェルヴェンドイツ語版. “PKGSRC will be officially supported as of the next release”. 2005年9月1日閲覧。
  8. ^ ジョン・マリーノイタリア語版. “An introduction to DPorts”. 2013年1月2日閲覧。
  9. ^ マシュー・ディロン英語版によれば、理想的にはM:Nスレッド実装をしたい、とのことである。
  10. ^ DragonFly BSDプロジェクト英語版. “hammer”. 2014年8月23日閲覧。

項目分類[編集]