Submit Checklist
|
Linux Kernel patch submission checklist
리눅스 커널 패치 제출 체크리스트
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here are some basic things that developers should do if they want to see their kernel patch submissions accepted more quickly.
이 문서는 커널 개발자들이 자신이 작성한 커널 패치를 제출할 때 제출한 커널 패치가 빠르게 받아들여지는 방법에 대하여 설명한다.
These are all above and beyond the documentation that is provided in Documentation/SubmittingPatches and elsewhere regarding submitting Linux kernel patches.
여기에서는 Documentation/SubmittingPatches나 다른 곳에서 설명한 리눅스 커널 패치 제출 방법 이외의 사항을 다룰 것이다.
1: Builds cleanly with applicable or modified CONFIG options =y, =m, and
=n. No gcc warnings/errors, no linker warnings/errors.
1: 커널 컨피그 옵션을 =y, =m, =n 중에 어떠한 것으로 하더라도 gcc 컴파일, 링크 중에 경고 혹은 에러가 발생하지 않도록 해야 한다.
2: Passes allnoconfig, allmodconfig
2: allnoconfig, allmodconfig 설정 시에도 컴파일 시에 경고 혹은 에러가 없어야 한다.
3: Builds on multiple CPU architectures by using local cross-compile tools
or something like PLM at OSDL.
3: OSDL의 PLM이나 다른 크로스 컴파일 툴을 사용하여 다양한 CPU 상에서 빌드를 테스트 해야 한다.
4: ppc64 is a good architecture for cross-compilation checking because it
tends to use `unsigned long' for 64-bit quantities.
4: ppc64는 'unsigned long'을 64비트 변수로 사용하는 경향이 있기 때문에 크로스 컴파일을 체크하기에 좋은 아키텍쳐이다.
5: Matches kernel coding style(!)
5: 커널 코딩 스타일을 따라야 한다.
6: Any new or modified CONFIG options don't muck up the config menu.
6: 새롭게 추가되거나 수정된 CONFIG 옵션이 기존의 config 메뉴를 깨뜨려서는 안된다.
7: All new Kconfig options have help text.
7: 새롭게 추가된 모든 Kconfig 옵션은 도움말을 제공해야 한다.
8: Has been carefully reviewed with respect to relevant Kconfig
combinations. This is very hard to get right with testing -- brainpower pays off here.
8: Kconfig 조합이 적절하게 이루어졌는지 주의하여 충분한 검토를 해야 한다. 이 작업은 매우 어려운 작업이며 충분한 테스트를 통해 검증되어야 한다. -- 뛰어난 사람들이 이 작업에 시간을 투자해야 할 것이다.
9: Check cleanly with sparse.
9: 엉성한 부분들을 깨끗하게 수정한다.
10: Use 'make checkstack' and 'make namespacecheck' and fix any problems
that they find. Note: checkstack does not point out problems explicitly, but any one function that uses more than 512 bytes on the stack is a candidate for change.
10: 'make checkstack'과 'make namespacecheck'을 사용하여 발견된 버그들을 수정한다. Note: checkstack이 모든 문제를 명백하게 발견하지는 못하지만 스택을 512바이트 이상 사용하는 함수를 발견하여 수정하도록 권고할 것이다.
11: Include kernel-doc to document global kernel APIs. (Not required for
static functions, but OK there also.) Use 'make htmldocs' or 'make mandocs' to check the kernel-doc and fix any issues.
11: 커널 API 문서를 위한 kernel-doc을 작성하여야 한다. (정적 함수를 위한 문서까지 작성할 필요는 없지만, 작성하여도 문제가 될 것은 없다.) kernel-doc이 제대로 작성되었는지 체크하기 위해서 'make htmldocs'와 'make mandocs'를 사용한다.
12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously enabled.
12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP 옵션을 모두 설정하여 커파일한 후 테스트를 거쳐야 한다.
13: Has been build- and runtime tested with and without CONFIG_SMP and
CONFIG_PREEMPT.
13: CONFIG_SMP와 CONFIG_PREEMPT를 포함한 빌드/동작 테스트와 두 옵션을 제거한 빌드/동작 테스트 모두를 수행해야 한다.
14: If the patch affects IO/Disk, etc: has been tested with and without
CONFIG_LBD.
14: 만약 당신이 작성한 패치가 IO/Disk나 그 이외의 것에 영향을 미친다면, CONFIG_LBD를 포함한 테스트와 포함하지 않는 테스트를 수행하라.
15: All codepaths have been exercised with all lockdep features enabled.
16: All new /proc entries are documented under Documentation/
16: 새롭게 작성된 모든 /proc 엔트리들은 Documentation 디렉토리 안에 문서화한다.
17: All new kernel boot parameters are documented in
Documentation/kernel-parameters.txt.
17: 새롭게 작성된 모든 커널 부트 파라미터들은 Documentation/kernel-parameters.txt 파일에 문서화한다.
18: All new module parameters are documented with MODULE_PARM_DESC()
18: 새롭게 작성된 모든 모듈 파라미터들은 MODULE_PARM_DESC() 매크로를 이용하여 문서화한다.
19: All new userspace interfaces are documented in Documentation/ABI/.
See Documentation/ABI/README for more information.
19: 새롭게 작성된 모든 유저 영역 인터페이스들은 Documentation/ABI/ 디렉토리에 문서화한다. 보다 자세한 사항은 Documentation/ABI/README 문서를 참조한다.
20: Check that it all passes `make headers_check'.
20: 'make headers_check'를 시행하여 에러가 발생하지 않는지 체크한다.
21: Has been checked with injection of at least slab and page-allocation
failures. See Documentation/fault-injection/.
21:
If the new code is substantial, addition of subsystem-specific fault injection might be appropriate. 22: Newly-added code has been compiled with `gcc -W' (use "make
EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
finding bugs like "warning: comparison between signed and unsigned".
23: Tested after it has been merged into the -mm patchset to make sure
that it still works with all of the other queued patches and various
changes in the VM, VFS, and other subsystems.
24: Avoid whitespace damage such as indenting with spaces or whitespace
at the end of lines. You can test this by feeding the patch to
"git apply --check --whitespace=error-all"
25: Check your patch for general style as detailed in
Documentation/CodingStyle. Check for trivial violations with the
patch style checker prior to submission (scripts/checkpatch.pl).
You should be able to justify all violations that remain in
your patch.
|
You are farsighted, a good planner, an ardent lover, and a faithful friend.    
|
