Linux kernel 개발 방법

번역 고지와 문서 목적

이 문서는 GPL-2.0 라이선스를 사용하며 Tsugikazu Shibata가 처음 기여했습니다. 제목은 'Linux kernel 개발 방법'입니다.

번역 주: 이 문서는 `Documentation/process/howto.rst`의 일본어 번역입니다. 면책 조건은 `translations_ja_JP_disclaimer`가 가리키는 일본어 발췌 면책 조항과 `translations_disclaimer`가 가리키는 영어판 Disclaimer를 확인해야 합니다.

이 문서는 Linux kernel developer가 되는 방법과 Linux kernel development community에서 함께 일하는 방법을 폭넓게 안내합니다. Kernel programming의 기술 세부 사항 자체는 다루지 않지만 올바른 학습 방향을 제시합니다.

내용이 오래되었다면 문서 끝에 적힌 maintainer에게 갱신 patch를 보내야 합니다.

.. SPDX-License-Identifier: GPL-2.0

.. Originally contributed by Tsugikazu Shibata

Linux カーネル開発のやり方
==========================

.. note:: 【訳註】
   この文書は、
   Documentation/process/howto.rst
   の翻訳です。
   免責条項については、
   :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、
   :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。

これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した
ドキュメントです。ここには Linux カーネル開発者になるための方法とLinux
カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。
カーネルプログラミングに関する技術的な項目に関することは何も含めないよ
うにしていますが、カーネル開発者となるための正しい方向に向かう手助けに
なります。

もし、このドキュメントのどこかが古くなっていた場合には、このドキュメント
の最後にリストしたメンテナにパッチを送ってください。

시작에 필요한 지식과 태도

Kernel developer가 되고 싶거나 관리자로부터 특정 device의 Linux driver를 작성하라는 지시를 받았다면, 이 문서는 필요한 절차와 community에서 협업하는 요령을 설명합니다. 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을 따르면서 표준에 없는 여러 extension도 활용합니다. Standard C library에 의존하지 않는 freestanding C environment이므로 C 표준의 일부는 지원하지 않으며, 임의의 `long long` division과 floating point 연산도 사용할 수 없습니다.

Toolchain 전제와 GNU C extension을 모두 설명하는 결정적 참고 자료는 없으므로 `info gcc`를 확인해야 합니다.

info gcc

목표는 기존 development community와 일하는 방법을 배우는 것입니다. 이 다양하고 지리적으로 분산된 대규모 팀은 coding, style, procedure에 높은 기준을 두며, 기준은 오랜 경험으로 형성되고 문서화되어 있습니다. 다른 개발자들이 자신이나 자기 회사의 방식에 맞춰 줄 것이라 기대하지 말고 먼저 기준을 익혀야 합니다.

はじめに
---------

あなたは Linux カーネルの開発者になる方法を学びたいのでしょうか？　そ
れとも上司から「このデバイスの Linux ドライバを書くように」と言われた
のかもしれません。この文書の目的は、あなたが踏むべき手順と、コミュニティ
と一緒にうまく働くヒントを書き下すことで、あなたが知るべき全てのことを
教えることです。また、このコミュニティがなぜ今うまくまわっているのかと
いう理由も説明しようと試みています。

カーネルは少量のアーキテクチャ依存部分がアセンブリ言語で書かれている以
外の大部分は C 言語で書かれています。C言語をよく理解していることはカー
ネル開発に必要です。低レベルのアーキテクチャ開発をするのでなければ、
(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要ありません。以下
の本は、C 言語の十分な知識や何年もの経験に取って代わるものではありませ
んが、少なくともリファレンスとしては良い本です。

 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
 - 『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
 - "Practical C Programming" by Steve Oualline [O'Reilly]
 - 『C実践プログラミング第3版』(Steve Oualline著 望月康司監訳 谷口功訳) [オライリージャパン]
 - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]
 - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク]

カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル
は ISO C11 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って
います。カーネルは標準 C ライブラリに依存しない、C 言語非依存環境です。
そのため、C の標準の中で使えないものもあります。特に任意の long long
の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張
に置いている前提がどうなっているのかわかりにくいことが時々あり、また、
残念なことに決定的なリファレンスは存在しません。情報を得るには、gcc の
info ページ( info gcc )を見てください。

あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
とに思い出してください。そのコミュニティは、コーディング、スタイル、開
発手順について高度な標準を持つ、多様な人の集まりです。地理的に分散した
大規模なチームに対してもっともうまくいくとわかったことをベースにしなが
ら、これらの標準は長い時間をかけて築かれてきました。これらはきちんと文
書化されていますから、事前にこれらの標準について事前にできるだけたくさ
ん学んでください。また皆があなたやあなたの会社のやり方に合わせてくれる
と思わないでください。

법률과 license

Linux kernel source code는 GPL license로 공개됩니다. 정확한 조건은 source tree 최상위의 `COPYING`을 확인합니다. Kernel licensing rule과 source의 SPDX identifier 사용법은 `Documentation/process/license-rules.rst`에 설명되어 있습니다.

License에 관한 추가 질문은 Linux Kernel mailing list가 아니라 법률 전문가에게 문의해야 합니다. Mailing list 참여자는 변호사가 아니므로 그들의 법률 관련 발언에 의존해서는 안 됩니다.

GPL의 일반적인 질문과 답변은 `https://www.gnu.org/licenses/gpl-faq.html`에서 확인할 수 있습니다.

法的問題
--------

Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
す。ソースツリーのメインディレクトリにある COPYING のファイルを見てく
ださい。Linux カーネルのライセンスルールとソースコード内の
`SPDX <https://spdx.org/>`_ 識別子の使い方は
:ref:`Documentation/process/license-rules.rst <kernel_licensing>`
に説明されています。

もしライセンスについてさらに質問があれば、
Linux Kernel メーリングリストに質問するのではなく、どうぞ
法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
問題については彼らの声明はあてにするべきではありません。

GPL に関する共通の質問や回答については、以下を参照してください-

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

Source tree의 필독 문서

Linux kernel source tree에는 kernel community와 소통하는 방법을 익히는 데 매우 유용한 문서가 폭넓게 들어 있습니다. 새 기능을 추가할 때는 그 기능의 사용법을 설명하는 새 documentation file도 함께 추가하는 것이 좋습니다.

Kernel 변경이 userspace에 공개되는 interface를 바꾼다면 설명 자료나 manual page patch를 manual page maintainer `[email protected]`에게 보내고 `[email protected]`를 CC하는 것이 좋습니다.

먼저 읽어야 할 source tree 문서는 다음과 같습니다.

• `Documentation/admin-guide/README.rst`: kernel 배경과 configure/build의 기본 절차. 입문자는 여기서 시작합니다.
• `Documentation/process/changes.rst`: kernel build와 실행에 필요한 software package의 최소 version 목록.
• `Documentation/process/coding-style.rst`: Linux kernel coding style과 그 근거. 새 code는 이 지침을 따라야 합니다.
• `Documentation/process/submitting-patches.rst`: patch 작성과 전송, email 내용·형식·수신자 선택. 규칙을 지켜도 성공이 보장되지는 않지만 어기면 거의 확실히 실패합니다.
• `Documentation/process/stable-api-nonsense.rst`: kernel 내부 stable API를 두지 않는 이유, compatibility layer, OS 간 driver portability, 빠른 source 변화에 관한 철학.
• `Documentation/process/security-bugs.rst`: security problem을 kernel developer에게 알리고 해결을 돕는 절차.
• `Documentation/process/management-style.rst`: maintainer의 작업 방식과 공통 ethos를 설명해 독특한 행동에 관한 오해를 줄입니다.
• `Documentation/process/stable-kernel-rules.rst`: stable kernel release 규칙과 stable release에 변경을 넣는 방법.
• `Documentation/process/kernel-docs.rst`: kernel development와 관련된 외부 documentation 목록.
• `Documentation/process/applying-patches.rst`: patch의 의미와 여러 development branch에 적용하는 방법의 입문서.

Patch 작성법을 더 설명하는 자료로 `The Perfect Patch`와 보관된 `Linux kernel patch submission format` 문서가 제시됩니다. URL은 원문에 그대로 보존됩니다.

ドキュメント
------------

Linux カーネルソースツリーは幅広い範囲のドキュメントを含んでおり、それ
らはカーネルコミュニティと会話する方法を学ぶのに非常に貴重なものです。
新しい機能がカーネルに追加される場合、その機能の使い方について説明した
新しいドキュメントファイルも追加することを勧めます。
カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
をマニュアルページのメンテナ [email protected] に送り、CC を
[email protected] に送ることを勧めます。

以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
す-

  :ref:`Documentation/admin-guide/README.rst <readme>`
    このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
    configure )し、生成(訳注 build )するために必要なことは何かが書かれ
    ています。 カーネルに関して初めての人はここからスタートすると良い
    でしょう。

  :ref:`Documentation/process/changes.rst <changes>`
    このファイルはカーネルをうまく生成(訳注 build )し、走らせるのに最
    小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい
    ます。

  :ref:`Documentation/process/coding-style.rst <codingstyle>`
    これは Linux カーネルのコーディングスタイルと背景にある理由を記述
    しています。全ての新しいコードはこのドキュメントにあるガイドライン
    に従っていることを期待されています。大部分のメンテナはこれらのルー
    ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
    だけをレビューします。

  :ref:`Documentation/process/submitting-patches.rst <codingstyle>`
    このファイルには、どうやってうまくパッチを作って投稿するかにつ
    いて非常に詳しく書かれており、以下を含みます (これだけに限らない
    けれども)

      - Email に含むこと
      - Email の形式
      - だれに送るか

    これらのルールに従えばうまくいくことを保証することではありません
    が (すべてのパッチは内容とスタイルについて精査を受けるので)、
    ルールに従わなければ間違いなくうまくいかないでしょう。

    この他にパッチを作る方法についてのよくできた記述は-

       "The Perfect Patch"
		https://www.ozlabs.org/~akpm/stuff/tpp.txt

       "Linux kernel patch submission format"
		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html

  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
    このファイルはカーネルの中に不変の API を持たないことにした意識的
    な決断の背景にある理由について書かれています。以下のようなことを含
    んでいます-

      - サブシステムとの間に層を作ること(コンパチビリティのため?)
      - オペレーティングシステム間のドライバの移植性
      - カーネルソースツリーの素早い変更を遅らせる(もしくは素早い変更を妨げる)

    このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
    そして、他のOSでの開発者が Linux に移る時にとても重要です。

  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
    もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
    のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
    支援してください。

  :ref:`Documentation/process/management-style.rst <managementstyle>`
    このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
    彼らの手法の背景にある共有されている精神について記述しています。こ
    れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
    重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
    行動についての多くの誤解や混乱を解消するからです。

  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
    このファイルはどのように stable カーネルのリリースが行われるかのルー
    ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
    り入れてもらいたい場合に何をすれば良いかが示されています。

  :Ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
    カーネル開発に付随する外部ドキュメントのリストです。もしあなたが探
    しているものがカーネル内のドキュメントでみつからなかった場合、この
    リストをあたってみてください。

  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
    パッチとはなにか、パッチをどうやって様々なカーネルの開発ブランチに
    適用するのかについて正確に記述した良い入門書です。

Documentation build

Kernel에는 source code 자체와 이 문서 같은 ReStructuredText(ReST) markup에서 자동 생성하는 문서가 많습니다. In-kernel API의 전체 설명과 올바른 locking 규칙도 포함됩니다.

Kernel source 최상위에서 다음 명령으로 PDF와 HTML 문서를 만듭니다.

make pdfdocs
make htmldocs

ReST 문서는 `Documentation/output`에 생성됩니다. LaTeX와 ePub 형식은 다음 명령으로 만듭니다.

make latexdocs
make epubdocs

カーネルはソースコードそのものや、このファイルのようなリストラクチャー
ドテキストマークアップ(ReST)から自動的に生成可能な多数のドキュメントを
もっています。これにはカーネル内APIの完全な記述や、正しくロックをかけ
るための規則などが含まれます。

これら全てのドキュメントを PDF や HTML で生成するには以下を実行します - ::

        make pdfdocs
        make htmldocs

それぞれメインカーネルのソースディレクトリから実行します。

ReSTマークアップを使ったドキュメントは Documentation/outputに生成され
ます。Latex とePub 形式で生成するには - ::

        make latexdocs
        make epubdocs

Kernel developer가 되는 첫 단계

Linux kernel development를 전혀 모른다면 `https://kernelnewbies.org`의 KernelNewbies project부터 살펴봅니다. 기본 질문을 할 수 있는 mailing list가 있지만 이미 답변된 질문을 반복하지 않도록 archive를 먼저 검색해야 합니다.

이 project에는 실시간 질문을 위한 IRC channel과 학습 자료가 있으며, website는 code organization, subsystem, tree 안팎의 project, kernel compile과 patch 적용 같은 기초도 설명합니다.

무엇부터 할지 모르지만 community의 첫 작업을 찾는다면 `https://kernelnewbies.org/KernelJanitors`를 방문합니다. Source tree에서 정리하거나 고칠 단순한 문제를 해결하며 patch를 kernel tree에 넣는 기본 절차를 배울 수 있습니다.

실제 code를 수정하기 전에 동작 방식을 이해해야 합니다. 가장 좋은 방법은 source를 직접 읽는 것이며 까다로운 부분에는 대체로 comment가 있습니다. `https://elixir.bootlin.com/`의 cross-reference는 최신 kernel source를 상호 참조 가능한 indexed web 형태로 보여 줍니다.

カーネル開発者になるには
------------------------

もしあなたが、Linux カーネル開発について何も知らないのならば、
KernelNewbies プロジェクトを見るべきです

	https://kernelnewbies.org

このサイトには役に立つメーリングリストがあり、基本的なカーネル開発に関
するほとんどどんな種類の質問もできます (既に回答されているようなことを
聞く前にまずはアーカイブを調べてください)。またここには、リアルタイム
で質問を聞くことができる IRC チャネルや、Linuxカーネルの開発に関して学
ぶのに便利なたくさんの役に立つドキュメントがあります。

Web サイトには、コードの構成、サブシステム、現在存在するプロジェクト
(ツリーにあるもの無いものの両方)の基本的な管理情報があります。ここには、
また、カーネルのコンパイルのやり方やパッチの当て方などの間接的な基本情
報も記述されています。

あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
ニティに参加して何かすることをさがしているのであれば、Linux kernel
Janitor's プロジェクトにいけば良いでしょう -

        https://kernelnewbies.org/KernelJanitors

ここはそのようなスタートをするのにうってつけの場所です。ここには、
Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
らない、単純な問題のリストが記述されています。このプロジェクトに関わる
開発者と一緒に作業することで、あなたのパッチを Linuxカーネルツリーに入
れるための基礎を学ぶことができ、そしてもしあなたがまだアイディアを持っ
ていない場合には、次にやる仕事の方向性が見えてくるかもしれません。

実際に Linux カーネルのコードについて修正を加える前に、どうやってその
コードが動作するのかを理解することが必要です。そのためには、特別なツー
ルの助けを借りてでも、それを直接よく読むことが最良の方法です(ほとんど
のトリッキーな部分は十分にコメントしてありますから)。そういうツールで
特におすすめなのは、Linux クロスリファレンスプロジェクトです。これは、
自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
ます -

	https://elixir.bootlin.com/

Development branch 개요

Linux kernel development process는 역할이 다른 주요 kernel branch와 여러 subsystem별 branch로 구성됩니다.

• Linus의 mainline tree
• 여러 major version에 걸친 stable tree
• Subsystem별 kernel tree
• Integration test용 linux-next tree

開発プロセス
------------

Linux カーネルの開発プロセスは現在幾つかの異なるメインカーネル「ブラン
チ」と多数のサブシステム毎のカーネルブランチから構成されます。これらの
ブランチとは -

  - Linus のメインラインツリー
  - メジャー番号をまたぐ数本の安定版ツリー
  - サブシステム毎のカーネルツリー
  - 統合テストのための linux-next カーネルツリー

Mainline tree와 release candidate

Mainline tree는 Linus Torvalds가 관리하며 `https://kernel.org`의 repository에 있습니다.

• 새 kernel release 직후 2주간 merge window가 열립니다. Maintainer는 보통 linux-next에서 여러 주 검증된 큰 변경을 Linus에게 보내며, 큰 변경에는 git을 선호하지만 patch file도 허용됩니다.
• 2주 뒤 `-rc1`이 release되면 목표가 kernel 안정화로 바뀝니다. 대부분의 patch는 regression을 고쳐야 하며 오래된 bug fix는 중요할 때만 넣습니다. 독립적인 새 driver나 filesystem은 외부 영역에 영향을 주지 않으면 `-rc1` 뒤에도 받을 수 있습니다.
• Linus가 현재 git tree를 test하기에 충분히 안정적이라고 판단할 때 새 `-rc`를 release합니다. 목표 주기는 매주 한 번입니다.
• Kernel이 준비되었다고 판단될 때까지 반복하며 보통 약 6주가 걸립니다.

Andrew Morton은 release 시점이 사전 일정이 아니라 실제로 관찰된 bug 상태에 따라 결정되므로 언제 release될지 아무도 모른다고 설명했습니다.

メインラインツリー
~~~~~~~~~~~~~~~~~~

メインラインツリーは Linus Torvalds によってメンテナンスされ、
https://kernel.org のリポジトリに存在します。
この開発プロセスは以下のとおり -

  - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
    この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
    このような差分は通常 linux-next カーネルに数週間含まれてきたパッチです。
    大きな変更は git(カーネルのソース管理ツール、詳細は
    http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ
    チファイルの形式のまま送るのでも十分です。
  - 2週間後 -rc1 カーネルがリリースされ、新しいカーネルを可能な限り堅牢に
    することに焦点が移ります。この期間のパッチのほとんどは退行を修正する
    ものとなります。以前から存在していたバグは退行には当たらないため、
    送るのは重要な修正だけにしてください。
    新しいドライバ (もしくはファイルシステム) のパッチは
    -rc1 の後で受け付けられることもあることを覚えておいてください。な
    ぜなら、変更が独立していて、追加されたコードの外の領域に影響を与え
    ない限り、退行のリスクは無いからです。-rc1 がリリースされた後、
    Linus へパッチを送付するのに git を使うこともできますが、パッチは
    レビューのために、パブリックなメーリングリストへも同時に送る必要が
    あります。
  - 新しい -rc は Linus が、最新の git ツリーがテスト目的であれば十分
    に安定した状態にあると判断したときにリリースされます。目標は毎週新
    しい -rc カーネルをリリースすることです。
  - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
    す。このプロセスはだいたい 6週間継続します。

Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
て書いたことをここで言っておくことは価値があります -

        *「カーネルがいつリリースされるかは誰も知りません。なぜなら、
        これは現実に認識されたバグの状況によりリリースされるのであり、
        前もって決められた計画によってリリースされるものではないから
        です。」*

Major version별 stable tree

Version number가 세 부분인 kernel은 `-stable` kernel입니다. 앞의 두 version number가 나타내는 major mainline release에서 발견된 security problem과 중대한 regression을 고치는 작고 중요한 fix가 포함됩니다.

같은 major stable series의 각 release는 세 번째 version만 증가하고 앞의 두 값은 유지됩니다. Development 또는 experimental version test에는 참여하지 않으면서 최신 stable kernel을 쓰려는 사용자에게 권장됩니다.

Stable tree는 stable team `<[email protected]>`이 관리하고 필요에 따라 release합니다. 보통 약 2주 간격이지만 긴급한 문제가 없으면 더 길어질 수 있고 security 문제에는 대체로 즉시 대응합니다.

허용되는 변경 종류와 release process는 `Documentation/process/stable-kernel-rules.rst`에 설명되어 있습니다.

メジャー番号をまたぐ数本の安定版ツリー
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

バージョン番号が3つの数字に分かれているカーネルは -stable カーネルです。
これには最初の2つのバージョン番号の数字に対応した、
メジャーメインラインリリースで見つかったセキュリティ問題や
重大な後戻りに対する比較的小さい重要な修正が含まれます。

メジャー安定版シリーズのそれぞれのリリースは
バージョン番号の3番目を増加させ、最初の2つの番号は同じ値を保ちます。

これは、開発/実験的バージョンのテストに協力することに興味が無く、最新
の安定したカーネルを使いたいユーザに推奨するブランチです。

安定版ツリーは"stable" チーム <[email protected]> でメンテされており、
必要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差
し迫った問題がなければもう少し長くなることもあります。セキュリティ関
連の問題の場合はこれに対してだいたいの場合、すぐにリリースがされます。

カーネルツリーに入っている、
Documentation/process/stable-kernel-rules.rst ファイルにはどのような種
類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう
動くかが記述されています。

Subsystem별 kernel tree

각 subsystem maintainer와 많은 developer는 최신 개발 상태를 source repository로 공개합니다. 다른 사람도 각 영역의 진행 상황을 볼 수 있고, 빠르게 변하는 영역에서는 제출물과 진행 중 작업의 conflict를 피하려고 특정 subsystem tree를 base로 patch를 만들도록 요청받을 수 있습니다.

대부분 git tree지만 다른 SCM이나 quilt series 형태의 patch queue도 있습니다. Repository 주소는 `MAINTAINERS`에 있고 많은 tree를 `https://git.kernel.org/`에서 볼 수 있습니다.

Patch가 subsystem tree에 commit되기 전에는 mailing list에서 review합니다. 일부 subsystem은 patchwork로 게시된 patch, comment, revision을 추적하고 maintainer가 review 중·accepted·rejected 상태를 표시합니다. Site 목록은 `https://patchwork.kernel.org/`에 있습니다.

サブシステム毎のカーネルツリー
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
公開しています。そのため、自分とは異なる領域のカーネルで何が起きている
かを他の人が見られるようになっています。開発が早く進んでいる領域では、
開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問
されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。

大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
quilt シリーズとして公開されているパッチキューも使われています。これら
のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
ています。これらの多くは https://git.kernel.org/ で参照することができま
す。

提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
リングリストで事前にレビューにかけられます（以下の対応するセクションを
参照）。いくつかのカーネルサブシステムでは、このレビューは patchworkと
いうツールによって追跡されます。Patchwork は web インターフェイスによっ
てパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そしてメン
テナはパッチに対して、レビュー中、受付済み、拒否というようなマークをつ
けることができます。大部分のこれらの patchwork のサイトは
https://patchwork.kernel.org/ でリストされています。

linux-next integration test

Subsystem tree 변경을 mainline에 merge하기 전에는 integration test가 필요합니다. 이를 위해 거의 모든 subsystem tree에서 거의 매일 pull하는 전용 test repository `https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git`가 있습니다.

linux-next는 다음 merge window에 mainline으로 들어갈 내용을 미리 보여 줍니다. 이를 실제로 실행해 test하는 적극적인 tester의 참여는 매우 환영받습니다.

統合テストのための linux-next カーネルツリー
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

サブシステムツリーの更新内容がメインラインツリーにマージされる
前に、それらは統合テストされる必要があります。この目的のため、実質的に
全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリポジ
トリが存在します-

       https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

このやり方によって、linux-next は次のマージ機会でどんなものがメイン
ラインにマージされるか、おおまかな展望を提供します。
linux-next の実行テストを行う冒険好きなテスターは大いに歓迎されます。

Kernel bug 보고

Source tree 최상위의 `Documentation/admin-guide/reporting-issues.rst`는 kernel bug로 보이는 문제를 보고하는 방법과 kernel developer가 원인을 추적하는 데 필요한 정보를 자세히 설명합니다.

バグレポート
-------------

メインカーネルソースディレクトリにあるファイル
'Documentation/admin-guide/reporting-issues.rst'
は、カーネルバグらしきものの報告の仕方、および、カーネル開発者が問題を
追跡する際の手がかりとなる情報についての詳細を説明しています。

보고된 bug를 고치는 연습

다른 사람이 보고한 bug를 고치는 것은 kernel hacking 실력을 기르는 가장 좋은 방법 중 하나입니다. Kernel 안정화에 기여하면서 실제 문제 해결 능력을 키우고 다른 developer에게 자신의 존재와 성과도 알릴 수 있습니다.

관심 있는 subsystem을 정한 뒤 `MAINTAINERS`에서 해당 subsystem의 bug 보고 위치를 찾습니다. 대개 mailing list이고 드물게 bug tracker입니다. Archive에서 최근 보고를 검색해 해결 가능한 문제를 돕습니다.

`https://bugzilla.kernel.org`도 일부 subsystem과 kernel 전체에 관한 bug의 등록·추적에 사용됩니다.

バグレポートの管理
-------------------

あなたのハッキングのスキルを訓練する最高の方法のひとつに、他人がレポー
トしたバグを修正することがあります。あなたがカーネルをより安定化させる
こに寄与するということだけでなく、あなたは 現実の問題を修正することを
学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつきま
す。バグを修正することは、多くの開発者の中から自分が功績をあげる最善の
道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好まな
いからです。

すでにレポートされたバグの作業をするためには、興味のあるサブシステムを
見つけ、そのサブシステムのバグの報告先 (多くの場合メーリングリスト、
稀にバグトラッカー) を MAINTAINERS ファイルで調べてください。
そのアーカイブで最近の報告を検索し、できそうなものに力を貸してください。
https://bugzilla.kernel.org でバグ報告を調べようとする人もいるでしょう。
これは限られた一部のサブシステムのバグ報告と追跡に利用されるとともに、
とりわけ、カーネル全体に対するバグの登録先となっています。

Mailing list 사용법

많은 core kernel developer가 Linux kernel mailing list에 참여합니다. 구독과 탈퇴 방법은 `https://subspace.kernel.org/subscribing.html`에 있습니다.

Archive는 여러 web site에 있으며 대표적으로 `https://lore.kernel.org/linux-kernel/`가 있습니다. 게시 전에 같은 주제가 이미 논의되었는지 검색해야 합니다. 많은 내용이 archive에만 상세히 남아 있습니다.

대부분의 subsystem에도 자체 development mailing list가 있습니다. 각 group의 list는 `MAINTAINERS`에서 확인하며, kernel.org가 호스팅하는 list 정보는 `https://subspace.kernel.org`에 있습니다.

Mailing list에서는 좋은 행동 규칙을 따라야 합니다. 간단한 지침은 `https://subspace.kernel.org/etiquette.html`에 있습니다.

여러 사람이 답하면 CC 목록이 길어질 수 있습니다. 정당한 이유 없이 수신자를 CC에서 빼거나 mailing list 주소에만 답하지 말아야 합니다. 발신자와 list에서 같은 mail을 두 번 받더라도 header trick으로 이를 바꾸려 하지 않습니다.

이전 대화와 자신의 발언을 보존하고 `John Kernelhacker wrote ...:` 같은 인용 표식을 둔 뒤, 답변은 mail 맨 위가 아니라 관련 인용문 사이에 삽입합니다.

Patch를 mail로 보낼 때는 `Documentation/process/submitting-patches.rst`에 따라 plain readable text로 보냅니다. Attachment나 압축 patch는 줄별 comment가 어렵습니다. Mail client가 whitespace와 tab을 손상하지 않는지 자신에게 먼저 보내 다시 적용해 보는 test가 좋습니다.

무엇보다 다른 구독자를 존중해야 합니다.

メーリングリスト
----------------

上のいくつかのドキュメントで述べていますが、コアカーネル開発者の大部分
は Linux kernel メーリングリストに参加しています。このリストの登録/脱
退の方法については以下を参照してください-

	https://subspace.kernel.org/subscribing.html

このメーリングリストのアーカイブは web 上の多数の場所に存在します。こ
れらのアーカイブを探すにはサーチエンジンを使いましょう。例えば-

	https://lore.kernel.org/linux-kernel/

リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索
することを是非やってください。多数の事がすでに詳細に渡って議論されてお
り、アーカイブにのみ記録されています。

大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリス
トを持っています。個々のグループがどんなリストを持っているかは、
MAINTAINERS ファイルにリストがありますので参照してください。

多くのリストは kernel.org でホストされています。これらの情報は以下にあ
ります -

	https://subspace.kernel.org

メーリングリストを使う場合、良い行動習慣に従うようにしましょう。少し安っ
ぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合のシンプル
なガイドラインを示しています -

	https://subspace.kernel.org/etiquette.html

もし複数の人があなたのメールに返事をした場合、CC: で受ける人のリストは
だいぶ多くなるでしょう。正当な理由がない限り、CC: リストから誰かを削除
をしないように、また、メーリングリストのアドレスだけにリプライすること
のないようにしましょう。1つは送信者から、もう1つはリストからのように、
メールを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追
加してこの状態を変えようとしないように。人々はそのようなことは好みませ
ん。

今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
"John Kernelhacker wrote ...:" の行をあなたのリプライの先頭行にして、
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
す。

もしパッチをメールに付ける場合は、
Documentation/process/submitting-patches.rst に提示されているように、そ
れは プレーンな可読テキストにすることを忘れないようにしましょう。カー
ネル開発者は 添付や圧縮したパッチを扱いたがりません。彼らはあなたのパッ
チの行毎にコメントを入れたいので、そうするしかありません。あなたのメー
ルプログラムが空白やタブを圧縮しないように確認しましょう。最初の良いテ
ストとしては、自分にメールを送ってみて、そのパッチを自分で当ててみるこ
とです。もしそれがうまく行かないなら、あなたのメールプログラムを直して
もらうか、正しく動くように変えるべきです。

何をおいても、他の購読者に対する敬意を表すことを忘れないでください。

Community review와 대응

Kernel community의 목표는 가능한 최고의 kernel을 만드는 것입니다. Patch는 기술적 merit로 review되며, 제출자는 비판·comment·변경 요청·정당성 증명 요구·침묵을 예상해야 합니다.

• 비판
• Comment
• 변경 요청
• Patch 정당성 증명 요구
• 응답 없음

비판과 comment를 기술적으로 평가해 patch를 다시 만들거나 변경하지 않아야 할 명확하고 간결한 이유를 제시합니다. 응답이 없으면 mail에 묻혔을 수 있으므로 며칠 기다렸다가 다시 게시합니다.

질문 없이 받아들여질 것이라 가정하거나, 방어적으로 굴거나, comment를 무시하거나, 요청된 변경 없이 같은 patch를 다시 보내서는 안 됩니다.

• 무조건 수락될 것이라 가정하지 않기
• 방어적으로 반응하지 않기
• Comment를 무시하지 않기
• 요청된 변경 없이 재전송하지 않기

최선의 기술 해법에 관해서는 의견이 다를 수 있습니다. 협력적으로 아이디어를 kernel에 맞추거나 적어도 그 가치를 입증해야 합니다. 올바른 해법으로 나아갈 의지가 있다면 실수는 허용됩니다.

첫 patch에 열두 개 정도의 수정 요청이 달리는 일은 흔합니다. 이는 patch나 제출자 자체에 반대한다는 뜻이 아니므로 지적된 문제를 모두 고쳐 재전송하면 됩니다.

コミュニティと共に働くこと
--------------------------

カーネルコミュニティのゴールは可能なかぎり最高のカーネルを提供すること
です。あなたがパッチを受け入れてもらうために投稿した場合、それは、技術
的メリットだけがレビューされます。その際、あなたは何を予想すべきでしょ
うか?

  - 批判
  - コメント
  - 変更の要求
  - パッチの正当性の証明要求
  - 沈黙

思い出してください、これはあなたのパッチをカーネルに入れる話です。あな
たは、あなたのパッチに対する批判とコメントを受け入れるべきで、それらを
技術的レベルで評価して、パッチを再作成するか、なぜそれらの変更をすべき
でないかを明確で簡潔な理由の説明を提供してください。もし、あなたのパッ
チに何も反応がない場合、たまにはメールの山に埋もれて見逃され、あなたの
投稿が忘れられてしまうこともあるので、数日待って再度投稿してください。

あなたがやるべきでないことは?

  - 質問なしにあなたのパッチが受け入れられると想像すること
  - 守りに入ること
  - コメントを無視すること
  - 要求された変更を何もしないでパッチを出し直すこと

可能な限り最高の技術的解決を求めているコミュニティでは、パッチがどのく
らい有益なのかについては常に異なる意見があります。あなたは協調的である
べきですし、また、あなたのアイディアをカーネルに対してうまく合わせるよ
うにすることが望まれています。もしくは、最低限あなたのアイディアがそれ
だけの価値があるとすすんで証明するようにしなければなりません。
正しい解決に向かって進もうという意志がある限り、間違うことがあっても許
容されることを忘れないでください。

あなたの最初のパッチに単に 1ダースもの修正を求めるリストの返答になるこ
とも普通のことです。これはあなたのパッチが受け入れられないということで
は **ありません**、そしてあなた自身に反対することを意味するのでも **あ
りません**。単に自分のパッチに対して指摘された問題を全て修正して再送す
れば良いのです。

Kernel community와 기업 문화의 차이

Kernel community는 전통적인 회사 개발 환경과 다르게 움직입니다. 제안을 설명할 때 문제 해결, code 삭제, 작은 patch series, 여러 architecture test, 일반적인 machine의 성능 향상처럼 기술적 근거를 앞세우는 표현이 효과적입니다.

• 이 변경은 여러 문제를 해결합니다.
• 이 변경은 code 2,000줄을 제거합니다.
• 다음 patch가 제 아이디어를 구체적으로 보여 줍니다.
• 서로 다른 architecture 다섯 개에서 test했습니다.
• 다음은 작은 patch로 나눈 series입니다.
• 일반적인 machine에서 성능을 향상시킵니다.

다른 OS가 그렇게 한다는 주장, 경력 연수, 회사의 수익이나 enterprise 제품 일정, 방대한 설계 문서, 이미 투입한 기간, 5,000줄짜리 단일 patch, 전면 재작성, deadline을 수락 근거로 내세우는 표현은 피해야 합니다.

• AIX/ptx/Solaris에서 했으니 Linux도 그렇게 해야 한다.
• 20년 동안 이 일을 했으므로 내 방식이 맞다.
• 회사 수익이나 enterprise 제품을 위해 필요하다.
• 1,000쪽 설계 문서 또는 5,000줄 patch이므로 받아야 한다.
• 6개월을 투자했거나 deadline이 있으니 즉시 merge해야 한다.
• 현재 code 전체를 다시 작성했다.

또 다른 차이는 주로 email과 IRC로 만나지 않고 소통한다는 점입니다. 원문은 email address 중심의 상호작용이 성별·민족·국적에 따른 선입견을 줄이고 여성과 소수자를 받아들이는 환경에 도움이 된다고 설명합니다. 일본어 번역 주는 Andrea와 Pat 같은 이름으로 성별을 추정하기 어렵다는 예를 풀이합니다.

반면 영어가 익숙하지 않은 사람에게 언어 장벽은 실제 문제입니다. Mailing list에서 아이디어를 정확히 교환할 수 있도록 보내기 전에 영어 표현이 의미를 제대로 전달하는지 점검하는 것이 좋습니다.

カーネルコミュニティと企業組織のちがい
-----------------------------------------------------------------

カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
動いています。以下は問題を避けるためにできると良いことのリストです。

  あなたの提案する変更について言うときのうまい言い方 -

    - "これは複数の問題を解決します"
    - "これは2000行のコードを削除します"
    - "以下のパッチは、私が言おうとしていることを説明するものです"
    - "私はこれを5つの異なるアーキテクチャでテストしたのですが..."
    - "以下は一連の小さなパッチ群ですが..."
    - "これは典型的なマシンでの性能を向上させます..."

  やめた方が良い悪い言い方 -

    - "このやり方で AIX/ptx/Solaris ではできたので、できるはずだ..."
    - "私はこれを20年もの間やってきた、だから..."
    - "これは私の会社が金儲けをするために必要だ"
    - "これは我々のエンタープライズ向け商品ラインのためである"
    - "これは私が自分のアイディアを記述した、1000ページの設計資料である"
    - "私はこれについて、6ケ月作業している..."
    - "以下は ... に関する5000行のパッチです"
    - "私は現在のぐちゃぐちゃを全部書き直した、それが以下です..."
    - "私は〆切がある、そのためこのパッチは今すぐ適用される必要がある"

カーネルコミュニティが大部分の伝統的なソフトウェアエンジニアリングの労
働環境と異なるもう一つの点は、やりとりに顔を合わせないということです。
email と irc を第一のコミュニケーションの形とする一つの利点は、性別や
民族の差別がないことです。Linux カーネルの職場環境は女性や少数民族を受
容します。なぜなら、email アドレスによってのみあなたが認識されるからで
す。
国際的な側面からも活動領域を均等にするようにします。なぜならば、あなた
は人の名前で性別を想像できないからです。ある男性が アンドレアという名
前で、女性の名前は パット かもしれません (訳注 Andrea は米国では女性、
それ以外(欧州など)では男性名として使われることが多い。同様に、Pat は
Patricia (主に女性名)や Patrick (主に男性名)の略称)。
Linux カーネルの活動をして、意見を表明したことがある大部分の女性は、前
向きな経験をもっています。

言葉の壁は英語が得意でない一部の人には問題になります。メーリングリスト
の中で、きちんとアイディアを交換するには、相当うまく英語を操れる必要が
あることもあります。そのため、自分のメールを送る前に英語で意味が通じて
いるかをチェックすることをお薦めします。

변경을 작은 patch로 나누기

Linux kernel community는 한 번에 거대한 code 덩어리를 받는 것을 좋아하지 않습니다. 변경을 정확히 설명하고 논의 가능한 작고 독립적인 부분으로 나눠야 합니다. 제안은 development process 초기에 공개해 feedback을 받고 community와 함께 개발한다는 신뢰를 만들어야 합니다. Mailing list에 한 번에 50개의 mail을 보내는 규모도 피합니다.

작은 patch는 maintainer가 정확성을 확인하는 시간과 노력을 줄여 적용 가능성을 높입니다. 5줄 patch는 빠르게 확인할 수 있지만 500줄 patch는 수시간이 걸릴 수 있고 review 시간은 규모에 따라 급격히 늘어납니다.

작은 patch는 문제 발생 시 debugging도 쉽습니다. Patch를 하나씩 제거하는 편이 거대한 patch 적용 뒤 무엇이 잘못되었는지 해부하는 것보다 훨씬 간단합니다.

단순히 작게 나누는 것만으로는 부족합니다. 보내기 전에 history를 다시 쓰거나 순서를 바꿔 최종 series를 간결하고 이해하기 쉽게 만들어야 합니다.

Al Viro의 비유에 따르면 수학 교사는 학생이 정답에 이르는 모든 시행착오가 아니라 간결한 최선의 풀이를 보고 싶어 합니다. Kernel maintainer와 reviewer도 문제 해결의 중간 사고 과정보다 단순하고 우아한 최종 해법을 원합니다.

초기에 미완성 작업을 논의해 feedback을 받는 일과 review 가능한 우아한 해법을 제출하는 일 사이에는 균형이 필요합니다. 변경을 작은 부분으로 나누면 전체가 완성되기 전에도 독립적인 부분부터 받아들일 수 있습니다.

다만 완성되지 않았거나 '나중에 고치겠다'는 patch를 mainline에 넣어 달라고 보내면 받아들여지지 않습니다.

変更を分割する
--------------

Linux カーネルコミュニティは、一度に大量のコードの塊を喜んで受容するこ
とはありません。変更は正確に説明される必要があり、議論され、小さい、個
別の部分に分割する必要があります。これはこれまで多くの会社がやり慣れて
きたことと全く正反対のことです。あなたのプロポーザルは、開発プロセスのと
ても早い段階から紹介されるべきです。そうすれば あなたは自分のやってい
ることにフィードバックを得られます。これは、コミュニティからみれば、あ
なたが彼らと一緒にやっているように感じられ、単にあなたの提案する機能の
ゴミ捨て場として使っているのではない、と感じられるでしょう。
しかし、一度に 50 もの email をメーリングリストに送りつけるようなことは
やってはいけません、あなたのパッチ群はいつもどんな時でもそれよりは小さ
くなければなりません。

パッチを分割する理由は以下 -

1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
   ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
   らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
   しかし、500行のパッチは、正しいことをレビューするのに数時間かかるか
   もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
   ます)

   小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
   チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
   かしくなった後で)解剖するのに比べればとても簡単です。

2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
   る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。

以下はカーネル開発者の Al Viro のたとえ話です -

        *"生徒の数学の宿題を採点する先生のことを考えてみてください、
        先生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでし
        ょう。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知っ
        ており、そして最終解の前の中間作業を提出することは決してないの
        です*

        *カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
        問題を解決する解の背後になる思考プロセスを見たいとは思いません。
        彼らは単純であざやかな解決方法を見たいのです。"*

あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
議論することのバランスをキープするのは難しいかもしれません。ですから、
開発プロセスの早期段階で改善のためのフィードバックをもらうようにするの
も良いですが、変更点を小さい部分に分割して全体ではまだ完成していない仕
事を(部分的に)取り込んでもらえるようにすることも良いことです。

また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
てもらうように送っても、それは受け付けられないことを理解してください。

변경의 필요성 입증

Patch를 나누는 것과 함께 왜 해당 변경을 추가해야 하는지 Linux community에 설명하는 일이 매우 중요합니다. 새 기능은 필요성과 유용성으로 정당화해야 합니다.

あなたの変更を正当化する
------------------------

あなたのパッチを分割するのと同時に、なぜその変更を追加しなければならな
いかを Linux コミュニティに知らせることはとても重要です。新機能は必要
性と有用性で正当化されなければなりません。

Patch와 ChangeLog 설명

Patch를 보낼 때 mail 본문에 쓰는 내용을 특별히 신경 써야 합니다. 이 정보는 patch의 ChangeLog로 사용되어 계속 보존되므로 변경을 완전하게 설명해야 합니다.

• 변경이 필요한 이유
• Patch 전체의 설계 접근법
• 구현 세부 사항
• Test 결과

좋은 ChangeLog의 자세한 형식은 원문이 연결한 `The Perfect Patch`의 ChangeLog section과 `https://www.ozlabs.org/~akpm/stuff/tpp.txt`를 참고합니다.

이 모든 원칙을 완벽하게 실천하는 데는 수년이 걸릴 수 있습니다. 지속적인 개선에는 인내와 결의가 필요하지만 이미 많은 사람이 같은 출발점에서 성공했으므로 포기하지 않아야 합니다.

あなたの変更を説明する
----------------------

あなたのパッチを送付する場合には、メールの中のテキストで何を言うかにつ
いて、特別に注意を払ってください。この情報はパッチの ChangeLog に使わ
れ、いつも皆がみられるように保管されます。これは次のような項目を含め、
パッチを完全に記述するべきです -

  - なぜ変更が必要か
  - パッチ全体の設計アプローチ
  - 実装の詳細
  - テスト結果

これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
ントの ChangeLog セクションを見てください -

  "The Perfect Patch"
      https://www.ozlabs.org/~akpm/stuff/tpp.txt

これらはどれも、実行することが時にはとても困難です。これらの例を完璧に
実施するには数年かかるかもしれません。これは継続的な改善のプロセスであ
り、多くの忍耐と決意を必要とするものです。でも諦めないで、実現は可能で
す。多数の人がすでにできていますし、彼らも最初はあなたと同じところから
スタートしたのですから。

기여자와 maintainer

Paolo Ciarrocchi는 자신이 작성한 `Development Process` article `https://lwn.net/Articles/94386/`을 이 문서의 바탕으로 쓰도록 허락했습니다. Randy Dunlap과 Gerrit Huizenga는 mailing list에서 해야 할 일과 하지 말아야 할 일 목록을 제공했습니다.

Review, comment, contribution을 제공한 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에게 감사를 표합니다. 이들의 도움 없이는 문서가 완성되지 못했을 것입니다.

Maintainer는 Greg Kroah-Hartman `<[email protected]>`입니다.

----------

Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process"
(https://lwn.net/Articles/94386/) セクションをこのテキストの原型にする
ことを許可してくれました。Rundy 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
彼らの支援なしでは、このドキュメントはできなかったでしょう。



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