[번역] Beginner Guide to Linux Kernel Hacking

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 (error != -ENODEV) { foo(); foo2(); }

만약 if else 문의 구조라면 다음고 같이 한다.

if (error != -ENODEV) { foo(); foo2(); } else { report_error(); goto exit; }

아래와 같은 경우는 brace 를 사용하지 않는다.

if (error != -ENODEV) foo(); else goto exit;

checkpatch.pl

이제 위의 기본적인 coding style을 이해하고 checkpatch.pl script 를 수행 준비하자.

(이 script  가 무엇을 얘기해줄 수 있는지에 대해)

Download 받은 kernel 에서

   $ ./scripts/checkpatch.pl --help

// Image

위의 option 중에 두 개의 common 한 option 이 있는데 --terse 와 --file 이다. 특정 파일에 대한 문제를 간단하게 보여주는 option들이다. 하나의 file을 선택하여 테스트 해보자.

아무런 file을 선택하려고 했더니, 그닥 많이 나오는 파일이 drivers/staging 하위에 선택되지 않았다.

암튼 아무거나 선택해서

   $ ./scripts/checkpatch.pl --file --terse drivers/staging/bcm/Qos.c

를 돌려봤다.

// Image

위에서 보듯이 한 line 에 80자가 넘어간 것이거나, brace 를 rule 에 맞게 쓰지 않은 경우 등을 보여준다.

하나의 예를 들어 수정해보자.

drivers/staging/bcm/Qos.c:821: ERROR: that open brace { should be on the previous line

if(u16Etype == ETHERNET_FRAMETYPE_802QVLAN) { //802.1Q VLAN Header pstEthCsPktInfo->eNwpktEthFrameType = eEth802QVLANFrame; u16Etype = ((ETH_CS_802_Q_FRAME*)pvEthPayload)->EthType; //((ETH_CS_802_Q_FRAME*)pvEthPayload)->UserPriority } else { pstEthCsPktInfo->eNwpktEthFrameType = eEthOtherFrame; u16Etype = ntohs(u16Etype); }

소스를 위의 rule 에 맞게 고치면,

if(u16Etype == ETHERNET_FRAMETYPE_802QVLAN) { //802.1Q VLAN Header pstEthCsPktInfo->eNwpktEthFrameType = eEth802QVLANFrame; u16Etype = ((ETH_CS_802_Q_FRAME*)pvEthPayload)->EthType; //((ETH_CS_802_Q_FRAME*)pvEthPayload)->UserPriority } else { pstEthCsPktInfo->eNwpktEthFrameType = eEthOtherFrame; u16Etype = ntohs(u16Etype); }

위와 같이 수정 가능하다.

그럼 제대로 수정이 되었는지 확인하면,

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