· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
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'를 사용한다.



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/.

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.

Let him who takes the Plunge remember to return it by Tuesday.

sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2008-03-18 10:26:00
Processing time 0.0016 sec