SourceForge.JP: Open Source Software

発端

2002年9月にRusty Russellは、彼が従来バージョンと比べて、変更点が少ないようにモジュール・ローダのコードを書き直したとLKML(Linux Kernel Mailong List)に発表した。それにはまだ、追加作業が必要であるが、基本的部分は機能し、またCPU hotpluggingやプリエンプションを妨げないように工夫されていた。なお、この時に発表されたRustyのモジュール・ローダ（実際には、insmod, rmmod, lsmod等）からは、従来のモジュール・ローダがmodutilsと呼ばれていたのに対して、module-init-toolsという名で区別される事になった。

これに対してRoman Zippelは、Rustyの方法が単純な問題を解決するにしては、多くの複雑さを加えるように感じた。彼はユーザ空間で動作するアプリケーションに、大きいコードの一部を移してはどうかと提案して議論に加わった。そもそもRomanは2002年7月に、「新しいモジュール・インタフェイス」に関する提案を2.4.18へのパッチの形式で出していたのだが、採用されなかったのである。

別の提案

Romanが提案したパッチは、モジュールがFAILでEXITする機能を加え、ほかにもモジュール管理に必要な制御をユーザ空間アプリケーションに加える事で、一般的なモジュールコードを単純化させるように考慮していた。また、Rustyの方法が互換性を損なうのに対して、必要なだけ長い間は互換性を保つべきであるとも主張した。これは新しいモジュールが古いmodutilsにロードされ、古いインタフェースを使用しているモジュールはしばらくの間働かせ続けられることができるようにする事を意味するものである。

実際はRomanの方法によるモジュールのロードは、現状のinsmodの処理よりは複雑であった。システムコールを追加する必要があるため少しトリッキーであるが、'ld'と2、3行のシェル・スクリプトを使って新しいフォーマットのモジュールをロードすることができるものであった。

採択

Romanの方法では、全てのモジュールがunload可能で、与えられた時間にアンロードされたかを報告するためのAPIを含むようになっていたのに対して、Rustyの方法では状況によってモジュールをunloadさせるのを不可能にすることによって、単純化させていた。しかしGreg KHやAlan Coxが、LSMモジュール(Linux-Security-Module)の処理を例に挙げてRomanの方法の問題点を指摘し、よりシステムに負荷がかからないRustyの方法に賛成したため、Rustyが開発作業を継続したのである。

その後11月、Rustyは次のように彼の新しいモジュール・ツール(module-init-tools 0.8)をLKMLに発表した。以下の文章は彼の最新のmodule-init-toolsの中でも、'NEWS'ファイルとして参照できる。

このリリースでは再びdepmodを必要とする事になった。それは1300のモジュールの処理速度を助けるだろう。以前の2.5.47+カーネルの混乱に対して、depmodの置き換えが提供される。PCIとUSBテーブルの動作のために2.5.50までのバージョンにはカーネル・パッチが要求される。

それから、このリリースにはmodules.conf2modprobe.confが含まれる。単純なものであるが、多くの人が動作させる必要があるだろう。これは、新しいmodprobeの新機能の一つである。いくつかのダミー・オプションも実装されているので、「modprobe-c」もまた、実行可能である、それはMandrakeとRedHatのinitスクリプト処理の助けになるだろう。パッチ、バグ・レポートとそれらのinitスクリプトのコピーを提供した人々のフィードバックには大いに感謝している。どんなバグでもrusty@rustcorp.com.auに報告して欲しい。

* 筆者注

modules.conf2modprobe.confは、従来のバージョンの'modules.conf'を、カーネル2.5 / 2.6で使用する新しいモジュール設定ファイルであるmodprobe.conf'に変換するシェル・スクリプトである。この時にリリースされたバージョンである0.8には含まれていたが、0.9の途中から古い'modules.conf'を参照しないように配慮されたgenerate-modprobe.confにスクリプト名が変わった。

このアナウンスは様々な議論を呼び起こした。例えばGerd KnorrはRustyのパッチのせいで、彼のシステムがブートしなくなったと報告したが、原因はLinusがRastyのパッチの一部を当初はカーネルに取り込まなかったからであった。そのほかにも、いくつかの不具合や意見が投稿された。後に振り返って言える事実としては、この近辺にリリースされた2.5.47から2.5.52辺りのカーネルのモジュールに関する機能が不安定であったが、やがてこの嵐は落ち着いたという事と、Rustyの提案した新しいモジュール・フォーマットとモジュール・ツールの採用がこの時期に決定されたという事である。新しいモジュール・フォーマットの効用については、別の機会に取り上げたい。