概要：Phantom OS内のUnix OSとの互換性のためのモジュール内のHummingbird OSとの互換性のためのモジュールの開発）
OS Phantomの中には、気取らない小さなUnixがあります。 POSIXサブシステム。 原則として、Phantom自体はオプションであり、非常に不完全です-その下でUnix Quakeを収集することは可能でしたが、たとえば、Apacheはほとんど確実に収集されません。 それにもかかわらず-彼女はそうです。
続行するには、Hummingbird OSが何であるかを理解する必要があります。 ハミングバード-アセンブラーでのマイクロOSのロシア化された西洋プロジェクト。 実際、この説明は完全です。 x86アセンブラープログラミングのHummingbirdファンは、Hummingbirdに取り組んでいます;したがって、耐えられず、残念ながら、非常に不十分に設計されています。 非常に-それは悲惨です。 災害の規模を理解するために、システムコールの成否を判断する一般的なメカニズムはありません。 障害を特定するのは不可能な人もいれば、個人的なエラーコードセットを返す呼び出しもあれば、他の呼び出しを呼び出す呼び出しもあります。
しかし、なぜ、このOSとの互換性レイヤーを実装したいのですか？ これにはいくつかの理由があります。
- とてもコンパクトです。 将来を見据えて-ファントムのハミングバード向けの最初のプログラムは、4時間の作業後に実行できました。
- このミニプロジェクトは、Phantomの一部のネイティブサブシステムの開発の推進者となり、
特に-ウィンドウ。 - 主なことは、コアで知られているハミングバードプロセスの状態全体が小さな構造に収まることです。 多くの（ほとんどすべての）チャレンジはステートレスです。つまり、知識に依存していません。
カーネルに保存されます。 これは、Phantomでの永続的な（OSの再起動中）バイナリ（バイトコード言語で記述されていない）プロセスの実装の理想的な候補です。
好奇心、盛な
code 、
headerの場合 。
実際、互換性レイヤーの開発はいくつかの明白な部分に分かれています。
- 実行可能画像ローダー
- システムコールエントリポイント
- 既存のシステムコンポーネントのセマンティクスに変換するシステムコール用のガスケット
- 欠落している機能の開発
ハミングバードイメージダウンローダーは、実行中のパッケージプログラムの実装を除き、簡単です。 残念ながら、断片的な仕様に基づいた展開の実装は成功につながらず、理解できる人を見つけることはできませんでした。 展開されたプログラムは非常にシンプルに設計されているため、イメージの検出とロードは既存のエルフブートローダーを問題なく補完しました。 ちなみに、Phantomでは、Hummingbirdsのプログラムは通常のelf-toolchainでコンパイルできます。どのブートローダーがプログラムをロードしたかに関係なく、POSIXシステムコールとHummingbirdsの両方にアクセスできます。 混合可能）
エントリポイントには予期しないものも表示されません。呼び出しは、ソフトウェア割り込み、通常のIDTゲート、および
小さなアセンブラースプリングボードを介して行われ、問題を解決します。
もちろん、主な仕事はシステムコールの実装です。 作業は2つの理由で時間がかかります。1つ目は、呼び出しが概略的に文書化され、2つ目は、作成者が一貫性を保てなかったためです。 たとえば、フィールドの1つにあるプロセスに関する情報を要求する呼び出しは、...ウィンドウが画面上の指定されたz位置にある
別のプロセスの番号を返します。
呼び出しは、「TDDタイプ」の原則に従って行われました。システムコールを実装する代わりに、単にログにエラーを書き込み、アプリケーションプログラムを実行します。未実現のシステムコールが呼び出された場合、呼び出されたものを実装します。 したがって、呼び出しが行われない場合、それを必要とするアプリケーションプログラムに到達していません。
一般に、通話はいくつかのグループに分けられます。
情報
それらを使用すると、すべてが簡単です。 また、情報の一部は定数または偽の形式で発行できるためです。 良い例は
st->eax = dummy++; // TODO n of context switches st->eax = dummy++; // TODO n of context switches -増加、および大丈夫。 もちろん、可能な場合、情報は本物です。
低レベル
ハミングバード-ほとんど保護されていないシステム、プロセスは非常に多くの場合があります-通常はカーネルのみがアクセスできるプロセッサレジスタを変更します。 もちろん、これらの課題のほとんどは、単に実装されていません。
ファイル操作
Hummingbirdのファイル操作はほぼ一貫しています（少なくともエラーコードは同じです）が、実装は非常に高価です-それらはすべてカーネルにほとんど状態を保存せず、実際にはopen / do / closeグループになります。 つまり、呼び出しごとにファイルから読み取ると、ファイルが開いたり閉じたりします。 原則として、ファイル名のハッシュマップを使用してこれを最適化して、オープンな記述子のプールを保持することができますが、これは週末のプロジェクトスコープには含まれません。 しなかった。 実装の残りの部分は多かれ少なかれ簡単です。
グラフィックス
それから私は問題を予想しました。 彼らはそうでしたが、大部分はそうであったかもしれないほど気味が悪いです。 しかし、私はまだハチドリのグラフィックサブシステムの作者の表現を理解していないという感じがあります-いくつかのプログラムはうまく動作し、いくつかは奇妙です。 残念ながら、元の実装のソースコードを実際に読み取らない限り、ここでの進行はおそらく不可能であり、ソースコードはアセンブラーで思い出します。 私は自分自身に十分な勇気を見つけられず、プログラムのサブセットがうまく機能したという事実に落ち着きました。
ハミングバードグラフィックスの主な違いは、カーネルが伝統的に適用されているウィンドウコンポーネントの一部、特にボタンを実装することです。 Phantomウィンドウシステムには準備ができた仲間はいませんでした。 明らかに、Hummingbirdのアプリケーションコードは、カーネルで使用される特定のフォントに厳密に結び付けられています。フォントを抽出し、Phantomウィンドウサブシステムの形式に変換し、さらにフォントの視覚化コードを若干改良する必要がありました。 一般に取るに足らない他の小さなものがありました。
実装されているがテストされていない
ハミングバードは、シンプルなIPCメカニズム-メールボックスをサポートしています。 概略的に実装されていますが、詳細なテストは行われていません。 追加のプロセススレッドの実装も実装されています-深刻なテストも行われていません。 ところで、カーネルの状態のどの部分がプロセスに関係し、どの部分がスレッドに関係するのかは明確ではありません。
行方不明です
メモリマッピング制御機能は完全には実装されていません-現在、Phantomカーネルは1つのアドレススペースのみで動作します（UnixおよびHummingbirdプロセスはx86セグメントアドレッシングメカニズムを介してサポートされています）。 同じ事実により、プロセスアドレススペースのサイズの変更を実装することは（可能ですが）困難です。 DLLのサポートは実装されていませんが、ハチドリ自身は非常に非アクティブなDLLを使用しており、計画では必要最小限のものを作成することでした。 ただし、これは複雑ではないようです。
プロジェクト開発
作業を続行するには以下が必要であることは明らかです。
- 一連の回帰テスト。 a）コンポーネントの内部単体テストの形式であることが望ましい。
b）特別なテストアプリケーションプログラム、およびc）既存のプログラムの実行とそのパフォーマンスの制御。 - オリジナルの実装コンプライアンスに関する経験豊富なハチドリカーネル開発者によるコードレビュー
- パラメータの許容性と有意性について、すべてのHummingbird-Phantomエントリポイントの詳細な検証のためのコードレビュー。
一般的に、Hummingbird OS開発チームのヒーローが必要です。 私はヒーローが必要です:)