diff options
Diffstat (limited to 'Documentation/translations/ja_JP')
| -rw-r--r-- | Documentation/translations/ja_JP/SubmitChecklist | 12 | ||||
| -rw-r--r-- | Documentation/translations/ja_JP/SubmittingPatches | 60 | ||||
| -rw-r--r-- | Documentation/translations/ja_JP/index.rst | 14 | ||||
| -rw-r--r-- | Documentation/translations/ja_JP/process/howto.rst (renamed from Documentation/translations/ja_JP/howto.rst) | 126 |
4 files changed, 110 insertions, 102 deletions
diff --git a/Documentation/translations/ja_JP/SubmitChecklist b/Documentation/translations/ja_JP/SubmitChecklist index b42220d3d46c..1759c6b452d6 100644 --- a/Documentation/translations/ja_JP/SubmitChecklist +++ b/Documentation/translations/ja_JP/SubmitChecklist @@ -56,8 +56,8 @@ Linux カーネルパッチ投稿者向けチェックリスト 9: sparseを利用してちゃんとしたコードチェックをしてください。 -10: 'make checkstack' と 'make namespacecheck' を利用し、問題が発見されたら - 修正してください。'make checkstack' は明示的に問題を示しませんが、どれか +10: 'make checkstack' を利用し、問題が発見されたら修正してください。 + 'make checkstack' は明示的に問題を示しませんが、どれか １つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と なります。 @@ -88,20 +88,18 @@ Linux カーネルパッチ投稿者向けチェックリスト 18: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に Documentation/ABI/README を参考にして必ずドキュメントを追加してください。 -19: 'make headers_check'を実行して全く問題がないことを確認してください。 - -20: 少なくともslabアロケーションとpageアロケーションに失敗した場合の +19: 少なくともslabアロケーションとpageアロケーションに失敗した場合の 挙動について、fault-injectionを利用して確認してください。 Documentation/fault-injection/ を参照してください。 追加したコードがかなりの量であったならば、サブシステム特有の fault-injectionを追加したほうが良いかもしれません。 -21: 新たに追加したコードは、`gcc -W'でコンパイルしてください。 +20: 新たに追加したコードは、`gcc -W'でコンパイルしてください。 このオプションは大量の不要なメッセージを出力しますが、 "warning: comparison between signed and unsigned" のようなメッセージは、 バグを見つけるのに役に立ちます。 -22: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや +21: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存 できることを確認するテストを行ってください。 diff --git a/Documentation/translations/ja_JP/SubmittingPatches b/Documentation/translations/ja_JP/SubmittingPatches index dd0c3280ba5a..5334db471744 100644 --- a/Documentation/translations/ja_JP/SubmittingPatches +++ b/Documentation/translations/ja_JP/SubmittingPatches @@ -35,8 +35,7 @@ Linux カーネルに変更を加えたいと思っている個人又は会社 てもらえやすくする提案を集めたものです。 コードを投稿する前に、Documentation/process/submit-checklist.rst の項目リストに目 -を通してチェックしてください。もしあなたがドライバーを投稿しようとし -ているなら、Documentation/process/submitting-drivers.rst にも目を通してください。 +を通してチェックしてください。 -------------------------------------------- セクション1 パッチの作り方と送り方 @@ -81,9 +80,7 @@ Linux カーネルに対する全ての変更は diff(1) コマンドによる dontdiff ファイルには Linux カーネルのビルドプロセスの過程で生成された ファイルの一覧がのっています。そして、それらはパッチを生成する diff(1) コマンドで無視されるべきです。dontdiff ファイルは 2.6.12 以後のバージョ -ンの Linux カーネルソースツリーに含まれています。それより前のバージョン -の Linux カーネルソースツリーに対する dontdiff ファイルは、 -<http://www.xenotime.net/linux/doc/dontdiff>から取得することができます。 +ンの Linux カーネルソースツリーに含まれています。 投稿するパッチの中に関係のない余分なファイルが含まれていないことを確 認してください。diff(1) コマンドで生成したパッチがあなたの意図したとお @@ -125,6 +122,17 @@ http://savannah.nongnu.org/projects/quilt 登録済みのバグエントリを修正するパッチであれば、そのバグエントリを示すバグ ID や URL を明記してください。 +特定のコミットを参照したい場合は、その SHA-1 ID だけでなく、一行サマリ +も含めてください。それにより、それが何に関するコミットなのかがレビューする +人にわかりやすくなります。 +例 (英文のママ): + + Commit e21d2170f36602ae2708 ("video: remove unnecessary + platform_set_drvdata()") removed the unnecessary + platform_set_drvdata(), but left the variable "dev" unused, + delete it. + + 3) パッチの分割 意味のあるひとまとまりごとに変更を個々のパッチファイルに分けてください。 @@ -162,7 +170,8 @@ http://savannah.nongnu.org/projects/quilt MAINTAINERS ファイルとソースコードに目を通してください。そして、その変 更がメンテナのいる特定のサブシステムに加えられるものであることが分か -れば、その人に電子メールを送ってください。 +れば、その人に電子メールを送ってください。その際 +./scripts/get_maintainers.pl のスクリプトが有用です。 もし、メンテナが載っていなかったり、メンテナからの応答がないなら、 LKML ( linux-kernel@vger.kernel.org )へパッチを送ってください。ほとんど @@ -208,21 +217,6 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの たとえ、メンテナが #5 で反応がなかったとしても、メンテナのコードに変更を 加えたときには、いつもメンテナに CC するのを忘れないようにしてください。 -小さなパッチであれば、Trivial Patch Monkey(ちょっとしたパッチを集めている) -<trivial@kernel.org>に CC してもいいです。その現管理者については MAINTAINERS -ファイルを見てください。ちょっとしたパッチとは以下のルールのどれか1つを満たして -いなければなりません。 - ・ドキュメントのスペルミスの修正 - ・grep(1) コマンドによる検索を困難にしているスペルの修正 - ・コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた - めです) - ・コンパイル問題の修正(それらの修正が本当に正しい場合に限る) - ・実行時の問題の修正(それらの修正が本当に問題を修正している場合に限る) - ・廃止予定の関数やマクロを使用しているコードの除去(例 check_region ) - ・問い合わせ先やドキュメントの修正 - ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で - あればアーキテクチャ特有のことでも他の人がコピーできます) - ・作者やメンテナによる修正(すなわち patch monkey の再転送モード) 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ @@ -415,7 +409,7 @@ Acked-by: が必ずしもパッチ全体の承認を示しているわけでは このタグはパッチに関心があると思われる人達がそのパッチの議論に含まれていたこと を明文化します。 -14) Reported-by と Tested-by: と Reviewed-by: の利用 +14) Reported-by:, Tested-by:, Reviewed-by: および Suggested-by: の利用 他の誰かによって報告された問題を修正するパッチであれば、問題報告者という寄与を クレジットするために、Reported-by: タグを追加することを検討してください。 @@ -456,7 +450,7 @@ Reviewed-by: タグは、それとは異なり、下記のレビューア宣言 状況においてその宣言した目的や機能が正しく実現することに関して、 いかなる保証もしない(特にどこかで明示しない限り)。 -Reviewd-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的 +Reviewed-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的 問題を残していないという意見の宣言です。興味のあるレビューアは誰でも(レビュー 作業を終えたら)パッチに対して Reviewed-by タグを提示できます。このタグは レビューアの寄与をクレジットする働き、レビューの進捗の度合いをメンテナに @@ -464,6 +458,13 @@ Reviewd-by タグはそのパッチがカーネルに対して適切な修正で レビューを実施したレビューアによって提供される時、Reviewed-by: タグがあなたの パッチをカーネルにマージする可能性を高めるでしょう。 +Suggested-by: タグは、パッチのアイデアがその人からの提案に基づくものである +ことを示し、アイデアの提供をクレジットするものです。提案者の明示的な許可が +ない場合、特にそのアイデアが公開のフォーラムで示されていない場合には、この +タグをつけないように注意してください。とはいえ、アイデアの提供者をこつこつ +クレジットしていけば、望むらくはその人たちが将来別の機会に再度力を貸す気に +なってくれるかもしれません。 + 15) 標準的なパッチのフォーマット 標準的なパッチのサブジェクトは以下のとおりです。 @@ -696,19 +697,20 @@ Jeff Garzik, "Linux kernel patch submission format". <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html> Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". - <http://www.kroah.com/log/2005/03/31/> - <http://www.kroah.com/log/2005/07/08/> - <http://www.kroah.com/log/2005/10/19/> - <http://www.kroah.com/log/2006/01/11/> + <http://www.kroah.com/log/linux/maintainer.html> + <http://www.kroah.com/log/linux/maintainer-02.html> + <http://www.kroah.com/log/linux/maintainer-03.html> + <http://www.kroah.com/log/linux/maintainer-04.html> + <http://www.kroah.com/log/linux/maintainer-05.html> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <https://lkml.org/lkml/2005/7/11/336> + <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> Kernel Documentation/process/coding-style.rst: <http://users.sosdg.org/~qiyong/lxr/source/Documentation/process/coding-style.rst> Linus Torvalds's mail on the canonical patch format: - <http://lkml.org/lkml/2005/4/7/183> + <https://lore.kernel.org/r/Pine.LNX.4.58.0504071023190.28951@ppc970.osdl.org> Andi Kleen, "On submitting kernel patches" Some strategies to get difficult or controversial changes in. diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 2f91b895e3c2..0b476b429e3b 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -1,12 +1,18 @@ .. raw:: latex - \renewcommand\thesection* - \renewcommand\thesubsection* + \renewcommand\thesection* + \renewcommand\thesubsection* + \kerneldocCJKon + \kerneldocBeginJP{ -Japanese translations +日本語訳 ===================== .. toctree:: :maxdepth: 1 - howto + process/howto + +.. raw:: latex + + }\kerneldocEndJP diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/process/howto.rst index 73ebdab4ced7..8d856ebe873c 100644 --- a/Documentation/translations/ja_JP/howto.rst +++ b/Documentation/translations/ja_JP/process/howto.rst @@ -1,3 +1,7 @@ +.. raw:: latex + + \kerneldocCJKoff + NOTE: This is a version of Documentation/process/howto.rst translated into Japanese. This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> @@ -11,6 +15,10 @@ try to update the original English file first. ---------------------------------- +.. raw:: latex + + \kerneldocCJKon + この文書は、 Documentation/process/howto.rst の和訳です。 @@ -57,7 +65,7 @@ Linux カーネル開発のやり方 - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク] カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル -は ISO C89 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って +は ISO C11 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って います。カーネルは標準 C ライブラリに依存しない、C 言語非依存環境です。 そのため、C の標準の中で使えないものもあります。特に任意の long long の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張 @@ -78,9 +86,14 @@ info ページ( info gcc )を見てください。 -------- Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま -す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在 -する、COPYING のファイルを見てください。もしライセンスについてさらに質 -問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ +す。ソースツリーのメインディレクトリにある COPYING のファイルを見てく +ださい。Linux カーネルのライセンスルールとソースコード内の +`SPDX <https://spdx.org/>`_ 識別子の使い方は +:ref:`Documentation/process/license-rules.rst <kernel_licensing>` +に説明されています。 + +もしライセンスについてさらに質問があれば、 +Linux Kernel メーリングリストに質問するのではなく、どうぞ 法律家に相談してください。メーリングリストの人達は法律家ではなく、法的 問題については彼らの声明はあてにするべきではありません。 @@ -103,7 +116,7 @@ linux-api@vger.kernel.org に送ることを勧めます。 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で す- - README + :ref:`Documentation/admin-guide/README.rst <readme>` このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注 configure )し、生成(訳注 build )するために必要なことは何かが書かれ ています。 カーネルに関して初めての人はここからスタートすると良い @@ -121,8 +134,8 @@ linux-api@vger.kernel.org に送ることを勧めます。 ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード だけをレビューします。 - :ref:`Documentation/process/submitting-patches.rst <codingstyle>` と :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` - これらのファイルには、どうやってうまくパッチを作って投稿するかにつ + :ref:`Documentation/process/submitting-patches.rst <codingstyle>` + このファイルには、どうやってうまくパッチを作って投稿するかにつ いて非常に詳しく書かれており、以下を含みます (これだけに限らない けれども) @@ -137,7 +150,8 @@ linux-api@vger.kernel.org に送ることを勧めます。 この他にパッチを作る方法についてのよくできた記述は- "The Perfect Patch" - http://www.ozlabs.org/~akpm/stuff/tpp.txt + 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 @@ -153,7 +167,7 @@ linux-api@vger.kernel.org に送ることを勧めます。 このドキュメントは Linux 開発の思想を理解するのに非常に重要です。 そして、他のOSでの開発者が Linux に移る時にとても重要です。 - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を 支援してください。 @@ -229,13 +243,6 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、 れるための基礎を学ぶことができ、そしてもしあなたがまだアイディアを持っ ていない場合には、次にやる仕事の方向性が見えてくるかもしれません。 -もしあなたが、すでにひとまとまりコードを書いていて、カーネルツリーに入 -れたいと思っていたり、それに関する適切な支援を求めたい場合、カーネルメ -ンターズプロジェクトはそのような皆さんを助けるためにできました。ここに -はメーリングリストがあり、以下から参照できます - - - https://selenic.com/mailman/listinfo/kernel-mentors - 実際に Linux カーネルのコードについて修正を加える前に、どうやってその コードが動作するのかを理解することが必要です。そのためには、特別なツー ルの助けを借りてでも、それを直接よく読むことが最良の方法です(ほとんど @@ -254,27 +261,29 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン チ」と多数のサブシステム毎のカーネルブランチから構成されます。これらの ブランチとは - - - メインの 4.x カーネルツリー - - 4.x.y -stable カーネルツリー - - サブシステム毎のカーネルツリーとパッチ - - 統合テストのための 4.x -next カーネルツリー + - Linus のメインラインツリー + - メジャー番号をまたぐ数本の安定版ツリー + - サブシステム毎のカーネルツリー + - 統合テストのための linux-next カーネルツリー -4.x カーネルツリー +メインラインツリー ~~~~~~~~~~~~~~~~~~ -4.x カーネルは Linus Torvalds によってメンテナンスされ、 -https://kernel.org の pub/linux/kernel/v4.x/ ディレクトリに存在します。 +メインラインツリーは Linus Torvalds によってメンテナンスされ、 +https://kernel.org のリポジトリに存在します。 この開発プロセスは以下のとおり - - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、 この期間中に、メンテナ達は Linus に大きな差分を送ることができます。 - このような差分は通常 -next カーネルに数週間含まれてきたパッチです。 + このような差分は通常 linux-next カーネルに数週間含まれてきたパッチです。 大きな変更は git(カーネルのソース管理ツール、詳細は http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ チファイルの形式のまま送るのでも十分です。 - - 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定 - 性に影響をあたえるような新機能は含まない類のパッチしか取り込むこと - はできません。新しいドライバ(もしくはファイルシステム)のパッチは + - 2週間後 -rc1 カーネルがリリースされ、新しいカーネルを可能な限り堅牢に + することに焦点が移ります。この期間のパッチのほとんどは退行を修正する + ものとなります。以前から存在していたバグは退行には当たらないため、 + 送るのは重要な修正だけにしてください。 + 新しいドライバ (もしくはファイルシステム) のパッチは -rc1 の後で受け付けられることもあることを覚えておいてください。な ぜなら、変更が独立していて、追加されたコードの外の領域に影響を与え ない限り、退行のリスクは無いからです。-rc1 がリリースされた後、 @@ -295,20 +304,21 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー 前もって決められた計画によってリリースされるものではないから です。」* -4.x.y -stable カーネルツリー -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +メジャー番号をまたぐ数本の安定版ツリー +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ バージョン番号が3つの数字に分かれているカーネルは -stable カーネルです。 -これには、4.x カーネルで見つかったセキュリティ問題や重大な後戻りに対す -る比較的小さい重要な修正が含まれます。 +これには最初の2つのバージョン番号の数字に対応した、 +メジャーメインラインリリースで見つかったセキュリティ問題や +重大な後戻りに対する比較的小さい重要な修正が含まれます。 + +メジャー安定版シリーズのそれぞれのリリースは +バージョン番号の3番目を増加させ、最初の2つの番号は同じ値を保ちます。 これは、開発/実験的バージョンのテストに協力することに興味が無く、最新 の安定したカーネルを使いたいユーザに推奨するブランチです。 -もし、4.x.y カーネルが存在しない場合には、番号が一番大きい 4.x が最新 -の安定版カーネルです。 - -4.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、 +安定版ツリーは"stable" チーム <stable@vger.kernel.org> でメンテされており、 必要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差 し迫った問題がなければもう少し長くなることもあります。セキュリティ関 連の問題の場合はこれに対してだいたいの場合、すぐにリリースがされます。 @@ -318,7 +328,7 @@ Documentation/process/stable-kernel-rules.rst ファイルにはどのような 類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう 動くかが記述されています。 -サブシステム毎のカーネルツリーとパッチ +サブシステム毎のカーネルツリー ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル @@ -343,33 +353,27 @@ quilt シリーズとして公開されているパッチキューも使われ けることができます。大部分のこれらの patchwork のサイトは https://patchwork.kernel.org/ でリストされています。 -統合テストのための 4.x -next カーネルツリー -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +統合テストのための linux-next カーネルツリー +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -サブシステムツリーの更新内容がメインラインの 4.x ツリーにマージされる +サブシステムツリーの更新内容がメインラインツリーにマージされる 前に、それらは統合テストされる必要があります。この目的のため、実質的に 全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリポジ トリが存在します- https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git -このやり方によって、-next カーネルは次のマージ機会でどんなものがメイン -ラインカーネルにマージされるか、おおまかなの展望を提供します。-next カー -ネルの実行テストを行う冒険好きなテスターは大いに歓迎されます。 +このやり方によって、linux-next は次のマージ機会でどんなものがメイン +ラインにマージされるか、おおまかな展望を提供します。 +linux-next の実行テストを行う冒険好きなテスターは大いに歓迎されます。 バグレポート ------------- -https://bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する -場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。どう -kernel bugzilla を使うかの詳細は、以下を参照してください - - - https://bugzilla.kernel.org/page.cgi?id=faq.html - メインカーネルソースディレクトリにあるファイル -admin-guide/reporting-bugs.rstはカーネルバグらしいものについてどうレポー -トするかの良いテンプレートであり、問題の追跡を助けるためにカーネル開発 -者にとってどんな情報が必要なのかの詳細が書かれています。 +'Documentation/admin-guide/reporting-issues.rst' +は、カーネルバグらしきものの報告の仕方、および、カーネル開発者が問題を +追跡する際の手がかりとなる情報についての詳細を説明しています。 バグレポートの管理 ------------------- @@ -382,15 +386,13 @@ admin-guide/reporting-bugs.rstはカーネルバグらしいものについて 道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好まな いからです。 -すでにレポートされたバグのために仕事をするためには、 -https://bugzilla.kernel.org に行ってください。もし今後のバグレポートに -ついてアドバイスを受けたいのであれば、bugme-new メーリングリスト(新し -いバグレポートだけがここにメールされる) または bugme-janitor メーリン -グリスト(bugzilla の変更毎にここにメールされる)を購読できます。 - - https://lists.linux-foundation.org/mailman/listinfo/bugme-new - - https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors +すでにレポートされたバグの作業をするためには、興味のあるサブシステムを +見つけ、そのサブシステムのバグの報告先 (多くの場合メーリングリスト、 +稀にバグトラッカー) を MAINTAINERS ファイルで調べてください。 +そのアーカイブで最近の報告を検索し、できそうなものに力を貸してください。 +https://bugzilla.kernel.org でバグ報告を調べようとする人もいるでしょう。 +これは限られた一部のサブシステムのバグ報告と追跡に利用されるとともに、 +とりわけ、カーネル全体に対するバグの登録先となっています。 メーリングリスト ---------------- @@ -404,7 +406,7 @@ https://bugzilla.kernel.org に行ってください。もし今後のバグレ このメーリングリストのアーカイブは web 上の多数の場所に存在します。こ れらのアーカイブを探すにはサーチエンジンを使いましょう。例えば- - http://dir.gmane.org/gmane.linux.kernel + https://lore.kernel.org/lkml/ リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索 することを是非やってください。多数の事がすでに詳細に渡って議論されてお @@ -615,7 +617,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を ントの ChangeLog セクションを見てください - "The Perfect Patch" - http://www.ozlabs.org/~akpm/stuff/tpp.txt + https://www.ozlabs.org/~akpm/stuff/tpp.txt これらはどれも、実行することが時にはとても困難です。これらの例を完璧に 実施するには数年かかるかもしれません。これは継続的な改善のプロセスであ |