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

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


2004-07-13 (Tue)

[Linux] Goodbye, Linux 4.

man 再考

今日は man ファイルを通して、Linux と BSD の世界観を検討してみよう。

これまで、雑誌上や本メモ上で指摘してきた通り、Linux 環境における「man section 2」は、惨憺たる状況にある。Section 2 には、開発者にとっての生命線とも言うべき、全システムコールの解説が収められているが、Linux のそれは正式な管理者が存在せず、しかもカーネルハッカーが自由気ままに改編・削除・追加を行うために、最新カーネルとの整合性が全く取れていない箇所が多々存在する(私の経験からして、Linux の man section 2 は、読まない方が身のためである)。

今月号の GCC プログラミング工房でも紹介したが、2.6 カーネルのモジュール関連では、"Init module" system call の引数インターフェースが様変わりし(2つから3つへ)、"Query module" system call に至っては、驚くべきことに削除されている。

ライブラリー内における関数インターフェースの変更であれば、まだ話は分かるが(それでも全世界のユーザーへの影響は甚大である)、カーネル・システムコールの引数が変更されたり、システムコールそのものがあるバージョンから突如姿を消す・・という事態は、良い意味でも悪い意味でも Linux kernel ならではのものだと言えるだろう。

前回紹介した記事やプレゼンテーション資料を読めば、なぜ Russell 氏が周囲の反対を押し切ってまで、この改編を貫き通したのかは、理解できる。確かに、"bad code" に対しては、"patch" よりも "rewrite" が相応しい場合もあるだろう。

しかし・・Linux を巡る状況は、Torvalds 氏が恐る恐る 0.01 をネット上で公開した時とは、打って変わっている。今や Linux は、ひとつのカーネルインターフェースの変化が、全世界のユーザーに影響をもたらすまでに巨大化しているのである。

今回のモジュール・インターフェースの変化により、残業をよぎなくされた技術者達は、かなりの数に上ることだろう。しかも、この変化の技術的背景や、正しい問題回避方法について触れた資料は、カーネルソースツリーはもとより、ネット上にすら存在しない。一体どれだけの、無駄な時間が世界中で浪費されたことか?おそらく、この延べ時間は、Russell 氏自身が 2.6 モジュール開発のために費やした時間を、遙かに上回るのではないかと思われる。

頭の良い Russell 氏であるから、自分のコード改変が世界中のユーザーに与える影響は、事前に予想できていたに違いない。だからこそ、module-init-tools という 2.6 用のユーザースペースツールを自前で用意し、バージョンアップによる混乱を極力避けようとしていたのだろう。

ところが、蓋を開けてみれば、言葉足らずであったことは否めない。モジュール開発者にとっては、2.6 モジュールの正体が掴めないだけでも、大きな不安の種だろう。さらに悪いことには、新しく導入された kbuild による「不透明な 2.6 モジュール構築環境」が追い打ちをかける。こうなると、もはやユーザーは思考停止、ノックアウト状態である。開発者が「わしゃ、2.6 やーめた」と退散したとしても、誰が責められようか?(現実世界において、逃げることはかなわぬ夢だろうが)

このようにしてみると、どうにも不思議でならないのは、module-init-tools ソースツリーの中身である。この中には、新しい insmod, modprobe などのソース以外に、同コマンドの man ファイルが含まれている(insmod.8, modprobe.8 など)。しかし、新しいシステムコールに対応した man ファイルは用意されていない。

なぜか?この背景には、Russell 氏個人だけではなく、Linux 自身が抱える根元的な問題が存在するように思う。

Top pages

ここから先へは、Linux の世界にどっぷり浸かっているだけでは、進めない。思い切って、視点を変える必要がある。幸い現在は、ネットを通じて様々なドキュメントや、ソースツリーが手に入るのであるから、これらを活用しない手はない。

それでは、何気ないことではあるが、様々な PC-UNIX のトップページから man ファイルを探してみよう。

何はともあれ、Linux である。その Linux であるが、正式ホームページとなると、はて一体どこになるのであろうか?Linux と言えば、カーネルである。カーネルと来れば、"The Linux Kernel Archives" であるが、その実体はあまりに素っ気ない。カーネルソースツリーとパッチが無造作に置かれているだけである。

次に OSDN 主催の "LINUX.COM" を見てみよう。こちらは、いささか賑わっているようには見えるが、目指す man ファイルは見当たらない。

RedHat もしかり、SUSE もしかり、あの Debian でさえ御同様という有様である。Linux の世界では、「man ファイル問題はタブー化」しているのだろう。

さて、恐ろしいのは、Linux 界では上記のような事態が日常化してしまい、多くの人達が「これが普通なのだ」と受け止めてしまっている点にある。ここで、BSD を見てみよう。全体として BSD の世界は文書に重きを置いているが、中でも丁寧に整備されている OpenBSD を見て欲しい。

OpenBSD では左サイドバーの中程に存在する "OpenBSD Resources" の2段目に、そのものズバリの "Manual Pages" というリンクが用意されている。

"OpenBSD Manual Pages" には、システムコールのセクション2はもとより、各種システムツールからライブラリーに至るまで、あらゆる man ファイルが完備されている。

しかも、各セクション毎に introduction が設けられており、システムコールであれば、intro(2) を参照すれば、重要な errno のインデックスコードに始まり、各種引数タイプの解説などを一望することができる。

"Very Important For New Systems" と題された afterboot も秀逸である。これは、インストールを完了したシステム管理者向けに、最低限必要な勘所を解説したものだが、「ユーザーが出来るだけ無駄な時間を割くことがないように」という、大人の配慮が伝わってくる。

なぜ BSD では、このように全ての man ファイルを一同に会してユーザーに提供することが出来るのか?その秘密は、ソースツリーにあるが、続きはまた後日(ちなみに、Plan 9 の man ファイルは BSD のさらに上を行く)。