264 lines · plain
1NOTE:2This is a version of Documentation/process/stable-api-nonsense.rst into Japanese.3This document is maintained by IKEDA, Munehiro <m-ikeda@ds.jp.nec.com>4and the JF Project team <http://www.linux.or.jp/JF/>.5If you find any difference between this document and the original file6or a problem with the translation,7please contact the maintainer of this file or JF project.8 9Please also note that the purpose of this file is to be easier to read10for non English (read: Japanese) speakers and is not intended as a11fork. So if you have any comments or updates of this file, please try12to update the original English file first.13 14Last Updated: 2007/07/1815==================================16これは、17linux-2.6.22-rc4/Documentation/process/stable-api-nonsense.rst の和訳18です。19翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >20翻訳日 ： 2007/06/1121原著作者: Greg Kroah-Hartman < greg at kroah dot com >22翻訳者 ： 池田 宗広 < m-ikeda at ds dot jp dot nec dot com >23校正者 ： Masanori Kobayashi さん < zap03216 at nifty dot ne dot jp >24 Seiji Kaneko さん < skaneko at a2 dot mbn dot or dot jp >25==================================26 27 28 29Linux カーネルのドライバインターフェース30（あなたの質問すべてに対する回答とその他諸々）31 32Greg Kroah-Hartman <greg at kroah dot com>33 34 35この文書は、なぜ Linux ではバイナリカーネルインターフェースが定義36されていないのか、またはなぜ不変のカーネルインターフェースを持たな37いのか、ということを説明するために書かれた。ここでの話題は「カーネ38ル内部の」インターフェースについてであり、ユーザー空間とのインター39フェースではないことを理解してほしい。カーネルとユーザー空間とのイ40ンターフェースとはアプリケーションプログラムが使用するものであり、41つまりシステムコールのインターフェースがこれに当たる。これは今まで42長きに渡り、かつ今後も「まさしく」不変である。私は確か 0.9 か何か43より前のカーネルを使ってビルドした古いプログラムを持っているが、そ44れは最新の 2.6 カーネルでもきちんと動作する。ユーザー空間とのイン45ターフェースは、ユーザーとアプリケーションプログラマが不変性を信頼46してよいものの一つである。47 48 49要旨50----51 52あなたは不変のカーネルインターフェースが必要だと考えているかもしれ53ないが、実際のところはそうではない。あなたは必要としているものが分54かっていない。あなたが必要としているものは安定して動作するドライバ55であり、それはドライバがメインのカーネルツリーに含まれる場合のみ得56ることができる。ドライバがメインのカーネルツリーに含まれていると、57他にも多くの良いことがある。それは、Linux をより強固で、安定な、成58熟したオペレーティングシステムにすることができるということだ。これ59こそ、そもそもあなたが Linux を使う理由のはずだ。60 61 62はじめに63--------64 65カーネル内部のインターフェース変更を心配しなければならないドライバ66を書きたいなどというのは、変わり者だけだ。この世界のほとんどの人は、67そのようなドライバがどんなインターフェースを使っているかなど知らな68いし、そんなドライバのことなど全く気にもかけていない。69 70 71まず初めに、クローズソースとか、ソースコードの隠蔽とか、バイナリの72みが配布される使い物にならない代物[訳注(1)]とか、実体はバイナリ73コードでそれを読み込むためのラッパー部分のみソースコードが公開され74ているとか、その他用語は何であれ GPL の下にソースコードがリリース75されていないカーネルドライバに関する法的な問題について、私は「いか76なる議論も」行うつもりがない。法的な疑問があるのならば、プログラマ77である私ではなく、弁護士に相談して欲しい。ここでは単に、技術的な問78題について述べることにする。（法的な問題を軽視しているわけではない。79それらは実際に存在するし、あなたはそれをいつも気にかけておく必要が80ある）81 82訳注(1)83「使い物にならない代物」の原文は "blob"84 85 86さてここでは、バイナリカーネルインターフェースについてと、ソースレ87ベルでのインターフェースの不変性について、という二つの話題を取り上88げる。この二つは互いに依存する関係にあるが、まずはバイナリインター89フェースについて議論を行いやっつけてしまおう。90 91 92バイナリカーネルインターフェース93--------------------------------94 95もしソースレベルでのインターフェースが不変ならば、バイナリインター96フェースも当然のように不変である、というのは正しいだろうか？正しく97ない。Linux カーネルに関する以下の事実を考えてみてほしい。98 - あなたが使用するＣコンパイラのバージョンによって、カーネル内部99 の構造体の配置構造は異なったものになる。また、関数は異なった方100 法でカーネルに含まれることになるかもしれない（例えばインライン101 関数として扱われたり、扱われなかったりする）。個々の関数がどの102 ようにコンパイルされるかはそれほど重要ではないが、構造体のパデ103 ィングが異なるというのは非常に重要である。104 - あなたがカーネルのビルドオプションをどのように設定するかによっ105 て、カーネルには広い範囲で異なった事態が起こり得る。106 - データ構造は異なるデータフィールドを持つかもしれない107 - いくつかの関数は全く実装されていない状態になり得る108 （例：SMP向けではないビルドでは、いくつかのロックは中身が109 カラにコンパイルされる）110 - カーネル内のメモリは、異なった方法で配置され得る。これはビ111 ルドオプションに依存している。112 - Linux は様々な異なるプロセッサアーキテクチャ上で動作する。113 あるアーキテクチャ用のバイナリドライバを、他のアーキテクチャで114 正常に動作させる方法はない。115 116 117ある特定のカーネル設定を使用し、カーネルをビルドしたのと正確に同じ118Ｃコンパイラを使用して単にカーネルモジュールをコンパイルするだけで119も、あなたはこれらいくつもの問題に直面することになる。ある特定の120Linux ディストリビューションの、ある特定のリリースバージョン用にモ121ジュールを提供しようと思っただけでも、これらの問題を引き起こすには122十分である。にも関わらず Linux ディストリビューションの数と、サ123ポートするディストリビューションのリリース数を掛け算し、それら一つ124一つについてビルドを行ったとしたら、今度はリリースごとのビルドオプ125ションの違いという悪夢にすぐさま悩まされることになる。また、ディス126トリビューションの各リリースバージョンには、異なるハードウェア（プ127ロセッサタイプや種々のオプション）に対応するため、何種類かのカーネ128ルが含まれているということも理解して欲しい。従って、ある一つのリ129リースバージョンだけのためにモジュールを作成する場合でも、あなたは130何バージョンものモジュールを用意しなければならない。131 132 133信じて欲しい。このような方法でサポートを続けようとするなら、あなた134はいずれ正気を失うだろう。遠い昔、私はそれがいかに困難なことか、身135をもって学んだのだ・・・136 137 138不変のカーネルソースレベルインターフェース139------------------------------------------140 141メインカーネルツリーに含まれていない Linux カーネルドライバを継続142してサポートしていこうとしている人たちとの議論においては、これは極143めて「引火性の高い」話題である。[訳注(2)]144 145訳注(2)146「引火性の高い」の原文は "volatile"。147volatile には「揮発性の」「爆発しやすい」という意味の他、「変わり148やすい」「移り気な」という意味がある。149「（この話題は）爆発的に激しい論争を巻き起こしかねない」ということ150を、「（カーネルのソースレベルインターフェースは）移ろい行くもので151ある」ということを連想させる "volatile" という単語で表現している。152 153 154Linux カーネルの開発は継続的に速いペースで行われ、決して歩みを緩め155ることがない。その中でカーネル開発者達は、現状のインターフェースに156あるバグを見つけ、より良い方法を考え出す。彼らはやがて、現状のイン157ターフェースがより正しく動作するように修正を行う。その過程で関数の158名前は変更されるかもしれず、構造体は大きく、または小さくなるかもし159れず、関数の引数は検討しなおされるかもしれない。そのような場合、引160き続き全てが正常に動作するよう、カーネル内でこれらのインターフェー161スを使用している個所も全て同時に修正される。162 163 164具体的な例として、カーネル内の USB インターフェースを挙げる。USB165サブシステムはこれまでに少なくとも３回の書き直しが行われ、その結果166インターフェースが変更された。これらの書き直しはいくつかの異なった167問題を修正するために行われた。168 - 同期的データストリームが非同期に変更された。これにより多数のド169 ライバを単純化でき、全てのドライバのスループットが向上した。今170 やほとんど全ての USB デバイスは、考えられる最高の速度で動作し171 ている。172 - USB ドライバが USB サブシステムのコアから行う、データパケット173 用のメモリ確保方法が変更された。これに伴い、いくつもの文書化さ174 れたデッドロック条件を回避するため、全ての USB ドライバはより175 多くの情報を USB コアに提供しなければならないようになっている。176 177 178このできごとは、数多く存在するクローズソースのオペレーティングシス179テムとは全く対照的だ。それらは長期に渡り古い USB インターフェース180をメンテナンスしなければならない。古いインターフェースが残ることで、181新たな開発者が偶然古いインターフェースを使い、正しくない方法で開発182を行ってしまう可能性が生じる。これによりシステムの安定性は危険にさ183らされることになる。184 185 186上に挙げたどちらの例においても、開発者達はその変更が重要かつ必要で187あることに合意し、比較的楽にそれを実行した。もし Linux がソースレ188ベルでインターフェースの不変性を保証しなければならないとしたら、新189しいインターフェースを作ると同時に、古い、問題のある方を今後ともメ190ンテナンスするという余計な仕事を USB の開発者にさせなければならな191い。Linux の USB 開発者は、自分の時間を使って仕事をしている。よっ192て、価値のない余計な仕事を報酬もなしに実行しろと言うことはできない。193 194 195セキュリティ問題も、Linux にとっては非常に重要である。ひとたびセキ196ュリティに関する問題が発見されれば、それは極めて短期間のうちに修正197される。セキュリティ問題の発生を防ぐための修正は、カーネルの内部イ198ンターフェースの変更を何度も引き起こしてきた。その際同時に、変更さ199れたインターフェースを使用する全てのドライバもまた変更された。これ200により問題が解消し、将来偶然に問題が再発してしまわないことが保証さ201れる。もし内部インターフェースの変更が許されないとしたら、このよう202にセキュリティ問題を修正し、将来再発しないことを保証することなど不203可能なのだ。204 205 206カーネルのインターフェースは時が経つにつれクリーンナップを受ける。207誰も使っていないインターフェースは削除される。これにより、可能な限208りカーネルが小さく保たれ、現役の全てのインターフェースが可能な限り209テストされることを保証しているのだ。（使われていないインターフェー210スの妥当性をテストすることは不可能と言っていいだろう）211 212 213 214これから何をすべきか215-----------------------216 217では、もしメインのカーネルツリーに含まれない Linux カーネルドライ218バがあったとして、あなたは、つまり開発者は何をするべきだろうか？全219てのディストリビューションの全てのカーネルバージョン向けにバイナリ220のドライバを供給することは悪夢であり、カーネルインターフェースの変221更を追いかけ続けることもまた過酷な仕事だ。222 223 224答えは簡単。そのドライバをメインのカーネルツリーに入れてしまえばよ225い。（ここで言及しているのは、GPL に従って公開されるドライバのこと226だということに注意してほしい。あなたのコードがそれに該当しないなら227ば、さよなら。幸運を祈ります。ご自分で何とかしてください。Andrew228と Linus からのコメント＜Andrew と Linus のコメントへのリンクをこ229こに置く＞をどうぞ）ドライバがメインツリーに入れば、カーネルのイン230ターフェースが変更された場合、変更を行った開発者によってドライバも231修正されることになるだろう。あなたはほとんど労力を払うことなしに、232常にビルド可能できちんと動作するドライバを手に入れることができる。233 234 235ドライバをメインのカーネルツリーに入れると、非常に好ましい以下の効236果がある。237 - ドライバの品質が向上する一方で、（元の開発者にとっての）メンテ238 ナンスコストは下がる。239 - あなたのドライバに他の開発者が機能を追加してくれる。240 - 誰かがあなたのドライバにあるバグを見つけ、修正してくれる。241 - 誰かがあなたのドライバにある改善点を見つけてくれる。242 - 外部インターフェースが変更されドライバの更新が必要になった場合、243 誰かがあなたの代わりに更新してくれる。244 - ドライバを入れてくれとディストロに頼まなくても、そのドライバは245 全ての Linux ディストリビューションに自動的に含まれてリリース246 される。247 248 249Linux では、他のどのオペレーティングシステムよりも数多くのデバイス250が「そのまま」使用できるようになった。また Linux は、どのオペレー251ティングシステムよりも数多くのプロセッサアーキテクチャ上でそれらの252デバイスを使用することができるようにもなった。このように、Linux の253開発モデルは実証されており、今後も間違いなく正しい方向へと進んでい254くだろう。:)255 256 257 258------259 260この文書の初期の草稿に対し、Randy Dunlap, Andrew Morton, David261Brownell, Hanna Linder, Robert Love, Nishanth Aravamudan から査読262と助言を頂きました。感謝申し上げます。263 264