Linux 2.6とide-scsiモジュール

Linus TorvaldsがLinuxカーネルメーリングリスト（LKML）に投稿した内容をしばらく追いかけていると、「グッドテイスト」で記述されたカーネルコードに対して彼が大きな敬意を払っていることに気付く。

Linusがこれまで自分以外のカーネルハッカーに払った中で最高の敬意は、「グッドテイスト」を持っているという賛辞のようである。これは、彼がAlan Coxを始めとするごく限られた人たちにしか使わない賛辞だ。一方、「バッドテイスト」で記述されたコードに対する彼の嫌悪感も、グッドテイストなコードに対するものと同じほど強いようである。過去数か月間、ある特定のカーネルモジュールを中心にして静かな論争が繰り広げられてきた。表面的には、この問題は当初、2.6カーネルのテスト中に判明した単純なバグのように思えた。ところが、実際にはもっと深刻なものであることが明らかになった。まさに「バッドテイスト」の格好の例だったのである。

問題の所在は

問題のモジュールはide-scsiで、特定の非SCSIデバイスやアプリケーションに「SCSI風」のインターフェイスを提供する働きをする。特に対象になるのは、CD-Rドライブや広く普及しているcdrecordだ。その結果、ide-scsiモジュールに不具合があると、ATAPI IDEテープドライブ、デジタルカメラ、USBストレージデバイスを使用しているユーザーが、新しいカーネルでそのデバイスを使えなくなるのではないかと、LKMLの一部の投稿者が心配し始めたわけだ。

11月の初め、Bill Davidsenは、誰かがCDを焼こうとしたときに生じた問題に関するLKMLの投稿に対して、次のように回答した。

ide-scsiと2.6カーネルの組み合わせには問題がある。この問題を解決するのではなく、cdrecordアプリケーションが正常に動作するように、また、おそらくはある意味で「改良される」ように、誰かがcdrecordへのパッチを考案した。ところが、ide-scsiに関する問題はほかのアプリケーションでも発生すると思われるため、cdrecordで-padオプションを使うか（今では、少なくともTAOについてはこれが標準的だと思う）、IDE-CDドライバを使って読み取ることで、この問題を回避する必要があるだろう。

Davidsenの投稿に対するTorvaldsの返答は次のようなものだった。

On 6 Nov 2003, bill davidsen wrote:
>
> ide-scsiと2.6カーネルの組み合わせには問題がある。
> この問題を解決するのではなく、 cdrecordアプリケーションが
> 正常に動作するように、また、おそらくはある意味で
> 「改良される」ように、誰かがcdrecordへのパッチを考案した。
間違っている。
その「誰か」は、ide-scsiが単に醜いだけでなく、「有害」であり、「cdrecord」の構文や使い方も実に間が抜けていると強く感じた。
そして、その誰かとは僕のことだ。
ide-scsiにはこれまでずっと不具合があった。使うべきではないし、そもそも存在価値が「まったく」ない。ただ、cdrecordのインターフェイスが不完全だったから、cdrecordは昔からSCSIデバイスをいじろうとしてきただけだ。要するに、cdrecordにまったくふさわしくない愚かなエミュレーションレイヤーにすぎない。
誰もide-scsiの問題を解決しようとしないという事実は、誰もそんなことを望まなかった結果だと思う。
だから、使ってはいけない。それでも使うのなら、その解決策を知らせてほしい。
Linus

DavidsenとTorvaldsのやり取りはこの後も続き、その結果、ide-scsiとcdrecordインターフェイスに対するTorvaldsの嫌悪感はますます強くなっていった。Torvaldsの主な意見は次のとおりである。

cdrecordを使用した誰もが、愚劣なSCSI番号付けに困惑してきた。
CDを焼くためにide-scsiを有効にしてブートせざるを得ない人がいたが、（同じドライブで）DVDを鑑賞しようとすると、ide-scsiを外してブートする必要があった。
昔のcdrecordインターフェイスは「信じられないほどのゴミの山」だ。
ランダムなハードウェアレイアウトのメカニズムに基づいたインターフェイスであり、「本物」とはほど遠く、これまでずっと本物であったためしがない。
技術的観点から見ても不良品だし（フラットな名前空間で汎用デバイスに名前を付ける奴は基本的に無知だ）、ユーザビリティの観点から見ても出来損ないだ。レンダリング品質はゼロに等しい。

意見はもっとあるが、Torvaldsがある特定の（ただし、広く普及している）アプリケーションとide-scsiモジュール自体のどちらのアプローチも憂慮していることは十分に伝わっただろう。

Linuxは最悪

（cdrecordが同梱されている）cdrtoolsの作者Joerg Schillingはまったく違う見方をしている。彼は、問題があるのはcdrecordではなく、Linuxだと考えている。彼の意見は次のとおりだ。

Linuxカーネル開発者（および、その最大の広告塔であるLinus Torvalds）にカーネル内部について議論するだけの知識がないことを知って、残念でならない。
礼儀正しいSCSIトランスポートインターフェイスがどうあるべきかを説明しようとすればするほど、私にはうまく説明できなくなってしまう。私は2.6 Linuxカーネルを調べたことはないし、半年以上も前にSuSEがフリーのSuSEディストリビューションを開発者に提供するのをやめてしまったので、とうてい、新しいLinuxカーネルをインストールする気にはなれない。
SCSIトランスポートの実装を比較する限り、Linuxはこれまでで最悪のOSだと思う。まるで一貫性のない新規カーネルが毎年のように登場する。ところが、私が1995年からずっと待ち望み、訴え続けてきた機能を新しいカーネルインターフェイスが備えていたためしがない。そのため、Linuxでcdrecordを開発することができない。必要な機能が欲しいとき、私はSolarisを使用している。

心配すべきなのか

それでも、Bill Davidsenは、テープドライブやデジタルカメラなど、なじみのないデバイスのあらゆるユーザーに対して、降りかかるであろう災難を警告した。これを聞いて、ide-scsiを使用したデバイスを持っているユーザーは、Linux 2.6カーネルにアップグレードすると、どのような状況に置かれることになるのかをぜひ知りたいと思った。そこで、主な関係者にこの点を尋ねることにした。

まず、K3BプロジェクトのSebastian Truegに電子メールを送った。K3Bはすでに2.6カーネルに関する作業を始めていて、これ以上の変更が必要になることはないと保証してくれた。cdrecordについては、K3Bなどのプロジェクトが使用している基盤ツールであり、きちんと機能しており、Torvaldsが送ってくれたパッチに感謝するそうである。

SuSE LinuxカーネルハッカーのJens Axboeにも、ide-scsiモジュールの保守担当者の地位を誰も引き受けない理由を尋ねてみた。彼の返事は次のとおりだ。「実を言うと、ide-scsiはもうそれほど必要ないんだ。なくてもCDを焼けるからね。だから、ide-scsiの「マーケット」は基本的に消えているよ。残りの人は不具合があることまだ知らないんだよ。2.6を試したことがないだろうからね。もしくは、解決できるほどの知識がある人がいないんだろう」

Jensはこの状況にあまり関心がないようだった。続けてこう言ったからだ。「どこかのボランティアがすぐにも解決すると思うよ。そうならなかった場合は、SUSEが出す前に自分で解決しなくちゃならないかもしれないね。たまたま今は不具合があるから、ide-scsiの焼き込み機能が非難を浴びているから使わない方がよいと、（手厳しく）知らせれば済むんじゃない」

Linusにも電子メールを送って、この問題に関してかなりの質問をしたが、面倒がらずに返事をくれた。

Linusが最初に指摘したのは、この問題に対する私の認識不足だった。問題は、ide-scsiにバグがあることではないそうだ。

違うよ。ide-scsiのバグは、保守担当者がいないというだけのことだ。問題は、2種類のサブシステムを組み合わせようとしているせいで、不具合が起きやすい点にある。
「SCSIデバイスの識別」の件は別の問題だ。cdrecordは基本的にファイル名のようなものには注意を払いたがらない。それどころか、SCSI汎用デバイス（できれば、特定のハードウェアとまったくつながりのないもの）として開いて、「バス＋デバイス＋論理ユニット番号」でデバイスに番号を付けようとする。
cdrecordに違和感を覚えるのはまさにこの点だよ。

また、ide-scsiに保守担当者がいない点について、Linusは次のように語った。

そうだね。僕もJensも不具合の件を解決しようとしたし、多くの人にとっては僕の前回の解決策でうまくいくんだけど、だからといって基本的に価値が上がるとは思わないよ。
価値が上がるとすれば次の点だね。
– 「前と同じで済む」（つまり、設定をいじりたくないユーザーは、不具合を避けるためだけに変更したくない）
– IDEテープドライブのような今どき希少なデバイスを使っている人がいるけど、IDEテープドライブはときどきおかしくなることがあるから、彼らは意図的にide-scsi＋SCSIドライバを使うわけ。
最後の点については確信がないんだけどね。そういう報告を受け取ったことがないから。でも、その他の点については確かだよ。
基本的に、通常のIDE-CDの読み書きに関しては、通常のIDEドライバで問題ないはず。動かなかった場合は、ドライバのバグだろうし、ide-scsiはどっちにしろ、きっと動かないよ。

私が確信を持ったのは、彼がこの疑似SCSIを嫌っていて、きちんと番号が振られるのを好むということだ。Torvaldsは次のように書いている。「そのとおり。僕はSCSIコマンドセットが実際に好きだし、ありとあらゆるところで使われているしね（つまり、電気的に見てSCSIであろうとなかろうと、FC、IDE、USBはどれもディスクとのやり取りにSCSIコマンドセットを使用している）。でも、一部の人が持っているからといって、何もかも「SCSI」であるべきという考え方は嫌いだね。

心配せずに、気楽にいこう

簡単にまとめると次のようになるだろう。 IDEデバイス名と古いSCSI命名法を処理するためのパッチがcdrecordに適用されたため、また、IDEデバイス用の大半のアプリケーション（K3Bなど）はcdrecordを使用してそれらにアクセスしているため、2.6に移行しても不具合はわずかで済むと思われる。不具合が生じた場合は、誰かが解決してくれるはずだ。