Linux kernel 개발 HOWTO

이 문서의 목적

이 문서는 Linux kernel developer가 되는 방법과 Linux kernel development community에서 함께 일하는 방법을 안내하는 종합 문서다. Kernel programming의 기술적 세부 사항 자체는 다루지 않지만, 그 내용을 배우기 위해 어느 방향으로 가야 하는지 알려 준다.

문서 내용이 오래되어 현재 상황과 맞지 않게 되면 문서 맨 아래에 적힌 maintainer에게 patch를 보내 갱신해야 한다.

시작하기 전에 필요한 배경

Linux kernel developer가 되고 싶거나 관리자로부터 “이 장치의 Linux driver를 작성하라”는 지시를 받았다면, 이 문서는 그 목표에 이르기 위해 거쳐야 할 절차와 community에서 협업하는 방법을 설명한다. Kernel community가 현재와 같은 방식으로 움직이는 이유도 함께 설명하려 한다.

Kernel은 대부분 C로 작성되며 architecture-dependent 부분 일부는 assembly로 작성된다. 따라서 kernel development에는 C를 충분히 이해해야 한다. 특정 architecture의 low-level 개발을 할 계획이 아니라면 assembly 지식은 필수 사항이 아니다.

아래 책들은 탄탄한 C 교육이나 수년간의 경험을 대신할 수는 없지만 참고서로 유용하다.

• Kernighan과 Ritchie의 “The C Programming Language” [Prentice Hall]
• Steve Oualline의 “Practical C Programming” [O'Reilly]
• Harbison과 Steele의 “C: A Reference Manual” [Prentice Hall]

Kernel은 GNU C와 GNU toolchain을 사용한다. ISO C11 표준을 따르지만 표준에 없는 여러 GNU extension도 사용한다. Kernel은 standard C library에 의존하지 않는 freestanding C environment이므로 C 표준의 일부 기능은 지원되지 않는다. 임의의 long long division과 floating point 연산도 허용되지 않는다.

Kernel이 toolchain에 대해 두는 전제와 사용하는 extension을 모두 설명하는 결정적 참고 자료는 없다. 관련 정보는 gcc info page에서 확인할 수 있다.

info gcc

목표는 이미 존재하는 development community와 일하는 법을 배우는 것이다. 이 community는 다양한 사람으로 구성되어 있고 coding, style, procedure에 높은 기준을 둔다. 이 기준은 규모가 크고 지리적으로 흩어진 팀에서 가장 잘 작동했던 방법을 오랜 시간 축적해 만든 것이다. 기준은 잘 문서화되어 있으므로 미리 최대한 익혀야 하며, 다른 개발자들이 자신이나 자기 회사의 업무 방식에 맞춰 줄 것이라고 기대해서는 안 된다.

법률과 license

Linux kernel source code는 GPL에 따라 공개된다. 정확한 조건은 source tree 최상위의 COPYING file을 확인한다. Linux kernel의 licensing rule과 source code에서 SPDX identifier를 사용하는 방법은 Documentation/process/license-rules.rst에 설명되어 있다.

License에 관해 추가 질문이 있다면 변호사에게 문의해야 하며 Linux kernel mailing list에 묻지 않아야 한다. Mailing list 참여자는 변호사가 아니므로 법률 문제에 관한 그들의 발언에 의존해서는 안 된다. GPL의 일반적인 질문과 답변은 GNU GPL FAQ에서 확인할 수 있다.

• SPDXhttps://spdx.org/
• GNU GPL FAQhttps://www.gnu.org/licenses/gpl-faq.html

먼저 읽어야 할 Documentation

Linux kernel source tree에는 kernel community와 상호 작용하는 방법을 배우는 데 매우 유용한 문서가 폭넓게 들어 있다. Kernel에 새 기능을 추가할 때는 그 기능의 사용법을 설명하는 documentation file도 함께 추가하는 것이 권장된다.

Kernel change로 userspace에 노출되는 interface가 바뀌면 그 변경을 설명하는 정보나 manual page patch를 manual page maintainer인 [email protected]로 보내고 [email protected]를 CC하는 것이 권장된다.

Source tree의 필독 문서

• Documentation/admin-guide/README.rst: Linux kernel의 간략한 배경, kernel configuration과 build에 필요한 작업을 설명한다. Kernel을 처음 접한다면 여기서 시작한다.
• Documentation/process/changes.rst: Kernel을 성공적으로 build하고 실행하는 데 필요한 여러 software package의 최소 version을 나열한다.
• Documentation/process/coding-style.rst: Linux kernel coding style과 그 근거 일부를 설명한다. 모든 새 code는 이 지침을 따라야 한다. 많은 maintainer는 규칙을 지킨 patch만 받아들이며, 올바른 style이 아니면 review하지 않는 개발자도 많다.
• Documentation/process/submitting-patches.rst: Patch를 성공적으로 만들고 보내는 방법을 email 내용, email 형식, 수신자 선택을 포함해 구체적으로 설명한다. 규칙을 따른다고 성공이 보장되지는 않지만, 따르지 않으면 거의 언제나 patch가 받아들여지지 않는다.
• Documentation/process/stable-api-nonsense.rst: Kernel 내부에 stable API를 두지 않기로 한 의식적인 결정의 근거를 설명한다. 호환성을 위한 subsystem shim layer, operating system 사이의 driver portability, kernel source tree의 빠른 변화를 완화하거나 막는 문제를 포함한다. 다른 operating system 개발 환경에서 Linux로 옮겨 온 사람에게 특히 중요한 Linux development 철학이다.
• Documentation/process/security-bugs.rst: Linux kernel의 security problem을 발견했다고 판단했을 때 kernel developer에게 알리고 문제 해결을 돕는 절차를 설명한다.
• Documentation/process/management-style.rst: Linux kernel maintainer가 일하는 방식과 그 방법론에 깔린 공통 ethos를 설명한다. Maintainer의 독특한 행동 방식에 관한 흔한 오해와 혼란을 풀어 주므로 kernel development 입문자와 운영 방식이 궁금한 사람 모두에게 중요하다.
• Documentation/process/stable-kernel-rules.rst: Stable kernel release가 이루어지는 규칙과 특정 stable release에 변경을 넣으려면 무엇을 해야 하는지 설명한다.
• Documentation/process/kernel-docs.rst: Kernel development와 관련된 외부 documentation 목록이다. In-kernel documentation에서 원하는 정보를 찾지 못했다면 이 목록을 확인한다.
• Documentation/process/applying-patches.rst: Patch가 정확히 무엇이며 kernel의 여러 development branch에 어떻게 적용하는지 소개한다.

Patch 작성법을 더 설명하는 자료로 “The Perfect Patch”와 보관된 “Linux kernel patch submission format” 문서가 있다.

• The Perfect Patchhttps://www.ozlabs.org/~akpm/stuff/tpp.txt
• Linux kernel patch submission formathttps://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html

Documentation build

Kernel에는 source code 자체나 이 문서와 같은 ReStructuredText(ReST) markup에서 자동 생성할 수 있는 문서도 많다. In-kernel API의 전체 설명과 locking을 올바르게 다루는 규칙도 여기에 포함된다. Source tree 최상위에서 다음 명령을 실행하면 각각 PDF와 HTML을 생성한다.

make pdfdocs
make htmldocs

ReST markup을 사용하는 문서는 Documentation/output에 생성된다. LaTeX와 ePub 형식도 만들 수 있다.

make latexdocs
make epubdocs

Kernel developer로 첫발을 내딛기

Linux kernel development를 전혀 모른다면 Linux KernelNewbies project를 먼저 살펴본다. 이 project에는 기본적인 kernel development 질문을 거의 무엇이든 물어볼 수 있는 mailing list가 있다. 다만 이미 답변된 질문을 다시 올리지 않도록 먼저 archive를 검색해야 한다.

KernelNewbies에는 실시간으로 질문할 수 있는 IRC channel과 Linux kernel development 학습에 도움이 되는 documentation도 많다. Website는 code organization, subsystem, tree 내부와 외부의 현재 project에 관한 기본 정보뿐 아니라 kernel compile과 patch 적용 같은 기초 절차도 설명한다.

어디서 시작할지 정하지 못했지만 kernel development community에 참여할 첫 작업을 찾고 싶다면 Linux Kernel Janitors project를 방문한다. Kernel source tree에서 정리하거나 고쳐야 할 비교적 단순한 문제 목록이 있어 좋은 출발점이 된다. Project 담당 developer와 함께 작업하면서 patch를 Linux kernel tree에 넣는 기본 절차를 배우고, 다음 작업 방향도 안내받을 수 있다.

Kernel code를 실제로 수정하기 전에 대상 code가 어떻게 동작하는지 이해하는 것은 필수다. 가장 좋은 방법은 source를 직접 읽는 것이며, 까다로운 부분 대부분에는 좋은 comment가 있다. 필요하면 전용 도구도 활용한다. 특히 권장되는 Linux Cross-Reference project는 source code를 상호 참조 가능한 indexed webpage 형태로 보여 준다. 최신 kernel source는 Elixir에서 탐색할 수 있다.

• Linux KernelNewbieshttps://kernelnewbies.org
• Linux Kernel Janitorshttps://kernelnewbies.org/KernelJanitors
• Elixir Cross Referencerhttps://elixir.bootlin.com/

Kernel development branch와 merge 흐름

Linux kernel development에는 역할이 다른 여러 주요 kernel branch와 subsystem별 branch가 있다. 핵심은 Linus의 mainline tree, 여러 major version의 stable tree, subsystem-specific tree, linux-next integration testing tree다.

Mainline tree

Mainline tree는 Linus Torvalds가 관리하며 kernel.org 또는 repository에서 찾을 수 있다. 새 kernel이 release되면 즉시 2주간의 merge window가 열린다. 이 기간 maintainer는 큰 diff를 Linus에게 제출할 수 있다. 보통 linux-next에 이미 몇 주 동안 포함되어 검증된 patch다. 큰 변경은 kernel source management tool인 git으로 제출하는 것이 선호되지만 일반 patch도 허용된다.

2주가 지나면 -rc1 kernel이 release되고, 이후 목표는 새 kernel을 가능한 한 견고하게 만드는 것이다. 이 시점의 patch 대부분은 regression을 고쳐야 한다. 오래전부터 존재한 bug는 regression이 아니므로 중요할 때만 이런 fix를 밀어 넣는다.

새 driver나 filesystem 전체는 self-contained이고 추가되는 code 밖의 영역에 영향을 주지 않는다면 regression을 만들 위험이 없어 -rc1 뒤에도 받아들여질 수 있다. -rc1 뒤에도 git으로 Linus에게 patch를 보낼 수 있지만 public mailing list에도 함께 보내 review를 받아야 한다.

현재 git tree가 test하기에 충분히 정상적인 상태라고 Linus가 판단할 때마다 새 -rc가 release된다. 목표 주기는 매주 하나의 -rc다. Kernel이 ready 상태라고 판단될 때까지 이 과정을 반복하며 보통 약 6주가 걸린다.

여러 major version의 stable tree

세 부분으로 된 version을 가진 kernel은 -stable kernel이다. 특정 major mainline release에서 발견된 security problem이나 중대한 regression을 고치는 비교적 작고 중요한 fix가 들어간다. 같은 major stable series의 release마다 version 세 번째 부분만 증가하고 앞의 두 부분은 유지된다.

최신 stable kernel을 원하지만 development 또는 experimental version test에는 참여하지 않으려는 사용자에게 권장되는 branch다. Stable tree는 stable team <[email protected]>이 관리하며 필요에 따라 release한다. 보통 약 2주 간격이지만 긴급한 문제가 없으면 더 길어질 수 있고, security problem이 있으면 거의 즉시 release될 수도 있다. 허용되는 변경과 release 절차는 Documentation/process/stable-kernel-rules.rst에 설명되어 있다.

Subsystem-specific tree

여러 kernel subsystem의 maintainer와 많은 subsystem developer는 현재 개발 상태를 source repository로 공개한다. 따라서 다른 사람도 kernel 각 영역에서 어떤 일이 진행되는지 볼 수 있다. 개발 속도가 빠른 영역에서는 제출물과 이미 진행되는 작업 사이의 conflict를 피하기 위해 subsystem tree를 base로 삼아 patch를 만들도록 요청받을 수 있다.

대부분 git tree지만 다른 SCM을 쓰거나 quilt series 형태로 patch queue를 공개하는 곳도 있다. Subsystem repository 주소는 MAINTAINERS file에 나열되어 있고 많은 tree를 git.kernel.org에서 탐색할 수 있다.

제안된 patch가 subsystem tree에 commit되기 전에는 주로 mailing list에서 review를 받는다. 여러 subsystem은 patchwork로 review process를 추적한다. Patchwork web interface에서는 게시된 patch, patch에 달린 comment와 revision을 볼 수 있고 maintainer는 상태를 review 중, accepted, rejected로 표시할 수 있다. 관련 site 대부분은 patchwork.kernel.org에 모여 있다.

linux-next integration testing tree

Subsystem tree의 update를 mainline에 merge하기 전에 integration test해야 한다. 이를 위해 거의 모든 subsystem tree를 거의 매일 pull하는 전용 testing repository가 있다. linux-next는 다음 merge period에 mainline으로 들어갈 것으로 예상되는 내용을 한곳에서 미리 보여 준다. 적극적인 tester가 linux-next를 실제로 실행해 test하는 것은 매우 환영받는다.

• Kernel.orghttps://kernel.org
• Githttps://git-scm.com/
• Kernel Githttps://git.kernel.org/
• Kernel Patchworkhttps://patchwork.kernel.org/
• linux-next repositoryhttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Bug report 작성과 관리

Main kernel source directory의 Documentation/admin-guide/reporting-issues.rst는 의심되는 kernel bug를 보고하는 방법과 developer가 문제를 추적하는 데 필요한 정보의 종류를 설명한다.

다른 사람이 보고한 bug를 고치는 일은 kernel hacking 기술을 실제로 적용하는 가장 좋은 방법 중 하나다. Kernel을 더 안정적으로 만들 뿐 아니라 현실의 문제를 해결하는 법을 배우고 실력이 늘며, 다른 developer에게 자신의 존재도 알릴 수 있다. 다른 사람의 bug를 고치는 데 시간을 쓰고 싶어 하는 사람이 많지 않기 때문에 이 작업은 developer 사이에서 신뢰를 얻는 좋은 방법이기도 하다.

기존 bug report를 다루려면 관심 있는 subsystem을 고른다. MAINTAINERS file에서 그 subsystem의 bug가 어디로 보고되는지 확인한다. 보통 mailing list이고 드물게 bug tracker다. 해당 장소의 archive에서 최근 report를 검색하고 도울 수 있는 문제에 참여한다.

bugzilla.kernel.org도 확인할 수 있다. 이를 적극적으로 report 또는 tracking에 사용하는 subsystem은 소수지만 kernel 전체에 관한 bug가 이곳에 등록되기도 한다.

• Linux Kernel Bugzillahttps://bugzilla.kernel.org

Mailing list 사용법

핵심 kernel developer 대부분은 Linux Kernel Mailing List에 참여한다. 구독과 구독 해제 방법은 subspace.kernel.org의 안내에서 확인할 수 있다. Mailing list archive는 여러 web site에 있으며 search engine으로 찾을 수 있다. 대표적인 archive는 lore.kernel.org/linux-kernel이다.

List에 주제를 올리기 전에 관련 archive를 검색하는 것이 매우 권장된다. 이미 자세히 논의됐지만 mailing list archive에만 기록된 내용이 많다. Kernel subsystem 대부분은 별도의 development mailing list를 가지며 각 list는 MAINTAINERS file에서 확인할 수 있다. 여러 list가 kernel.org에 hosting되고 그 정보는 subspace.kernel.org에 있다.

Mailing list에서는 올바른 대화 습관을 지켜야 한다. 여러 사람이 답장하면 CC 수신자 목록이 상당히 길어질 수 있다. 정당한 이유 없이 CC에서 사람을 빼거나 list 주소에만 답장하지 않는다. 보낸 사람에게서 온 mail과 list를 거친 mail을 두 번 받는 것에 익숙해져야 하며, 복잡한 mail header를 추가해 이를 조정하려 하면 다른 참여자가 좋아하지 않는다.

답장의 문맥과 인용 주체를 그대로 유지한다. 답장 위쪽의 “John Kernelhacker wrote ...:” 같은 line을 남겨 두고, mail 맨 위에 답을 몰아 쓰지 말고 인용한 개별 구간 사이에 자신의 설명을 적는다.

Mail에 patch를 넣을 때는 Documentation/process/submitting-patches.rst가 요구하는 읽을 수 있는 plain text로 보낸다. Kernel developer는 attachment나 compressed patch를 다루고 싶어 하지 않는다. Patch의 개별 line에 comment하려면 plain text가 필요하다.

Space와 tab 문자를 훼손하지 않는 mail program을 사용해야 한다. 좋은 첫 test는 자신에게 mail을 보낸 뒤 그 mail의 patch를 직접 적용해 보는 것이다. 적용되지 않으면 제대로 될 때까지 mail program 설정을 고치거나 program을 바꾼다. 무엇보다 다른 subscriber를 존중해야 한다.

• Kernel mailing list subscriptionhttps://subspace.kernel.org/subscribing.html
• Linux-kernel archivehttps://lore.kernel.org/linux-kernel/
• Kernel mailing listshttps://subspace.kernel.org
• Mailing list etiquettehttps://subspace.kernel.org/etiquette.html

Community review와 대응

Kernel community의 목표는 가능한 한 최고의 kernel을 만드는 것이다. 받아들여 달라고 제출한 patch는 기술적 가치만을 기준으로 review된다. 제출자는 criticism, comment, 변경 요청, 근거 설명 요청 또는 아무 답도 없는 silence를 예상해야 한다.

이는 patch를 kernel에 넣는 과정의 일부다. Patch에 대한 비판과 comment를 받아들이고 기술적 관점에서 평가한 뒤 patch를 다시 고치거나, 요청된 변경을 하지 않아야 하는 이유를 명확하고 간결하게 설명할 수 있어야 한다.

게시물에 답이 없으면 며칠 기다렸다가 다시 시도한다. 엄청난 mail 양 때문에 누락되는 경우가 있다. 반대로 patch가 아무 질문 없이 받아들여질 것이라고 기대하거나, 방어적으로 반응하거나, comment를 무시하거나, 요청된 변경을 하나도 반영하지 않은 채 같은 patch를 다시 제출해서는 안 된다.

최선의 기술적 해법을 찾는 community에서는 patch가 얼마나 유익한지를 두고 언제나 다른 의견이 나올 수 있다. 협력적인 태도를 유지하고 자신의 idea가 kernel에 맞도록 조정할 의지가 있어야 하며, 최소한 그 idea가 가치 있음을 입증할 준비가 되어 있어야 한다. 틀리는 것 자체는 괜찮다. 올바른 해법을 향해 함께 일하려는 자세가 중요하다.

첫 patch에 대한 답장이 고쳐야 할 사항 열두 개를 나열하는 것뿐이어도 정상이다. 이는 patch가 받아들여지지 않는다는 뜻도 아니고 개인을 공격하려는 뜻도 아니다. 지적된 문제를 모두 고친 뒤 patch를 다시 보내면 된다.

Kernel community와 기업 조직의 차이

Kernel community는 전통적인 기업 개발 환경 대부분과 다르게 움직인다. 제안하는 변경을 설명할 때 좋은 표현은 여러 문제를 해결한다는 점, code 2,000줄을 삭제한다는 점, 설명하려는 내용을 보여 주는 patch가 있다는 점, 서로 다른 architecture 5개에서 test했다는 점, 작은 patch의 series라는 점, 일반적인 machine에서 performance를 높인다는 점처럼 기술적 결과와 검증 가능성을 드러낸다.

반대로 “AIX/ptx/Solaris에서 이렇게 했으니 좋은 방식이다”, “이 일을 20년 했다”, “우리 회사가 돈을 벌려면 필요하다”, “Enterprise product line을 위한 것이다”, “idea를 설명하는 1,000 page design document가 있다”, “6개월 동안 작업했다”, “5,000 line patch다”, “현재의 엉망인 부분을 전부 다시 작성했다”, “deadline 때문에 지금 적용해야 한다” 같은 말은 피해야 한다. 경력, 조직 사정, 투입 시간이나 큰 문서보다 code와 기술적 근거가 판단 기준이다.

Kernel community의 또 다른 차이는 서로 얼굴을 보지 않는 상호 작용이다. 문서는 email과 IRC가 주된 communication 방식이어서 성별이나 인종에 따른 차별이 줄어드는 이점이 있다고 설명한다. 참여자는 email address로 보이고, 국제적인 환경에서는 이름만으로 성별을 추측하기도 어렵다. Linux kernel에서 일한 뒤 의견을 밝힌 여성 대부분은 긍정적인 경험을 했다고 문서는 기록한다.

영어가 편하지 않은 사람에게는 language barrier가 문제가 될 수 있다. Mailing list에서 idea를 정확히 전달하려면 영어를 잘 이해해야 할 수 있으므로, 보내기 전에 email의 영어 문장이 의미가 통하는지 확인하는 것이 권장된다.

변경을 작은 patch로 나누기

Linux kernel community는 큰 code 덩어리를 한 번에 던져 넣는 방식을 반기지 않는다. 변경을 제대로 소개하고 논의하며 작고 독립적인 부분으로 나눠야 한다. 이는 기업에서 흔히 쓰는 방식과 거의 정반대다.

제안은 development process의 매우 이른 시점에 소개해야 작업 방향에 관한 feedback을 받을 수 있다. Community도 기능을 내다 버리듯 넘기는 것이 아니라 자신들과 함께 개발한다고 느낄 수 있다. 그렇다고 mailing list에 한 번에 email 50개를 보내서는 안 되며, 거의 언제나 patch series는 그보다 작아야 한다.

첫 번째 분할 이유는 작은 patch일수록 정확성을 검증하는 데 시간과 노력이 적게 들어 적용될 가능성이 커지기 때문이다. 5 line patch는 maintainer가 거의 한 번만 보고 적용할 수 있지만 500 line patch의 정확성을 review하는 데는 몇 시간이 걸릴 수 있다. Review 시간은 patch 크기에 지수적으로 비례한다고 표현할 정도다.

작은 patch는 문제가 생겼을 때 debug하기도 쉽다. 적용한 뒤 무언가를 깨뜨린 거대한 patch를 해부하는 것보다 patch를 하나씩 되돌리는 편이 훨씬 쉽다.

두 번째로, patch를 작게 보낼 뿐 아니라 제출 전에 다시 작성하고 단순화하거나 순서를 재배치하는 작업도 중요하다.

우아한 해법을 제시하는 일과 unfinished work를 community와 함께 논의하는 일 사이에서 균형을 잡기는 어렵다. 따라서 이른 시점에 feedback을 받아 작업을 개선하되, 전체 과제가 아직 merge할 상태가 아니더라도 완성된 작은 변경은 먼저 받아들여질 수 있도록 나눈다.

아직 완성되지 않았고 나중에 고치겠다는 patch를 inclusion 대상으로 보내는 것은 허용되지 않는다.

변경이 필요한 이유를 입증하기

Patch를 나누는 것과 함께 Linux community가 이 변경을 추가해야 하는 이유를 알리는 일도 매우 중요하다. 새 기능은 필요하고 유용하다는 근거를 제시해야 한다.

변경 내용을 기록하기

Patch를 보낼 때 email 본문에 무엇을 쓰는지 특별히 주의해야 한다. 이 정보는 patch의 ChangeLog가 되어 모든 사람이 영구히 볼 수 있도록 보존된다. Patch를 완전하게 설명해야 하며 변경이 필요한 이유, patch의 전체 design approach, implementation detail, testing result를 포함해야 한다.

정확한 형식에 관한 자세한 내용은 “The Perfect Patch”의 ChangeLog section을 참고한다.

• The Perfect Patchhttps://www.ozlabs.org/~akpm/stuff/tpp.txt

이 모든 일을 잘하기는 때때로 매우 어렵다. 이런 practice를 완성하는 데는 여러 해가 걸릴 수 있고 끝내 완벽해지지 않을 수도 있다. 많은 인내와 결단이 필요한 지속적인 개선 과정이다. 그러나 포기할 필요는 없다. 앞선 많은 사람도 해냈고 모두 지금의 입문자와 정확히 같은 자리에서 시작했다.

감사의 말과 maintainer

Paolo Ciarrocchi는 자신이 작성한 글을 바탕으로 “Development Process” section을 구성하도록 허락했다. Randy Dunlap과 Gerrit Huizenga는 말해야 할 것과 말하지 않아야 할 것의 목록 일부에 기여했다.

Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael Kerrisk, Alex Shepard에게 review, comment, contribution에 대해 감사를 전한다. 이들의 도움이 없었다면 문서는 만들어질 수 없었다.

• Development Process 원문https://lwn.net/Articles/94386/

Maintainer: Greg Kroah-Hartman <[email protected]>