/Documentation/ja_JP/stable_api_nonsense.txt

https://gitlab.com/vibisreenivasan/UML · Plain Text · 263 lines · 206 code · 57 blank · 0 comment · 0 complexity · 84d9c6807bb8917932ab5e0da3e69086 MD5 · raw file

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