SourceForge.JP: Open Source Software

「Building Embedded Linux Systems」（邦題： 組み込みLINUXシステム構築）の著者であるKarim Yaghmourは、前回の議論の後で次の言った。

私はここ最近の、Linuxで厳密な応答時間を得ることに関する話題について、非常に興味を持っているが、これにはあまり巻き込まれないようにしている。Ingoの作業は確かに多くの関心を集めているし、彼は確かに成り行きを見守る聡明さと、意欲的な考え方を持っている。しかし私は、少し懐疑的になり、心配したことを認めなければならない。このカーネルは、それまで多くのけなしてきた人々が、信じられないほどのレベルに達した。従って、私にとってそれはリアルタイム性能の点から、既存の(例えばLynxOSまたはQNXのような)RT-Unixesに貢献して、それを超えることが*できる*かどうかという領域にある。

Linux開発者コミュニティは「我々は、必要とするユーザにどのように厳密な振る舞い（deterministic behavior）を供給するか。」という質問に答えなければならない。

コミュニティでは多くの他の状況で、このような質問に対する答えは「コードを見せなさい！」というだけだった。その点に関してと、誰かの作業の批判をしないことから、Ingoの作業は多くの興味を集めていた。これはコンセプト面で新しい開発基盤を開いているからではなく、多くはその早期開発ペースのためにである。それについて考えてみると、望む姿をそのまま「Hard real-time Linux」と名づけた努力は、結局 LKMLでのIngoの活動と同じレベルに達していなかった。

しかし私は、これがまさしくコンセプトが重要な場合であって、公開されたコードの量が質問の本質を消すことはないだろうと信じている。

Unix環境で決定論的な応答時間を提供するための*正確な*方法は何か。恐らく答えがあるのがこの単語の定義に関わるので、「正確な」という単語を強調する。ここにはいくつかのの解決策を挙げる。これは「正確な」というために、誰かが出現年代順に見つけてきたものである。

1. Master/slave kernel （例： RTLinux）
2. Dual-CPU （何年か前から、その実例は多く出てきている）
3. 割込みレベル （例： D.Schleef, B.Kuhn, など）
4. ナノカーネル/Hypervisor （例：Adeos）
5. プリエンプション
6. Uberプリエンプション(uber-preemption)と IRQスレッド(別名：.acidプリエンプション) (例： Ingo, TimeSys, MontaVista, Bill)

これらに対する私の見解は、Unix環境で厳密な応答時間を提供する「正確な」方法とは、できるだけ多くを最小化するべきということである。

1. ターゲットとされたカーネルに対する、既存のAPI、振る舞い、ソースコードおよび機能の修正
2. 将来のメインストリーム・カーネル開発にかかわる労力
3. 結果的に厳密な振る舞いを失わせるような、Hard RealTime機能の偶然、または突発的な利用に対する適応能力

言い換えると次の通りになる。

1. ターゲットとされたカーネルに対して、既存のAPI、振る舞い、ソースコードおよび機能のさらなる修正を要求せずに、リアルタイム性能、サービスのそのままの拡張を可能にする方法で構成されるべきである。
2. サンプルテストを実行する間に発見された、いくつかの制限時間によって単に時間制約を受けるのではなく、真の意味で厳密であるべきである。
3. 前述のような、偶然または突発的な利用に対する適応能力を必要とせずに、簡単に利用可能であるべきである。(このようなソリューションは、ターゲットとされたUnixカーネルと同じAPIを提供するために、できるだけたくさん努力されるべきである)
4. APIと振る舞いの面で一貫して、1つのアーキテクチャから次へと、新しいアーキテクチャに対する容易な移植性の確保。

私はこの数年にわたって出たすべてのソリューションの中で、「ナノカーネル/Hypervisor」が正確さに関するこれらの条件に関して、最も適合できることをみつけた。

これは既に重要なマイルストンに達したのだが、Adeos/RT-nucleus/RTAI-fusionは、私が推奨している1つのインプリメンテーションである。それが動作するために必要なのは、Adeosが割込みパイプライン経由でLinuxにそれ自体を接続するべき必要なフックだけである。後者は非常に単純であり、移植性に優れ、副作用がない。また偶然または突発的な利用に対して、配慮せずに使用できる。この割込みパイプラインは、ローダブルモジュールによって実現する、私が示したスタックに必要なもの全てである。それはHard RealTimeの厳密な振る舞いをアプリケーションに提供するRTAI-fusionにより、既存のLinuxシステムコールの透過的サービスを含んでいる。

「バニラLinuxはHard RealTimeになるべきだ」という考え方を擁護している人々(その多くは今、Uberプリエンプション・キャンプにいる)が、このアプローチに向けた1つの論争は、個別のリアルタイム用ドライバを書くことが必要だという点である。しかし、この論争は致命的な欠点を含んでいる。ドライバはRTOSの上で走ることによって、厳密になるわけではない。IOW、ましてやLinuxがUnix RTOSとなるにしても、Linuxソース中のすべてのドライバは、 Hard RealTimeを要求するシステムの中で使用されるために、厳格性を持つように書き直されなければならないだろう。従ってこれは、問題ではない。

今まで述べてきたことを、今後どうして貰えるのだろうか。「問題はコードパスがすべて厳密であることを保証するために、OSカーネル全体を修正しなければならないということである。」2つの可能な手段がある。

• 現在のカーネル開発者は、既存のコードベース全体を厳密なコードパスだけを含んでいる単一のものへと変換し、それ結果すべての将来のcontributor（パッチ提供者）に同様の制限を課するようにする。その場合には、続くべき道はUberプリエンプションの人々によって行われるべきである。

• 現在のカーネル開発者は、LinuxをLinuxからの厳密なHard RealTime振る舞いを必要としないユーザベースに主として役立つ一般目的Unix OSにしておくつもりである。そして、明らかに最小限で、副作用がなく、フレキシブルで、Hard RealTimeを要求するものに対する変更は受理可能とする。その場合には、続くべき道は、「ナノカーネル/Hypervisor」の開発者によって行われるべきである。

Bill HueyはKarimの提案に対して、長い返事を書いた。結局のところ、次のように伝えた。

「これは問題ではない。Uberプリエンプションの開発者は、これまで通りのことを行い続けるだろう。2つのドメインのRT開発者に対して、より多くの可能性を明らかにするだけに過ぎない。他から、片方を除外すべきではない。」

カーネルメンテナであるAndrew Mortonもまた、Karimに答えた。

Uberプリエンプションは、メインライン・カーネルが主として選択する手法である。なぜならそのメカニズムの大部分は、隠された内部ヘッダファイルであり、またほとんどの開発者はそれについてまったく心配する必要はないからである。

私は、「いつかすべての平凡なベンチマークで、良いサブフェムト秒（訳注：ナノ秒の10億分の1、アト秒）単位のレイテンシを得る日が来る」ということに対して、結局リアルタイム・プロセスでは有用なものは何もすることができないと判明するのではないかと、ひそかに疑念を持っている。なぜなら、それらがsyscallsを行なう場合は常に、syscallsは結局長時間保持されるロックを持つからである。

我々は、Ingoの現在の作業のターゲット・アプリケーション領域を識別し、それらのアプリケーションが要求する結果を満足できることを確認する必要があるわけだが、どちらの提案が合致するのだろうか。

Ingo Molnarが答えた。彼は、リアルタイムプロセスがベンチマークでは明らかにできない問題を持つだろうという考えについて、次のような反論を提示した。

-RT-V0.3 では、「./hackbench 20」の実行において、最大でも20マイクロ秒以下のレイテンシ（平均レイテンシは1マイクロ秒）を得ている。そのため、サブフェムト秒のカテゴリになっても、PREEMPT_REALTIME はうまくやってくれると思う。スピンロック・ロックを中断するPREEMPT_REALTIMEは、正確にHard RealTimeタスクとインタラクションできるレイテンシである。

結果として彼は、その問題を解決することができる場合があるだろうと確信していたということである。