The beaver is out of detox
しかし本当にビーバーは完治したのだろうか？今回はカーネル・メンテナであるAndrew Mortonの投稿から、この正式リリースの位置付けと彼のカーネル・メンテナとしての作業を探ってみる。というのもビーバーには、まだ何かいろいろと残っている様子だからである。
Linus Tobalsは、2.6.0の正式リリースが近づくに従って、テストバージョンをビーバーに例えてアナウンスしていた。例えばtest10は”Stoned Beaver”（石になったビーバー）、test11は”Beaver in Detox” （解毒中のビーバー）といった具合に。Linusは以前からしばしば、リリースの節目が近づくと、新しいカーネル・リリースを七面鳥や亀などの動物に例えたニックネームで呼んでいる。今回のネーミングについては、「以前使われた”greased weasel”（油にまみれたイタチ）よりはいいだろう？」という事で、ビーバーになったようだ。
Linusの2.6.0の安定カーネルのアナウンスについて、2.6のカーネルのメンテナであるAndrew Mortonが、LKMLで次のようにフォローしている。
Re: Linux 2.6.0
Linus Torvalds は次のように書いた：
「Andrewには、2.4.xからの2.6.xの変更に関する情報について、警告や手がかりを書き上げてもらったので、ポストしてもらう。いくつかの既知の問題は、リリースに致命的であると考えられなかったので、相当数が待機のため、“-mm”のカーネル・ツリーに置いて修正を保留している。それらの多くは、2.6.0リリースを妥当で確実にするための、検証方法を持っていなかったからである。」
私が出遅れたために、この説明は実際のところ少し短すぎるので、以下を参照して欲しい。2.6でまだ認識されているTODOが、must-fixリストとshould-fixリストの項目としてある。
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/must-fix-7.txt
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt
- 2.6.0カーネルが安定動作し始めて数週間過ぎた。我々は、それがサーバ・クラスのマシン上で好調に動作していると考えている。一方デスクトップとラップトップでは、はるかに広い範囲のハードウェアがあり、それが原因でBIOSのバグやまだインプリメントされていない修正のために、多くの問題を抱えていることがある。2.6.0安定化期間には、かなりの数のそれほど重大でないフィックスが、様々な補助的カーネル・ツリーに蓄積した。これらは2.6.0リリースの後に2.6のメイン・ストリームへ合併される事になるだろう。このようなフィックスのうちの多くが、以下にあるアンドリュー・モートンの”-mm”のツリーにある。
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
- 何か問題があれば、適当なメーリング・リストにレポートして欲しい。メーリング・リストが判らなければ、LKMLに送って欲しい。サブシステムで活動しているメーリング・リストには次のものがある。
- linux1394-devel
- linux-xfs
- linux-acpi
- linux-scsi
- ext2-devel
- linux-usb-users
別の方法としては、カーネル・バグ・レポートをhttp://bugme.osdl.org/のカーネル・バグ追跡システムに入力してもよい。
- モジュール・サブシステム、LVM(デバイス・マッパ)およびRAIDサブシステムには、著しい変更がある。これらおよび他の多くのカーネル変更に関する詳細は以下のDavid Jonesのカーネル・アップグレード文書の中で示されている。
http://www.linux.org.uk/~davej/docs/post-halloween-2.6.txt
初めて2.6のカーネルをテストするユーザはこの文書を調べるべきである。
- ATA RAIDドライバ(例えばHighPoint RAIDドライバ)は新しいBIOコードに移植されておらず、現在の2.6カーネルの下で利用可能ではない。
- 「cryptoloop」はhighmemマシンで動作しない。これの修正は-mmにあって、2.6.1のために待機している。
- デフォルト・ディスクI/Oスケジューラでの既知の性能に関する問題がある。それは(例えば：データベースのような）作業量が小さい、ランダム読み取りと書き込みのときに現れる。大部分は-mmで修正されている。
一般に「デッドライン」のI/Oスケジューラは、「予測可能な」この種の標準I/Oスケジューラよりも多少は速くなっているはずである。データベース管理者は「elevator=deadline」のカーネル・ブート・パラメータを付け足すことを考慮するべきである。
- さらにデータベース・スタイルの作業量に影響を与える、”readahead”コード中の無作法によるパフォーマンスの問題がある。この修正も-mmにあって、2.6.1のために待機している。
- まだ取り込まれていない、多くのフレーム・バッファ・ドライバの修正がある。
Trond Myklebustへの応答
Andrewは別のメールで、2.6.0リリースに対するTrond Myklebustからのメールに答えている。
まず来週が、どれくらい大変なことになるか見てみよう。我々が過去から使用している、問題がある人々をここ(LKML)に招くというプロセスが、うまくいくことをと信じる。従って、そのプロセスに対するあらゆる恣意的な変更は認められるべきではない。
私は、2.7.0の分岐まで、Linusと私がほとんど同じような方法(それは私の好きな方法だが）で2.6.xを担当し続けることができると信じている。
明らかに、2.6に吸収するためのスレショールドはより高くなっていく。また大規模な変更は、より多くのレビューとテストを受けるために保留するので、拒絶されるだろう。私は、そのテスト・サービスの準備のための別のツリーを管理し続けることになる。
一般的に言えば、2.6の寿命の間に大規模な変更がされるだろうとは期待すべきである。そうでなければ信じることが非現実的になるからである。我々は、素材を壊すこと無く(2.7.xに、または2.7.xからの)変更を吸収するためのプロセスを、見つける必要がある。そのようなことは2.5ではかなりよくできたと、私は考える。
持ち込まれたバグ対応の2.6.1を急ぐ場合、我々は来週かそれぐらいには、厳格に対処するべきである。その後私は、-mm patchsetを相当縮める必要がある。
Trond Myklebustは、2.6でのNFS4の実装に関する積み残された問題点について、must-fixリストとshould-fixリストの項目、またそれらにまだリストされてない問題を挙げて要請した。これらに対してAndrewは答えた。私は、しばらくの間人々が、2.6のNFS4クライアント機能性にきわどく依存するとは思わない。そして、あなたの変更はNFS4だけに影響することである。だからワイルドで行こう。
また、Trond が検証したNFS v2/v3 用のRPCSEC_GSS サポートに関する作業については、Andrewは了解した。
ビーバーの行方
ビーバーは解き放されたばかりである。NFSのやりとりは、2.6.0に期待される要求項目のうちの一部に過ぎないが、このようにエンタープライズ・アーキテクチャ（比較的安定しているサーバ・クラスのマシン）上での2.6.0の機能に対してもFIXの議論となる項目はまだあり、また前述のようにハードウェアの進化に伴って変貌しつつある、デスクトップやラップトップ（ノートブック）PCではさらに多くの問題を抱えている。そして、2.4では数多くのCPU / プラットフォーム・アーキテクチャで安定動作が確認されていたのだが、2.6ではまだこれらの遺産を引き継ぐことができていない。ビーバーの行方と成長を見守りたい。
