Linuxの普及促進や標準化などを行う非営利団体「The Linux Foundation Japan」は2009年2月25日,技術者向けイベント「The Linux Foundation Japan Symposium」を開催した。10回めとなる今回のシンポジウムは,2009年10月に日本での開催が予定されている「Japan Linux Symposium」をにらんで,日本人コントリビュータの貢献内容やその関連プロジェクトの紹介をテーマに採用。メモリー管理機構の改善やテスト機構の開発などについての講演があった。

 本記事では午前中に行われた2つの講演に焦点を絞ったレポートをお伝えする。

組み込みでの開発成果はデスクトップやサーバーでも役立つ

組み込み機器向けカーネル開発のメンテナとして知られる米Intel社のDavid Woodhouse氏
写真1●組み込み機器向けカーネル開発のメンテナとして知られる米Intel社のDavid Woodhouse氏
[画像のクリックで拡大表示]

 最初の講演は,組み込み機器向けカーネル開発のメンテナとして知られる米Intel社のDavid Woodhouse氏(写真1)が務めた。講演のタイトルは「組み込みLinuxとメインライン・カーネル」である。同氏はここ数年の組み込みLinuxでの開発成果が,いかにメインライン・カーネルに取り込まれたかを紹介し,それが組み込みユーザー以外にとっても有益であることを説明した。例として同氏が挙げたのは,「Ticklessカーネル」,「起動高速化」などである。

 従来Linuxカーネルは,1000分の1秒や100分の1秒といった周期で発生するタイマー割り込み(tick)を基準に動作していた。システムがアイドル状態であっても,この間隔で起床して各種処理を行う実装になっていたので電力消費の面で無駄があった。これに対し,システム・アイドル時にはタイマー割り込みを無視し,完全にシステムを休止できるように改良したのが「Ticklessカーネル」である。2007年4月にリリースされたカーネル2.6.21で導入が始まり,2008年1月にリリースされたカーネル2.6.24でx86-64環境など対応アーキテクチャが拡充された。

 省電力化や起動高速化は,組み込み機器だけでなく一般のPCやエンタープライズ環境でも役立つ。省電力化は電気料金や発熱を抑え,起動高速化はダウンタイムを減らして可用性を向上させるからである。

 他に同氏が例示したのは「XIP」(eXecute In Place)と「DMA API」である。XIPは実行ファイルのデータを,直接プロセス空間にマッピングして実行する仕組みである。主メモリーにファイルのデータをコピーせずに済むので,搭載メモリーが少ない組み込み機器で良く使われる。しかしXIPは元々,S390システムにおいて複数の仮想マシンで同一のバイナリやライブラリを効率良く共有するために実装された仕組みだ。一方,DMA APIは,ARMやPowerPCを搭載する組み込み機器で,キャッシュ・コヒーレンシ(キャッシュ一貫性)を保ったDMA転送を行うために使われてきたインタフェースである。しかしこれも最近では,IOMMUを持つ大規模なシステムで使われている。

 このように組み込み用機能といっても,PCやエンタープライズ向け機能とクロスオーバーするものが多い。Woodhouse氏は「We are not so special!」と強調した。つまり,組み込みだからといって特別ではなく,組み込み開発者がコミュニティに積極参加することで多くのユーザーにとって有益な結果が得られるのである。

 開発者側の利点としては,コードのメンテナンス・コストの低下を挙げた。メインライン・カーネルにコードをマージできれば,カーネルの変更に追随しやすくなる。Linuxカーネルの変更はかなり激しく,独自プロジェクトではこれに追随するのに多大なコストがかかるという。

 もちろん,マージされるコードを書くのは大変である。特定の問題を解決するだけの場当たり的な「ハック」ではなく,できるだけ汎用性を持たせる必要があるし,コーディング・スタイルも「Linux流」に合わせる必要がある。マージのための作業は「ときにかなり辛いかもしれないが,慣れた方がいい」(Woodhouse氏)と言う。マージ・プロセスを経ることで,一般にコードの品質や可読性の向上が見込めるからである。

 特にWoodhouse氏が気をつけるべきとしたのはコーディング・スタイルである。これは一見ささいなことだが,可読性に大きな影響を及ぼす。小さなことが理解を妨げることがあり,マージの際にこれが支障となることもある。コードを書く際は,関数は短くする,StudlyCapsやハンガリー記法は避ける,typedefの多用は避けるといった配慮が必要である。また,カーネルのコーディング・スタイルについてはDocument/CodingStyleという,カーネルの付属ドキュメントに詳しく記載してあるので,これを見ると良いとアドバイスした。

 作成したパッチは,カーネル付属のスクリプト(scripts/checkpatch.pl)で(スタイルを)チェックできる。これでチェックしたあと,パッチを自分の目で見て問題点がないかを調べるべきと語った。さらにパッチは最初に自分自身に送信してテストしておくようにする。これによってメール環境に起因する問題を避けられる。「使えないものを送らないようにするということは,コミュニケーション上重要である」(Woodhouse氏)という。