DragonFly BSD













































DragonFly BSD
開発者
  • マシュー・ディロン（英語版）
OSの系統
BSD、FreeBSD
開発状況
Current
ソースモデル
オープンソース
最新安定版リリース
5.4[1] / 2018年12月3日（49日前） （2018-12-03）
対応プラットフォーム
  • AMD64
カーネル種別
ハイブリッドカーネル
ライセンス
BSDライセンス
ウェブサイト
www.dragonflybsd.org
テンプレートを表示

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]。




目次






  • 1 カーネルの設計


    • 1.1 CPU局所化


    • 1.2 共有資源の保護


    • 1.3 その他




  • 2 開発の方向性


    • 2.1 対応プロセッサー


    • 2.2 パッケージ管理


    • 2.3 スレッドとメッセージング


    • 2.4 ファイルシステム


    • 2.5 その他




  • 3 注釈・出典


  • 4 関連項目


  • 5 外部リンク





カーネルの設計


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


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


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



CPU局所化


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


LWKTサブシステムでは複数のカーネルスレッドに処理を分けるように実装された[4]。これに拠り、複数のカーネル内タスクでリソースを共有することで生じる競合状態を無くせる。このように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[5]とMSFBUFが使われている。SFBUFは短い時間しか使わない単一ページのマッピングを操作するのに用い、必要ならそれらのマッピングをキャッシュする。これらの機構は単一のVMページで保持されているデータへの参照を補うために使われる。この単純で強力な抽象化に拠って様々なことが可能になる。例えば、sendfile(2)[6]でのゼロコピーが実現されている。


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


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



開発の方向性



対応プロセッサー


DragonFly BSDは、現在では、x86-64アーキテクチャーベースの計算機（インテルとAMD）で動作する（32ビットへの対応は、3.8 を最後に打ち切られた[9]）。これは単一プロセッサーもSMPも両方対応している。



パッケージ管理


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


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



スレッドとメッセージング


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


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



ファイルシステム


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


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



その他




  • devfsがGoogle Summer of Code 2009のプロジェクトとして実装された。


  • PUFFSがNetBSDから移植された。


  • USB4BSDがFreeBSDから移植された。

  • バージョン4.0.1より、i386アーキテクチャ（32ビット版x86）のサポートが廃止されてx86_64版のみがサポートされることとなった[14]。





FLOSS logo.svg ポータル FLOSS


注釈・出典





  1. ^ “DragonFly BSD 5.4”. Dragonfly BSD (2018年12月3日). 2018年12月4日閲覧。


  2. ^ F.・ジュリアン（フランス語版）. “DragonFly-1.0 RELEASED!”. 2004年7月12日閲覧。


  3. ^ 末岡洋子 (2017年3月29日). “UEFIをサポートした「DragonFly BSD 4.8」リリース”. 2017年6月21日閲覧。


  4. ^ 例えば、ネットワークコードでは、プロトコル毎に1スレッドとなる。


  5. ^ マシュー・ディロン（英語版）. “sfbuf.h (TXT)”. 2011年2月14日閲覧。


  6. ^ DragonFly BSDプロジェクト（英語版）. “SENDFILE(2)”. 2014年8月22日閲覧。


  7. ^ マシュー・ディロン（英語版）. “xio.h (TXT)”. 2009年9月19日閲覧。


  8. ^ FreeBSDプロジェクト（英語版）. “SENDFILE(2)”. 2014年8月22日閲覧。


  9. ^ https://www.dragonflybsd.org/docs/faq/FAQ-English/


  10. ^ イェルーン・ラウフロック・ヴァン・デル・ウェルヴェン（ドイツ語版）. “PKGSRC will be officially supported as of the next release”. 2005年9月1日閲覧。


  11. ^ ジョン・マリーノ（イタリア語版）. “An introduction to DPorts”. 2013年1月2日閲覧。


  12. ^ マシュー・ディロン（英語版）によれば、理想的にはM:Nスレッドの実装をしたい、とのことである。


  13. ^ DragonFly BSDプロジェクト（英語版）. “hammer”. 2014年8月23日閲覧。


  14. ^ 末岡洋子 (2014年11月27日). “「DragonFly BSD 4.0」リリース、32ビット対応を廃止しx86_64のみをサポート”. 2016年8月1日閲覧。




関連項目



  • オペレーティングシステム


  • カーネル

    • モノリシックカーネル

    • マイクロカーネル




  • スレッド
    • 軽量カーネルスレッド



  • UNIX
    • UNIXライク


  • Linux


  • BSD

    • BSDの子孫
      • FreeBSD



  • オープンソース



外部リンク



  • 公式ウェブサイト

  • Leaf - DragonFly BSD Developer Resources

  • DragonFly BSD Mailing List Archives

  • DragonFlyBSD bugtracker

  • gitweb.dragonflybsd.org Git

  • avalon.dragonflybsd.org


  • GitHub · Build software better, together.
    • DragonFly BSD



  • FreeBSD and Linux Kernel Cross-Reference
    • DFBSD











  • 表

  • 話

  • 編

  • 歴


Unix と Unix系オペレーティングシステム



  • BSD


    • Darwin

      • macOS

      • iOS

      • watchOS




    • FreeBSD
      • DragonFly BSD


    • NetBSD


    • OpenBSD
      • Bitrig





  • GNU
    • Hurd


  • Linux

  • LynxOS

  • MINIX

  • Plan 9

  • QNX

  • Redox


  • System V

    • AIX

    • HP-UX


    • Solaris
      • illumos







  • BSD

    • 386BSD

    • BSD/OS

    • NEXTSTEP

    • SunOS

    • Ultrix



  • Coherent


  • Mach
    • Tru64 UNIX



  • Research Unix

    • BKUNIX

    • MNOS

    • DEMOS




  • System V

    • A/UX

    • IRIX

    • OpenServer

    • SINIX

    • Solaris
      • OpenSolaris


    • UnixWare



  • XENIX

  • その他


  • Unixの歴史



  • カテゴリカテゴリ


  • コモンズコモンズ


  • ウィキペディア・ブックブック




    • -

    Popular posts from this blog

    宮崎県

    Image
    みやざきけん 宮崎県 高千穂峡 宮崎県旗 宮崎県徽章 国 日本 地方 九州地方 団体コード 45000-6 ISO 3166-2:JP JP-45 面積 7,735.32 km 2 （境界未定部分あり） 総人口 1,079,727 人 （推計人口、2018年10月1日） 人口密度 140 人/km 2 隣接都道府県 大分県、熊本県、鹿児島県 県の木 フェニックス（1966年9月3日制定） ヤマザクラ（2003年2月6日制定） オビスギ（飫肥杉）（2003年2月6日制定） 県の花 ハマユウ（1964年12月22日制定） 県の鳥 コシジロヤマドリ（1964年12月22日制定） 他のシンボル 県の歌：宮崎県民歌（1964年制定） マスコット：みやざき犬（2011年11月11日制定） 宮崎県庁 知事 河野俊嗣 法人番号 4000020450006 所在地 〒 880-8501 宮崎県宮崎市橘通東2丁目10番1号 北緯31度54分39.6秒東経131度25分25.9秒 座標: 北緯31度54分39.6秒 東経131度25分25.9秒 外部リンク 宮崎県 ■ ― 市 / ■ ― 町 / ■ ― 村 地理院地図 Google Bing GeoHack MapFan Mapion Yahoo! NAVITIME ゼンリン ウィキポータル 日本の都道府県/宮崎県   表示   ウィキプロジェクト 宮崎県 （みやざきけん）は、九州地方南東部に位置する日本の県である。県庁所在地は宮崎市。 県木である「フェニックス」に代表される南国情緒豊かな気候から、1960年代には日南地区を中心とした新婚旅行のメッカだった。現在も春季のプロ野球などのキャンプ地として知られる。 目次 1 地理・地域 1.1 地形 1.2 自然公園 1.3 気候 1.4 自治体 1.5 合併済みの市町村 2 歴史 2.1 神話 2...
    Read more

    濃尾地震

    Image
    濃尾地震 『岐阜市街大地震之図』 歌川国利画 本震 発生日 1891年（明治24年）10月28日 発生時刻 6時38分50秒（JST） 震央 日本 岐阜県本巣郡西根尾村（現・本巣市） 北緯35度35分 東経136度20分（ 地図 ） 規模    マグニチュード（M）8.0 最大震度    震度7： 注1 福井県今立郡鯖江町、愛知県葉栗郡大田島村、東春日井郡勝川村 地震の種類 直下型地震 被害 死傷者数 死者7,273人、負傷者17,175人 注1：当時の震度階級では「激烈」 プロジェクト:地球科学 プロジェクト:災害 テンプレートを表示 濃尾地震 （のうびじしん）は、1891年（明治24年）10月28日に濃尾地方で発生した、日本史上最大の内陸地殻内地震。「 美濃・尾張地震 （みの・おわりじしん）」とも呼ばれている。辛卯の年に発生したことから 辛卯震災 と呼んでいる報告書もある。 目次 1 概要 1.1 震源断層 2 被害 3 各地の震度 4 前兆現象 5 報道 6 学術的な意義 7 地震防災 8 脚注 9 関連項目 10 外部リンク 概要 濃尾地震発生当時の根尾谷断層 濃尾地震を引き起こした根尾谷断層 写真中央を斜めに走る段差が根尾谷断層 濃尾地震は、1891年10月28日6時38分50秒に発生した。震源は、岐阜県本巣郡西根尾村（現・本巣市）、北緯35度35分、東経136度20分付近。河角廣 (1951) は岐阜市付近（北緯35.6度、東経136.6度）に震央を仮定し規模 M K = 7.0 を与え [1] 、マグニチュードは M = 8.4 に換算されているが、明治・大正期の地震については0.5程度大きく見積もられているとされる [2] 。また、震央距離と震度との関係など当時のデータから後にM8.0 [3] とも推定される。アメリカ地質調査所 (USGS) でも8.0としている [4] 。「根尾谷断層帯」が活動した典型的な内陸地殻内地震（いわゆる直下型地震）であり、これは記録が残っている日本の内陸...
    Read more

    シテ島

    Image
    シテ島 Île de la Cité シテ島（トゥルネル橋からの眺望） 所在地 フランス･パリ 座標 北緯48度51分17秒 東経2度20分45秒 座標: 北緯48度51分17秒 東経2度20分45秒 面積 0.225 km² 最高標高 48.854722 m  プロジェクト 地形 テンプレートを表示 シテ島 （シテとう、仏 : Île de la Cité）は、サン＝ルイ島と並ぶ、パリの中心部を流れるセーヌ川の中州である。パリ市内で最も古い歴史をもつパリ1区及び4区に属し、“パリ発祥の地”とも称される。ユリウス・カエサルの『ガリア戦記』では、すでに紀元前1世紀にパリシイ族 (Parisii) が住んでいたことが述べられている。 目次 1 概要 2 歴史ギャラリー 3 名所 4 シテ島の交通 4.1 橋 4.2 鉄道 5 ギャラリー 6 関連項目 7 脚注 8 外部リンク 概要 東半分が4区に、西半分は1区に属する。 ノートルダム大聖堂とパリ警視庁とパリ市立病院（ オテル・デュー・ド・パリ （フランス語版） 、直訳では「パリの神の館」）がある。病院の名前は、旅の病人を宿泊させ、病になれば看病した教会、巡礼教会からの発展の名残である。近代外科医学の開拓者で、床屋医者の出身でもある外科医アンブロワーズ・パレが勤務していた病院としてもその名が知られている。位置関係は大聖堂が警視庁庁舎と向き合い、警視庁の隣に市立病院。 また、この島はとても狭いので、ここの住民たちは夜も一定の時間を過ぎるとトイレの水は流さない等、互いに気配りしつつ一緒に住んでいくことの不便さを味わってきた。ここから「シテ島に住む者」を表す古仏語：citeain （現代仏語：シトワイヤン citoyen 、現代英語：シティズン citizen）の意味が転じ、「 市民 」という言葉が成立したという（仏語：cité は英語：city に相当する）。 中世以来からの狭く入り組んだ路地は、19世紀に入りセーヌ川左岸と共に貧民窟化していた。そうした狭く不衛生で入り組んだ空間は、2月革命に見るようなバリケード戦といった民衆騒...
    Read more