ハードウェアとソフトウェアのソリューションをSPARC SolarisからAMD64 Linuxに移植し、すべてを仮想化した方法

この記事は、古代のUnixを今でも非常に愛している人たちを対象にしていますが、すでにLinuxに移行する必要があることをすでに理解しています...







この話は、私たちの尊敬されている顧客が10歳の機器を操作するリスクを減らし、ライセンスを節約し、UnixからLinuxに切り替えると同時に、このソフトウェアとハ​​ードウェアソリューションを仮想化することを決めたという事実から始まりました。 顧客がSolarisやUnixを好まなかったのではなく、現在のSPARCアーキテクチャと「粗雑な」Solarisオペレーティングシステムに密接に結び付けられたサーバーアプリケーションを仮想化する能力だけが、顧客にとって非常に魅力的でした。 別のポイントは、特別なカードを手頃な価格の「仮想化」ソリューションでPCIインターフェースに置き換える問題でした。 私たちはこのような興味深い仕事をすることにしました。



ソースを見る前に、私たちは何を扱っているのかよくわからなかった。 後で、タスクをよりよく知るようになったとき、UNIXデーモンが次のようであることがわかりました。

1. Solarisカーネルのシステムコールに「拘束」されますが、外部Web APIを使用して柔軟にカスタマイズ可能なマルチスレッドWebサーバー（ デーモン ）
2. PCIスロットのC-shnoy API専用カードに関連付けられたコード
3. Unix-PGPへのIPC呼び出し
4. 多数の特殊なUnixライブラリに関連付けられたコード

そして、このコードとハードウェアとソフトウェアのソリューションを「仮想化」して、Linux上で動作するようにする必要がありました。









「額にある」タスクは解決できないため、タスクを分割することにしました。



また、悪魔のコードはエンディアン-ニュートラルであることが判明しました。



このコードを移植する最良の方法を見つける過程で、Linux上のアプリケーションであるSolarisの移植に関するIBMの技術ガイドを検討しました 。



私が最初に知りたかったのは、 Solarisカーネル呼び出しを比較的POSIX互換のLinuxに移植するのがどれほど面倒かということでした。 Solarisは、POSIX認定OSであり、コアに非常に特殊なスレッド機能があります。 当然、Linuxカーネルには類似物がないものがあります。

• thr_suspend（）;
• thr_continue（）;

デーモンの機能は、これらだけでなく、他のSolarisカーネル関数thr_keycreate（）、thr_self（）、thr_getspecific（）などにも依存していました。 IBMのマニュアルには、Linuxに移植する際にそのようなコードを書き直す必要があると明示的に記載されています。 そしてそれは、クラスを持つ数千行のマルチスレッド低レベルCコードを分析し、書き換える必要があることを意味していました。 他に方法はありませんか？ そして、私たちは彼を見つけたように思えました！ LinuxでSolarisのコードを「 現状のまま 」移植するための「松葉杖」を探して、古いCompaq Solaris互換スレッドライブラリ（ScTL）プロジェクトに出会いました 。 ほら、移植されたデーモンとLinuxカーネルの間にある「レイヤー」があります！ しかし、ここにはありませんでした...



当初は電車に乗っていたCompaq社がTru64 UNIXのプロジェクトを構想し、そのプロジェクトをLinux Intel x86および他のプラットフォームに移植したため、最初はこのプロジェクトを組み立てたくありませんでした。 ScTLソースコードを修正した後、試行錯誤を繰り返して、AMD64上の新しいLinuxカーネルに必要なライブラリを収集することができました。 Linuxデーモンは、Solaris固有の機能を認識し、動作するように見せかけましたが、それだけでした。 ScTLの操作中に、ScTLコード自体でランタイム例外が発生し、デーモンが「クラッシュ」しました。 13歳の「フレッシュネス」のこのコードを理解する時間はありませんでした。私たちは代替案を探し始めました。 選択は明らかで、C ++ 11およびSTLとの最大の互換性が必要だったため、スレッドのPOSIX標準を直接混乱させることなく、std :: threadに留まることにしました。 デーモンはWebサーバーであったため、低レベルのソケットからBoost :: Asioに切り替えることが非常に望ましいものでした。 ソリューションを比較して、比較的単純ですが、GitHubのサードパーティプロジェクト（MITライセンス） プロジェクトでの使用にすでに適しているものを使用することにしました。 アプリケーションクラスでは、std :: asyncと、もちろんラムダがC ++ 11からの非同期性を確保するのに役立ちました。 そのため、Webサーバーを交換し、個別のテストに合格しました。









次の問題は、PCIインターフェイスを備えた特殊な拡張カードを「仮想化」する方法を解決することです。 機能的に同様の機器が市場で入手できましたが、USBインターフェイスを備えていますが、 ハードウェアソリューションでもあります。 お客様が使用するハイパーバイザーにより、USB機器を仮想システムに接続できるようになったため、USBインターフェイスを備えたハードウェアソリューションが仮想環境に接続され、アプリケーションでLinuxで利用できるようになりました。 これにはすべて、PCIカードに関連付けられたコードの大幅な処理、USB機器の操作およびその後のテストのための新しいコードの作成が必要でした。







3番目の問題はPGPでした。 その無料のアナログGnuPGは、SolarisのようにLinuxで必要なシナリオに従って動作することを望まなかったため、IPCをgpgmeライブラリ呼び出しに書き換える必要がありました。その結果、信頼性が向上し、デーモンはネイティブC呼び出しで正常に動作し、緊急事態でエラーを正しく処理し始めました。



4番目の問題は残りました-Unixライブラリへの依存。 しかし、前のタスクを解決した後、これらのライブラリはそれほど大きな問題ではないようでした。 Solarisパッケージを使用してLinuxパッケージマッチングテーブル（アナログ）を作成し、必要なライブラリを含むパッケージと、その目的とデーモンの使用方法を把握しました。 その結果、必要な無料のアナログがすべて見つかり、アセンブリとテストにより、UnixライクなLinux OSがコードベースの移植を容易にすることが示されました。



結論として、私が使用するビルドシステムとターゲットLinuxディストリビューションという2つのポイントについてお話したいと思います。 オリジナルのSolaris用コードでは、Makefileを取得しました。 20年前には良い解決策でしたが、アセンブリに柔軟性が必要であり、 CMakeは探しているものを提供しました：Boostでの作業の構成、ライブラリの異なるバージョンとのリンク、g ++でのABIの変更を考慮します。 CMakeを使用すると、デバッグおよびリリースアセンブリ用のファイルを簡単に生成できます。 ターゲットディストリビューションの状況は、お客様がRed Hat Enterprise Linuxを使用したいのに、エンタープライズではUbuntuが使用されていたことです。 実行可能ファイルのサイズはいくぶん大きくなりましたが、このケースは、最小限の依存関係（.NetおよびJavaの愛好家にこんにちは）でリリースアセンブリの静的コンパイルで終了しました。



その結果、SolarisデーモンをLinuxに移植しましたが、同時にSolaris UNIXで「ルート化」されたほとんどすべてのシステムコードを破棄し、PCIカードを機能的に同様のUSBデバイスに「仮想化」するための新しいコードを作成し、コード内の特定の場所をより信頼性の高いものにしました。 重要なことに、新しいLinuxデーモンは、Solarisからコピーされた構成ファイルを読み取り、WebサービスとしてのAPIの仕様との100％の互換性を維持しながら、その作業を正しく構成します。









C ++ 11標準（およびC ++ 17アプローチ ）、Boost、CMake、および最新のハイパーバイザーのおかげで、最初は不可能と思われた技術的なタスクが、非常に実現可能で魅力的なものになりました。