Linux＆ITRONをマイクロカーネル上に仮想化　新アーキテクチャを産学で[06/03/13]

早稲田大学理工学部 中島研究室、筑波大学大学院 追川研究室、エルミック・ウェスコムは3月13日、
組み込み向け新OSアーキテクチャの開発に共同で着手すると発表した。
マイクロカーネル上にLinuxとITRONを仮想化して実装し、セキュリティや信頼性を強化する。
成果はオープンソースとして公開する。

1つのCPUマイクロカーネルを実装し、その上に仮想化したOSを複数動作させるプログラムを開発する。
（1）それぞれのOSで動作しているアプリケーションに対し、他のOSからはアクセスできないため、
アプリケーションやデータを外部から保護できる、
（2）あるアプリケーションに不具合が生じても、影響がその実行環境の内部に限定されるため、
被害を最小限に抑えることができる──などのメリットがあるという。

事前実験により、マイクロカーネル上のITRONはリアルタイム性を十分に保証できたといい、
新アーキテクチャでも従来と同等のリアルタイム性の実現を目指す。

プロジェクト終了後の2007年3月にはソースコードを一般公開する予定。
「リアルタイム性と信頼性が高いOSが普及することで、組み込み機器全体のパフォーマンス向上に寄与したい」としている。

◆ソース：itmedia
http://www.itmedia.co.jp/news/articles/0603/13/news087.html

中身読まずに健ちゃんは Linux におんぶに抱っこで生き残ることを決めましたか。

Xenのリアルタイム版でも目指すのか？

よくわからんが、とにかく凄い自信だ

これ CELL とは違うのけ？

実装においてはXenのソースをぱくってくる予感がする。
というか、リアルタイム性が求められるところで複数ＯＳが必要なのか？
これまでのITRON+LinuxってITRONの上にLinuxが被さっていて階層が違う扱いだったが、
ITRONとLinuxを同じ階層で利用するわけ？
しかも一個ずつじゃなく。

ITRONを仮想化してって・・・
意味あんのか？

MacでWindows動かすのと何が違うんだ？

LinuxとITRONをってぶっちゃけLinuxだけでもいいんじゃないの？

>>7
過去の資産が使えつつLinuxに移行できる

>>10
ITRONの各種実装同士の互換性が低い現状で、
これのITRON上で元のアプリ・ミドルウェアがちゃんと動く保証なんてないと思うんだが。

>>9
ｲﾗﾈだろ
ITRONは組み込み用だ
アプリ目的ならBTRON

>>6
多分カーネル書き換えるから、Xenほどの仮想化は必要ない。
coLinux的なアプローチか？
>>11
T-kernelかToppersに統一すんじゃね？

マイクロカーネル嫌いのリーナス・トーヴァルズ(笑)に華麗にスルーされる
ことだけはガチ

まぁ linuxのスケジューリングよりも
リアルタイムＯＳのスケジューリングの一部でlinuxが動いていた方が
幸せだわな。

坂村のほうはＭ＄と組んでるのに大丈夫なのか？

トヨタが採用しそうな予感。

ITRONだけでいいじゃないか

>>16
あっちは東大だからいいんじゃない

MkLinuxか！！

>>2
LinuxがITRONにおんぶにだっこで生き残ることになった。
なぜならLinuxのリアルタイム性能の向上が限界に来たから。
それは基本設計に由来する限界なのでとうてい無理なの。

>>6
この記事のは、典型的なハイブリッドOS

>>7>>9
ITRONのリアルタイム性能が欲しい。
もしITRONなかりせば、日本は工業国家たりえず。
ITRONをなめるなよ。

>>11
そのためのT-Kernel
ただ研究室としては勝手にいじくりまくれるITRONが好まれたんだろう。

>>12
記事に組み込み目的だと書いてあるよ。

それから、TRONプロジェクトのICBM-TRONは
それぞれターゲットを明確にして性格付けをはっきりさせているよ。
要と需要を見切ってそれぞれのOSが創られた。
それらの個性がはっきりしたOSを相互に連携させることで
未来的なコンピュータが実現する。

>>13
企業の目的は組み込み用OSが欲しいだけ。
大学の目的は仮想マシンモニタにある。

>>15
組み込みでラウンドロビンはとろくさすぎる。

>>13
この研究ではToppersを使うようだよ。

(2) 開発するソフトウエアの構成
http://www.elwsc.co.jp/japanese/newsrelease/images/os.gif

[超漢字/TRONコードの嘘]
・ISO/IEC 2022(1972制定)をパクって改悪しただけの「TRONコード(1987論文)」
しょせんウリジナルｗ 本家には「新しく作る意味が全くない」と一蹴された。
・多言語化の為のISO-2022という試みは当時すでに死に体、欧米はその変種の
TRONコードなんか相手にせずISO/IEC 10646(の制定を急いでいた。
・ISO-10646はUnicode Consortiumが実権を握り「CJK統合漢字」を半ば強引に推し進めた。
後に「漢字の危機」と呼ばれたこの愚行に対し、ジャストシステムは手弁当で海を渡り徹底抗戦した。
一方、日本学術振興会から数億円の補助金で潤ってたTRON一派は「何もしなかった」。
・ISO-2022は新しい文字集合の追加には慎重だったが、TRONは目先の実績作りに
ケンチャナヨで文字を追加(Unicodeまでも)、結果としてUnicodeと同じ欠陥まで抱え込んで自爆。
コード振るなら馬鹿でも出来ることを証明した。
・現在の実装では設計の問題からアラビア語などのリガチャを含む文字を
正しく表示できない、Linuxの多言語化ライブラリpangoやm17nlib以下の出来ばえ。
・150万字収録可能を誇るが、中共のGB18030-2000規格が160万字収録可能な事には一切触れないｗ

早稲田大学、筑波大学、エルミック・ウェスコムが組込みシステムの
セキュリティ強化を実現するOSアーキテクチャの開発に共同で着手
　〜マイクロカーネル上に仮想化したLinuxとITRONを実装〜
http://www.elwsc.co.jp/japanese/newsrelease/news/news060313.html

　　　　　　　　　　　　　　　　　　　　平成 18 年 3月 13日

　　　　　　　　　　　　　　　　　　　　早稲田大学 理工学部 中島研究室
　　　　　　　　　　　　　　　　　　　　筑波大学大学院 追川研究室
　　　　　　　　　　　　　　　　　　　　エルミック・ウェスコム株式会社

早稲田大学理工学部 中島研究室、筑波大学大学院 追川研究室、エルミック・ウェスコム株式会社
（本社：神奈川県横浜市、代表取締役社長：村島 一彌）
の３者は、組込みシステムのセキュリティと信頼性の強化を実現する
新しいOSアーキテクチャの開発に共同で着手することを発表します。

本プロジェクトで開発するアーキテクチャは、
マイクロカーネル上に仮想化したLinuxとITRONを実装するもので、
システムの強化と同時に、開発工数の短縮のメリットも得られます。

本プロジェクトでは、３者が協力して仕様の策定を行い、
プログラムの実開発はエルミック・ウェスコム株式会社が行います。

プロジェクトの終了は2007年3月を予定しており、
終了後には成果物であるプログラムのソースコードを公開し、
オープンソースソフトウエアとして幅広く普及することを目指します。

昨今、組込み機器においては、
オープンなネットワークへの接続や高機能化や用途の多様化の進行によるシステムの複雑化に伴い、
セキュリティの強化とソフトウエア信頼性の向上が重要な課題となっています。

また同時に、開発現場では商品サイクルの短期化により、
開発効率を向上し開発期間を短縮することが求められています。

このような課題の解決方法のひとつとして、
早稲田大学の中島教授と筑波大学大学院の追川助教授が
研究開発を行っている技術が仮想化OSです。

仮想化はコンピュータ上に何らかの実行環境を仮想的に構築する技術であり、
サーバやPCの分野では既に導入されていますが、
組込みシステムの分野では仮想化OSはまだ実用化されていません。

そこで、組込みOS分野でハイブリッドアーキテクチャの開発などの実績をもつ
エルミック・ウェスコムが両研究室と共同して開発することになりました。


本プロジェクトでは、1つのCPUマイクロカーネルを実装し、
その上で仮想化したOSを複数動作させるプログラムを開発します。

このOS構造では複数の実行環境がそれぞれ独立して動作するので、
アプリケーションやリソースをOSごとに分離することが可能となります。
このことにより、以下のような特徴をもつシステム環境を構築することができます。

(1) 外部からの攻撃に耐える強固なシステム

それぞれのOS上で動作しているアプリケーションに対して
他のOSのアプリケーションからはアクセスできないので、
アプリケーションそのものやデータを外部から保護することができます。


(2) 内部で発生した不具合に対して堅牢なシステム

あるアプリケーションに不具合が生じてもその実行環境の内部にしか影響を与えないので、
被害を最小限に抑える事ができ、システム全体の信頼性が向上します。

また、メモリ容量やCPU性能などシステム資源の限られている組込みシステムでは
特に資源管理機能がシステムの信頼性において重要となりますが、
仮想化OS構造では、OSごとに資源を割り当てたりできるので、
効率良い資源管理が可能となります。

また、過去に各OS上で作成したアプリケーションやドライバなどの
ソフトウエア資産を有効に活用できるので、開発効率が向上されます。

さらに各OSとそのOS上に構築したドライバやアプリケーションを合わせて仮想化するので、
異なるCPUへの移植が簡単に行えます。

また逆に、今後増加するであろうマルチコアプロセッサなどの複数CPUへ移植する場合には、
マイクロカーネルが資源管理を行うので、対応が容易に行えます。

負荷に応じてCPUの性能と構成に柔軟な対応が可能となります。


仮想化OSのデメリットとして、リアルタイム性が損なわれる事が危惧されていますが、
事前実験によりマイクロカーネル上のITRONが
十分なリアルタイム性を保証できることが実証されており、
今回開発するアーキテクチャにおいても
これまでと同等のリアルタイム性を実現することを目標としています。


なお、本プロジェクトの終了後には、オープンソースソフトウエアとして
成果物を一般に公開いたします（2007年3月を予定）。

リアルタイム性能と信頼性の高いOSが普及することにより、
組込み機器全般のパフォーマンス向上に寄与したいと考えております。

なお本件に関し、以下の方々からコメントをいただいております。


早稲田大学理工学部　コンピュータネットワーク工学科　教授　中島 達夫氏

「ハードウエア仮想化は今後の組み込みシステムにおいて大変重要な技術です。
今回の取り組みは、より複雑化する組み込みシステムに対処するための
重要なステップであると認識しています。」


筑波大学 大学院　システム情報工学研究科　助教授　追川 修一氏

「高い信頼性、堅牢性、セキュリティが要求される組み込みシステムには、
今後、仮想化技術が欠かせないものになっていくと考えられます。
今回の取り組みは産業界からの要求に応えることができるシステム構築を目指すものであり、
日本の基盤ソフトウェア技術向上のためにも重要な意味を持つと考えられます。」


エルミック・ウェスコム株式会社 代表取締役社長 村島 一彌氏

「当社では創業時よりリアルタイムOSの開発に取り組んでおり、
複数OSのハイブリッドアーキテクチャ開発や保護機能を有するリアルタイムOSなど、
独自のOS技術を培ってきました。
この度、先進的な技術開発を行う両研究室と共同で開発に携われることを光栄に思います。
また、今後もこのような産学協同のプロジェクトで技術力向上を図りたいと思います。」


・本文中の会社名および製品名は各社の商標または登録商標です。

補足資料】
●プロジェクトの詳細について

(1) 開発する範囲および内容

1）Linuxの仮想化およびマイクロカーネル上への実装

Linuxのハードウエア依存部をOS非依存レイヤとOS依存レイヤに切り分けて、
2つのレイヤとして実装する。
OS非依存レイヤは、Linuxカーネルにあるハードウエア依存部を抽象化することにより、
動作するハードウエアやLinuxを動作させるベース側のOS環境を隠蔽する。
OS依存レイヤでは、実際にLinuxを動作させるベースOSに依存するレイヤであり、
このレイヤを各OS上に実装することにより、様々なOS上での動作を可能にする。


2）RTOSの仮想化およびマイクロカーネル上への実装

上記1）と同様の構造でRTOSを実装する

3）上記2）と4）の同時実装

上記1）と同様の構造でRTOSを実装する。
仮想化された複数のOSを同一のマイクロカーネル環境へ移植することで、
結果としてシステム全体の信頼性を上げることを最終的な目標としている。

(2) 開発するソフトウエアの構成
http://www.elwsc.co.jp/japanese/newsrelease/images/os.gif

(3) 開発するソフトウエアの機能

1）メモリマネージメント制御

上位のLinuxカーネルに対して、メモリマネージメント機能の作成。
Linuxカーネル側ではこのサービスを使用してプロセスおよびスレッドなどのメモリマッピングを行う。


2）デバイスドライバ制御
上位のLinuxカーネルおよびRTOSの仮想デバイスドライバに対して、
実際のデバイス操作を行うサービスの作成。
ベースOSが持っているデバイスドライバに対してアクセスを行う。


3）割込み制御
上位のLinuxカーネルおよびRTOSに対して、実際の割込み調停部の作成。


4）スケジューリングインタフェースユニット
Linuxカーネル自身が持つプロレス/スレッドのスケジューリングと、
RTOSのスケジューリング機能、および、ベースOS側が持つスケジューリングの調整部の作成。



(4) 動作環境
・CPU：ARMコアのマルチコアCPU
・マイクロカーネル：L4 (http://os.inf.tu-dresden.de/L4/overview.html)
・仮想化Linux：L4Linux (http://os.inf.tu-dresden.de/L4/LinuxOnL4/)
・仮想化リアルタイムOS：Toppers/JSP (http://www.toppers.jp/jsp-kernel.html)

宣伝がおおいな

何か小難しく書いてるけど結局ITRONをGCCで実装して
マイクロカーネルに乗っけたLinuxで動かすのと違うんけ？

>>37
誰も読まないと思うが、直前の奴に反論すべきでは。

これだけ一気にベタベタ貼るのは保険の約款といっしょで
暗に読むなといってるようなもんだな。

>>39
ITRONとLinuxは基本的には別個に動作するみたいよ。

>>40-41
己の情報処理能力がないことを他人のせいにするな。

>>43
ソースを要約するのも情報処理能力のうちの1つじゃないか？

>>40
同意。
オレは5年ぶりくらいで見たﾃﾗﾅﾂｶｼｽなプロパガンダなんで丁重にお断りして
後進に道を譲るがね。ｗ
しかし、>>30 は10年近く前の1B/V当時の話そのままなんでﾖｯﾀﾜﾛｽ。ｗｗｗ

TRONって何に使うもの？

>>46
なんにでも。

>>46
TRONは万能のOSを目指すのではなく、
状況に応じたOSを創った。

ITRON＝機械と人間の交流のためのOS
CTRON＝機械と機械の交信のためのOS
BTRON＝人間と脳の交流のためのOS
MTRON＝各種TRONの相互交流


例えばあなたがBTRONを楽しみながら使うと、
一年後には実身/仮身システムを介して意識と脳が直結し、
結果として思考力が深まる。

なぜなら、BTRONは手軽で楽しく深い補完脳システムだから。

>>30
大前提
有益な議論をしたいのであれば、番号を振ることは基本中の基本。
有益な議論をしたいのであれば、差別的な表現を使わないこと。
有益な議論をしたいのであれば、情報操作を掛けないこと。
有益な議論をしたいのであれば、事実と嘘を織り交ぜないこと。
有益な議論をしたいのであれば、コピペを推奨してはならない。

結論
あなたは、議論をするつもりがなく、プロパガンダをしたいだけである。
あなたは、印象操作を行い、情報操作を掛けることが本当の目的である。
あなたは、経済産業省、ジャストシステム、孫正義の工作員である。

理由
通産省（現経済産業省）は、
日米貿易摩擦において、
日本の自動車産業をアメリカ企業として生き残らせることと引き替えに、
日本のエレクトロニクス産業を壊滅させた。
経済産業省は、いまやアメリカの傘下にある組織であり、
TRONプロジェクトを潰すことを組織の至上命題としている。

ジャストシステムは、
TRONプロジェクトが過去のしがらみをすべて絶つ
まったく新しいコンピュータプロジェクトであることの意義を理解せず、
TRONプロジェクトに自社の一太郎をねじ込もうとしたが、
当然のこととして断られた。そしてそれを逆恨みしている。
また、ジャストシステムは、
独自OS路線を採れたにもかかわらず、独自OS路線を捨てた。
そして、ジャストシステムは、国産ソフト愛国企業という偽りの看板をかかげながら、
アメリカとMicrosoftの傘下に入った。
このため、独自OS路線をとり続けているTRONプロジェクトをお門違いにも憎んでいる。
あまつさえ、自社の法務部の強さとアメリカという後ろ盾を武器に、
パーソナルメディア株式会社が10余年の歳月を掛けて完成させた
虎の子のアプリケーションソフト「超漢字原稿プロセッサ２」を剽窃し、
「一太郎文藝」なる盗作商品を販売している。

孫正義は、
アメリカのスパイで売国奴成金である。
孫正義は、貿易摩擦でアメリカが日本を潰すさいに、そのてかとなることで、
莫大なバックマージンを受け取り、新興成金に成り上がった。
孫正義の最大の任務はTRONプロジェクトを潰したこと。
孫正義はそのことを公言し誇りに思っている。

>>30
議論したいのならば、番号を振ることは基本中の基本。

[超漢字/TRONコードの嘘]
01.ISO/IEC 2022(1972制定)をパクって改悪しただけの「TRONコード(1987論文)」
しょせんウリジナルｗ 本家には「新しく作る意味が全くない」と一蹴された。
02.多言語化の為のISO-2022という試みは当時すでに死に体、欧米はその変種の
TRONコードなんか相手にせずISO/IEC 10646(の制定を急いでいた。
03.ISO-10646はUnicode Consortiumが実権を握り「CJK統合漢字」を半ば強引に推し進めた。
後に「漢字の危機」と呼ばれたこの愚行に対し、ジャストシステムは手弁当で海を渡り徹底抗戦した。
一方、日本学術振興会から数億円の補助金で潤ってたTRON一派は「何もしなかった」。
04.ISO-2022は新しい文字集合の追加には慎重だったが、TRONは目先の実績作りに
ケンチャナヨで文字を追加(Unicodeまでも)、結果としてUnicodeと同じ欠陥まで抱え込んで自爆。
コード振るなら馬鹿でも出来ることを証明した。
05.現在の実装では設計の問題からアラビア語などのリガチャを含む文字を
正しく表示できない、Linuxの多言語化ライブラリpangoやm17nlib以下の出来ばえ。
06.150万字収録可能を誇るが、中共のGB18030-2000規格が160万字収録可能な事には一切触れないｗ

>>30
有益な議論をしたいのであれば、番号を振るのは基本中の基本。

[実身/仮身の嘘]
07.さも凄い物のように宣伝するが、WindowsのOLEオブジェクトに毛が生えた程度。
そこらの事務屋のねーちゃんでもACCESS + OLEで同等の処理やってるｗ
08.いまだに約6,5000までのファイル(実身)を持つ事しかできない
最大ファイルサイズも2Gまで、これは懐かしのWindows95のFAT16レベル。
互換性がなくなるので直すに直せないという話もある。
パーテーションも1区画120GBまでしか対応していない
09.ちなみにSolarisのZFSならファイル数はフォーマット時に自由に指定
パーテーション及びファイルサイズの最大は16EB(=1,000PB=1,000,000TB=1,000,000,000GB)まで対応している。
10.TRON厨は「仮身を増やせばいいので実身の少なさは問題じゃない」というが、
画像1000枚をOLE(=仮身)でワードファイル(=実身)に貼り付けて管理しろって
のと同じなわけで、ありえない解決法。
11.ディスクの容量が指数乗に増えてきたせいで、MicrosoftですらWinFSを
性能上の問題(メモリが湯水のように必要)でVistaへの投入を見送った。
BTRONが次期リリース(あるのか？ｗ)テラバイトが当り前の時代にまともな速度を出せるか疑問。

>>30
＞[実身/仮身の嘘]

あなたは超漢字４R4.2を使っていますか？


＞07.さも凄い物のように宣伝するが、WindowsのOLEオブジェクトに毛が生えた程度。
そこらの事務屋のねーちゃんでもACCESS + OLEで同等の処理やってるｗ


OLEは、BTRONの実身/仮身システムのパクりそこないです。

BTRONの実身/仮身システムは、「手軽で楽しく深い。」。

これには、道具論・意味論・身体論の背景があります。
しかし、実身/仮身システムは意識させません。
実身/仮身システムは黒子に徹します。
あなたが考えることを助けながら邪魔しない黒子。
それが実身/仮身システムです。

これを超えるものは未だにありません。
比肩できる物すら未だに皆無です。

世は実身/仮身システムのパクりそこないの死屍累々です。
ハイパーカードしかり、OLEしかり、ネタの種しかり。

>>30
＞08.いまだに約6,5000までのファイル(実身)を持つ事しかできない
最大ファイルサイズも2Gまで、これは懐かしのWindows95のFAT16レベル。
互換性がなくなるので直すに直せないという話もある。
パーテーションも1区画120GBまでしか対応していない


まず基本的な話をしますね。
実身数上限などはこのままでいいんですよ。
BTRONはライトウェアなシステムとしてあくまで軽くあるべきなのです。
BTRONでは軽さこそが命です。

それが嫌だというならば、BTRON一般ユーザを現状の1000倍以上に増加させて、
普通に使って上限まで達したという例を多く集めて、
「ヘビーウェア」なBTRONをつくらせればいいだけのことです。
あるいは自分でヘビーウェアなBTRONを作ればいいだけのことです。
つまり、ライトウェアなBTRONとヘビーウェアなBTRONの両方が必要なのです。

では、個別の話をしましょう。
実身数上限は必要がないから拡張されないだけの話です。
普通に使っていて上限まで達したという例が一定数集まれば拡張されるでしょう。
最大ファイルサイズも必要がないから拡張しないだけの話です。
必要があれば最大ファイルサイズは拡張されるでしょう。
パーティションも必要がないから拡張しないだけの話です。
ユーザが増えてコアなユーザが増えて要望が多くなれば対応するでしょう。

では、最後に根本の話をしましょう。
なぜそれらの「古い」上限が未だに残っているか？
なぜならば、アメリカがTRONプロジェクトを潰したからです。
アメリカがTRONプロジェクトを潰していなければ、
BTRONはマルチメディアOSになるはずでした。
マルチメディアOSになっていれば、
実身数上限・最大ファイルサイズ・パーティション上限などは
とっくの昔に拡張されていたでしょう。

組み込みやってる人間ですが・・・
ＩＴＲＯＮを仮想化しても十分なリアルタイム性を実現と書いてあるのが非常に嘘くさく感じる
Ｈ８やμＰＤでは複数スレッドに分割しただけで処理が間に合わないのに。
ターゲットＣＰＵを故意にかどうかわからないけど隠してるのも気になるし。

組み込みだとＩ／Ｏを占有するってことがよくあるんだけど
そんな事をしても仮想環境が調停してくれるってこと？
んなばかな。ＩＴＲＯＮでＩ／Ｏを占有してる間にＬＩＮＵＸ側でタイムアウト連発の予感

>>30
＞09.ちなみにSolarisのZFSならファイル数はフォーマット時に自由に指定
パーテーション及びファイルサイズの最大は16EB(=1,000PB=1,000,000TB=1,000,000,000GB)まで対応している。


それで？
いちいち一項目にした理由がわかりませんね。

あえてレスをするならば、BTRONの実身/仮身システムの威力を体感した身としては、
他のOSに興味などわきません。
BTRONは特別なOSです。
BTRON以外のあらゆるOSは、凡百なあってもなくてもかまわない普通のOSです。
BTRONこそが真の未来OSです。

>>30
＞10.TRON厨は「仮身を増やせばいいので実身の少なさは問題じゃない」というが、
画像1000枚をOLE(=仮身)でワードファイル(=実身)に貼り付けて管理しろって
のと同じなわけで、ありえない解決法。


工夫はひとそれぞれでしょうが、ありえないとおっしゃっているその解決法は、
Windowsなどでは「ありえない」でしょうが、
BTRONなら誰でも簡単にできることです。

それから、普通に使っていれば10年以上使い続けても、
実身数上限を超えることはありませんよ。

あなたの実身数を教えていただけませんか？

>>30
＞11.ディスクの容量が指数乗に増えてきたせいで、MicrosoftですらWinFSを
性能上の問題(メモリが湯水のように必要)でVistaへの投入を見送った。
BTRONが次期リリース(あるのか？ｗ)テラバイトが当り前の時代にまともな速度を出せるか疑問。


BTRONの軽さは世界一。

軽い速い深い　BTRON
手軽で楽しい　BTRON

BTRONの深さは世界一。

やめられないとまらない♪TRON〜κベTRON♪

>>54

ターゲットはARMじゃないの？

>>54
＞組み込みやってる人間ですが・・・
ＩＴＲＯＮを仮想化しても十分なリアルタイム性を実現と書いてあるのが非常に嘘くさく感じる
Ｈ８やμＰＤでは複数スレッドに分割しただけで処理が間に合わないのに。

このタイプのハイブリッドOSではITRONの持つリアルタイム性は損なわれると考えられます。


＞ターゲットＣＰＵを故意にかどうかわからないけど隠してるのも気になるし。

>>31-37
(4) 動作環境
・CPU：ARMコアのマルチコアCPU


＞組み込みだとＩ／Ｏを占有するってことがよくあるんだけど
そんな事をしても仮想環境が調停してくれるってこと？
んなばかな。ＩＴＲＯＮでＩ／Ｏを占有してる間にＬＩＮＵＸ側でタイムアウト連発の予感

このプロジェクトはおもしろいけれども実践で期待できるものではありません。
T-EngineフォーラムのT-Kernel/SEに期待してください。

2006年、T-Kernelはこうなる！ 〜 T-Kernelロードマップで見る最新事情 〜
1.T-Kernelとは
http://www.atmarkit.co.jp/fembedded/special/tkernel/tkernel01.html
2.T-Kernelを機能拡張するExtension
http://www.atmarkit.co.jp/fembedded/special/tkernel/tkernel02.html
3.T-Kernelの未来
http://www.atmarkit.co.jp/fembedded/special/tkernel/tkernel03.html

マイクロカーネルの上にマイクロカーネルを仮想化すればいいじゃん

失敗しそうなプロジェクト