WSL2-Linux-Kernel/Documentation/ja_JP/SubmitChecklist

NOTE:
This is a version of Documentation/SubmitChecklist into Japanese.
This document is maintained by Takenori Nagano <t-nagano@ah.jp.nec.com>
and the JF Project team <http://www.linux.or.jp/JF/>.
If you find any difference between this document and the original file
or a problem with the translation,
please contact the maintainer of this file or JF project.

Please also note that the purpose of this file is to be easier to read
for non English (read: Japanese) speakers and is not intended as a
fork. So if you have any comments or updates of this file, please try
to update the original English file first.

Last Updated: 2008/07/14
==================================
これは、
linux-2.6.26/Documentation/SubmitChecklist の和訳です。

翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日： 2008/07/14
翻訳者： Takenori Nagano <t-nagano at ah dot jp dot nec dot com>
校正者： Masanori Kobayashi さん <zap03216 at nifty dot ne dot jp>
==================================


Linux カーネルパッチ投稿者向けチェックリスト
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

本書では、パッチをより素早く取り込んでもらいたい開発者が実践すべき基本的な事柄
をいくつか紹介します。ここにある全ての事柄は、Documentation/SubmittingPatches
などのLinuxカーネルパッチ投稿に際しての心得を補足するものです。

 1: 妥当なCONFIGオプションや変更されたCONFIGオプション、つまり =y, =m, =n
    全てで正しくビルドできることを確認してください。その際、gcc及びリンカが
    warningやerrorを出していないことも確認してください。

 2: allnoconfig, allmodconfig オプションを用いて正しくビルドできることを
    確認してください。

 3: 手許のクロスコンパイルツールやOSDLのPLMのようなものを用いて、複数の
    アーキテクチャにおいても正しくビルドできることを確認してください。

 4: 64bit長の'unsigned long'を使用しているppc64は、クロスコンパイルでの
    チェックに適当なアーキテクチャです。

 5: カーネルコーディングスタイルに準拠しているかどうか確認してください(!)

 6: CONFIGオプションの追加・変更をした場合には、CONFIGメニューが壊れていない
    ことを確認してください。

 7: 新しくKconfigのオプションを追加する際には、必ずそのhelpも記述してください。

 8: 適切なKconfigの依存関係を考えながら慎重にチェックしてください。
    ただし、この作業はマシンを使ったテストできちんと行うのがとても困難です。
    うまくやるには、自分の頭で考えることです。

 9: sparseを利用してちゃんとしたコードチェックをしてください。

10: 'make checkstack' と 'make namespacecheck' を利用し、問題が発見されたら
    修正してください。'make checkstack' は明示的に問題を示しませんが、どれか
    １つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と
    なります。

11: グローバルなkernel API を説明する kernel-doc をソースの中に含めてください。
    ( staticな関数においては必須ではありませんが、含めてもらっても結構です )
    そして、'make htmldocs' もしくは 'make mandocs' を利用して追記した
    ドキュメントのチェックを行い、問題が見つかった場合には修正を行ってください。

12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB,
    CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
    CONFIG_DEBUG_ATOMIC_SLEEP これら全てを同時に有効にして動作確認を
    行ってください。

13: CONFIG_SMP, CONFIG_PREEMPT を有効にした場合と無効にした場合の両方で
    ビルドした上、動作確認を行ってください。

14: もしパッチがディスクのI/O性能などに影響を与えるようであれば、
    'CONFIG_LBDAF'オプションを有効にした場合と無効にした場合の両方で
    テストを実施してみてください。

15: lockdepの機能を全て有効にした上で、全てのコードパスを評価してください。

16: /proc に新しいエントリを追加した場合には、Documentation/ 配下に
    必ずドキュメントを追加してください。

17: 新しいブートパラメータを追加した場合には、
    必ずDocumentation/kernel-parameters.txt に説明を追加してください。

18: 新しくmoduleにパラメータを追加した場合には、MODULE_PARM_DESC()を
    利用して必ずその説明を記述してください。

19: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に
    Documentation/ABI/README を参考にして必ずドキュメントを追加してください。

20: 'make headers_check'を実行して全く問題がないことを確認してください。

21: 少なくともslabアロケーションとpageアロケーションに失敗した場合の
    挙動について、fault-injectionを利用して確認してください。
    Documentation/fault-injection/ を参照してください。

    追加したコードがかなりの量であったならば、サブシステム特有の
    fault-injectionを追加したほうが良いかもしれません。

22: 新たに追加したコードは、`gcc -W'でコンパイルしてください。
    このオプションは大量の不要なメッセージを出力しますが、
    "warning: comparison between signed and unsigned" のようなメッセージは、
    バグを見つけるのに役に立ちます。

23: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや
    VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存
    できることを確認するテストを行ってください。