カーネル比較: 2.4から2.6へのカーネル開発における改善

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 初級

Paul Larson (pl@us.ibm.com), Software Engineer, Linux Technology Center, FIT Team, IBM China Development Lab　

2004年 2月 17日

長く待たれていた2.6カーネルが遂に登場しました。IBM Linux Technology CenterのPaul Larsonが、2.6カーネルの背後にあるツールやテスト、手法など・・改版管理やリグレッション・テストからバグ追跡やリスト保存に至るまで・・を見ていきます。これらによって2.6カーネルはそれ以前のどれよりも良いものとなったのです。

最近行われた新Linuxカーネル2.6のリリースに至るこの3年間の活発な開発活動期間中に、Linuxカーネルの開発やテストに面白い変化がありました。多くの面においては、このカーネル開発に使われた手法は3年前も今日もほとんど同じなのですが、いくつかの重要な変更によって全体的な安定性や品質が改善されたのです。

ソースコード管理

歴史的に見て、Linuxカーネルには正式なソースコード管理や改版管理システムというものはありませんでした。多くの開発者が自分で改版管理を行っており、Linus Torvaldsがコードを入れておいて他の人が引き出せるような、Linuxの正式なCVSアーカイブは無いのが現実だったのです。改版管理が無いためにリリース間に大きな穴が開いていることがよくありました。つまりどの変更が入っていているのか、適切にマージされているのかどうか、次のリリースでは新しいものとして何を想定すべきなのか誰も分からないことが頻繁にあったのです。色々なものが分断されがちでしたが、これも変更が行われている間にもっと多くの開発者がその変更のことを知っていれば避けられたはずなのです。

正式な改版管理とソースコード管理が無いため、多くの人はBitKeeperと呼ばれる製品を使うように助言していました。BitKeeperはソース管理システムで、カーネル開発者の多くがこれまでにも自分のカーネル開発作業にうまく使ってきたものです。最初の2.5カーネルがリリースされた直後から、Linus TorvaldsはBitKeeperが必要に見合うものかどうかを見るために、試しに使い始めました。カーネル開発にほとんど又は全く関心が無い大部分のユーザーには大したことではないかも知れませんが、BitKeeperがLinuxカーネル開発の手法にもたらした変更のおかげで、ユーザーもいくつかの恩恵が受けられるのです。

BitKeeperがもたらした重要な利点の一つはパッチをマージする時に分かります。同じベースのコードに複数のパッチをあて、しかもこうしたパッチの一部が同じ部分に関係している時には、マージによって問題が起きる事が予想されます。良くできたソースコード管理システムであれば、この作業のもっと面倒な部分まで自動的に行うので、パッチのマージが早くなり、カーネルに適用されるパッチのスループットも向上するようになるのです。Linuxカーネル開発のコミュニティは拡大しているので、あらゆる変更を追跡できるように、改版管理も重要になっています。一人の人間がメインのLinuxカーネルに対する変更をきちんとまとめなければならないので、どのパッチも忘れずに当て、しかも簡単にマージでき、管理できるためにはBitKeeperのようなツールは必須なのです。

Linuxカーネルに対する最新の変更を常に保持する中央リポジトリがあるのは重要な事です。カーネルに反映されたどんな変更もパッチも変更セットとして追跡されるのです。エンドユーザーや開発者は自分独自でソース・リポジトリのコピーを保持しておき、簡単なコマンドと最新の変更セットを使って、好きなように更新ができるのです。開発者にとっては、常にコードの最新コピーで作業できるということになります。テスターにとってはこうした論理的な変更セットを使うことによって、どの変更が問題を引き起こしたのかを判定できるようになり、デバッグの時間が短縮できます。最新カーネルを使いたいというエンドユーザーも必要な新しい機能やバグ修正がカーネルに反映され次第更新ができるようになるので、常時更新されている中央リポジトリから直接の恩恵を受けるのです。またどんなユーザーでも、変更がカーネルにマージされ次第その結果を報告したりバグのレポートを出したりすることができるようになるのです。

上に戻る

並行開発

Linuxが成長し、より複雑になり、カーネルの特定部分に特化した開発に携わる開発者の多くが注目するようになると、Linux開発の手法にまた別の興味深い変化が現れてきました。2.3バージョンのカーネル開発の期間中には、Linus Torvaldsがリリースする中心的なカーネル以外には他のカーネル・ツリーはごくわずかしかありませんでした。

ところが2.5が開発されている間にカーネル・ツリーは爆発的に増えました。こうした並行開発ができるようになった理由の一つは、ソースコード管理ツールを使う事によって、開発が同期してできるようになったためです。開発の並行化は、大きな変更を受け入れる前に他の人がテストできるようにするためにも必要なのものです。メモリ管理、NUMA機能、スケーラビリティ改善、アーキテクチャ特有のコード、さらには小さなバグ修正を集めて追跡したツリーまで、といった特定のコンポーネントや目標に注目した独自のツリーを保持するカーネルメンテナーがいました。

この並行開発モデルの利点は、ある特定の目標に向かって大きな変更ができるようになる事、または似たような変更を大量に行える事で、他の人のカーネル安定性に影響を与えることなく、制御された環境で自由に開発を行えるようになるのです。作業が終わったら開発者達は、それまで行った全ての変更を実装したLinuxカーネルの（現在のバージョンに対する）パッチをリリースできます。すると今度はコミュニティのテスター達はこうした変更を容易にテストする事ができ、その結果をフィードバックできるのです。ある部分の安定性が確認できると、その部分はメインのLinuxカーネルの中に個別に（または全て同時に）組み入れられるのです。

上に戻る

バザールでのテスト

歴史的にLinuxカーネルのテスト手法はオープンソースの開発モデルを中心としていました。コードはリリースされ次第オープンになり、他の開発者が見る事ができるので、他の形式のソフトウェア開発には普通ある、正式な検証サイクルというものがありませんでした。「The Cathedral and the Bazaar（伽藍とバザール・・ 参考文献 ）」にある「Linus's Law（Linusの法）」と呼ばれるこの手法の裏にある哲学は「十分多くの目玉（eyeball）で見れば、どんなバグも小さなものになる」、つまり仲間が厳しい目で見れば本当に大きな問題の大部分はとらえる事ができる、という事なのです。

ところが現実として、カーネルには複雑な相互動作が数多くあるのです。たとえ多くの仲間がチェックしたとしても重大なバグの多くがチェックをすり抜けてしまうのです。それにエンドユーザーは最新カーネルがリリースされるとすぐにそれをダウンロードして使うことができ、実際にダウンロードして使ってしまうのです。2.4.0がリリースされた時にはコミュニティの多くの人たちが、その場その場で行われるテストやコード・レビューを補完するような、もっと組織的なテストが必要だと呼びかけたのです。組織的なテストにはテスト計画やテスト手順の再現性なども含まれます。こうした3つの手法を全て使う事で、元々あった2つの方法だけの場合よりもコード品質の向上につながります。

Linuxテスト・プロジェクト

Linuxで組織的なテストを行うようにした最初のプロジェクトの一つがLinuxテスト・プロジェクト(LTP）でした。このプロジェクトはより組織的な手法でLinuxの質を改善しようと言うものでした。その一部には自動テスト・スイートの開発も含まれています。LTPが開発した中心的なテスト・スイートもまた、Linuxテスト・プロジェクトと呼ばれています。2.4.0カーネルがリリースされた時には、LTPテスト・スイートには100位のテストしかありませんでした。Linuxがカーネル2.4や2.5を通して成長・成熟するにつれてLTPテスト・スイートも成長・成熟してきました。今日ではLinuxテスト・プロジェクトには2000を優に超えるテストがあり、さらにその数は増えているのです！

コードガバレッジ

今や新しいツールも使われるようになり、コードカバレッジが行えるようになってカーネルを強化しています。カバレッジは、与えられたテストが実行している時にカーネルのどの行のコードが実行されているかを知らせてくれるのです。もっと重要なのは、カバレッジでカーネルのどの部分が全くテストされていないかが分かるのです。このデータは重要で、このデータによって未テスト部分をテストするために、どんな新ツールを書く必要があるかを知る事ができます。これによって、カーネルがより完全にテストされるようになるのです。（カバレッジの方が一般的に使用されていると思いますので修正しました。）

夜間カーネル・リグレッションテスト

カーネル2.5開発の期間中、Linux Test Projectが行ったもう一つのプロジェクトにLTPテスト・スイートを使ったLinuxカーネルの夜間リグレッション・テストがあります。BitKeeperを使う事で、常時更新される中央リポジトリができ、ここから随時Linuxカーネルのスナップショットを引き出す事ができるようになりました。BitKeeperやスナップショットを使う前には、テスター達は、リリースを待ってからテストをするしかありませんでしたが、今度は変更が行われるとすぐにテストができるのです。

自動ツールを使って毎晩リグレッション・テストを行う別の利点は、最後のテスト以後に加えらる変更が少なくなることです。新しいリグレッション・バグが見つかると、どの変更がそのバグを引き起こしたのか検出するのが簡単になる場合が多いのです。

また、変更が行われたのはごく最近なので、まだ開発者の記憶にも新しく、従って関連のコードを覚えていて修正するのも容易であろうと期待できるのです。おそらくLinusの法には、一部のバグは他のものよりも小さいと言っている補足項があるはずで、そうしたバグこそが夜間カーネル・リグレッションテストがつまみ出すバグなのです。開発期間中や実際のリリース前に毎日これが行えることで、完全なリリースだけを見るテスター達は、より重大で時間のかかるバグにだけ目玉の時間（eyeball time）を使う事ができるのです。

スケーラブルなテスト・プラットフォーム

オープンソースデベロップメントラボ（OSDL）と呼ばれる別のグループもLinuxのテストに大きな貢献をしました。2.4カーネルがリリースされてしばらく後にOSDLはスケーラブル・テスト・プラットフォーム（STP）と呼ばれるシステムを作ったのです。STPは自動化されたテスト・プラットフォームで、これによって開発者やテスターがOSDLのハードウェア上のシステムに用意されているテストを実行できるようになるのです。このシステムを使うと、開発者は（カーネルに対する）自分のパッチでもテストができるのです。STPがカーネルの構築、テストの設定と実行、結果の収集などをしてくれるので、スケーラブルなテストのプラットフォームによってテスト手順が単純化できるのです。結果は将来の比較に備えてアーカイブされます。このシステムでもう一つ良い所は、8つのプロセッサーを持つSMPマシンのような大きなシステムを皆が所有することが無くて済む点です。STPを利用すれば、誰でもそうした大きなシステム上でのテストを実行できるのです。

上に戻る

バグを追跡する

2.4リリース以来、Linuxカーネルに対する組織的なテストになされた改善として一番大きなものはバグ追跡です。歴史的に、Linuxカーネルで見つけられたバグはLinuxカーネル・メーリング・リストに報告されるか、よりコンポーネント専門、またはアーキテクチャ専門のメーリングリストに報告されるか、もしくはバグが見つかった部分を維持管理している個人に直接報告されていました。今まではバグを報告した人がよほど執念深くない限り、バグはどこかで紛失されたり、忘れられたり、無視されたりしがちだったのです。

今度はLinuxカーネルに対するバグの報告と追跡のために、OSDL（ 参考文献 ）でバグ追跡システムがインストールされました。このシステムでは、あるコンポーネントに対するバグが報告されると、そのコンポーネントの維持管理者に通知されるように設定されています。そうするとその維持管理者はバグを認めて修正するか、実はそのバグがカーネルの別部分でのバグであると分かってそのバグを再割り付けするか、またはシステム設定の誤り等によるものと分かって拒否するかといった選択をするのです。メーリングリストには次から次とメールが溢れてくるので、メーリングリストにバグを報告しても失われてしまう危険があります。ところがバグ追跡システムでは、常に全バグの記録とそのバグがどういう状態にあるのかが分かるのです。

上に戻る

情報の量

こうした情報管理の自動化手法に加えて、オープンソース・コミュニティの色々なメンバーによって、2.6 Linuxカーネルとなるべきものの開発期間中に驚くほどの量の情報が集められ、追跡されています。

カーネルのバージョンの歴史 私たちの多くはこの段階でLinuxカーネル・バージョンの番号付け体系を知っているはずですが、Andries Brouwerは how atypical it really is（実はそれがいかに型破りなものか）を教えてくれます。 Linuxの最初の公開リリースは1991年10月の version 0.02 です。２ヶ月後の1991年12月、LinusはMinix無しに動作する最初のスタンドアローンのカーネルである、バージョン0.11をリリースしています。 さらに１ヶ月後の0.12リリースの後、その成熟具合を反映して3月にバージョン番号は0.95に跳ね上がりました。とは言えマイルストーンとなる1.0.0は２年後の1994年3月でした。 カーネル開発に見られる2種類の「流れ」の年代記も。この頃に起源があります。偶数バージョンのカーネル（1.0や2.2、2.4それに2.6）は安定な「生産」モデル、奇数バージョン（1.1や2.3）のカーネルは最先端つまり「開発」カーネルです。最近までは、新しい開発カーネル作業の開始は安定カーネルのリリースからせいぜい数ヶ月後でした。2.5の作業の開始は2.4が終了してから10ヶ月近く経ってからだったのです。 ではカーネル2.7はいつなのでしょう？ 簡単には言えませんがKernelTrapには既に a thread to discuss it ができています。 それまではRagib Hasanによる記事 History of Linux で歴史を楽しんでください。

例えば、提案されている新しいカーネル機能を追跡するためのステータス・リストがKernel Newbies（カーネル初心者）サイトに作られました。このリストには新機能の項目が載っており、その項目が完成したらどのカーネルに含まれるはずか、まだ不完全であれば、あとどれくらいで出来上がるかといったステータスの順に並べられています。リストの項目の多くは、大きなプロジェクトではWebサイトへのリンクを、小さな項目の場合にはその機能を説明するeメール・メッセージのコピーへのリンクを含んでいます。

一方「post-halloween document（ハロウィーン後文書）」には、次の2.6カーネルには何ができるのかが記されています（ 参考文献 ）。post-halloween documentにある説明の大部分はユーザーが気付くような主な変更や、（利用するには更新が必要となる）システム・ユーティリティについてに費やされています。この情報の対象者としては、2.6カーネルの中に何があるのか早く覗いてみたいと思っているLinuxディストリビューターですが、エンドユーザーもその対象でした。この情報によって、新しい機能を利用するためにアップグレードが必要なプログラムがあるのかどうか判断できたわけです。

Kernel Janitors（カーネル管理人）プロジェクトでは修正が必要な小さなバグや後処理のリストを保持してきました（実際今でも保持しています）。こうしたバグ処理や後処理の大部分はカーネルにあてられたパッチの内、（例えばデバイスドライバーに影響するような）コードのあちこちに変更が必要になるような大きなパッチのために引き起こされたものです。カーネル開発が初めての人はこのリストにある項目に対して作業をすれば、小さなプロジェクトでカーネルコードの書き方を学べる一方で、コミュニティに貢献できる可能性があります。

リリース前プロジェクトとしてもう一つ、John Cherryがリリースされたカーネル各バージョンのカーネル・コンパイル中に見つかったエラーや警告の数を追跡しています。こうしたコンパイル統計は時間と共に確実に低下するので、こうした結果を整理して公開することでどれくらい進展したかが明確になります。コンパイル時の警告はごく簡単に修正できるような小さなバグに起因する場合が多いので、色々な点からこうした警告やエラー・メッセージの一部はKernel Janitorsリストと同じような使い方をすることができます。

最後に、Andrew Mortonによる「must-fix（修正必須）」リストがあります。彼は2.6リリース後カーネルの維持管理者に選ばれたので、その特権を使って彼の目から見て2.6カーネルの最終リリース前に解決が必要で最も優先度が高いと思える問題を選び出したのです。must-fixリストにはカーネルBugzillaシステムのバグや最終調整が必要な機能、既知の問題のうち、解決までは2.6のリリースを止めるべきだと多くの人が考えるような問題などへの参照が含まれています。この情報は新しいリリースを行う前にどんな段階を踏む必要があるかという行程を立てる上で役に立つものでしたし、長く待たれている2.6のリリースがどれほど近いのか知りたがっている人たちには貴重な情報でもありました。

こうした資料の一部は昨年暮れの2.6のリリース以来どうも更新を停止しているようであり、また一部はこの主要リリースの後でも作業は終わっていないとして更新情報の掲示を続けています。次の主要リリースが近づいた時に、何がとり上げられ、どんな革新が追加されるのか興味あるところです。

上に戻る

まとめ

新しい、安定なバージョンのカーネルについて多くの人が最初に考えるのは「このリリースでは何が新しいのか？」ということでしょう。実は新しい機能や修正の下には、時間をかけて改善を図ってきた過程があるのです。

Linuxコミュニティではオープンソースでの開発が盛んです。Linuxのカーネルについて作業するコード設計者への統制が緩いことなどLinuxの持つ色々な要素のおかげで、このグループの人たちがうまく協力しやすくなっています。多くの点で、Linuxの開発やテストでとられている手法、特にLinuxが時間と共に進化してきたその姿が、個々の改善やバグ修正がもたらした影響よりも新しいカーネルの信頼性に影響してきたと言えるでしょう。

参考文献

• Eric S. Raymondによる「 The Cathedral and the Bazaar」を読んだ事がないなら、ぜひ読んでください。もし読んでから大分経っているなら再度読んでみてください。Raymondによるこのエッセイやその他の作品が 本として 出版されています（1999年O'Reilly & Associates刊）。
  
  
• Wikipediaによる Linus's Law の定義を読んでください。最初はEric S. Raymondによる「The Cathedral and the Bazaar」に出てきたものです。
  
  
• BitKeeper はソース制御管理システムです。LinuxカーネルのBitKeeperは BitMover が管理しています。
  
  
• Linuxカーネル本筋のバグを掲示する Kernel Tracker システムは Bugzilla に基づいています。
  
  
• 2.5開発の間、2.6カーネルで何が期待できるかをユーザーは the "post-halloween" documentで知る事ができました。また、提案された新しいカーネル機能を追跡するための リスト が作られ、 Kernel Janitors project が小さなバグや後処理をまとめたリストを作り始めました（Kernel Janitorsはいまでも更新されています）。
  
  
• 2.6が公開されたので、カーネルについての最新ニュースを知るには Linux Kernel Mailing List を見るか、購読すればよいでしょう（ただし膨大な量が来ますので注意！）。普通の人であれば Kernel Traffic を見るか購読すればよいでしょう。こちらはLinux Kernel Mailing Listを専門家が注釈を付けた要約版に近いものなので好ましいかも知れません。
  
  
• LinuxHQ もカーネルやカーネル・プログラミングに関する資料や情報の宝庫です。
  
  
• Open Source Development Labs （OSDL）はLinux採用加速に特化した推進協議会です。2.6カーネルのリリースにあたり、 新しいカーネルのために彼らが行った貢献を概説する声明 (US)を発表し、OSDL自体についてもさらに情報を提供しています。OSDLが行ったテスト結果は（John Cherryによる Linux 2.6 Compile Statisticsを含め） OSDL Linux Stability page で見る事ができます。OSDLはIBMやRed Hat Linux、SUSE LINUXその他の会員会社による費用負担で運営されています。
  
  
• OSDLやIBM他多くは Linux Test Project （LTP）にも貢献しています。
  
  
• リグレッション・テストは新しいコードが古いコードを壊したりしないかを確認します。これについて、また他のテスト形式についてTesting Craftの Grand Index of [testing] Techniques を読んでみてください。
  
  
• IBM Systems Journalには IBMでソフトウェアのテストがどのように行われているか について多数の記事が掲載されています (US)。
  
  
• 内部的にはIBMの Linux Technology Center はLinux開発コミュニティと直接作業しています。
  
  
• Linux at IBM サイトではIBMのあらゆる部署からのLinuxに関するニュースを提供しています。
  
  
• 2.6リリースの前にIBMdeveloperWorksでは「 Linux 2.6へ 」（developerWorks 2003年9月）を特集し、新スケジューラーやNative Posix Threading Library (NPTL)を含む新しいカーネルの魅力を紹介しています。
  
  
• また記事「 Putting Linux reliability to the test 」developerWorks 2003年12月）も読んでみてください。
  
  
• developerWorks Linuxゾーン にはLinux開発者のための資料がさらに豊富に用意されています。
  
  
• Developer Bookstoreの Linuxセクション には多彩な技術書があります。
  

著者について

		Paul LarsonはIBMのLinux Technology CenterのLinuxテスト・チームで働いています。昨年行った作業にはLinuxテスト・プロジェクトや2.5/2.6カーネル安定化、カーネル・コード範囲解析などがあります。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る