HOWTO do Linux kernel development

리눅스 커널 개발자가 되는 일은 정말 길고도 힘든 길일것 같다.

하지만, 그렇기에 정말 멋진 일이 아닐까..

나는 지금 그 길의 첫발을 딛고 있다.

---

원문 : http://wiki.kldp.org/wiki.php/HOWTO_do_Linux_kernel_development

---

FrontPage › LinuxdocSgml/Majordomo-KLDP › HOWTO_do_Linux_kernel_development

원문: "HOWTO do Linux kernel development"

저자: Greg Kroah-Hartman <greg@kroah.com>

번역: 조수형 <xfree@paran.com>

---

HOWTO do Linux kernel development

이 문서는 이 주제에 대한 가장 중요한 문서로 어떻게 리눅스 커널 개발자가 되고 어떻게 리눅스 커널 개발 커뮤니티와 작업할 수 있는지를 알려준다. 커널 프로그램에 관한 기술적인 면을 다루고 있지는 않지만 이 주제에 올바른 방향으로 접근하는데 도움이 될것이다.

이 문서 내용중에 구식이 된 내용이 있으면 문서 마지막에 나와있는 문서 관리자에게 패치를 보내길 바란다.

소개

그럼, 어떻게 리눅스 커널 개발자가 되는지 궁금할 것이다. 혹은 상사한테 이런말 들어봤을 것이다. "가서 이 디바이스의 리눅스 드라이버 작성해바." 이 문서의 목적은 이 문제를 해결하기 위해 거처야 할 과정을 설명함으로써 알아야 할 것들을 알려주고 커뮤니티와 어떻게 작업할 수 있는지 조언한다. 또한 왜 커뮤니티 작업이 그러한지 몇가지 이유에 대해서도 설명할 것이다.

커널은 대부분 C로 작성되며 몇몇 아키텍쳐에 의존적인 부분들은 어셈블리로 작성된다. 커널 개발은 C를 잘 이해해야 한다. 아키텍쳐에 대한 저수준의 개발 개획이 없다면 어셈블리는 (어떤 아키텍쳐에서라도) 필요하지 않다. 부단한 C 학습과 몇년간의 경험보다 좋을리는 없겠지만 참고서가 필요하다면 다음 책들을 추천한다.

• "The C Programming Language" by Kernighan and Ritchie Prentice Hall
• "Practical C Programming" by Steve Oualline O'Reilly
  
  

커널은 GNU C와 GNU 툴체인으로 작성된다. 이들은 ISO C89 표준을 고수하지만 표준에 없는 몇몇 기능을 확장하여 사용한다. 커널은 독립된 구조의 C 환경으로 표준 C 라이브러리에 의존하지 않는다. 즉 C 표준의 몇몇 부분은 지원하지 않는다. 확실치 않은 long long 이나 소수점은 허용되지 않는다. 커널이 툴체인에 대해 갖는 가정이나 커널이 사용하는 확장에 대해 때때로 이해하기 힘들 수 있으나 아쉽게도 참조할 만한 결정적인 문서가 없다. gcc info 문서가 (info gcc) 약간의 정보를 제공하니 참조하길 바란다.

기존의 개발 커뮤니티와 함께 작업함을 기억하길 바란다. 코딩, 스타일, 절차에 있어서 높은 기준을 지닌 다양한 그룹의 사람들이다. 이러한 기준은 지형적으로 떨어진 큰 규모의 사람들이 최고의 작업을 할 수 있도록 오랜 시간에 걸쳐 형성되었다. 잘 설명해 놓았듯이 가능한한 시간을 들여서 미리 이러한 기준에 대해 익힐 수 있도록 노력하라; 사람들이 당신 혹은 당신네 회사 방식에 적응하리라 기대하지 말아라.

법적 문제

리눅스 커널 코드는 GPL을 따른다. 라이센스에 관해서는 소스 트리의 메인 디렉토리에 있는 COPYING 파일을 읽어보길 바란다. 라이센스에 관해 더 많은 궁금증이 생기면 리눅스 커널 메일링 리스트에 질문하지 말고 법률가에게 연락하길 바란다. 메일링 리스트에 있는 사람들은 법률가가 아니라서 법적 문제에 있어서는 그들의 말에 기댈 수 없다.

GPL에 대한 일반적인 질문과 답변은 이 문서에 나와있다.

http://www.gnu.org/licenses/gpl-faq.html

문서

리눅스 커널 트리는 큰 범위의 문서들을 갖는다. 이 문서들은 커널 커뮤니티와 어떻게 교류할 수 있는지 알려주는 매우 귀중한 문서들이다. 새로운 기능이 커널에 추가되면 이 기능을 어떻게 사용하는지 설명하는 새로운 문서 파일 또한 추가되어야 한다. 커널 변경으로 커널과 사용자 영역 사이의 인터페이스가 변경되면 이를 설명하는 메뉴얼 페이지의 정보나 패치를 mtk-manpages@gmx.net에 있는 메뉴얼 페이지 관리자에게 보내야 한다.

여기 나열된 파일은 커널 소스 트리에 있는것으로 읽어봐야 한다:

README

이 파일은 리눅스 커널의 배경에 대해 짧게 소개하고 커널을 설정하고 빌드하기 위해 필요한 사항을 설명한다. 커널을 처음 접한 사람이라면 이 문서부터 읽어봐야 한다.

Documentation/Changes

이 파일은 커널을 올바르게 빌드하고 실행하는데 필요한 소프트웨어 패키지들의 최소한의 목록이다.

Documentation/CodingStyle

이 파일은 리눅스 커널 코딩 스타일과 이와 관련된 근거를 설명한다. 모든 새로운 코드는 이 문서의 지침을 따르도록 한다. 최근의 관리자들은 이 규칙을 따르는 패치만 받아들이며 코드가 올바른 스타일이어야만 사람들이 재검토한다.

Documentation/SubmittingPatches Documentation/SubmittingDrivers

이 파일들은 다음 사항을 포함하여 (제한 되지는 않지만) 패치를 어떻게 만들고 보내는지를 명확하고 자세하게 설명한다:

이메일 내용

이메일 형식

받을 사람

이들 규칙을 따른다고 패치가 됨을 뜻하지 않으나 (모든 패치는 내용과 스타일이 검토되기 때문에) 규칙을 따르지 않으면 거의 대부분 패치가 되지 않는다.

올바른 패치를 만드는 방법은 이곳에도 훌륭히 설명돼있다:

"The Perfect Patch" (확인해보니 죽은 링크임...)

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

"Linux kernel patch submission format"

http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt

이 파일은 다음과 사항과 같이 커널 내부에서 안정된 API가 아닌것들에 대한 이유를 설명한다.

• shim-layers 서브시스템 (호환성 문제?)
• 운영체제간의 드라이버 포팅성
• 커널 소스 트리 내부의 빠른 변화 완화 (혹은 빠른 변화 방지)
  
  

리눅스 개발 철학을 이해하기 위한 결정적인 문서이며 다른 운영 체제를 개발하다 리눅스로 옮겨온 사람들에게 매우 중요한 문서이다.

Documentation/SecurityBugs

리눅스 커널에 보안 문제가 발견되면 이 문서에 나와있는 순서에 따라 커널 개발자들에게 알려주고 이 문제를 해결하도록 돕길 바란다.

Documentation/ManagementStyle

이 문서는 리눅스 커널 관리자가 어떠한 성향으로 운영하고 공유하는지를 그들의 방법론적으로 설명한다. 커널 개발에 처음인 모든이들에게 중요한 문서이다 (혹은 단순히 궁금해 하는 모든이들). 커널 관리자의 독단적 태도에 대한 많은 공통된 오해와 혼란을 해결하기 때문이다.

Documentation/stable_kernel_rules.txt

이 파일은 안정된 커널이 어떠한 규칙으로 발표되고 이들중 하나를 얻고자 한다면 무엇을 해야 하는지 설명한다.

Documentation/kernel-docs.txt

커널 개발과 관련된 외부 문서 목록이다. 커널 내부 문서중에 찾고자하는 내용이 없으면 이 목록을 참조하길 바란다.

Documentation/applying-patches.txt

패치가 정확이 무엇이고 다른 커널 개발 브랜치에 어떻게 적용하는지 설명하는 좋은 입문서.

커널은 또한 소스 코드로부터 자동적으로 생성되는 많은 문서들을 갖는다. 커널 내부API의 자세한 기술이나 올바르게 락킹을 처리하는 방법을 포함한다. 이 문서들은Documentation/DocBook/ 디렉토리에 생성되며 다음 명령으로 PDF, 포스트스크립트,HTML 맨 페이지로 생성될 수 있다.

• make pdfdocs
• make psdocs
• make htmldocs
• make mandocs
  
  

메인 리눅스 커널 소스 디렉토리에서 따로따로 입력.

[edit]

커널 개발자 되기 ¶

리눅스 커널 개발에 대해 아무것도 알지 못한다면 리눅스 KernelNewbies 프로젝트부터 봐야한다: http://kernelnewbies.org 커널 개발에 관한 어떠한 기본적인 질문이라도 물을 수 있는 도움이 될만한 메일링 리스트로 구성된다. (무언가 묻기 전에 과거에 답변된 질문인지 아카이브부터 살펴볼 것을 잊지 말아라). 실시간 질문할 수 있는 IRC 채널도 갖고 있고 리눅스 커널 개발에 대해 배울 수 있는 도움이 될만한 문서들도 많이 있다.

웹사이트는 코드 구성이나 서브시스템, 현재 진행중인 프로젝트에 대한 (트리 내부 및 외부) 기본적인 정보를 갖고 있다. 또한 커널을 어떻게 컴파일하고 패치를 어떻게 적용하는지와 같은 몇몇 기본적인 전략적 정보도 설명한다.

어디서 시작해야 할지 모르지만 커널 개발 커뮤니티에 참여하여 뭔가 해보길 원한다면 리눅스 커널 Janitor 프로젝트를 방문하라:

http://janitor.kernelnewbies.org/

시작하기 정말 좋은곳이다. 리눅스 커널 소스 트리를 정리하고 수정하는데 필요한 다소 간단한 문제들을 설명한다. 이 프로젝트를 담당하고 있는 개발자와 일해보면, 리눅스 커널 트리에서 어떻게 패치를 얻을 수 있는지 기본적인 것들은 배울 수 있으며 다음 작업으로 무엇을 해야 하는지 모른다면 알려줄 것이다.

커널 트리에 넣고자하는 코드를 갖고 있지만 올바른 형태로 만드는데 도움이 필요하다면 커널-멘토 프로젝트가 도움이 될것이다. 메일링 리스트로 여기에서 구할 수 있다:

http://selenic.com/mailman/listinfo/kernel-mentors

리눅스 커널 코드에 대한 실제적인 변경 코드를 만들기 전에 그 코드가 어떻게 동작하는지 반드시 이해해야 한다. 그러기 위해서는 전문화된 툴의 도움을 받는다 할지라도 직접 읽어보는게 가장 좋은 방법이다. (까다로운 부분은 대부분 설명이 잘되어 있다) 특별히 추천할만한 툴로 소스 코드를 자신을 참조하면서 색인있는 웹페이지 형태로 표현해주는 리눅스 크로스-레퍼런스 프로젝트가 있다. 이곳에 최근 커널 코드의 훌륭한 저장소가 있다:

http://sosdg.org/~coywolf/lxr/

[edit]

개발 과정 ¶

현재 리눅스 커널 개발 과정은 몇개의 "브랜치"와 다른 많은 서브시스템에 종속적인 커널 브랜치로 구성된다. 브랜치 종류는:

• 메인 2.6.x 커널 트리
• 2.6.x.y -stable 커널 트리
• 2.6.x -git 커널 패치
• 2.6.x -mm 커널 패치
• 서브시스템에 종속적인 커널 트리와 패치
  
  

[edit]

2.6.x 커널 트리 ¶

2.6.x 커널은 리누즈 토발즈에 의해 관리되며 kernel.org의 pub/linux/kernel/v2.6/ 디렉토리에서 구할 수 있다. 개발과정은 다음과 같다.

• 새 커널이 2주간 창을 열어 놓으면, 이 기간동안 관리자들은 많은 양의 수정된 부분을 리누즈에게 제출할 수 있다. 대개 패치는 -mm 커널에 몇주간 미리 적용된다. 많은 양의 수정사항은 주로 git를 (커널 소스 관리 툴, 더 많은 정보는 http://git.or.cz/ 에 있다) 사용하여 제출되지만 일반 패치도 상관없다.
• 2주 후 -rc1 커널이 발표된다. 이젠 전체 커널의 안정성에 영향을 미칠수 있는 새로운 기능이 표함된 패치는 받아들여지지 않는다. 모든 새로운 드라이버 (혹은 파일시스템)은 -rc1 이후에도 받아들여질 수 있다는 점을 명심하라. 그러한 변경은 추가된 코드가 자신만 포함되고 외부 영역에 영향을 미치질 않는다면 문제를 야기할 위험이 없기 때문이다. -rc1 발표 이후의 패치는 git를 사용하여 리누즈에게 보낼 수 있지만 그러한 패치들은 또한 재검토 목적으로 공공의 메일링 리스트에게 전달 될 필요도 있다.
• 리누즈는 현재의 git 트리가 테스팅하기에 알맞은 상태라고 판단될때마다 새로운 -rc를 발표한다. 매주마다 새 -rc를 발표하도록 노력한다.
• 이 과정은 커널이 "준비" 상태가 될때까지 약 6주간 계속된다.
  
  

Andrew Morton이 리눅스-커널 메일링 리스트에 커널 발표에 대해 쓴글은 언급할 필요가있다:

"예상된 스케줄에 따른것이 아니라 파악된 버그 상태에 따른것이기 때문에 아무도 언제 커널이 발표될지 모른다."

[edit]

2.6.x.y -stable 커널 트리 ¶

4개의 숫자로된 커널 버전은 -안정된 커널이다. 2.6.x 커널에서 발견된 상대적으로 적은 수의 보안 문제나 주요 역행 문제들이 수정된다.

가장 최신의 안정 커널을 원하고 테스트 개발/실험 버전에 관심이 없는 사용자에게 추천한다.

2.6.x.y 커널이 없다면 가장 높은 수의 2.6.x 커널이 현재의 안정 커널이다.

2.6.x.y는 "stable" 팀 <stable@kernel.org>에 의해 관리되고 거의 매주마다 발표된다.

커널 트리의 Documentation/stable_kernel_rules.txt 파일은 어떤식의 수정이 -stable 트리에 받아들여질 수 있고 발표과정이 어떠한지를 설명한다.

[edit]

2.6.x -git 패치 ¶

git 저장소에서 (이름을 보라) 관리되는 리누즈 커널 트리의 일별 스냅샷이다. 이 패치들은 거의 매일 발표되며 리누즈 트리의 현재 상태를 나타낸다. 한번도 검사하지 않고 자동적으로 생성되기 때문에 -rc 커널보다 더 실험적인 커널이다.

[edit]

2.6.x -mm 커널 패치 ¶

Andrew Morton에 의해 발표되는 실험적인 커널 패치다. Andrew는 모든 다른 서브시스템 커널 트리를 받아들이고 리눅스-커널 메일링 리스트에서 받은 많은 패치들을 적용하여 하나로 합쳐놓는다. 이 트리는 새로운 기능과 패치를 위한 장소로 제공된다. 일단 -mm 패치가 제공되면 Andrew나 서브시스템 관리자들은 이것을 리누즈에게 보내어 메인라인에 포함되도록 한다.

모든 새로운 패치들은 메인 커널 트리에 포함되기위해 리누즈에게 보내기전에 -mm 트리에서 테스트 거칠것을 매우 권장한다.

이 커널들은 안정적이어야 할 시스템에 사용하기에는 적합하지 않으며 다른 모든 브랜치보다 더욱 모험적이다.

커널 개발 과정을 돕고자 한다면 이 커널을 테스트하고 사용하여 문제가 있는지 혹은 올바로 동작하는지 리눅스-커널 메일링 리스트에 피드백을 제공하길 바란다.

다른 모든 실험적인 패치 외에도 이 커널은 또한 발표된 시기에 따른 메인라인 -git 커널의 어떠한 변경사항도 포함한다.

-mm 커널은 정해진 스케줄이 없고 대개 각각의 -rc 커널 (1에서 3이 보통이다) 사이에 몇번의 -mm 커널이 발표된다.

[edit]

서브시스템에 종속적인 커널 트리와 패치 ¶

몇몇의 다른 커널 서브시스템 개발자들은 그들의 개발 트리를 공개하여 다른 사람들이 커널의 다른 부분에서 무슨일이 일어나고 있는지 볼수있도록 공개한다. 이러한 트리는 위에서 설명했듯이 -mm 커널 발표에 포함된다.

여기에 유용한 몇몇 다른 커널 트리 목록이 있다.

git 트리:

- Kbuild 개발 트리, Sam Ravnborg <sam@ravnborg.org>

kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

- ACPI 개발 트리, Len Brown <len.brown@intel.com>

kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

- 블럭 개발 트리, Jens Axboe <axboe@suse.de>

kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

- DRM 개발 트리, Dave Airlie <airlied@linux.ie>

kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

- ia64 개발 트리, Tony Luck <tony.luck@intel.com>

kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

- ieee1394 개발 트리, Jody McIntyre <scjody@modernduck.com>

kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

- 인피니밴드, Roland Dreier <rolandd@cisco.com>

kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

- libata, Jeff Garzik <jgarzik@pobox.com>

kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

- 네트웍 드라이버, Jeff Garzik <jgarzik@pobox.com>

kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>

kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

- SCSI, James Bottomley <James.Bottomley@SteelEye.com>

kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

다른 git 커널 트리는 http://kernel.org/git 에서 볼수 있다.

퀼트 트리:

- USB, PCI, 드라이버 코어, 그리고 I2C, Greg Kroah-Hartman <gregkh@suse.de>

kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

[edit]

버그 보고 ¶

bugzilla.kernel.org는 리눅스 커널 개발자들이 커널 버그를 추적하는 곳이다. 사용자들이 발견한 모든 버그는 이 툴로 보고하길 권장한다. 커널 버그질라에 대한 자세한 사용법은 이 문서를 보길 바란다:

http://test.kernel.org/bugzilla/faq.html

메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 가능한 커널 버그를 어떻게 보고하고 어떤식의 정보가 커널 개발자들이 문제를 추적하는데 도움이 되는가에 대한 자세한 사항을 나타낸 좋은 예제이다.

[edit]

메일링 리스트 ¶

위에서 설명했듯이, 대다수의 핵심 커널 개발자들은 리눅스 커널 메일링 리스트에 참여한다. 리스트에 어떻게 가입하고 탈퇴할 수 있는지 자세한 설명이 여기에 나와있다.

http://vger.kernel.org/vger-lists.html#linux-kernel

이것들은 많은 다른 장소의 웹에 있는 메일링 리스트의 아카이브이다. 이 아카이브를 찾으려면 서치 엔진을 사용하라. 예를 들어:

http://dir.gmane.org/gmane.linux.kernel

리스트에 글을 보내기전에 찾고자하는 주제를 아카이브에서 먼저 찾아 볼것을 강하게 충고하는 바이다. 이미 자세히 토론된 많은 주제들이 메일링 리스트 아카이브에 기록돼있다.

대부분의 개별적인 커널 서브시스템은 그들의 개발 공간인 그들만의 분리된 메일링 리스트도 갖고 있다. 다른 그룹을 위한 이들 리스트 목록은 MAINTAINERS 파일에 나와있다.

많은 리스트들이 kernel.org에서 운영된다. 그들에 대한 정보는 이곳에서 볼 수 있다:

http://vger.kernel.org/vger-lists.html

리스트를 이용할때 좋은 행동 습관을 따를것을 기억하길 바란다. 다소 느끼하겠지만 리스트와 (어떠한 리스트라도) 같이 작업하기위한 간단한 지침이 다음 URL에 나와있다:

http://www.albion.com/netiquette/

여러 사람들이 답변해 준다면, CC: 수신 목록이 꽤 커질수도 있다. 특별한 이유없이 CC: 목록에서 누군가를 지우거나 리스트 주소에만 답장하지 말아라. 한번은 보낸이로부터 한번은 리스트로부터 메일을 두번 받게 되더라도 기호에 맞게 메일-헤더를 고치지 말아라. 사람들이 좋아하지 않을 것이다.

답변 내용과 속성을 그대로 유지해야 하고, 답변 처음에는 "존 커널핵커가 씀 ...:" 라인을 유지해야 하며, 의견은 메일 처음에 쓰지 말고 개별 인용구 사이에 추가돼야 한다.

메일에 패치를 추가하려면 Documentation/SubmittingPatches에 나와있듯이 패치는 읽을 수 있는 평범한 텍스트여야 한다. 커널 개발자들은 첨부되거나 압축된 패치로 작업하려하지 않는다; 패치의 개별 라인에 의견을 달아 줄 것이다. 그런식으로만 작업한다. 반드시 스페이스와 탭 문자로 난도질 하지 않는 메일 프로그램을 사용해라. 좋은 방법은 자신에게 메일을 보내고 자신의 패치를 직접 적용해 보는 것이다. 패치가 되지 않으면 될때까지 메일 프로그램을 고치거나 바꿔라.

무엇보다, 다른 가입자들에게 정중할것을 기억하길 바란다.

[edit]

커뮤니티와 작업하기 ¶

커널 커뮤니티의 목적은 가능한한 최고의 커널을 제공하는데에 있다. 패치를 제출하면 기술적 장점과 이런저런 재검토가 이루어질 것이다. 그럼 무엇을 기대해야 하는가?

• 비평
• 의견
• 수정 요청
• 정당성 요구
• 침묵
  
  

명심하라, 이것은 패치가 커널에 반영되는 과정이다. 패치에 대한 비평과 의견을 받아들일 수 있어야 하고 기술적 차원에서 평가할 수 있어야 하며 패치를 재작업 하거나 왜 그러한 수정이 만들어질 수 없는가에 대한 명료하고 간결한 이유를 제공할 수 있어야 한다. 올린글에 응답이 없으면 며칠 기달리고 다시 올려라. 가끔씩 큰 단위로 사라진다.

해선 안될것들?

• 질문없이 패치를 받아들일거라 기대하지 마라
• 화내지 마라
• 의견을 무시하지 마라
• 어떠한 수정 요구 없이 패치를 다시 재출하지 마라
  
  

가능한 최고의 기술적 해결책을 찾고자 하는 커뮤니티에선, 패치가 어떤 이득이 있는지에 대해 항상 다른 의견이 있을것이다. 협동해야 하고 아이디어를 커널에 맞도록 기꺼이 개조해야 한다. 혹은 적어도 아이디어가 가치가 있음을 입증하도록 노력해야 한다. 기억하라, 올바른 방향으로 작업하고자 한다면 잘못은 받아들여질 수 있다.

첫번째 패치에 대한 답변은 단순히 온통 올바르게 해야된다는 말만 적혀 있는게 보통이다. 이것은 패치가 받아들여질 수 없다는 것을 의미하지 않으며 인격에 대한 의미도 아니다. 패치에 대한 모든 문제점을 고쳐서 다시 보내면 그만이다.

[edit]

커널 커뮤니티와 회사 조직과의 차이점 ¶

커널 커뮤니티는 대부분의 적통적 회사 개발 환경과 다르게 작업한다. 문제를 피하기 위해 해야할 일들이 여기에 있다:

언급하면 좋은 말들:

• "이것은 다양한 문제들를 해결한다."
• "이것은 코드의 2000 라인을 삭제한다."
• "설명하고자하는 패치가 여기있다."
• "5개의 다른 아키텍처에서 테스트하였다..."
• "적은 패치 모음이 여기있다..."
• "이것은 전형적인 기계의 성능을 향상시킨다..."
  
  

피해야 할 나쁜 말들:

• "AIX/ptx/Solaris 방식으로 했으므로 좋아야 한다..."
• "20년동안 이일을 하고 있다. 그러니까..."
• "이것은 우리 회사가 돈버는데 필요하다"
• "이것은 우리 기업 제품군이다."
• "이일을 6개월간 작업해왔다..."
• "여기 5000 라인짜리 패치가 있다..."
• "모든 난잡한 코드를 재작업했다. 그코드가 여기있다..."
• "마감시간 때문에 패치가 지금 적용돼야 한다."
  
  

커널 커뮤니티가 대부분의 전통적 소프트웨어 엔지니어링 작업 환경과 다른 또한가지는 얼굴을 마주대하지 않는다는 점이다. 대화의 주요 수단으로 이메일이나 irc를 사용하는 잇점은 성별이나 인종에 차별이 없다는 점이다. 리눅스 커널 작업 환경에서는 모두 이메일 주소로 표현되므로 여성과 소수를 받아들인다. 사람 이름으로 성별을 알 수 없기에 국제적이라는 점도 노는 수준에 도움이 된다. Andrea가 남성일 수 있고 Pat이 여성일 수 있다. 리눅스 커널로 작업해보고 의견을 표현해본 대부분의 여성들은 확실한 경험을 갖고 있다.

언어 장벽은 영어에 익숙하지 못한 몇몇에게 문제를 야기할 수 있다. 언어에 대한 좋은 이해가 메일링 리스트에서 오가는 아이디어를 이해하기위해 필요할 수 있다. 즉 메일을 보내기 전에 그들이 영어로된 이메일을 이해할 수 있는지 점검해 보기를 권한다.

[edit]

수정 사항을 분할하라 ¶

리눅스 커널 커뮤니티는 한꺼번에 떨어진 많은 양의 코드를 꺼려한다. 수정 사항은 올바르게 소개되고, 논의되고, 개별적인 작은 부분으로 분할될 필요가 있다. 이부분은 회사에서 행해지는것과 거의 정반대이다. 제안도 개발 과정에서 일찍 먼저 소개되어야 한다. 그래야 하는 일에 대한 피드백을 받을 수 있다. 커뮤니티를 단순히 기능을 위한 작업장으로 이용하지 말고 커뮤니티도 당신이 그들과 함께 일하고 있도록 느끼게 해야한다. 그러나 한번에 50개의 이메일을 메일링 리스트에 보내지마라, 패치들은 거의 대부분 그수보다 적어야 한다.

분할해야 되는 이유는 다음과 같다:

1) 패치가 적으면 올바른지 판단하는데 시간과 노력이 적게 들기 때문에 패치가 적용될 확률이 높다. 5줄의 패치는 관리자가 잠깐만바도 적용될 수 있다. 그러나 500줄의 패치는 올바른지 검토하는데 몇시간이 걸릴수도 있다 (걸리는 시간은 패치의 크기나 무언가에 기하급수적으로 비례한다).

무언가가 잘못됐을 때에도 패치가 적으면 디버그도 매우 쉬워진다. 패치가 적용된 이후에 (그리고 뭔가 잘못되면) 매우 큰 패치를 분석하는 것보다도 적은 패치들을 하나하나 취소해 나가는 것이 훨씬 더 쉽다.

2) 적은 패치를 보내는 것뿐만 아니라 패치를 보내기 전에 재작성하고 단순화 (혹은 단순히 재배치) 하는것도 중요하다.

커널 개발자인 Al Viro의 유사한 설명이 여기있다:

"학생들로부터 수학 숙제의 점수를 매기를 선생님과 같이 생각하라. 선생님은 문제의 해답을 얻기까지의 학생들의 시행착오는 보려하지 않는다. 가장 분명하고 가장 명쾌한 답을 원한다. 좋은 학생은 이것을 알기에 마지막 해답을 얻기전인 중간 결과물은 결코 제출하려 하지 않는다."

커널 개발자도 같은게 사실이다. 관리자들과 재검토자들은 풀고자하는 문제의 해답이 어떤 사고 과정을 거처서 나왔는지 보려하지 않는다. 단순하고 명쾌한 답을 원한다."

명쾌한 답을 보여주는 것과 커뮤니티와 함께 작업하고 진행중인 작업을 논의하는것 사이에서 균형을 유지한데는게 힘들 수 있다. 그러므로 작업을 진행할때 작업 초기에 피드백을 얻는게 좋지만 전체 임무가 포함될 준비가 되어있지 않다면 이미 받아들여졌을 수정 사항을 작은 단위로 유지하는것도 중요하다.

또한 완료되지 않은 패치나 "나중에 고처질것."으로 적어 보낸 패치는 받아들여 질 수 없다는 것도 알아둬라.

[edit]

수정 사항을 정당화 하라 ¶

패치를 분할하는데 있어서 리눅스 커뮤니티가 왜 이 수정사항을 포함해야 하는지 알게끔 하는게 매우 중요하다. 새로운 기능은 필요로 하고 쓸모있게끔 정당화 되어야 한다.

[edit]

수정 사항을 문서화 하라 ¶

패치를 보낼 때, 이메일에 쓸 말에 대해 특히 주의를 기울여라. 이 정보는 그 패치를 위한 ChangeLog 정보가 될것이고 모두가 항상 볼 수 있도록 유지될 것이다. 패치에 대해 다음을 포함해서 완벽히 설명해야 한다.

• 왜 수정이 필요한지
• 패치의 종합적인 설계 방법
• 상세한 설명
• 테스트한 결과
  
  

어떤 형태여야 하는지 자세한 사항은 이 문서의 ChangeLog 부분을 참고하길 바란다:

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

이 모든 것들을 하기에는 때때로 매우 힘이든다. (모든 경우에 있어서) 완벽해지까지 몇년이 걸릴 수 있다. 많은 인내와 결단이 필요한 지속적인 개선 과정이다. 하지만 포기하지 마라, 가능한 작업이다. 이미 많은 이들이 해왔고 그들도 지금의 당신과 똑같이 시작했었다.