0001 NOTE:
0002 This is a version of Documentation/process/stable-api-nonsense.rst into Japanese.
0003 This document is maintained by IKEDA, Munehiro <m-ikeda@ds.jp.nec.com>
0004 and the JF Project team <http://www.linux.or.jp/JF/>.
0005 If you find any difference between this document and the original file
0006 or a problem with the translation,
0007 please contact the maintainer of this file or JF project.
0008
0009 Please also note that the purpose of this file is to be easier to read
0010 for non English (read: Japanese) speakers and is not intended as a
0011 fork. So if you have any comments or updates of this file, please try
0012 to update the original English file first.
0013
0014 Last Updated: 2007/07/18
0015 ==================================
0016 これは、
0017 linux-2.6.22-rc4/Documentation/process/stable-api-nonsense.rst の和訳
0018 です。
0019 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
0020 翻訳日 ： 2007/06/11
0021 原著作者: Greg Kroah-Hartman < greg at kroah dot com >
0022 翻訳者 ： 池田 宗広 < m-ikeda at ds dot jp dot nec dot com >
0023 校正者 ： Masanori Kobayashi さん < zap03216 at nifty dot ne dot jp >
0024 Seiji Kaneko さん < skaneko at a2 dot mbn dot or dot jp >
0025 ==================================
0026
0027
0028
0029 Linux カーネルのドライバインターフェース
0030 （あなたの質問すべてに対する回答とその他諸々）
0031
0032 Greg Kroah-Hartman <greg at kroah dot com>
0033
0034
0035 この文書は、なぜ Linux ではバイナリカーネルインターフェースが定義
0036 されていないのか、またはなぜ不変のカーネルインターフェースを持たな
0037 いのか、ということを説明するために書かれた。ここでの話題は「カーネ
0038 ル内部の」インターフェースについてであり、ユーザー空間とのインター
0039 フェースではないことを理解してほしい。カーネルとユーザー空間とのイ
0040 ンターフェースとはアプリケーションプログラムが使用するものであり、
0041 つまりシステムコールのインターフェースがこれに当たる。これは今まで
0042 長きに渡り、かつ今後も「まさしく」不変である。私は確か 0.9 か何か
0043 より前のカーネルを使ってビルドした古いプログラムを持っているが、そ
0044 れは最新の 2.6 カーネルでもきちんと動作する。ユーザー空間とのイン
0045 ターフェースは、ユーザーとアプリケーションプログラマが不変性を信頼
0046 してよいものの一つである。
0047
0048
0049 要旨
0050 ----
0051
0052 あなたは不変のカーネルインターフェースが必要だと考えているかもしれ
0053 ないが、実際のところはそうではない。あなたは必要としているものが分
0054 かっていない。あなたが必要としているものは安定して動作するドライバ
0055 であり、それはドライバがメインのカーネルツリーに含まれる場合のみ得
0056 ることができる。ドライバがメインのカーネルツリーに含まれていると、
0057 他にも多くの良いことがある。それは、Linux をより強固で、安定な、成
0058 熟したオペレーティングシステムにすることができるということだ。これ
0059 こそ、そもそもあなたが Linux を使う理由のはずだ。
0060
0061
0062 はじめに
0063 --------
0064
0065 カーネル内部のインターフェース変更を心配しなければならないドライバ
0066 を書きたいなどというのは、変わり者だけだ。この世界のほとんどの人は、
0067 そのようなドライバがどんなインターフェースを使っているかなど知らな
0068 いし、そんなドライバのことなど全く気にもかけていない。
0069
0070
0071 まず初めに、クローズソースとか、ソースコードの隠蔽とか、バイナリの
0072 みが配布される使い物にならない代物[訳注(1)]とか、実体はバイナリ
0073 コードでそれを読み込むためのラッパー部分のみソースコードが公開され
0074 ているとか、その他用語は何であれ GPL の下にソースコードがリリース
0075 されていないカーネルドライバに関する法的な問題について、私は「いか
0076 なる議論も」行うつもりがない。法的な疑問があるのならば、プログラマ
0077 である私ではなく、弁護士に相談して欲しい。ここでは単に、技術的な問
0078 題について述べることにする。（法的な問題を軽視しているわけではない。
0079 それらは実際に存在するし、あなたはそれをいつも気にかけておく必要が
0080 ある）
0081
0082 訳注(1)
0083 「使い物にならない代物」の原文は "blob"
0084
0085
0086 さてここでは、バイナリカーネルインターフェースについてと、ソースレ
0087 ベルでのインターフェースの不変性について、という二つの話題を取り上
0088 げる。この二つは互いに依存する関係にあるが、まずはバイナリインター
0089 フェースについて議論を行いやっつけてしまおう。
0090
0091
0092 バイナリカーネルインターフェース
0093 --------------------------------
0094
0095 もしソースレベルでのインターフェースが不変ならば、バイナリインター
0096 フェースも当然のように不変である、というのは正しいだろうか？正しく
0097 ない。Linux カーネルに関する以下の事実を考えてみてほしい。
0098 - あなたが使用するＣコンパイラのバージョンによって、カーネル内部
0099 の構造体の配置構造は異なったものになる。また、関数は異なった方
0100 法でカーネルに含まれることになるかもしれない（例えばインライン
0101 関数として扱われたり、扱われなかったりする）。個々の関数がどの
0102 ようにコンパイルされるかはそれほど重要ではないが、構造体のパデ
0103 ィングが異なるというのは非常に重要である。
0104 - あなたがカーネルのビルドオプションをどのように設定するかによっ
0105 て、カーネルには広い範囲で異なった事態が起こり得る。
0106 - データ構造は異なるデータフィールドを持つかもしれない
0107 - いくつかの関数は全く実装されていない状態になり得る
0108 （例：SMP向けではないビルドでは、いくつかのロックは中身が
0109 カラにコンパイルされる）
0110 - カーネル内のメモリは、異なった方法で配置され得る。これはビ
0111 ルドオプションに依存している。
0112 - Linux は様々な異なるプロセッサアーキテクチャ上で動作する。
0113 あるアーキテクチャ用のバイナリドライバを、他のアーキテクチャで
0114 正常に動作させる方法はない。
0115
0116
0117 ある特定のカーネル設定を使用し、カーネルをビルドしたのと正確に同じ
0118 Ｃコンパイラを使用して単にカーネルモジュールをコンパイルするだけで
0119 も、あなたはこれらいくつもの問題に直面することになる。ある特定の
0120 Linux ディストリビューションの、ある特定のリリースバージョン用にモ
0121 ジュールを提供しようと思っただけでも、これらの問題を引き起こすには
0122 十分である。にも関わらず Linux ディストリビューションの数と、サ
0123 ポートするディストリビューションのリリース数を掛け算し、それら一つ
0124 一つについてビルドを行ったとしたら、今度はリリースごとのビルドオプ
0125 ションの違いという悪夢にすぐさま悩まされることになる。また、ディス
0126 トリビューションの各リリースバージョンには、異なるハードウェア（プ
0127 ロセッサタイプや種々のオプション）に対応するため、何種類かのカーネ
0128 ルが含まれているということも理解して欲しい。従って、ある一つのリ
0129 リースバージョンだけのためにモジュールを作成する場合でも、あなたは
0130 何バージョンものモジュールを用意しなければならない。
0131
0132
0133 信じて欲しい。このような方法でサポートを続けようとするなら、あなた
0134 はいずれ正気を失うだろう。遠い昔、私はそれがいかに困難なことか、身
0135 をもって学んだのだ・・・
0136
0137
0138 不変のカーネルソースレベルインターフェース
0139 ------------------------------------------
0140
0141 メインカーネルツリーに含まれていない Linux カーネルドライバを継続
0142 してサポートしていこうとしている人たちとの議論においては、これは極
0143 めて「引火性の高い」話題である。[訳注(2)]
0144
0145 訳注(2)
0146 「引火性の高い」の原文は "volatile"。
0147 volatile には「揮発性の」「爆発しやすい」という意味の他、「変わり
0148 やすい」「移り気な」という意味がある。
0149 「（この話題は）爆発的に激しい論争を巻き起こしかねない」ということ
0150 を、「（カーネルのソースレベルインターフェースは）移ろい行くもので
0151 ある」ということを連想させる "volatile" という単語で表現している。
0152
0153
0154 Linux カーネルの開発は継続的に速いペースで行われ、決して歩みを緩め
0155 ることがない。その中でカーネル開発者達は、現状のインターフェースに
0156 あるバグを見つけ、より良い方法を考え出す。彼らはやがて、現状のイン
0157 ターフェースがより正しく動作するように修正を行う。その過程で関数の
0158 名前は変更されるかもしれず、構造体は大きく、または小さくなるかもし
0159 れず、関数の引数は検討しなおされるかもしれない。そのような場合、引
0160 き続き全てが正常に動作するよう、カーネル内でこれらのインターフェー
0161 スを使用している個所も全て同時に修正される。
0162
0163
0164 具体的な例として、カーネル内の USB インターフェースを挙げる。USB
0165 サブシステムはこれまでに少なくとも３回の書き直しが行われ、その結果
0166 インターフェースが変更された。これらの書き直しはいくつかの異なった
0167 問題を修正するために行われた。
0168 - 同期的データストリームが非同期に変更された。これにより多数のド
0169 ライバを単純化でき、全てのドライバのスループットが向上した。今
0170 やほとんど全ての USB デバイスは、考えられる最高の速度で動作し
0171 ている。
0172 - USB ドライバが USB サブシステムのコアから行う、データパケット
0173 用のメモリ確保方法が変更された。これに伴い、いくつもの文書化さ
0174 れたデッドロック条件を回避するため、全ての USB ドライバはより
0175 多くの情報を USB コアに提供しなければならないようになっている。
0176
0177
0178 このできごとは、数多く存在するクローズソースのオペレーティングシス
0179 テムとは全く対照的だ。それらは長期に渡り古い USB インターフェース
0180 をメンテナンスしなければならない。古いインターフェースが残ることで、
0181 新たな開発者が偶然古いインターフェースを使い、正しくない方法で開発
0182 を行ってしまう可能性が生じる。これによりシステムの安定性は危険にさ
0183 らされることになる。
0184
0185
0186 上に挙げたどちらの例においても、開発者達はその変更が重要かつ必要で
0187 あることに合意し、比較的楽にそれを実行した。もし Linux がソースレ
0188 ベルでインターフェースの不変性を保証しなければならないとしたら、新
0189 しいインターフェースを作ると同時に、古い、問題のある方を今後ともメ
0190 ンテナンスするという余計な仕事を USB の開発者にさせなければならな
0191 い。Linux の USB 開発者は、自分の時間を使って仕事をしている。よっ
0192 て、価値のない余計な仕事を報酬もなしに実行しろと言うことはできない。
0193
0194
0195 セキュリティ問題も、Linux にとっては非常に重要である。ひとたびセキ
0196 ュリティに関する問題が発見されれば、それは極めて短期間のうちに修正
0197 される。セキュリティ問題の発生を防ぐための修正は、カーネルの内部イ
0198 ンターフェースの変更を何度も引き起こしてきた。その際同時に、変更さ
0199 れたインターフェースを使用する全てのドライバもまた変更された。これ
0200 により問題が解消し、将来偶然に問題が再発してしまわないことが保証さ
0201 れる。もし内部インターフェースの変更が許されないとしたら、このよう
0202 にセキュリティ問題を修正し、将来再発しないことを保証することなど不
0203 可能なのだ。
0204
0205
0206 カーネルのインターフェースは時が経つにつれクリーンナップを受ける。
0207 誰も使っていないインターフェースは削除される。これにより、可能な限
0208 りカーネルが小さく保たれ、現役の全てのインターフェースが可能な限り
0209 テストされることを保証しているのだ。（使われていないインターフェー
0210 スの妥当性をテストすることは不可能と言っていいだろう）
0211
0212
0213
0214 これから何をすべきか
0215 -----------------------
0216
0217 では、もしメインのカーネルツリーに含まれない Linux カーネルドライ
0218 バがあったとして、あなたは、つまり開発者は何をするべきだろうか？全
0219 てのディストリビューションの全てのカーネルバージョン向けにバイナリ
0220 のドライバを供給することは悪夢であり、カーネルインターフェースの変
0221 更を追いかけ続けることもまた過酷な仕事だ。
0222
0223
0224 答えは簡単。そのドライバをメインのカーネルツリーに入れてしまえばよ
0225 い。（ここで言及しているのは、GPL に従って公開されるドライバのこと
0226 だということに注意してほしい。あなたのコードがそれに該当しないなら
0227 ば、さよなら。幸運を祈ります。ご自分で何とかしてください。Andrew
0228 と Linus からのコメント＜Andrew と Linus のコメントへのリンクをこ
0229 こに置く＞をどうぞ）ドライバがメインツリーに入れば、カーネルのイン
0230 ターフェースが変更された場合、変更を行った開発者によってドライバも
0231 修正されることになるだろう。あなたはほとんど労力を払うことなしに、
0232 常にビルド可能できちんと動作するドライバを手に入れることができる。
0233
0234
0235 ドライバをメインのカーネルツリーに入れると、非常に好ましい以下の効
0236 果がある。
0237 - ドライバの品質が向上する一方で、（元の開発者にとっての）メンテ
0238 ナンスコストは下がる。
0239 - あなたのドライバに他の開発者が機能を追加してくれる。
0240 - 誰かがあなたのドライバにあるバグを見つけ、修正してくれる。
0241 - 誰かがあなたのドライバにある改善点を見つけてくれる。
0242 - 外部インターフェースが変更されドライバの更新が必要になった場合、
0243 誰かがあなたの代わりに更新してくれる。
0244 - ドライバを入れてくれとディストロに頼まなくても、そのドライバは
0245 全ての Linux ディストリビューションに自動的に含まれてリリース
0246 される。
0247
0248
0249 Linux では、他のどのオペレーティングシステムよりも数多くのデバイス
0250 が「そのまま」使用できるようになった。また Linux は、どのオペレー
0251 ティングシステムよりも数多くのプロセッサアーキテクチャ上でそれらの
0252 デバイスを使用することができるようにもなった。このように、Linux の
0253 開発モデルは実証されており、今後も間違いなく正しい方向へと進んでい
0254 くだろう。:)
0255
0256
0257
0258 ------
0259
0260 この文書の初期の草稿に対し、Randy Dunlap, Andrew Morton, David
0261 Brownell, Hanna Linder, Robert Love, Nishanth Aravamudan から査読
0262 と助言を頂きました。感謝申し上げます。
0263
