mathjax

2019年6月16日日曜日

Xenomai参考書

Xenomaiがどう動くのかが分からなかったので参考資料を探した所、「組み込みLinuxシステム構築 第2版」が良さそうなことが分かり、図書館で借りてきた。(4,752円と良いお値段の本なのでおいそれと買えない。)第2版でカーネル2.6に対応したとあるので、昔のカーネルの話になってしまうが、基本的な考え方を知る上では問題は無く非常に有用な資料だった。但し、2015年リリースのXenomai 3はカバーされないのでその点は注意が必要だ。

組み込みLinuxシステム構築 第2版
Karim Yaghmour Jon Masters Gilad Ben-Yossef Philippe Gerum


オライリージャパン

下記の所を読んでみた。

O'Reilly Japan - 組み込みLinuxシステム構築 第2版
12章 リアルタイムLinux入門
12.1 リアルタイム処理とは何か
12.2 Linuxにリアルタイム性が必要な場合
12.2.1 カーネルがリアルタイム性を意識すべき理由
12.2.2 レイテンシとは
12.3 リアルタイムカーネルの一般的要件
12.3.1 細かい粒度でプリエンプト可能なカーネル
12.3.2 タスクの優先度を厳密に適用する
12.3.3 一定時間内に外部イベントを処理する
12.4 リアルタイムコンピューティング技術の典型的な適用例
12.5 リアルタイムLinuxへの道
12.5.1 コカーネルによる手法
12.5.2 完全にプリエンプト可能なカーネルによる手法
13章 Xenomaiリアルタイムシステム
13.1 従来のRTOSアプリケーションをLinuxへ移植する
13.2 Xenomaiアーキテクチャ
13.2.1 割り込みパイプライン
13.2.2 ハードウェアとシステムの抽象化層
13.2.3 Xenomaiコアと核
13.2.4 Xenomaiスキン
13.3 Xenomaiの動作
13.3.1 リアルタイムシャドウ
13.3.2 新しいシステムコール群
13.3.3 カーネル機能の共有とドメインマイグレーション
13.4 リアルタイムドライバモデル
13.4.1 RTDMによる仲介
13.5 Xenomaiの変幻自在な設計
14章 RTパッチ
14.1 割り込みのスレッド化
14.1.1 ハードIRQのスレッド化
14.1.2 割り込みとCPUアフィニティ
14.1.3 softirqのスレッド化
14.1.4 softirqタイマスレッド
14.2 優先度継承
14.3 RTパッチを適用したカーネルの設定
14.3.1 No Forced Preemption(プリエンプションを強制しない)
14.3.2 Voluntary Kernel Preemption(自発的なカーネルプリエンプション)
14.3.3 Preemptible Kernel(プリエンプト可能なカーネル)
14.3.4 Complete Preemption(完全なプリエンプション)

12章 リアルタイムLinux入門

リアルタイム処理とは何かがまず丁寧に説明されている。処理が速いということでは無く、処理が想定通りの時間で実施されることだと。

時折、訳文に意味の取れないところが現れる。

p361 本文:当然、どんなリアルタイムソフトウェアを設計する前にも、ターゲットプラットフォームの割り込みレイテンシが既知の予測可能な値であることを知っておく必要がある。
代案:どのようなリアルタイムソフトウェアを設計するにしても、ターゲットプラットフォームの割り込みレイテンシが、既知で予測可能な値でなければならない。

本文:リアルタイム用途に~
代案:リアルタイムアプリケーションが使用するハードウェアはムーアの法則に従っており、ハードウェアとやりとりを行うアプリケーションを実装する人々は、より豊かで機能が豊富なアプリケーションを作ることを望んでいるので、Linuxのような洗練されたオペレーティングシステムが求められるようになった。

proprietaryが「独占的な」と訳されるのだが、Linuxの世界ではそう呼ぶのが一般的なのだろうか?特定の企業、団体、個人が権利を有しているものという意味で使われている言葉だと思うが。「独自の」では意味が違ってしまうのか?

Co-Kernelのアプローチ


  • Linuxの標準的なKernelの横で小さなreal-time kernelを走らせる。
  • real-timeプロセスは小さなco-kernelに渡され、そこでスケジュールされ処理される、通常の汎用OS的な処理は標準的なLinux kernelで処理される。
  • co-kernelは動的にロード可能なモジュール群として提供されるか、一般的なサブシステム同様にLinuxのソースツリーの中で直接コンパイルされるかのどちらかになる。
  • いくつかのco-kernel(特にRTAIとXenomai)は、real-timeプログラムがMMUの保護の利いたユーザースペースで実行できるようになっている。その他は(特にRTLinux/GPL)はreal-timeアプリケーションがkernel modulesに埋め込まれている必要がある。
  • 割り込みはco-kernelを通過してから標準的なLinux Kernelに渡される。
  • 仮想のPIC(割り込みコントローラ)をハードウェアとLinux Kernelの間に介在させる。
  • ただしこの方法には大きな欠点があり、co-kernelのサービスのみを使うようにしなければ、Linux Kernel自体はreal-timeになっていないので、標準KernelのLinuxドライバ、ライブラリ、標準Cライブラリ(glibc)のサービスはLinux Kernelを呼び出したときに予測不可能なレイテンシを引き起こす可能性がある。

完全にプリエンプト可能なカーネルのアプローチ

  • Linuxそのものを完全なRTOSに変える。
  • non real-timeプロセスが行う予測不能であったり、時間制限がなかったりといった処理の影響をreal-timeプロセスが受けないようにするための変更を行うことを意味する。
  • Linux Kernelは巨大で、何百万行のコードを含んでいるが、その多くはdriverと、Linuxがサポートする複数のアーキテクチャに対するものなので、組み込みのreal-timeプラットフォームの為にRT patchを使うことを選んだら、経験のあるRT kernelプログラマが、そのプラットフォームで使用するドライバに関して、preemptionや割り込みを長時間禁止する場所が無いかを調査すればよい。
  • Linux kernelのコア部分はkernelの僅かな部分に過ぎないが、プロセスのスケジューリングや、割り込みのハンドリング、internal locking、新しいスレッドの生成と削除、メモリ管理、ファイルシステム、タイマーのコードを含んでいる。
  • core kernelはmicrokernelが実装すべき機能を含んでいる。
  • Linux kernelをRTOSに変換するには、これらのkernelのコア部分を変更すればよいので、単純化される。
  • 実際にLinux kernelでreal-time taskに問題を起こす部分は上記でもその一部で、本質的にはlockingとinterruptsに関連する箇所だ。
  • Linux kernelの本線(2.6.23)はプリエンプションが禁止されている箇所や、kernel内での優先順位の逆転を引き起こすmutexを含む箇所が多く有る。
  • Linux kernelの本線は優先順位が最低のプロセスを実行するために、(real-timeを含む)いかなるプロセスもプリエンプトできる割り込みサービスルーチンを持っている。
  • RT patchはこれらの問題に対応し、Linux kernelをRTOSに変える。

13章 Xenomaiリアルタイムシステム

  • 2001年に始まった。
  • Xenomai coreは、伝統的なRTOS APIをLinux-based real-time frameworkにポーティング可能にするため、real-time API(スキンとも呼ばれる)を実装するための一般的なビルディングブロックを提供する。このreal-time frameworkで提供される再利用可能なオブジェクトを使ってproprietary/in-house APIを効果的に模倣することが出来る。
  • サポートされているreal-time APIはVxWorks, pSOS+, VRTX, uITRON, POSIX 1003.1bなど。

伝統的なRTOSアプリケーションをLinuxへ移植する

  • 2つのreal-time APIが似ていたとしても、元のシステムコールがターゲットのプラットフォームの最も近い同等なものに単純に置き換えても、アプリケーションの挙動は微妙な違いが生じてしまう。
  • non-POSIXインターフェースからLinuxのPOSIXベースのものに移行すると予期しない問題が発生する。
  • それと同時に、伝統的なRTOSが似通っていることは明確で、これらのエミュレータを開発するための共通のソフトウェアフレームワークを作ることは道理に適っている。
  • 伝統的なRTOSを最小限の所で見れば、どれもpreemptiveで、固定優先度のタスクスケジューラがあり、その多くはラウンドロビンのスケジューリングに対応している。イベントフラググループや、メールボックス、メッセージキューなどの馴染みのあるIPCメカニズムも提供している。固定サイズや動的なブロック割り付けなどのメモリ管理機能は、RTOS間で呼び方などは違うにしても僅かなコアの違いのみで存在する。
  • 伝統的なRTOSには共通点が多いことから、フレームワークに抽象化することが可能で、それぞれのRTOSのインターフェースを適切に模倣するには適切な見た目を用意すればよい。

Xenomaiアーキテクチャ

  • XenomaiはRTOSベンダの仕様書で定義されるシステムコールを厳密に模倣することができるreal-time APIエミュレータを提供することで、伝統的な組み込み環境をLinuxに移植するプロセスを容易にする。
  • Xenomaiはアプリケーションが必要とするreal-time性の保証を堅持する。
  • 全てのXenomaiエミュレータは、RTOS間の共通性を活用して、共通のビルディングブロックのセットから作られているため、Xenomai coreの改善の利益をコスト無しに享受することが出来る。

割り込みパイプライン

  • ハードウェアとLinux, Xenomaiの間に、仮想的なプログラマブル割り込みコントローラとして働くソフトウェアが追加されている。割り込みパイプライン、もしくはI-pipeと呼ばれる。
  • I-pipeはシステムをソフトウェアのパイプラインで繋がれた複数のドメインとしてシステムを構成する。
  • Linux kernelのレベルでは、ドメインはkernel moduleで、自分自身を登録するためにI-pipeのサービスをコールする。I-pipeの実装はcore kernelコードのそれぞれのバージョンにしっかりと適合する必要がある為、Linuxバージョン毎にパッチとして提供されている。
  • I-pipeが有効化されたkernelでは、XenomaiはLinux kernel自身よりも上の、優先度が最上位のドメインとなっている。

ハードウェアとシステムの抽象化層

  • CPUとプラットフォームに依存するコード部分を集めたものがXenomai hardware abstraction layer (HAL)で、核(nucleus)とそれより上のコードをハードウェアに依存しないものにしている。
  • Xenomai HALはsystem abstraction layer (SAL)と組み合わせられていて、核とスキンの移植性を高めている。
  • Xenomaiはevent-driver simulatorの上にコアサービスを置くためにHALとSALを使っている。
  • このツールは新しいRTOSのスキンを作る際にテストやデバッグに多用される。

Xenomaiコアと核

  • Xenomaiコアは、伝統的なRTOS APIsを適切に模倣するためにスキンが必要とするOSリソースを提供する。
  • Xenomaiはco-kernelデザインをベースとしているので、non-real-time Linux kernelでXenomaiは動作し、遅延時間を予測可能な範囲に保つにはreal-timeプロセスはXenomaiのサービスだけを呼び出す必要がある。
  • そのため、スキンは通常のLinuxサービスを使うことが出来ない為、Xenomai coreはすべての基本的なRTOSリソースを提供する必要がある。

Xenomaiスキン

  • XenomaiはすべてのRTOS APIsを同等として扱うので、特定のRTOS用のAPIが推奨されるといったことは無い。
  • 開発者は好きなスキンを選べるし、自分自身でまだサポートされていないRTOSのスキンを作ることも出来る。
この辺から意味が取れないので一旦停止。Xenomai Wikiに移動する。



0 件のコメント:

コメントを投稿