DragonFly BSD(ドラゴンフライ ビーエスディー)は、NetBSDやFreeBSDと同じくBSDの子孫の1つの、オープンソースのUnix系オペレーティングシステムである。
マシュー・ディロン(英語版)がプロジェクトリーダーとなり、2003年にFreeBSD 4.8-STABLEから分岐する形で開発が始まり、2004年7月12日に初のメジャーバージョンであるDragonFly BSD 1.0が公開された[2]。
DragonFly BSDは、FreeBSD 4.xの後継というだけでなく、FreeBSD 5.xとも全く異なる方針で開発されている。この例として、LWKTや軽量メッセージシステムがある。このような多くのDragonFly BSDに実装される概念は、AmigaOSに触発されている。
バージョン4.8からは、インストーラーでUEFIがサポートされている[3]。
DragonFly BSDには、最近の殆どのカーネルのように、ハイブリッドカーネルが採用されている。つまり、これは、モノリシックカーネルとマイクロカーネルの両方の性質を併せ持ち、必要に応じて両方のメリットを使うということである。例えば、マイクロカーネルのメッセージシステムにあるようなメモリ保護の恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。メッセージサブシステムは、Machのようなマイクロカーネルのデザインと似て、余り複雑ではないものになっている。さらに、これは同期通信と非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。
デバイスI/Oや仮想ファイルシステム (VFS) はメッセージサブシステムを使うように変更されている。これらの新しい機構に拠り、カーネルの様々な部分をユーザーランドで実行可能になる。ユーザーランドでカーネルの一部を実行すると、その部分はカーネルという大きなプログラムの一部ではなく、小さく独立した1つのプログラムとなる。こうすることで、ユーザーランドで動いているドライバーがクラッシュしても、カーネル全体はクラッシュしなくなるという利点もある。
システムコールはユーザーランド版とカーネルランド版に分けられ、メッセージとしてカプセル化されるようになった。これに拠って、標準システムコールの実体をユーザーランドにある互換レイヤーに移すときのプログラム量と複雑さを軽減可能になると同時に、新旧のDragonFly BSDの互換性を保ちやすくなった。さらに、Linuxやその他のUNIX系OSのアプリケーションを動かすための機構もユーザーランドに移せる。このようなFreeBSD jail上に作られたネイティブなユーザーランド互換レイヤーを使うことで、UMLと同等のことができる。しかし、UMLと異なり、仮想化には実際のハードウェアと通信するための特別なドライバーを必要としない。なお、UMLはLinuxをポーティングしたもので、ホストOSのカーネルを別のハードウェアプラットフォームと見なす実装になっている。
スレッドはCPUに強く結び付けられるというデザインになっていて、各々のCPUはそれぞれLWKTスケジューラーを持っている。なお、スレッドが勝手に動作するプロセッサーを変えることはできず、IPIメッセージを使った場合のみ別のCPUへとスレッドが移される。そして、CPUを跨ぐスレッドスケジューリングも非同期のIPIメッセージを送ることで行われる。この方法を使うと、スレッドサブシステムを綺麗に区切れるが、その利点は、SMPシステムにて複数のCPUのキャッシュに同一データが乗らない、ということである。これに拠り、システムの各プロセッサーがスレッドの実行のために異なったデータをキャッシュできるようになり、高い性能を出せる。
LWKTサブシステムでは複数のカーネルスレッドに処理を分けるように実装された[注釈 1]。これに拠り、複数のカーネル内タスクでリソースを共有することで生じる競合状態を無くせる。このようにCPU毎の局所性を保つようにするアルゴリズムでスレッドを分ける実装は間違いなくDragonFly BSDに特有のデザインである。
共有資源(ファイルやデータ構造体など)へのアクセスは、マルチプロセッサーマシーンで安全に動作させるためには、直列化されなくてはならない。こうすることで、スレッドやプロセスは同時に同じ資源を変更できなくなる。アトミック操作・スピンロック・クリティカルセクション・ミューテックス・直列化トークン・メッセージキューは全て同じ資源への同時アクセスを防ぐのに使える方法である。LinuxもFreeBSD 5.xも粒度の細かいミューテックスを使ったモデルを用いることでより高性能なマルチプロセッサーシステムを構成しているが、DragonFly BSDはそうではなく、複数のスレッドが共有リソースに同時にアクセスしたり変更したりするのを防ぐために、クリティカルセクションと直列化トークンを用いている。最近まで、DragonFly BSDもSPLを使っていたが、その部分はクリティカルセクションで置き換えられた。
LWKTサブシステム・IPIメッセージサブシステム・新しいメモリアロケーターなどを含むシステムの中心的な部分の多くはロックしない。つまり、ミューテックス無しで動き、CPU毎に処理を行う。クリティカルセクションは局所的な割り込みから守るために使われ、CPU毎に処理を行う。これに拠り、動かされているスレッドはCPUを横取りされないことが保証されている。
直列化トークンは他のCPUからの並列アクセスを防ぐために使われ、複数のスレッドで同時に保持される。この結果、それらのスレッドの一つが与えられた時間に処理を行うことが保証される。それゆえ、ミューテックスを持っているスレッドと違い、ブロックされていたりスリープしているスレッドは他のスレッドが共有リソースにアクセスすることを禁止しない。直列化トークンを使うことで、ミューテックスを使った場合のようなデッドロックや優先度の逆転を引き起こす状況を防げる。これに加え、複数のスレッドで共有するようなリソースを要求する長いプロシージャーの設計や実装をずっと単純にできる。直列化トークンの実装は最近のLinuxにあるRCUによく似たものに発展しているが、計算機内の全てのプロセッサーではなく同じトークンで競合しているプロセッサー同士が影響を受ける、という実装になっている。
開発の初期段階では、スラブアロケーターが採用され、FreeBSD 4.xのカーネルメモリアロケーターから置き換えられた。これはメモリを割り当てるときに排他制御やブロック操作を必要とせず、MPSAFEである。
SFBUF[4]とMSFBUFが使われている。SFBUFは短い時間しか使わない単一ページのマッピングを操作するのに用い、必要ならそれらのマッピングをキャッシュする。これらの機構は単一のVMページで保持されているデータへの参照を補うために使われる。この単純で強力な抽象化に拠って様々なことが可能になる。例えば、sendfile(2)[5]でのゼロコピーが実現されている。
SFBUFはカーネルの様々な箇所で用いられる。例えば、vnodeオブジェクトのページャーやパイプサブシステム(XIO[6]を用いた間接転送の場合)で広帯域な転送を行うために用いられる。SFBUFは単一のVMページでしか使えないために、MSFBUFSが短い時間しか使わない複数のページのマッピングを操作するのに用いられる。
SFBUFの概念はFreeBSDプロジェクト(英語版)のデイビッド・グリーンマン(英語版)がsendfile(2)[7]を書いたときに考案された。そして、この概念はアラン・L.・コックス(英語版)とマシュー・ディロン(英語版)によって書き直された。また、MSFBUFはハイテン・パーンディヤ(英語版)とマシュー・ディロンにより考案された。
DragonFly BSDは、現在では、x86-64アーキテクチャーベースの計算機(インテルとAMD)で動作する(32ビットへの対応は、3.8 を最後に打ち切られた[8])。これは単一プロセッサーもSMPも両方対応している。
初期のDragonFly BSDでは、FreeBSDのportsをパッケージ管理システムとして使っており、NetBSDのpkgsrcはオプションとして使えるに過ぎなかった。しかし、DragonFly BSD 1.4からpkgsrcがシステムの公式なパッケージ管理システムとなった[9]。これで、開発者は追加でインストールされるソフトウェアのアップデート作業から解放されることになった。また、この変更はpkgsrcの開発者がpkgsrcの移植性を高めるのにも役立った。
DragonFly BSD 3.4より、新たなパッケージ管理システムとしてDPortsが導入された[10]。DPortsはFreeBSDのportsをDragonFly BSDで使用できるようにする仕組みであるが、pkgsrcとDPortsを同時には使えない。
システムコールとデバイスI/Oの実装はDragonFly BSDのスレッドメッセージングシステムを使うように変更されたが、これらは未だに同期して動作している。最終的には、全てのメッセージサブシステムを同期又は非同期のどちらでも動作するようにする予定である。
ユーザーランドスレッドのサポートも今後のリリースの重要な課題である。DragonFly BSDでは、今のところ、N:1スレッドしか持っていない。これについては、開発当初から取り組んでおり、近代的なスレッド実装になる予定である[注釈 2]。
DragonFly BSD 2.0より、ファイルシステムとして、HAMMER[11]を採用している。
HAMMERの後継として、HAMMER2の開発がマシュー・ディロンによって主導され、DragonFly BSD 5.0より実験的にサポートされ、DragonFly BSD 5.2より公式にサポートされる。
FreeBSDとOpenBSDと同様に、DragonFly BSDの開発者は関数プロトタイプスタイルのCのコードを、より現代的でANSI準拠のものに少しずつ置き換えている。他のOSと同様に、DragonFlyのバージョンのGCCは、Stack-Smashing Protecterがデフォルトで有効になっており、バッファ・オーバーフローに基づいた攻撃に対する追加的な保護を提供している。ただし、2005年7月23日からは、この保護付きのカーネルのビルドはデフォルトではない[13]。
FreeBSDの派生物として、DragonFlyは、簡単に使うことができる統合されたビルドシステムを持ち、このシステムは、ベースシステムの全体をソースコードから少ないコマンドでリビルドすることができる。DragonFlyの開発者たちは、GitをDragonFlyのソースコードを管理するために使っている。また、FreeBSDとは違って、Dragonflyは、安定版と非安定版のリリースの両方をひとつのソースツリーに持っており、これはより小さな開発ベースによるものである[14]。
OSは、Live CDとLive USB(完全なX11フレーバーが利用可能)として配布され、これは完全なDragonFlyのシステムにブート可能である[15]。また、このメディアは、マニュアルページの完全なセットとソースコード、将来のバージョンで有用なパッケージとベースシステムを含んでいる。このことの優位点は、単一のCDで、ソフトウェアをコンピュータにインストールすることができ、フルセットのツールをダメージを受けたシステムの修復に利用することができ、システムの能力をインストールなしでデモンストレートすることができることである。デイリースナップショットは、マスターサイトから利用することができ、これは最も最近のバージョンのDragonFlyをソースからのビルドなしで利用したいと考えているユーザーに向いている。
DragonFlyは、他のオープンソースのBSDと同様に、現代のバージョンのBSDライセンスの下で配布されている。
Lokasi Pengunjung: 3.141.42.250