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.