git.oblomov.eu Git - linux-2.6/blob - Documentation/ja_JP/SubmitChecklist

   1 NOTE:
   2 This is a version of Documentation/SubmitChecklist into Japanese.
   3 This document is maintained by Takenori Nagano <t-nagano@ah.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
   9 Please also note that the purpose of this file is to be easier to read
  10 for non English (read: Japanese) speakers and is not intended as a
  11 fork. So if you have any comments or updates of this file, please try
  12 to update the original English file first.
  13
  14 Last Updated: 2008/07/14
  15 ==================================
  16 これは、
  17 linux-2.6.26/Documentation/SubmitChecklist の和訳です。
  18
  19 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
  20 翻訳日： 2008/07/14
  21 翻訳者： Takenori Nagano <t-nagano at ah dot jp dot nec dot com>
  22 校正者： Masanori Kobayashi さん <zap03216 at nifty dot ne dot jp>
  23 ==================================
  24
  25
  26 Linux カーネルパッチ投稿者向けチェックリスト
  27 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  28
  29 本書では、パッチをより素早く取り込んでもらいたい開発者が実践すべき基本的な事柄
  30 をいくつか紹介します。ここにある全ての事柄は、Documentation/SubmittingPatches
  31 などのLinuxカーネルパッチ投稿に際しての心得を補足するものです。
  32
  33  1: 妥当なCONFIGオプションや変更されたCONFIGオプション、つまり =y, =m, =n
  34     全てで正しくビルドできることを確認してください。その際、gcc及びリンカが
  35     warningやerrorを出していないことも確認してください。
  36
  37  2: allnoconfig, allmodconfig オプションを用いて正しくビルドできることを
  38     確認してください。
  39
  40  3: 手許のクロスコンパイルツールやOSDLのPLMのようなものを用いて、複数の
  41     アーキテクチャにおいても正しくビルドできることを確認してください。
  42
  43  4: 64bit長の'unsigned long'を使用しているppc64は、クロスコンパイルでの
  44     チェックに適当なアーキテクチャです。
  45
  46  5: カーネルコーディングスタイルに準拠しているかどうか確認してください(!)
  47
  48  6: CONFIGオプションの追加・変更をした場合には、CONFIGメニューが壊れていない
  49     ことを確認してください。
  50
  51  7: 新しくKconfigのオプションを追加する際には、必ずそのhelpも記述してください。
  52
  53  8: 適切なKconfigの依存関係を考えながら慎重にチェックしてください。
  54     ただし、この作業はマシンを使ったテストできちんと行うのがとても困難です。
  55     うまくやるには、自分の頭で考えることです。
  56
  57  9: sparseを利用してちゃんとしたコードチェックをしてください。
  58
  59 10: 'make checkstack' と 'make namespacecheck' を利用し、問題が発見されたら
  60     修正してください。'make checkstack' は明示的に問題を示しませんが、どれか
  61     １つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と
  62     なります。
  63
  64 11: グローバルなkernel API を説明する kernel-doc をソースの中に含めてください。
  65     ( staticな関数においては必須ではありませんが、含めてもらっても結構です )
  66     そして、'make htmldocs' もしくは 'make mandocs' を利用して追記した
  67     ドキュメントのチェックを行い、問題が見つかった場合には修正を行ってください。
  68
  69 12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB,
  70     CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
  71     CONFIG_DEBUG_SPINLOCK_SLEEP これら全てを同時に有効にして動作確認を
  72     行ってください。
  73
  74 13: CONFIG_SMP, CONFIG_PREEMPT を有効にした場合と無効にした場合の両方で
  75     ビルドした上、動作確認を行ってください。
  76
  77 14: もしパッチがディスクのI/O性能などに影響を与えるようであれば、
  78     'CONFIG_LBD'オプションを有効にした場合と無効にした場合の両方で
  79     テストを実施してみてください。
  80
  81 15: lockdepの機能を全て有効にした上で、全てのコードパスを評価してください。
  82
  83 16: /proc に新しいエントリを追加した場合には、Documentation/ 配下に
  84     必ずドキュメントを追加してください。
  85
  86 17: 新しいブートパラメータを追加した場合には、
  87     必ずDocumentation/kernel-parameters.txt に説明を追加してください。
  88
  89 18: 新しくmoduleにパラメータを追加した場合には、MODULE_PARM_DESC()を
  90     利用して必ずその説明を記述してください。
  91
  92 19: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に
  93     Documentation/ABI/README を参考にして必ずドキュメントを追加してください。
  94
  95 20: 'make headers_check'を実行して全く問題がないことを確認してください。
  96
  97 21: 少なくともslabアロケーションとpageアロケーションに失敗した場合の
  98     挙動について、fault-injectionを利用して確認してください。
  99     Documentation/fault-injection/ を参照してください。
 100
 101     追加したコードがかなりの量であったならば、サブシステム特有の
 102     fault-injectionを追加したほうが良いかもしれません。
 103
 104 22: 新たに追加したコードは、`gcc -W'でコンパイルしてください。
 105     このオプションは大量の不要なメッセージを出力しますが、
 106     "warning: comparison between signed and unsigned" のようなメッセージは、
 107     バグを見つけるのに役に立ちます。
 108
 109 23: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや
 110     VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存
 111     できることを確認するテストを行ってください。