/ «2004-07-04 (Sun) ^ 2004-07-13 (Tue)» ?
   西田 亙の本:GNU 開発ツール -- hello.c から a.out が誕生するまで --

Categories Books | Hard | Hardware | Linux | MCU | Misc | Publish | Radio | Repository | Thoughts | Time | UNIX | Writing | プロフィール


2004-07-06 (Tue)

[Linux] Goodbye, Linux 3.

Source be with you!

今日は視点を変えて、Paul Rusty Russell 氏の立場から、2.6 モジュール問題を捉えてみる。

既に述べている通り、Russell 氏自身は今回のモジュール改編に関して、ほとんど文書を作成していない。Linux 2.6 カーネルソースツリーはもとより、同氏が作成に関わっている module-init-tools パッケージ内部にも、説明と言えるような記述は見当たらない。よって、2.6 モジュールに新たに関わることになった世界中のエンジニア達は、まさに手探り状態で歩を進めることになる。

「2.6 カーネルの華々しい登場と共に、世界各地でその新機能を紹介する記事が配信されたではないか?」という意見もあるだろう。しかし、少し斜め読みすれば分かることなのだが、この手の紹介記事は表層をさらりと撫でるだけであり、読み終えたところで何ら残るものがない、もしくは書いている本人が内容を理解していないため、読者はチンプンカンプンというものが、ほとんどである。

「いや、そんなはずはない。世界のどこかに有効な資料があるはずだ!」と、辛抱強く検索を続けた猛者の目には、5/2 のメモで紹介した、"Porting device drivers to the 2.6 kernel""Migrating Device Drivers to the 2.6 Kernel" などが見つかるかもしれない。しかし、これらの資料とて本気で読み進めて行けば、「make modules の裏側で一体何が起こってんのよ?」、「そもそも 2.4 モジュールと 2.6 モジュールの物理的違いってどこにあるの?」という根元的問題には全く触れていないことが分かる。要するに、

誰も分かっていない、もしくは誰も問題点を明文化していないのである。

結果、「"Source be with you!" だよ、お兄さん、いやオジサン」と年老いた頭を鼓舞するしかない訳だが、最近の集中力低下は凄まじく、テストコードを組んで解析を終える頃には、それこそ息も絶え絶え・・の状態。しかも、これまで精魂込めて書き上げた解説が、新しいカーネルの登場によって、全面的に書き直さなければならないというのは、ライターですら萎える。新たなコードの導入によって、Replace される側のプログラマーは、もっと応えるだろう。

よって、ここに "Module War" の幕が開ける訳である。

The Great Module War

2.6 カーネルが持つ新機能の中でも、極めて重要な位置を占めるモジュール改編の背景については、次のふたつの資料が参考になる(というか、このふたつ以上に優れた資料を見つけることは出来なかった)。

前者は、日本で昨年10月に行われた Linux Kernel Conference 2003 での Russell 氏の講演資料を PDF 化したもの。後者は、硬派な記事で知られる KernelTrap.org で紹介された、Russell 氏へのインタビュー記事である。

残念ながら、前者はプレゼンテーション資料をまとめただけであり、講演内容については、各スライドから推測するしかない。しかし、極めて興味深い内容を含んでおり、私のように当日の講演を聞き逃した方の中で、モジュールに興味をお持ちの方には、是非とも一読をお勧めする。

ただし、本講演の内容を理解するためには、2.4 モジュールと 2.6 モジュール回りのカーネルソースおよびヘッダーファイルを熟読しておく必要があるだろう。あとは、ELF セクション構造と、GCC における __attribute__ 指定子使いこなしのノウハウも必要。

余談ではあるが、Linux カーネルを読みこなすためにまず必要なことは、binutils および GCC の基本操作知識を身につけると共に、ELF の構造、中でもセクション構造、さらには GNU tool によるセクション管理の方法をマスターすることにある。

私自身その昔「とっても痛い目」にあったので、よく分かるのだが、世の中の識者達は誰も「カーネルソースを読む前に、binutils/GCC/ELF を勉強せよ!」とはアドバイスしてくれないのである。このアドバイスに出会うことが出来なかったおかげで、まる2年近くは無駄な彷徨を続けてしまった・・。

「人生は短い。後輩の方々には、私と同じ轍は歩まずに、最短距離を進んで欲しい」という思いで、GCC プログラミング工房はスタートした。近々連載の方はお休みを頂いて、これまでに書いた記事をベースにしながら、GNU 開発ツールおよび ELF 解説書を「現在の視点」から新たに書き上げる予定。ということで、書籍の方は今しばらくお待ちくださいませ。

Russell 氏曰く

さて、肝心の講演資料だが、この内容を解説するためには、連載にして数回分以上の分量が必要になる。来月の GCCプログラミング工房を読み終えた上で、再度目を通して頂ければ、より深く味わうことができるかもしれない。手短にまとめれば、この講演の中では次のようなことが語られている。

  • Russell 氏がモジュールの改編に取り組むことになった、その理由と背景
  • 当時の 2.4 モジュールに存在した問題点
  • それまでユーザースペースで行われていたたリンク作業をカーネル内部に持ち込むアイデアとその実現
  • その結果、いかにコードが短縮かつ洗練されたか(insmod などのツールも含む)が述べられる。Russell 氏ここで一句
You'll Only Ever Know If You Write The Code
  • 御意。意訳すれば、「自分自身の手でコードを書いた時、初めて問題点とその解決方法を理解することができる」、これには諸手を上げて大賛成。
  • カーネルソースツリーへのマージを巡る戦いや他のハッカーから受けた影響の話(.gnu.linkonce.this_module セクション誕生の舞台裏が明らかにされている)が続く。そこで、氏曰く
Be Vicious With Code. Be Nice With People
  • これは、Linux community を理解する上で、非常に示唆に富む言葉であろう。以後、いくつかのテーマが続くが、この資料中で最も着目すべきは、次に示すふたつの Rusty's Lesson である。
No Feature Is Complete Until It Has Lots of Users.

そして、

Good Code Lowers The Barriers: More People Can Do More Cool Things.

氏が数々の軋轢をものともせず、積極果敢にコード改編に取り組む背景には、このような信念が存在するのである。

Where to go?

続いて、 KernelTrap.org で紹介された、Russell 氏へのインタビュー記事を見てみよう。この長文のインタビュー記事を作成した Jeremy Andrews 氏、ただ者ではない。

ちなみに、Russell 氏は先ほどの講演資料中で、自己紹介のために、同インタビュー記事を引用している。それはなぜかと言えば、Jeremy 氏が、2.6 モジュールの意義を十二分に理解できるほどの凄腕インタビュアーであると同時に、事実を冷静に分析し読者に伝える力を持っているからである。

一般的に、インタビュアーというのは「お前、分かっとんのかい!」という輩が多いものだが、本記事はその意味において、奇跡的ですらある。

「質問をする」ということは、実は極めて高等なテクニックであり、長期間にわたり地道な修練を要する。少しでも「アホな質問」を浴びせかけようものなら、実力を持った相手であればあるほど、瞬間的に見限られてしまうからだ(無論、聴衆からも)。見限られてしまっては、価値ある一言を引き出せるはずもない。こうして、多くのインタビューは不毛に終わるのである。

最後に、本インタビュー記事の中から印象的な言葉をふたつ紹介しておこう。ひとつは、Russell 氏がインタビュー中で引用している、Kernighan and Pike の言葉。

Don't patch bad code, rewrite it!

そして、もうひとつは「あなたがこれから取り組もうとしている、次のカーネルプロジェクトについて教えてください」という問いに対する答え。

... There's some "workload management" stuff which looks really useful, but maybe I'll
wonder into some of the more bohemian parts of kernel and be forced to rewrite that instead.

このふたつの言葉に氏の考え、そして Linux kernel の行く末がよく現れている。Linux user たるもの、カーネルの rewrite は今後も覚悟しておかねばならないだろう。

次回は少し視点を変え、BSD や Plan9 の世界から、今回の問題を考えてみたい。