RTLinux

RTLinuxは、 Linuxオペレーティングシステム全体を完全なプリエンプティブプロセスとして実行するハードリアルタイムの リアルタイムオペレーティングシステム（RTOS）マイクロカーネルです。ハードリアルタイムの特性により、ロボット、データ収集システム、製造工場、その他の時間に敏感な機器や機械をRTLinuxアプリケーションから制御できます。この設計は特許を取得しました。^{[1]名前が似ていますが、} Linux FoundationのReal-Time Linuxプロジェクトとは関係ありません。^[2]

RTLinux は、ニューメキシコ鉱業技術研究所の Victor Yodaiken、Michael Barabanov、Cort Dougan らによって開発され、その後 FSMLabs で商用製品として提供されました。Wind River Systems は2007 年 2 月に FSMLabs の組み込みテクノロジを買収し、 Wind River Linux用の Wind River Real-Time Core としてバージョンを提供しました。2011 年 8 月現在、Wind River は Wind River Real-Time Core 製品ラインを廃止し、RTLinux 製品の商用サポートを事実上終了しています。

RTLinux の主な設計目標^[3]は、ハードリアルタイム機能をコモディティオペレーティングシステムに追加して、両方の機能を備えた複雑な制御プログラムの開発を容易にすることでした。^{[4] [5]}たとえば、コモディティデータベースを使用し、Web オペレータインターフェイスをエクスポートするリアルタイムモーターコントローラを開発したいとします。リアルタイム機能と非リアルタイム機能をサポートできる単一のオペレーティングシステムを構築しようとするのではなく、RTLinux は、リアルタイムオペレーティングシステムと非リアルタイムオペレーティングシステム間でコンピューティングデバイスを共有するように設計されました。これにより、(1) リアルタイムオペレーティングシステムの実行が非リアルタイムオペレーティングシステムによってブロックされることがなく、(2) 2 つの異なる環境で実行されるコンポーネントが簡単にデータを共有できるようになりました。名前が示すように、RTLinux はもともと Linux を非リアルタイムシステムとして使用するように設計されましたが^[6]、最終的には RTCore リアルタイムカーネルが Linux またはBerkeley Software Distribution (BSD) Unixのどちらでも実行できるように進化しました。

Multi-Environment Real-Time (MERT) は、リアルタイム オペレーティング システムと Unix システムが共存する最初の例です。MERT は従来の仮想化技術に依存していました。リアルタイム カーネルがホストオペレーティングシステム (またはハイパーバイザー) で、Bell Systems Unix がゲストでした。RTLinux は、MERT の概念を PC 時代とコモディティ ハードウェアに合わせて更新する試みでした。また、MERT のパフォーマンスの限界、特に仮想化によって生じるオーバーヘッドを克服する試みでもありました。

ゲスト OS を仮想マシンにカプセル化する代わりに、RTLinux はゲストの割り込み制御のみを仮想化しました。この方法により、リアルタイム カーネルはゲスト OS を完全にプリエンプティブなシステムに変換できましたが、ストレージ デバイスなどを直接制御することはできました。特に、ゲストの標準ドライバはソースの変更なしで動作しましたが、仮想化「フック」を使用するには再コンパイルする必要がありました。準仮想化も参照してください。Unixパイプはリアルタイム プログラムと非リアルタイム プログラムの通信を可能にするために採用されましたが、共有メモリなどの他の方法も追加されました。

プログラマーの観点から見ると、RTLinux は当初、リアルタイム タスク用の小規模なスレッド環境と、その他すべて用の標準 Linux 環境を組み合わせたもののように見えました。リアルタイム オペレーティング システムは、ゲスト割り込み制御を仮想化して開始し、次にリアルタイム スケジューラを開始するロード可能なカーネル モジュールとして実装されました。タスクには静的な優先順位が割り当てられ、スケジューリングは当初、純粋に優先順位に基づいていました。ゲスト オペレーティング システムは、最も優先順位の低いタスクとして組み込まれ、基本的にリアルタイム システムのアイドル タスクとして機能しました。リアルタイム タスクはカーネル モードで実行されました。RTLinux のその後の開発では、ポータブル オペレーティング システム インターフェイス ( POSIX ) POSIX スレッドアプリケーション プログラミング インターフェイス ( API ) が採用され、ユーザー モードでスレッドを作成し、ゲスト プロセス内でリアルタイム スレッドを実行できるようになりました。マルチプロセッサ環境では、スレッドはプロセッサ コアにロックされ、ゲスト スレッドが指定されたコアで実行されないようにすることができました (実質的に、コアをリアルタイム処理専用に予約する)。

RTLinux は、標準 Linux と同じマシンで特別なリアルタイム タスクと割り込みハンドラを実行する機能を提供します。これらのタスクとハンドラは、Linux が何をしているかに関係なく、必要なときに実行されます。プロセッサによってハードウェア割り込みが検出されてから割り込みハンドラが実行を開始するまでの最悪の時間は、汎用 x86 (2000 年頃) で実行されている RTLinux では 15 マイクロ秒未満です。RTLinux の定期タスクは、同じハードウェアでスケジュールされた時間から 35 マイクロ秒以内に実行されます。これらの時間はハードウェアによって制限されており、ハードウェアが向上すると RTLinux も向上します。標準 Linux は平均パフォーマンスが優れており、POSIX ソフト リアルタイム機能を使用してタスクのスケジュール精度をミリ秒レベルにすることもできます。ただし、標準 Linux は、ミリ秒未満の精度と信頼性の高いタイミング保証を提供するようには設計されていません。RTLinux は軽量の仮想マシンに基づいており、Linux「ゲスト」には仮想化された割り込みコントローラとタイマーが与えられ、その他のすべてのハードウェア アクセスは直接行われました。リアルタイム「ホスト」の観点から見ると、Linux カーネルはスレッドです。確定的な処理に必要な割り込みはリアルタイム コアによって処理され、その他の割り込みはリアルタイム スレッドよりも低い優先度で実行される Linux に転送されます。Linux ドライバーはほぼすべてのI/O を処理します。先入れ先出しパイプ ( FIFO ) または共有メモリを使用して、オペレーティング システムと RTLinux 間でデータを共有できます。

RTLinux の主要な設計目標は、システムが透過的、モジュール式、拡張可能であることです^[要出典]。透過性とは、開けられないブラック ボックスが存在せず、あらゆる操作のコストが決定可能であることを意味します。モジュール性とは、必要ない場合は機能とその機能のコストを省略できることを意味します。拡張性とは、プログラマがモジュールを追加して、システムを要件に合わせて調整できることを意味します。基本の RTLinux システムは、高速割り込み処理のみをサポートしています。このシステムには、特定のアプリケーションのニーズに適したスケジューラに簡単に置き換えることができる、シンプルな優先度スケジューラがあります。RTLinux の開発では、Linux とその強力な機能を利用できることから得られる利点を最大化するように設計されました。

RTLinux は、小さなコア コンポーネントとオプション コンポーネントのセットで構成されています。コア コンポーネントでは、Linux 自体では遅延またはプリエンプトされない非常に低レイテンシの割り込みハンドラーと、低レベルの同期および割り込み制御ルーチンをインストールできます。このコア コンポーネントは SMP をサポートするように拡張され、同時にコアの外部で提供できる一部の機能を削除することで簡素化されました。

ほとんどの RTLinux 関数は、オプションのサービスと抽象化レベルを提供するロード可能なカーネル モジュールのセットに含まれています。これらのモジュールには次のものが含まれます。

1. rtl sched - 以下で説明する「lite POSIX」インターフェースとオリジナルの V1 RTLinux API の両方をサポートする優先度スケジューラ。
2. rtl time - プロセッサ クロックを制御し、ハンドラーをクロックに接続するための抽象インターフェイスをエクスポートします。
3. rtl posixio - デバイス ドライバーへの POSIX スタイルの読み取り/書き込み/オープン インターフェイスをサポートします。
4. rtl fifo - Linux プロセスが RT コンポーネントの読み取り/書き込みを行えるように、デバイス レイヤーを介して RT タスクと割り込み ハンドラーを Linux プロセスに接続します。
5. セマフォ - Jerry Epplin が寄贈したパッケージで、RT タスクにセマフォをブロックする機能を提供します。
6. POSIX ミューテックスのサポートは、RTLinux の次のマイナー バージョン アップデートで利用可能になる予定です。
7. mbuff は、RT コンポーネントと Linux プロセス間の共有メモリを提供するために Tomasz Motylewski によって書かれた寄付パッケージです。

RTLinux リアルタイム タスクは、Linux がドライバー、ファイル システムなどに使用するモジュールの種類に似たカーネル モジュールとして実装されます。リアルタイム タスクはハードウェアに直接アクセスし、仮想メモリを使用しません。初期化時に、リアルタイム タスク (モジュール) は、期限、期間、およびリリース時間の制約を RTLinux カーネルに通知します。

RT-Linux は、スレッドの操作用に POSIX API を実装しています。スレッドはpthread_create関数を呼び出すことによって作成されます。の 3 番目のパラメータは、pthread_createスレッドによって実行されるコードを含む関数です。

RTLinux では、スレッドの優先度を設定する必要があります。優先度の高いスレッドは、優先度の低いスレッドをプリエンプトできます。たとえば、ステッピング モーターを制御するスレッドがあるとします。モーターをスムーズに動かすには、このスレッドを厳密に一定の間隔で開始する必要があります。これは、このスレッドに高い優先度を割り当てることで保証できます。例の threads2.c は、さまざまなスレッドの優先度を設定します。スレッドの優先度の設定は、次のコードで行います。

int init_module ( void ) { pthread_attr_t attr ; struct sched_pa​​ram param ; pthread_attr_init ( & attr ); param . sched_priority = 1 ; pthread_attr_setschedparam ( & attr , & param ); pthread_create ( & t1 , & attr , & thread_code , "これはスレッド 1 です" ); rtl_printf ( "スレッド 1 が開始されました\n " ); /* ... */ } 

     
      
    
      
     
       
    
    

プログラムの出力は次のようになります。

スレッド1が開始しました
スレッド2が始まりました
スレッド3が始まりました
メッセージ: これはスレッド 1 です
メッセージ: これはスレッド 2 です
メッセージ: これはスレッド 2 です
メッセージ: これはスレッド 2 です
メッセージ: これはスレッド 1 です
メッセージ: これはスレッド 1 です
メッセージ: これはスレッド3です
メッセージ: これはスレッド3です
メッセージ: これはスレッド3です

スレッド 2 の優先度が最も高く、スレッド 3 の優先度が最も低くなります。最初のメッセージは、スレッド 2 より少し前に開始されたため、中程度の優先度のスレッド 1 によって出力されます。

• RTAIは「MyRTlinux」と呼ばれる RTLinux の派生版として始まり、その後のリリースでは、その作者によって特許取得済みの RTLinux 仮想化技術を使用していないと主張されました^{[疑わしい–議論する]}。
• RMX (オペレーティング システム)
• スケジュール期限
• ゼノマイ
• プリエンプション（コンピューティング）
• 組み込みシステム上の Linux
• リアルタイムテスト

• RTLinux 同期に関する記事
• リアルタイム Linux 2007-03-18 にWayback Machineでアーカイブされました。Victor Yodaiken と Michael Barabanov、ニューメキシコ工科大学
• archive.todayの RT コンセプトに関する記事(2013-01-28 アーカイブ)