Linuxでハードリアルタイムを実現するもう1つの選択肢「Xenomai」：リアルタイムOS列伝（35）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第35回は、第27回で取り上げた「RTAI」と同じくLinuxでハードリアルタイムを実現する選択肢となる「Xenomai」を紹介する。

[大原雄介，MONOist]

「Xenomai」の実装は“Co-Kernel”

　さて、そのXenomaiは基本的に“Co-Kernel”という実装である。それではCo-Kernelとは何なのか？　を端的に表現したのが図3である。図3内左側のScheduler AがLinuxの標準スケジューラーであり、これにパッチを当てる形でもう1つ別のスケジューラーも走らせる。この際Interrupt Dispatcherのルーティング先にもパッチを当てることで、一部のInterruptに関してはScheduler Bで直接受けてハンドリングできるようにする。こうした仕組みを取ることで、Linuxの上に、Linuxのスケジューラーとは別に動くTaskを稼働させることができる。

図3　LinuxはこうしたCo-Kernelを標準でサポートしているわけではない。このため、Co-Kernelの実現にはカーネルへのパッチが必要となるのはXenomaiに限った話ではない［クリックで拡大］

　もちろん、このScheduler AとScheduler Bが完全に独立していると、CPUリソースなどを取り合うことになってしまうので、Scheduler Bがフルに動く時には一瞬Scheduler Aを止める形になる。実装としてはいろいろあって、Scheduler BをHighest Priorityを持つTaskとしてScheduler Aに登録しておくといった方法が一番楽ではあるが、これだとInterruptの処理が遅れる場合もある。

　このPriority周りに関してのDispatchのメカニズムが先述したI-pipeである（図4）。要するにISR（割り込みハンドラ）の手前に入り、Interruptをいったん受けてDispatchするものだ。図3で言えば、“Dispatching and Collaboration Services”と、あとScheduler BからScheduler AへのPreemptionがこのI-pipeとして実装されることになる。

図4　この場合、RTOSがHighest Priority Domain X、通常のLinux環境がRoot Domainに相当することになる［クリックで拡大］

　アプリケーションから見た時の仮想的なハードウェアとして提供されるのがXenomai Nucleusである（図5）。このNucleusには、POSIXやVxWorksなどさまざまなスキンが用意されており、これを利用する形で複数のRTOSが稼働できる（同時稼働が可能か？　というのはまた別の問題）。

図5　右端のRTDMはReal-Time Driver Modelの略。ハードウェアのアクセスは、このRTDMへのStub Library経由で行い、その先でRTDMに対応したドライバが動くことになる［クリックで拡大］

　さて、Scheduler BをつかさどるのはCobalt coreと呼ばれている。これはデュアルカーネル用に設計されたもので、続くXenomai 3ではシングルカーネル（既存のカーネルを完全に置き換えて動作するもの）用のMercuryも提供されるようになったが、Xenomai 2ではこのCobaltのみである（図6）。

図6　Cobalt coreでのアクセスはlibcobalt経由だが、その手前にcopperplateというI/Fがあり、これで非POSIX準拠RTOSに対応させる［クリックで拡大］

　これに続き、2015年にはXenomai 3.0が登場した。3.0の最大の特徴は、APIがPOSIX centrixになったことかと思う。またネイティブLinuxへのサポートも新たに追加された項目である。このネイティブLinuxに対応するためのものが先述したMercuryである（図7）。POSIX APIへの移行やMercuryの提供などもあって、使い勝手そのものが多少Xenomai 2から変わったという話もある。またXenomai 2ではソースを展開するとksrc\archの下に機種別のファイルが置かれていたが、Xenomai 3ではネイティブLinux対応ということでこれがなくなっている。もっとも、これはMercuryを使った場合の話で、Cobaltは引き続き機種別対応になっている。それもあり、kernel\cobaltの下には引き続き機種別ファイルが並んでいる。

図7　APIが全てPOSIXに対応したことで、libcobaltは不要になり、Glibcでアクセス可能になった［クリックで拡大］

　ちなみにXenomai 3.0.1ではSHやNios IIへのサポートがなくなり、代わりにArm64が追加された。このサポート機種はだんだん減っており、2020年2月にリリースされたXenomai 3.1ではArm／Arm64／PowerPC／x86になっている（Blackfinが落ちた）。現在は3.2.1が最新のStable版としてリリースされている。