· 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'를 사용한다.


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

If the new code is substantial, addition of subsystem-specific fault injection might be appropriate.

21:

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.


ID
Password
Join
You will be recognized and honored as a community leader.


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.0059 sec