HelenOSについて興味があるのだが、日本語の情報がない。 FAQを読んでみたので記載しておく。 2019年1月18日時点のhttp://www.helenos.org/wiki/FAQの内容である。
基礎的な概念
マイクロカーネルとは何か?
マイクロカーネルオペレーティングシステムでは、 デバイスドライバーやファイルシステム、ネットワーキングなどの機能は、 カーネルスペースからユーザースペースへと追い出されている。 カーネルの外のコードは、通常のユーザープロセスとして実行される。 マイクロカーネル自体は、ユーザープロセスが実行と通信できる最低限の機能のみを提供する。 これは、伝統的なモノリシックなオペレーティングシステムが、これらのほとんどを カーネル内部に持っているのと対照的である。 マイクロカーネル設計に従ってオペレーティングシステムを構築する根拠は、 オペレーティングシステムのポリシーのほとんどをユーザースペースへと追い出し、 マイクロカーネル自体を可能な限りポリシーから自由にし、より大きな 拡張性を実現することである。 このことにより、マイクロカーネルは異なるオペレーティングシステムとしての性格を 提供することもできる。 これは同時に複数の性格を1つのマイクロカーネルの上に構築することさえ論理的には可能とする。 これにより、オペレーティングシステムカーネルに機能をハードコードするのではなく、 簡単に機能を変更できるようになる。 マルチサーバーマイクロカーネルにより、限定的なフォールトトレラントな利用も可能となる。 モノリシックなオペレーティングシステムのカーネルドライバーにバグがあった場合、 通常はシステム全体がクラッシュする。 しかし、マイクロカーネルオペレーティングシステムのユーザースペースドライバーにバグがあっても、」 ドライバーを実行するユーザープロセスがシステム全体をクラッシュさせることはない。
マルチサーバーとは何か?
マイクロカーネルオペレーティングシステムの視野の範囲内では、 マルチサーバーは、複数のユーザープロセスにまたがってオペレーティングシステムの機能が 広がっていることを指す。 これは、全ての機能が1つのユーザープロセスに集約されているシングルサーバーマイクロカーネル とは異なる。 システムをマルチサーバーにしようという動機は、 シングルサーバーシステムにおける唯一のサーバープロセスという単一障害点をなくしたい と言うことである。 マルチサーバーシステムのもう1つの利点は、明示的なインターフェイスを通してのみ通信できる 小さくてシンプルなコンポーネントの集まりにできるということである。 小さくてシンプルなコンポーネントの集まりにすることで、考慮すべきことを分離でき、 1つのことをよく実行でき、理解することも容易になる。 明示的なインターフェイスにより、コンポーネントは交換可能となり、 コンポーネントの粒度レベルでのシステムの正しさも分かりやすくなる。 同時に、コンポーネントを間違った方法で利用することも難しくなる。
マイクロカーネルベースのシステムは根源的に遅いのではないか?
遅くはないが、モノリシックカーネルと比較して、多くのコンテクストスイッチやアドレス空間の スイッチが必要であり、性能上不利ではある。 しかし文献が 示すように、しかるべき配慮をしてシステムを実装すれば、この不利は6%程度まで小さくできること が分かっている、 この不利は、マイクロカーネルベースのシステムから得られる利点の妥当な対価であると考えられる。 これは、例えるならば、快適に高級言語を使うために、いくらかの性能を犠牲にすることに似ている、
HelenOS一般に関する質問
HelenOSとは何か?
HelenOSは、一から書かれたオープンソースのマイクロカーネルベースの マルチサーバーオペレーティングシステムである。 IA-32やx86-64、SPARC V9、IA-64、PowerPC、ARM、MIPSのそれぞれ異なるCPUアーキテクチャー で動く。 HelenOSは、移植性、モジュール化、クリーンな設計、コーディングスタイルを誇りとしている。
HelenOSは何に利用されているか?
HelenOSを単に趣味として扱っている人もいるし、オペレーティングシステムの研究といった分野での 職業的な目標を成し遂げるために使っている人もいる。 HelenOSは、プラハのカレス大学のFaculty of Mathematics and Physicsにおいて、 オペレーティングシステムの講義の宿題のためのプラットフォームとして利用されているし、 学士の卒業論文や修士論文、チームのソフトウエアプロジェクトのプラットフォームとしても 利用されている。
この点に関して、私たちがHelenOSを研究開発のためだけに役立つとは考えていない。 実用できるまであと一歩のところへ来ている、
エンドユーザーとして何ができるか?
私たちがコマンドラインと単純がグラフィカルユーザーインターフェイスを持っており、 ファイルを操作したり、アプリケーションを実行したり、ファイルシステムを ディスクやディスクイメージからマウントしたりすることができる。 テトリスで遊ぶことも、テキストファイルを編集することもできる。 HelenOSは、UCS (つまりUnicode)を利用して、多国語テキストをサポートしている。 ネットワーク機能もあり、単純なウェブサーバーをHelenOS上で動かすこともできるし、 HelenOSをネットワーク経由で制御することもできる。 HelenOSは音楽を再生することもできる。 GCCやbinutils、Python、pccといったサードパーティーの開発ツールも移植してある。
HelenOSで何をしようとしているか?
主に3つある。 1つ目は、完全な役に立つオペレーティングシステムを作ることである (つまり、少なくともいくつかの毎日のタスクを実行するにに利用できるシステムである。 ルーターとしてやサーバーとして、PDAとして、デスクトップとしてなど)。 2つ目は、新しいアイディアやアプローチを実際に使えるオペレーティングシステムの設計を実装で 実験することである。 最後は、それだけではないが、HelenOSを開発する目的は楽しむことである。
HelenOSの開発体制は?
HelenOSの開発はコミュニティー主導であり、長期的な開発者であるコアチームと、 コントリビューターのゆるやかな集まりで構成されている。 全ての開発者とコントリビューターの主なコミュニケーション媒体は development mailing listである。 現在のところ、ほとんどの長期的な開発者がプラハ(またはその近郊)にいるため、 私たちは開発者ミーティングを毎月1回プラハで開催している。 議事録は、通常はメーリングリストで公開される。 HelenOSコミュニティーの意思決定プロセスは、オープンで合意を共同で決定すると言うものであり、 実力主義でもある。 動くコードの重さは千の言葉より重いが、コードは意図が明確で、良い設計がされ、十分に 文書化されていなくてはならない。
HelenOSのソースコードはどこにあるか?
HelenOSのソースコードは、現在は Gitで管理されており、 開発者はhttps://github.com/HelenOS のリポジトリーをcloneすることで、GitHub上に 開発ブランチをホストしておくことが勧められている。
HelenOSに貢献するに当たってどこから始めたら良いか?
私たちはWiki上にに将来のコントリビューターを助け導くためにいくつかのページを用意している。 summary for contributorsと、 tips for (not only) students (本当に学生だけを対象にしているのではない)と、 これらのページからリンク先を注意深く読んで欲しい。 どんなコントリビューターにも最初に必要なことは、HelenOSをソースからコンパイルできるように なることである。 しかし、単にHelenOSを試してみるだけであれば、ソースコードからHelenOSをビルドする 必要はない(ビルド済みのサポートされたHelenOSイメージを簡単に実行できる)。
もし、バグを報告することによって貢献したいならば、バグの報告の仕方についてを読んで欲しい。 また、このFAQを読み終えるようにもして欲しい。FAQではHelenOSの大きな将来像について説明されている。
他のシステムとの比較
HelenOSはUNIXとどう違うか?
HelenOSとUNIX-likeシステムの設計の違いについて、私たちのページで説明しているので読んで欲しい。
HelenOSはGNU Hurdとどう違うか
GNU Hurdは、UNIXをMachマイクロカーネル上で
マルチサーバーとして再実装しようとしている。
バージョン0.7の時点で、Hurdはシングルプロセッサーのia32システムで動く。
amd64への移植は作業中である。
Hurdのコンポーネントには、ext2fsファイルサーバーやpfinet
ネットワーキングサーバーのように太古のバージョンのLinuxから拾って来たものもあるが、
オリジナルのものもある。
ネットワーキングスタックは、シングルプロセスアーキテクチャーである。
NICとディスクドライバーはLinuxから取り込まれているが、カーネルモードのMachの一部として
動いている。
DDE互換レイヤーと通し、ユーザーモードでLinux 2.6.xのネットワーキングとディスクの
ドライバーを動かそうという実験的なバージョンが存在する。
Hurnのハードウェアサポートは限られている。
バージョン0.7の時点では、USBやサウンド機能をサポートしていない。
しかし、rumpカーネルを使ってUSBとサウンド機能をサポートしようという実証用の
実験的な実装は存在している。
Hurdはマルチユーザーシステムであり、特権を持たないユーザーが、
ある種のタスク(信頼されない/実験的なファイルシステムをファイルシステムの名前空間内で
アクセス可能にすることなど)を管理者の特権をなしに行えるようにする方法を構築することに重点が
置かれている。
Hurdは動的な構成の変更について、トランスレーターメカニズムを通して大きなフレキシビリティーを
与えている。
ユーザーはIPCサーバーを任意のファイルシステムノードと関連付ける(トランスレーターを設定する)
ことにより、そのファイルシステムノードを訪れた際にシステムの挙動を変更することができる。
GNU Hurdのディストリビューションは2つある。Debian GNU/HurdとArch Hurdである。
前者はDebianのパッケージの80%が対応しており、何万ものパッケージが良い状態にある。
一方HelanOSは、他のレガシーシステムの何かを再実装しようとするマルチサーバー環境ではない。 HelenOSはSPARTANと呼ばれる独自のマイクロカーネルを持っている。 またia32以外にamd64やarm32、ia64、mips32、ppc32、sparc64をそれぞれの度合で サポートしており、マルチプロセッサーをサポートしているアーキテクチャーもある。 ファイルシステムやネットワーキングスタック、デバイスドライバー、GUIといったほとんどの HelenOSのコンポーネントは、HelenOSのために独自に実装されており、 互換レイヤーやグルーといった余計なものは実施のところ導入されていないし、 サードパーティーのコンポーネントをサポートする手間もない。 ネットワークスタックは、いくつかのプロセスに分離されており、 IPやTCP、UDPといったスタックの部分ごとに実装されている。 基本的に全てのHelenOSのデバイスドライバーはユーザーモードで動く。 例外はデバッグ目的のものとタイマーと割り込みコントローラーのドライバーだけである。 HelenOSは、USBもサウンド(Sound Blaster 16とIntel HDA)をサポートしている。 HelenOSはシングルユーザーのオペレーティングシステムであるが、 マルチユーザーサポートのための実験的な作業も行われて来ている。 トランスレーターメカニズムに最も近いのは、ロケーションファイルシステムにサービスを 割り当てる機能である。 システムの構成は、あるIPCプロトコルを実装しそれぞれに積み重ねられたユーザースペース のサービスをspawnしたりkillしたりすることで、動的に変更可能である。 HelenOSは、現在のところあまり多くのユーザーアプリケーションをサポートしていない。 主にサブシステムやフレームワーク。ドライバーに注力しているためである。 いくつかの標準的な開発ツール(例えば、binutils、gcc、pythonなど)をHelenOS上で動かす 非常に限定されたサポートが存在する。
HelenOSはMINIX 3とどう違うのか?
MINIX 3
は、独自のマイクロカーネルコアサービス、NetBSDのユーザーランドを持った
マルチサーバーシステムである。
マイクロカーネルはマルチスレッドをサポートしていない。
バージョン3.3.0の時点で、MINIXはシングルプロセッサーのia32とarm32システムで動く。
マルチプロセッサーをサポートするコードは存在するが、バージョン3.1.x以降メンテナンス
されていない。
MINIX 3は2つのネットワーキングスタックを持っている。
独自のinetサーバーとlwIPネットワーキングスタックベースのlwip
サーバーである。
lwIPは実験的なIPv6サポートを含んでいるが、両方のサーバー共にIPv4のみである。
lwipサーバーのIPv6サポートは作業中である。
inetとlwipのいずれもモノリシックなアーキテクチャーで
IPとUDP、TCPは1つのプロセスである。
ネットワーキングスタックをモジュール化する研究も行われている。
ファイルシステムとほとんどのデバイスドライバーはMINIX独自で開発されている。
バージョン3.3.0の時点で、MINIXはUSBハブとUSBマスストレージ、MUSB OTGコントローラー
(いくつかのSoCには搭載されている)をサポートしている。
DDE互換レイヤー内でLinux 2.6.29のUSBドライバーを使う開発版のMINIX 3が存在する。
MINIX 3の売りは、信頼性である。
MINIX 3は、ある場合に動く復活サービスを含んでおり、
これによりクラッシュしたり正しく動かなくなっているサービスを再起動させる。
MINIX 3の開発版は、動いているサービスのライブアップデートをサポートしている。
NetBSDユーザーランドのおかげでMINIX 3は何千ものパッケージを持っている。
繰り返しを避けるため、1つ前の質問に対する答えも見て欲しい。 それに加えて、HelenOSカーネルはカーネルスレッドを実装している。 HelenOSのモジュール化されたネットワーキングスタックは、IPv4とIPv6の両方をサポート している。HelenOSのUSBスタックは、UHCIとOHCI、EHCI、XHCIをサポートしている。 USBハブとヒューマンインターフェイスデバイス(つまり、マウスとキーボード)、 マスストレージデバイスのドライバーが利用可能である。 HelenOSは復活サービスもライブアップデートも持たない。
HelenOSはGenodeとどう違うか?
Genode
はマルチサーバー環境において多くのサードパーティーのコンポーネントを
利用しやすくするオペレーティングシステムコンポーネントフレームワークである。
Genodeは、いくつかの異なるマイクロカーネル(とLinuxといったモノリシックカーネルさえも)
を、多くのオリジナルまたはラップされたユーザースペースコンポーネント(例えば、DDE互換レイヤー
でラップされた外部由来のデバイスドライバーやrumpカーネル)と組み合わせることを
サポートしている。
ユーザースペースのコンポーネントの粒度は様々であり、細かいものから大きくモノリシックな
ものまである。
もちろん、全ての理論的なコンポーネントの組み合わせが、Genodeで動く訳ではないし、
機能セットも異なる。
Genodeはコンポーネントをツリー状の階層構造に保持する再帰的なシステム構造を使っている。
親コンポーネントは子コンポーネントを完全に制御下におき、同時に子コンポーネントに
開始時にRAMといったリソースを与える。
Genodeコンポーネントと特にルートのcoreコンポーネントは、
提供するサービスに対するリソースの割り当てを要求することで、効率的なリソースの管理を
強制している。
Genodeコンポーネントは、特別なリソースの取り引きプロトコルを使い、
リソースの消費を動的に調整している。
Genodeと比べて、HelenOSは一貫して移植性の高いマイクロカーネルと、 きめ細かくHelenOSネイティブに設計されビルドされたマルチプラットフォームなユーザーランド を組み合わせている。 私たちは、外部のコンポーネントを他のオペレーティングシステムからインポートして それを冗長な互換レイヤーでラップするよりも、独自のコンポーネントを設計して 実装するのを強く志向しており、特にHelenOSのクリティカルなコアコンポーネントについては、 そうである。 HelenOSは基本的なリソース管理をサポートしているが、現在はGenodeのように精巧なものではない。 Genodeのコンポーネントとは異なり、HelenOSのコンポーネントは、厳密な階層構造ではなく、 システム全体の構造はよりフラットである。
HelenOSはL4Reとどう違うか?
L4Reは、Fiasco.OCマイクロカーネル上に構築されたマルチサーバーの
オペレーティングシステムフレームワークである。
カーネルはケーパビリティーベースで、リアルタイム機能を持っている。
2017年10月のr75リリース時点では、L4Reはamd64とarm32、ia32、mips32、mips64の
プロセッサーアーキテクチャーで動く。
SMPをサポートし、仮想化を特徴とする。
マイクロカーネルは、数個のカテゴリーに分類されるユーザースペースのコンポーネントを
実行する。
カテゴリーは、ネイティブL4Reコンポーネント(例えば、ルートとinitタスク、I/Oマネージャー、
ドライバー、GUIウィンドウマネージャー、仮想マシンモニター)と、準仮想化VM(L4linux)、
完全仮想化VM、デモンストレーション目的のサードパーティーコンポーネントがある。
実行時のシナリオは、ほとんどは(これには限定されないが)、initタスクとI/Oマネージャーを
2つのLuaスクリプトで静的にセットアップされる。
L4ReはPOSIXインターフェイスを提供し、多くのコントリビュートされたパッケージの利用が
可能になっている。
L4Reはまたネイティブとサードパーティーのデバイスドライバーとサーバーコンポーネントを混在して
利用している。
特に、サードパーティーのコンポーネントは、歴史的にLinux 2.6.29からインポートされた
ものをDDEフレームワークを利用して有効化されている。
これにより、互換性のあるLinuxデバイスドライバーの再利用が可能になっている。
より最近では、L4ReはL4linuxを利用し、さらにデバイスドライバーOSとして
完全仮想化VMも利用している。
L4linuxはサーバーコンポーネントとしても利用可能である。
過去にリリースされたバージョンは、Linux NICドライバーとDDEとlwIPネットワーキングスタックを
組み合わせたネットワーキングサーバーの痕跡を含んでいる。
しかし、r72リリースでは、無効化され壊れているとマーキングされている。
一方で、HelenOSは、いくらか違うプロセッサーアーキテクチャーをサポートしている。 、あた、いくつかの実験的な修士論文の結果として、現在は約束はできない。 HelenOSのカーネルはリアルタイム機能を提供しない。 HelenOSのコネクション志向のIPCは、基本的には単一の種類のカーネルオブジェクト (非同期IPCでHelenOSではanswerboxとして知られている)のための粗い粒度のケーパビリティー システムである。 HelenOSは一般性があり動的でシングルユーザーな汎用システムを、多数きめ細やかなコンポーネントから 作ることを目的としている。 HelenOSは、ほとんど全て独自のドライバーやフレームワーク、GUI、ネットワーキング、 ファイルシステムを展開する。
ツールチェインに関する質問
なぜclangを主なコンパイラーとして使わないのか?
実際、いくつかのアーキテクチャー)ia32とamd64では、代替のコンパイラーとしてclangを サポートしている。 しかし、今の所、clangはHelenOSのサポートするCPUアーキテクチャーの全てをサポートは していない。 そのためデフォルトではGCCがHelenOSをビルドするのに利用される。
