Beginner Guide to Linux Kernel Hacking
막상 kernel 에 관련된 책도 보고 어떻게 개발에 참여할 수 있는지 고민만 많이 하지 딱히 문제가 있는 부분을 찾는 것도 수정하는 것도 어렵다.(다 잘되어 있는 code 처럼 보이기도 하고 ^^)
이래 저래 초보자(?)를 위한 blog 나 site 를 찾아봤지만 뭘 해야하는지 콕 찝어 얘기해주는 것도 아니고..
암튼, 이 제목을 가진 글은 조금 쉬운 접근 방법인 것 같기도 하고 번역도 쉬울 듯 하여 시작해본다.
시작.
Linux kernel 은 굉장히 복잡한 software 이며 누구나 참여가능하지만 hacking 을 쉽게 하고 개발에 기여하기는 어렵다. 다른게 얘기하면 하루 이틀만에 시작하여 hacking 할 수 있는 것은 아니라는 것이다. 개발자는 kernel 에 대한 지식이 필요한데 모든 kernel 내부는 배울 수 있다는 점이 장점이다.
간단한 kernel 에 대한 note 가 있는데 The workings of the Linux kernel 를 참조하면 된다.(이부분도 번역을..)
개발자 스스로 질문을 해보자, kernel 이 나에게 있어 완벽하게 동작하고 내가 고칠 수 있는 부분은 있는 것인가?
(내가 하고 싶었던 질문이다.) 여기 blog 에서는 이런 부분에 대해서는 미리 단념할 필요가 없다고 한다. 커널 개발자들은 도움이 필요한 상세한 list(정리가 필요한 무수한 code들) 를 갖고 있다. 예를 들어, 이런 code들은 /drivers/staging 디렉토리 내부에서 찾을 수 있다. 이 디렉토리 내부에 있는 driver 들은 일반적인 linux kernel coding guideline 을 만족하지 못하는 code 들이 많다. 여기에 위치한 code들은 다른 개발자들에 의해 mainline 에 merge 되기 전에 정리를 도움받고자 하는 것이다. staging 디렉토리 하위에 있는 모든 driver 는 TODO list를 갖고 있는 것도 참고하면 좋다고 한다.
여기 driver 들의 대부분이 그것들의 TODO list 에 다음과 같은 line을 갖고 있다:
- fix checkpatch.pl issues
이것은 어떤 의미를 가지며 어떻게 해야 하는지에 대한 의문이 있을 것이다. 모든 큰 code 의 내용은 여러 개발자들이 참여하여 개발하기 위한 일정한 coding rule 을 갖고 있다. 어떤 kernel 개발자의 목표는 다른 개발자들에게 code의 error를 찾도록 도움을 받고 싶어 한다. 이런 coding rule 은 이런 error를 찾는 것에 도움을 줄 수 잇다는 것이다. 그래서 kernel 에 code가 들어가기 전에 적어도 두명의 개발자가 code에 대한 review 를 하기 때문에 이런 coding style guildline 은 매우 중요한 덕목(?)이다. 그리고 개발자는 kernel source tree 에 Documentation/CodingStyle 에서 관련 사항을 볼 수 있다. coding style 및 error를 빨리 찾기 위해 scripts/checkpatch.pl 이라는 것이 개발되어 졌고, 기본적이 coding style 이 지켜지지 않아 다른 개발자들의 시간을 낭비하는 일을 줄여주는 역할을 해준다.
암튼, drivers/staging 에 위치하는 driver 들은 거의 항상 styling issue 를 갖고 있을 것이다.(guildline 에 익숙치 않은 개발자가 개발하는 경우가 있기 때문이다.) 일단 처음으로 해볼 것이 이런 것들을 kernel coding style guildline 에 맞춰 수정해주는 것이다. 그래서 처음 시작하는 kernel 개발자는 checkpatch.pl 을 수행하고 관련사항을 수정해주므로 해서 도움을 줄 수 있다는 것이다.
Specific Coding Rules
Documentation/CodingStyle 에 모두 나와있지만 개발자가 시작하는데 있어 간략한 부분을 overview 한다.
Whitespace
대부분이 code를 개발함에 있어 indentation(들여쓰기)를 space 가 아닌 tab 을 사용한다. tab은 대게 8 의 길이의 space 를 갖는다. (kernel code 는 tab 을 space 가 아닌 하나의 tab 문자-4 or 8길이의-를 사용한다.) 커널 code를 보고 tab 이 어떻게 되어 있는지 맞춰 주면 될 듯 하다. 또한 한 line 을 80자 이상 넘겨서는 안된다. 80자는 개발자들이 logic을 더 작고 쉽게 인지 할 수 있도록 도와준다.
Braces
Brace 의 사용에 대한 rule 은 꾀 까다롭다. brace를 여는 것은 한 문장의 마지막에 붙여서 쓰고, brace를 닫는 것은 마지막 문장의 다음 line 으로 넘어가서 사용한다. 예제를 보자
만약 if else 문의 구조라면 다음고 같이 한다.
위와 같이 수정 가능하다.
그럼 제대로 수정이 되었는지 확인하면,
$ ./scripts/checkpatch.pl --file --terse drivers/staging/bcm/Qos.c | grep 821
해서 아무런 message 도 나오지 않으면 성공한 것이다.
수정 후, build 해서 확인 해야 한다.
빌드 방법은 다른 site 에서 찾아 보면 된다.
간단히 그 파일만 빌드 하는 방법을 보면, 물론 full build 가 되어있다는 것을 가정하는 것이다.
$ make drivers/staging/bcm/Qos.o
만약 위와 같이 해서 error 발생하지 않는다면, 변경사항을 patch로 만들고 적용가능한 상황까지 만든 것이다.
일단 이것까지 해왔다면 kernel을 download 받았다는 것이지만, 간략하게 kernel 을 받고 patch를 만들고 전달하는 과정을 적어본다.
// 참고로 /path/to/linux/kernel은 아무대나 kernel이라는 directory를 만들면 된다.
$ mkdir /path/to/linux/kernel
$ cd /path/to/linux/kernel
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
준비 되었다면 다음 단계로 넘어간다.
수정을 한 상태라면 git 을 이용해 local commit 을 만들고 그것을 patch set 으로 변환한 뒤, 관계자(?) 에게 review 메일을 보내면 된다.
commit 을 어떻게 했는지 확인해 보자.
$ cd drivers/staging/bcm
$ git log Qos.c
맨 위의 commit 을 보자
commit c5485e9ca70b5bd5eabfc7c298f7e367062d4f56
Author: Kevin McKinney <klmckinney1@gmail.com>
Date: Sat Dec 22 14:27:56 2012 -0500
Staging: bcm: Remove typedef for TransportHeaderT and call directly. // 제목
// new line + 추가 설명
This patch removes typedef for TransportHeaderT, and
changes the name of the struct to bcm_transport_header.
In addition, any calls to struct "xporthdr" are
changed to call directly.
Signed-off-by: Kevin McKinney <klmckinney1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
patch 만드는 방법은,
수정 완료 후,
$ git add drivers/staging/bcm/Qos.c
$ git commit
하면 당신의 editor로 comment 를 입력받는 화면이 나온다.
// image
위에 처럼 comment 를 달고(영어를 못하니 일단 대충..) 저장하면 된다.
첫번째 line은 수정사항에 대한 제목 같은 것을 적고 추가적으로 적으려면 새 line(엔터)을 두개 넣고
적으면 된다. 참고하여 위의 commit 처럼 만든다.
Signed-off-by : Your Name <youremail@email.com> 을 추가한뒤 저장.(저는 안했음. 지금 보낼것이 아니라서..)
이제 당신의 첫번째 patch를 완성했다.
Getting Your Change into the Kernel Tree
위에서 수정한 사항을 patch로 만들어 커널 개발자에게 review 및 전달을 요청해야 한다. 일단 patch를 일단 만들어 보자.
$ git log
당신의 commit 이 제일 위에 있을 것이다.
바로 밑에 있는 commit 의 hashid 를 parameter 로 넣어준다.
$ git format-patch <hashid> -o ~/
이렇게 하면 만들어진 commit 이 0001-XXX.patch라는 이름으로 만들어 진다.
이것을 다시한번 checkpatch.pl 을 수행해서 정상적으로 반영가능한지 확인을 해보자.
내가 위에서 했던 수정했던 것은 또다른 문제를 갖고 있어 error를 출력했지만 정상적으로 되었다면
total :0 errors, 0 warnnings, XX lines checked 가 보일 것이다.
이제 메일을 보내보자.
Now to Send it Off
이제 완정된 patch를 누구에게 보내야 하는지 알아야 한다. 커널 개발자들은 script 로 누구에게 알려야 되는지 쉽게 알수 있다. 그 script는 get_maintainer.pl 이고 이것은 scripts directory에 위치한다. 이 script는 파일을 확인하고 내가 수정한 파일이 kernel source tree의 maintainer 들에 대한 정보를 알려준다.
$ ./scripts/get_maintainer.pl /path/to/0001-your-patch.patch
devel@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)
위와 같이 나오더라.
이것은 일반적인 e-mail client 로 전송하면 patch format에 space및 tab 등 변형이 되기 때문에 Documentation/email-clients.txt 를 확인하여 그 email client 를 이용하여 전송하면 된다. 하지만 git commit 로도 지원이 되는데, 그 방법은,
$ git send-email -to email@email.com -to email2@email.com -cc devel@driverdev.osuosl.org -cc linux-kernel@vger.kernel.org 0001-your-patch.patch 하면 된다.
사실 to 를 누구로 해야하는지는 안나와 있어서 나중에 내가 용기가 나면 시도 해보고 다시 알려주겠다.
또 한가지 git send-email command 가 없다고 나오는 경우도 있는데, 그 때는
// ubuntu 의 경우
$ sudo apt-get install git-email
하면된다.
이렇게 해서 적절한 CC로 메일이 일단 전달되면 몇일 내로 개발자에게 답변이 온다고 한다. 답변은 accept 해주거나 comment 를 포함해서 온다고 한다. (comment 가 날아오면 그것을 해결하고 다시 보내면 될 듯.)
이상 여기까지 초보 개발자가 kernel 에 contribution을 하는 방법을 알리는 blog 를 나름 번역을 해봤다.
원문 : http://lotphelp.com/lotp/beginner-guide-linux-kernel-hacking
'Linux Kernel Study' 카테고리의 다른 글
[분석] Linux kernel physical memory allocator (Buddy) - Part 2 (0) | 2013.10.01 |
---|---|
[분석] Linux kernel physical memory allocator (Buddy) - Part 1 (2) | 2013.09.28 |
[번역] Anatomy of a Program in Memory (0) | 2013.04.05 |
[번역] The Kernel Boot Process - 32bit X86 (2) | 2013.04.01 |
[ION] Sharing a buffer between kernel-space and user-space (0) | 2013.03.28 |