SWEST6 セッションSB-4 議事録 「Beyond Consumer Electronic Linux」 2004年7月23日 講師　中本幸一 参加人数　25から30名ほど ＊講演内容 １．Consumer Electronic Linux仕様の紹介 ２．Beyond Consumer Electronic Linux 携帯Linuxの開発経験から ＊Part1.　Consumer Electronic Linux仕様 ＊CE Linux Forum 　理念：LinuxがCE機器に広く利用され，継続的に発展していくことを目指す 　　いままでのやり方では生産性が追いつかなくなっている． 　　生産性のいいOSが必要−＞Linuxに白羽の矢が立つ． 　　LinuxのメンテナにCE機器の重要性をアピールしていく． 　活動内容： 　　従来のLinuxにおいて，CE機器の観点から共有的な仕様を定義する 　　商品開発の使用するなどの方法により，実現した仕様・機能の普及をはかる 　　Linux関連企業・団体・個人などのCE機器への関心を高め，Linuxコミュニティによる 　CE向け仕様・機能の発展を促進する． 　期間：2003年4月より2年間 　対象範囲： 　メンバ： 　　松下，SONY 　　日立，IBM,NEC,Philips,Samsung, Sharp，東芝，NOKIA，モトローラ 　など．．． ＊CELF　Spec　v1.0 　CELFでは以下の6つについて仕様を検討している 　1．Boot Time 　　　Linuxの立ち上がり時間をいかに短くするか 　2．Power Management 　　　低消費電力にするにはどうすればよいか 　3．Audo/Video/Graphics 　　　どれを標準にするか 　4．Realtime 　5．System Size 　　　カーネルのフットプリントを小さくする 　6．Security 　それぞれワーキンググループが検討してきた 　講師は、System Sizeのワーキンググループに参加していた ＊Bootup Time 　Purpose: To define requested or required features of Linux which 　　　　　improve the bootup time of the system for such products 　ブートアップ時間とは：電源を入れてからユーザが使えるようになるまで 　ブート時間を短縮するための具体的な方法 　1．Calibrate Delay Avoidance 　　　calibrate_delay()ティックタイムの計算に時間がかかっている 　　　−＞カーネルコンフィギュレーションで設定することで起動時間を短縮する 　2．IDE NoProbe 　　　つながっていない機器にプローブしにいくのは時間がかかる 　　　−＞無いものは無いと設定しておくことで，起動時間を短縮する 　3．Kernel Execute-In-Place（XIP） 　　　カーネルをROMから直接起動することで起動時間を短縮する 　　　従来はカーネルをいったんRAMに展開していた 　　　　しかし、期待したほど短縮されていない ＊Power Management 　電池駆動の携帯機器をどうやって長持ちさせるか 　　−＞Suspend・Resumeをちゃんと入れる 　Voltage/clock scalingを使った消費電力の低減 　　　P = K * Cout * Vdd ^ 2 * f 　　　K : activity factor 　　　Cout: total chip capacitance 　　　Vdd : supply voltage 　　　f : clock frequency ＊Power Management Architecture 　アーキテクチャ図を参照 　ユーザレベル 　　　Energy-aware Applications 　　　　　消費電力を考慮したアプリケーションプログラム 　　　Policy Manager 　　　　　デバイスへの電力供給を管理するプログラム 　カーネルレベル 　　　Platform suspend/resume 　　　　　もとのLinuxではきちんと実装されていないので，それをしっかり仕様 　　　　として固める 　　　Dynamic Power Management 　　　　　プログラムが動いているときに電力管理をする 　　　　　　例：割込みがきたときには電力を上げ，そのほかの時には電力を下げる 　　　　　メカニズムを提供する．ポリシはユーザが決める． 　　　Device Power Management 　　　　　デバイス毎にサスペンド・レジュームができるAPIを提供する 　　　　　2.6のDriveModelをうまく使っていく． （余談：現在のCELinuxは2.4ベース．2.5や2.6の機能をバックポートしている） 　　　　Working in Progress 　　　　アプリケーションとポリシマネージャのプロトコル 　　　　自動的なデバイスのPower Saving ＊Audio/Video/Graphics 　Purpose: to define default/standard interface for AVG 　新しいものを作らずに，世の中にあるいいものを使う． 　　　Audo 　　　　　　　−＞ALSA 　　　Video-in・Capture　−＞V4L2 　　　Video-out・Graphics−＞DirectFB（FrameBuffer） ＊Realtime 　Purpose: To improve realtime capabilities of Linux 　　fixed priority schedulingを入れる 　カーネルをプリエンプティブにする 　　O(1)スケジューラの導入 　割り込みをできるだけカーネルスレッドで受ける 　　Interrupt 　　SoftIRQ 　POSIXのすべては実装できない 　　Timer, Message Queueを導入 　　Priority Inheritance on User Mutexes ＊System Size 　携帯電話のROMのサイズを調べると 　　　ミドルウェアがメモリを食っている 　　　カーネルは小さい 　コンフィギュレーションによってサイズがどう変わるかを計る方法を定義する 　以下について，典型的なブートプロセスと比較する 　　　　　　　　O：向上した 　　　　　　　　-：同じ程度 　　　　　　　　X：悪い 　　＊Kernel XIP 　　　ROMSIZE　X 　　　RAMSIZE　O 　　　BOOTTIME O 　　　EXESPEED X 　　＊Compress FS（initrdを使う） 　　　ROM O 　　　RAM X 　　　BOOT X 　　　EXEC - 　　＊CRAMFS 　　　ROM O 　　　RAM - 　　　BOOT - 　　　EXEC - 　　　　　　　　注意：ReadOnly File Systemであるので使い方を選ぶ 　　＊JFFS2 　　　ROM O 　　　RAM - 　　　BOOT X 　　　EXEC - ＊Security 　目的：よりセキュアにする 　　Protected RAM file systemの導入 　　　　ユーザデータへの影響をできるだけおさえる ＊PART2．携帯Linuxの開発経験から 1．ミドルウェア標準化の必要性 　　　Memory Usage in a mobile phone product 　　　　携帯電話において何がメモリを食っているかを調査した． 　　　　　　カーネルは40％弱 　　　　　　ミドルウェア50％弱 　　　　　　アプリケーション20％弱 　　　　　　−＞ミドルウェアの占める量が多い． 　　　ミドルウェアを小さくしなければならないが．．． 　　　　機能を落とさなければならない． 　　　どうやってやればよいのか？各社でやり方を共通化・標準化しなければならない． 　　　　アプリケーションのポータビリティの確保 　　　　やり方は製品によって異なるだろう． 　　　対象としているミドルウェア 　　　　ウィンドウシステム 　　　　　アプリケーション表示の根幹に関わるので重要 　　　　通信プロトコル（ソケットより上のプロトコル） 　　　　　一個プロトコルがあればOKという状態にしてほしい 　　　　　アプリケーション毎にプロトコルがついてくるのが現状 　　　　　（OSも同じプロトコルを提供していることがある） 　　　　　−＞共通化したい 2．開発環境について 　　　UserModeLinuxを使う 　　　　ターゲットの環境は固定だが，ホストのバージョンは頻繁に変わるのが現実． 　　　　　−＞リコンパイルで一発というわけにはいかない． 3．品質保証の仕組み 　　　Linux自身に起因する要因 　　　　オープンソースのプロジェクトであり，新しい機能が次々と追加されている 　　　　テストされていない機能や不十分な機能がある． 　　　　　−＞品質が不揃いである 　　　　　−＞誰が面倒を見るのか？ 　　　　　　−＞携帯メーカ各社が努力している（メーカの宿命） 　　　　　　　−＞協調のための仕組みを作れないか？ 4．CE製品向けアプリケーションソフト統合アーキテクチャの必要性 　　　携帯電話アプリの利便性向上 　　　　携帯アプリの粒度と，Linuxのプロセス・スレッドの粒度が異なる． 　　　　　Fork/Execの数が多くなる． 　　　　　　−＞アプリを常駐させなければならないから？ 　　　　携帯電話アプリの複雑さの克服 　　　　　携帯アプリの連携，携帯アプリの粒度とプロセスの粒度の違い 　　　　　デスクトップPCのアーキテクチャを使っていいのか？ ＝＝＝＝＝ 質疑応答 Q．携帯電話では通信用プロセッサとUIのプロセッサを分けているのか A．YES 　CDMAの処理はすごく重い 　通信用のプロセッサをライセンシングして商売したい Q．通信用プロセッサとユーザ用のプロセッサが分かれているが，両方含めてLinuxで 　やろうとしているのか，それともUIだけか？ A．通信処理はTRONを使い，UIはLinuxでやっている Q．NECがLinuxの品質を改善した部分はオープンソースにしているのか？ A．YES Q.CELFでのソースコード管理 新しいバージョンに追従していくときは，各社でやるのか，CELFの責任者がやるのか A．現在は決まっていない Q．ある会社が提案した後で，その会社が抜けたらそのコードをメンテナンスする人が 　いなくなる．それをどうするのか？ A．オープンソース開発のやり方を踏襲する．必要になったらほかの会社が開発する． 　そのためにソースコードを共有する仕組みを整備している． Q．各社共同でテストケースを作るという話はあるのか？ A．具体的な話はない． Q. 携帯電話を作るときは電力が重要だと思うが，OSやミドルウェアではどのような 　努力をしているのか A．ディスプレイと通信が電力を食う． 　　ディスプレイ−＞ミドルウェアのレベルで省電力化している 　　通信−＞OSのレベルで省電力化を図っている Q．CELFではミドルウェアがリッチであるが，スピードやメモリサイズとのトレード 　オフはどのように考えたのか？ A．CELFではウィンドウシステムまで考えられていない．つまり，CELinux上のミドル 　ウェアまで仕様を決めているわけではない． 　携帯電話は5年遅れのPCである．トレードオフは特に考えていない．ノートPCを基 　準に考えている． Q．ミドルウェアも含めたリアルタイム性を考慮する必要があると思うが，LINUXでは 　困難である．どのように考えているか？ A．すでにあるものを使って標準化するというのが今のやり方． 　今ないものは，同じ土俵に上げる．（人が開発するのを待つ？） 　CELF自身は新しいものを開発しようという姿勢が弱い 　　　それを開発するためのオープンソースコミュニティを立ち上げる支援をする Q．UMLを採用しようと思った経緯について A．ホストの環境の違いを吸収するため