さて、そのXenomaiは基本的に“Co-Kernel”という実装である。それではCo-Kernelとは何なのか? を端的に表現したのが図3である。図3内左側のScheduler AがLinuxの標準スケジューラーであり、これにパッチを当てる形でもう1つ別のスケジューラーも走らせる。この際Interrupt Dispatcherのルーティング先にもパッチを当てることで、一部のInterruptに関してはScheduler Bで直接受けてハンドリングできるようにする。こうした仕組みを取ることで、Linuxの上に、Linuxのスケジューラーとは別に動くTaskを稼働させることができる。
もちろん、この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として実装されることになる。
アプリケーションから見た時の仮想的なハードウェアとして提供されるのがXenomai Nucleusである(図5)。このNucleusには、POSIXやVxWorksなどさまざまなスキンが用意されており、これを利用する形で複数のRTOSが稼働できる(同時稼働が可能か? というのはまた別の問題)。
さて、Scheduler BをつかさどるのはCobalt coreと呼ばれている。これはデュアルカーネル用に設計されたもので、続くXenomai 3ではシングルカーネル(既存のカーネルを完全に置き換えて動作するもの)用のMercuryも提供されるようになったが、Xenomai 2ではこのCobaltのみである(図6)。
これに続き、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の下には引き続き機種別ファイルが並んでいる。
ちなみにXenomai 3.0.1ではSHやNios IIへのサポートがなくなり、代わりにArm64が追加された。このサポート機種はだんだん減っており、2020年2月にリリースされたXenomai 3.1ではArm/Arm64/PowerPC/x86になっている(Blackfinが落ちた)。現在は3.2.1が最新のStable版としてリリースされている。
Copyright © ITmedia, Inc. All Rights Reserved.