Documentation: Add HOWTO Japanese translation into rst based build system

This commit adds Japanese translation of HOWTO document into rst based
documentation build system with updates.

Signed-off-by: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

2 files changed, 322 insertions, 286 deletions

diff --git a/Documentation/translations/ja_JP/HOWTO b/Documentation/translations/ja_JP/howto.rst
index 4ebd20750ef1..4511eed0fabb 100644
--- a/Documentation/translations/ja_JP/HOWTO
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -1,95 +1,81 @@
 NOTE:
 This is a version of Documentation/HOWTO translated into Japanese.
 This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
-and the JF Project team <www.linux.or.jp/JF>.
-If you find any difference between this document and the original file
-or a problem with the translation,
-please contact the maintainer of this file or JF project.
-
-Please also note that the purpose of this file is to be easier to read
-for non English (read: Japanese) speakers and is not intended as a
-fork. So if you have any comments or updates for this file, please try
-to update the original English file first.
-
-Last Updated: 2013/07/19
-==================================
-これは、
-linux-3.10/Documentation/HOWTO
+If you find any difference between this document and the original file or
+a problem with the translation, please contact the maintainer of this file.
+
+Please also note that the purpose of this file is to be easier to
+read for non English (read: Japanese) speakers and is not intended as
+a fork. So if you have any comments or updates for this file, please
+try to update the original English file first.
+
+----------------------------------
+
+この文書は、
+Documentation/process/howto.rst
 の和訳です。
 
-翻訳団体： JF プロジェクト < http://linuxjf.sourceforge.jp/ >
-翻訳日： 2013/7/19
-翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
-校正者： 松倉さん <nbh--mats at nifty dot com>
-         小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
-         武井伸光さん、<takei at webmasters dot gr dot jp>
-         かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
-         野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
-         河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
-         岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
-         内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
-==================================
+翻訳者： Tsugikazu Shibata <tshibata@ab.jp.nec.com>
+
+----------------------------------
 
 Linux カーネル開発のやり方
--------------------------------
+==========================
 
 これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した
-ドキュメントです。ここには Linux カーネル開発者になるための方法と
-Linux カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれて
-います。カーネルプログラミングに関する技術的な項目に関することは何も含
-めないようにしていますが、カーネル開発者となるための正しい方向に向かう
-手助けになります。
+ドキュメントです。ここには Linux カーネル開発者になるための方法とLinux
+カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。
+カーネルプログラミングに関する技術的な項目に関することは何も含めないよ
+うにしていますが、カーネル開発者となるための正しい方向に向かう手助けに
+なります。
 
-もし、このドキュメントのどこかが古くなっていた場合には、このドキュメン
-トの最後にリストしたメンテナにパッチを送ってください。
+もし、このドキュメントのどこかが古くなっていた場合には、このドキュメント
+の最後にリストしたメンテナにパッチを送ってください。
 
 はじめに
 ---------
 
-あなたは　Linux カーネルの開発者になる方法を学びたいのでしょうか？　そ
-れともあなたは上司から「このデバイスの Linux ドライバを書くように」と
-言われているのでしょうか？　
-この文書の目的は、あなたが踏むべき手順と、コミュニティと一緒にうまく働
-くヒントを書き下すことで、あなたが知るべき全てのことを教えることです。
-また、このコミュニティがなぜ今うまくまわっているのかという理由の一部も
-説明しようと試みています。
-
-
-カーネルは 少量のアーキテクチャ依存部分がアセンブリ言語で書かれている
-以外は大部分は C 言語で書かれています。C言語をよく理解していることはカー
-ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
-でなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
-ません。以下の本は、C 言語の十分な知識や何年もの経験に取って代わるもの
-ではありませんが、少なくともリファレンスとしては良い本です。
+あなたは Linux カーネルの開発者になる方法を学びたいのでしょうか？　そ
+れとも上司から「このデバイスの Linux ドライバを書くように」と言われた
+のかもしれません。この文書の目的は、あなたが踏むべき手順と、コミュニティ
+と一緒にうまく働くヒントを書き下すことで、あなたが知るべき全てのことを
+教えることです。また、このコミュニティがなぜ今うまくまわっているのかと
+いう理由も説明しようと試みています。
+
+カーネルは少量のアーキテクチャ依存部分がアセンブリ言語で書かれている以
+外の大部分は C 言語で書かれています。C言語をよく理解していることはカー
+ネル開発に必要です。低レベルのアーキテクチャ開発をするのでなければ、
+(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要ありません。以下
+の本は、C 言語の十分な知識や何年もの経験に取って代わるものではありませ
+んが、少なくともリファレンスとしては良い本です。
+
  - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
- -『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
+ - 『プログラミング言語Ｃ第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 スティール共著 斉藤 信男監訳)[ソフトバンク]
+ - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク]
 
 カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル
 は ISO C89 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って
-います。カーネルは標準 C ライブラリとは関係がないといった、C 言語フリー
-スタンディング環境です。そのため、C の標準で使えないものもあります。任
-意の long long の除算や浮動小数点は使えません。
-ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどう
-なっているのかわかりにくいことがあり、また、残念なことに決定的なリファ
-レンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を
-見てください。
+います。カーネルは標準 C ライブラリに依存しない、C 言語非依存環境です。
+そのため、C の標準の中で使えないものもあります。特に任意の long long
+の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張
+に置いている前提がどうなっているのかわかりにくいことが時々あり、また、
+残念なことに決定的なリファレンスは存在しません。情報を得るには、gcc の
+info ページ( info gcc )を見てください。
 
 あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
-とに留意してください。そのコミュニティは、コーディング、スタイル、
-開発手順について高度な標準を持つ、多様な人の集まりです。
-地理的に分散した大規模なチームに対してもっともうまくいくとわかったこと
-をベースにしながら、これらの標準は長い時間をかけて築かれてきました。
-これらはきちんと文書化されていますから、事前にこれらの標準についてでき
-るだけたくさん学んでください。また皆があなたやあなたの会社のやり方に合わ
-せてくれると思わないでください。
+とに思い出してください。そのコミュニティは、コーディング、スタイル、開
+発手順について高度な標準を持つ、多様な人の集まりです。地理的に分散した
+大規模なチームに対してもっともうまくいくとわかったことをベースにしなが
+ら、これらの標準は長い時間をかけて築かれてきました。これらはきちんと文
+書化されていますから、事前にこれらの標準について事前にできるだけたくさ
+ん学んでください。また皆があなたやあなたの会社のやり方に合わせてくれる
+と思わないでください。
 
 法的問題
-------------
+--------
 
 Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
 す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在
@@ -98,8 +84,9 @@ Linux カーネルのソースコードは GPL ライセンスの下でリリー
 法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
 問題については彼らの声明はあてにするべきではありません。
 
-GPL に関する共通の質問や回答については、以下を参照してください。
-	http://www.gnu.org/licenses/gpl-faq.html
+GPL に関する共通の質問や回答については、以下を参照してください-
+
+	https://www.gnu.org/licenses/gpl-faq.html
 
 ドキュメント
 ------------
@@ -119,111 +106,129 @@ linux-api@vger.kernel.org に送ることを勧めます。
   README
     このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
     configure )し、生成(訳注 build )するために必要なことは何かが書かれ
-    ています。カーネルに関して初めての人はここからスタートすると良いで
-    しょう。
+    ています。 カーネルに関して初めての人はここからスタートすると良い
+    でしょう。
 
-  Documentation/Changes
-     このファイルはカーネルをうまく生成(訳注 build )し、走らせるのに最
-     小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい
-     ます。
+  :ref:`Documentation/Process/changes.rst <changes>`
+    このファイルはカーネルをうまく生成(訳注 build )し、走らせるのに最
+    小限のレベルで必要な数々のソフトウェアパッケージの一覧を示してい
+    ます。
 
-  Documentation/process/coding-style.rst
+  :ref:`Documentation/process/coding-style.rst <codingstyle>`
     これは Linux カーネルのコーディングスタイルと背景にある理由を記述
     しています。全ての新しいコードはこのドキュメントにあるガイドライン
     に従っていることを期待されています。大部分のメンテナはこれらのルー
     ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
     だけをレビューします。
 
-  Documentation/process/submitting-patches.rst
-  Documentation/process/submitting-drivers.rst
-     これらのファイルには、どうやってうまくパッチを作って投稿するかに
-     ついて非常に詳しく書かれており、以下を含みます(これだけに限らない
-     けれども)
-        - Email に含むこと
-        - Email の形式
-        - だれに送るか
-     これらのルールに従えばうまくいくことを保証することではありません
-     が (すべてのパッチは内容とスタイルについて精査を受けるので)、
-     ルールに従わなければ間違いなくうまくいかないでしょう。
-
-     この他にパッチを作る方法についてのよくできた記述は-
-
-	"The Perfect Patch"
+  :ref:`Documentation/process/submitting-patches.rst <codingstyle>` と :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
+    これらのファイルには、どうやってうまくパッチを作って投稿するかにつ
+    いて非常に詳しく書かれており、以下を含みます (これだけに限らない
+    けれども)
+
+      - Email に含むこと
+      - Email の形式
+      - だれに送るか
+
+    これらのルールに従えばうまくいくことを保証することではありません
+    が (すべてのパッチは内容とスタイルについて精査を受けるので)、
+    ルールに従わなければ間違いなくうまくいかないでしょう。
+
+    この他にパッチを作る方法についてのよくできた記述は-
+
+       "The Perfect Patch"
 		http://www.ozlabs.org/~akpm/stuff/tpp.txt
-	"Linux kernel patch submission format"
+       "Linux kernel patch submission format"
 		http://linux.yyz.us/patch-format.html
 
-  Documentation/process/stable-api-nonsense.rst
-     このファイルはカーネルの中に不変のAPIを持たないことにした意識的な
-     決断の背景にある理由について書かれています。以下のようなことを含
-     んでいます-
-       - サブシステムとの間に層を作ること(コンパチビリティのため?)
-       - オペレーティングシステム間のドライバの移植性
-       - カーネルソースツリーの素早い変更を遅らせる(もしくは素早い変更
-         を妨げる)
-     このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
-     そして、他のOSでの開発者が Linux に移る時にとても重要です。
-
-  Documentation/admin-guide/security-bugs.rst
+  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
+    このファイルはカーネルの中に不変の API を持たないことにした意識的
+    な決断の背景にある理由について書かれています。以下のようなことを含
+    んでいます-
+
+      - サブシステムとの間に層を作ること(コンパチビリティのため?)
+      - オペレーティングシステム間のドライバの移植性
+      - カーネルソースツリーの素早い変更を遅らせる(もしくは素早い変更を妨げる)
+
+    このドキュメントは Linux 開発の思想を理解するのに非常に重要です。
+    そして、他のOSでの開発者が Linux に移る時にとても重要です。
+
+  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
     もし Linux カーネルでセキュリティ問題を発見したように思ったら、こ
     のドキュメントのステップに従ってカーネル開発者に連絡し、問題解決を
     支援してください。
 
-  Documentation/process/management-style.rst
+  :ref:`Documentation/process/management-style.rst <managementstyle>`
     このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
     彼らの手法の背景にある共有されている精神について記述しています。こ
     れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
     重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
     行動についての多くの誤解や混乱を解消するからです。
 
-  Documentation/process/stable-kernel-rules.rst
+  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
     このファイルはどのように stable カーネルのリリースが行われるかのルー
     ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
     り入れてもらいたい場合に何をすれば良いかが示されています。
 
-  Documentation/process/kernel-docs.rst
-　　カーネル開発に付随する外部ドキュメントのリストです。もしあなたが
-    探しているものがカーネル内のドキュメントでみつからなかった場合、
-    このリストをあたってみてください。
+  :Ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
+    カーネル開発に付随する外部ドキュメントのリストです。もしあなたが探
+    しているものがカーネル内のドキュメントでみつからなかった場合、この
+    リストをあたってみてください。
 
-  Documentation/process/applying-patches.rst
+  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
     パッチとはなにか、パッチをどうやって様々なカーネルの開発ブランチに
     適用するのかについて正確に記述した良い入門書です。
 
-カーネルはソースコードから自動的に生成可能な多数のドキュメントを自分自
-身でもっています。これにはカーネル内 API のすべての記述や、どう正しく
-ロックをかけるかの規則が含まれます。このドキュメントは
-Documentation/DocBook/ ディレクトリに作られ、以下のように
-	make pdfdocs
-	make psdocs
-	make htmldocs
-	make mandocs
-コマンドを実行するとメインカーネルのソースディレクトリから
-それぞれ、PDF, Postscript, HTML, man page の形式で生成されます。
+カーネルはソースコードそのものや、このファイルのようなリストラクチャー
+ドテキストマークアップ(ReST)から自動的に生成可能な多数のドキュメントを
+もっています。これにはカーネル内APIの完全な記述や、正しくロックをかけ
+るための規則などが含まれます。
+
+これら全てのドキュメントを PDF や HTML で生成するには以下を実行します - ::
+
+        make pdfdocs
+        make htmldocs
+
+それぞれメインカーネルのソースディレクトリから実行します。
+
+ReSTマークアップを使ったドキュメントは Documentation/outputに生成され
+ます。Latex とePub 形式で生成するには - ::
+
+        make latexdocs
+        make epubdocs
+
+現在、幾つかの DocBook形式で書かれたドキュメントは ReST形式に転換中で
+す。それらのドキュメントはDocumentation/DocBook ディレクトリに生成され、
+Postscript または man ページの形式を生成するには以下のようにします - ::
+
+        make psdocs
+        make mandocs
 
 カーネル開発者になるには
----------------------------
+------------------------
 
-もしあなたが、Linux カーネル開発について何も知らないならば、
+もしあなたが、Linux カーネル開発について何も知らないのならば、
 KernelNewbies プロジェクトを見るべきです
-	http://kernelnewbies.org
+
+	https://kernelnewbies.org
 
 このサイトには役に立つメーリングリストがあり、基本的なカーネル開発に関
 するほとんどどんな種類の質問もできます (既に回答されているようなことを
-聞く前にまずはアーカイブを調べてください)。
-またここには、リアルタイムで質問を聞くことができる IRC チャネルや、Linux
-カーネルの開発に関して学ぶのに便利なたくさんの役に立つドキュメントがあ
-ります。
+聞く前にまずはアーカイブを調べてください)。またここには、リアルタイム
+で質問を聞くことができる IRC チャネルや、Linuxカーネルの開発に関して学
+ぶのに便利なたくさんの役に立つドキュメントがあります。
 
-web サイトには、コードの構成、サブシステム、現在存在するプロジェクト(ツ
-リーにあるもの無いものの両方)の基本的な管理情報があります。
-ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接
-的な基本情報も記述されています。
+Web サイトには、コードの構成、サブシステム、現在存在するプロジェクト
+(ツリーにあるもの無いものの両方)の基本的な管理情報があります。ここには、
+また、カーネルのコンパイルのやり方やパッチの当て方などの間接的な基本情
+報も記述されています。
 
 あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
-ニティに参加して何かすることをさがしている場合には、Linux kernel
+ニティに参加して何かすることをさがしているのであれば、Linux kernel
 Janitor's プロジェクトにいけば良いでしょう -
-	http://kernelnewbies.org/KernelJanitors
+
+        https://kernelnewbies.org/KernelJanitors
+
 ここはそのようなスタートをするのにうってつけの場所です。ここには、
 Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
 らない、単純な問題のリストが記述されています。このプロジェクトに関わる
@@ -232,10 +237,11 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、�
 ていない場合には、次にやる仕事の方向性が見えてくるかもしれません。
 
 もしあなたが、すでにひとまとまりコードを書いていて、カーネルツリーに入
-れたいと思っていたり、それに関する適切な支援を求めたい場合、カーネル
-メンターズプロジェクトはそのような皆さんを助けるためにできました。
-ここにはメーリングリストがあり、以下から参照できます
-	http://selenic.com/mailman/listinfo/kernel-mentors
+れたいと思っていたり、それに関する適切な支援を求めたい場合、カーネルメ
+ンターズプロジェクトはそのような皆さんを助けるためにできました。ここに
+はメーリングリストがあり、以下から参照できます -
+
+	https://selenic.com/mailman/listinfo/kernel-mentors
 
 実際に Linux カーネルのコードについて修正を加える前に、どうやってその
 コードが動作するのかを理解することが必要です。そのためには、特別なツー
@@ -244,27 +250,29 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、�
 特におすすめなのは、Linux クロスリファレンスプロジェクトです。これは、
 自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
 できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
-ます-
+ます -
+
 	http://lxr.free-electrons.com/
 
 開発プロセス
------------------------
+------------
 
 Linux カーネルの開発プロセスは現在幾つかの異なるメインカーネル「ブラン
-チ」と多数のサブシステム毎のカーネルブランチから構成されます。
-これらのブランチとは-
-  - メインの 3.x カーネルツリー
-  - 3.x.y -stable カーネルツリー
-  - 3.x -git カーネルパッチ
+チ」と多数のサブシステム毎のカーネルブランチから構成されます。これらの
+ブランチとは -
+
+  - メインの 4.x カーネルツリー
+  - 4.x.y -stable カーネルツリー
+  - 4.x -git カーネルパッチ
   - サブシステム毎のカーネルツリーとパッチ
-  - 統合テストのための 3.x -next カーネルツリー
+  - 統合テストのための 4.x -next カーネルツリー
 
-3.x カーネルツリー
------------------
+4.x カーネルツリー
+~~~~~~~~~~~~~~~~~~
 
-3.x カーネルは Linus Torvalds によってメンテナンスされ、kernel.org
-の pub/linux/kernel/v3.x/ ディレクトリに存在します。この開発プロセスは
-以下のとおり-
+4.x カーネルは Linus Torvalds によってメンテナンスされ、
+https://kernel.org の pub/linux/kernel/v4.x/ ディレクトリに存在します。
+この開発プロセスは以下のとおり -
 
   - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
     この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
@@ -272,7 +280,6 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン�
     大きな変更は git(カーネルのソース管理ツール、詳細は
     http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ
     チファイルの形式のまま送るのでも十分です。
-
   - 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定
     性に影響をあたえるような新機能は含まない類のパッチしか取り込むこと
     はできません。新しいドライバ(もしくはファイルシステム)のパッチは
@@ -282,44 +289,45 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン�
     Linus へパッチを送付するのに git を使うこともできますが、パッチは
     レビューのために、パブリックなメーリングリストへも同時に送る必要が
     あります。
-
   - 新しい -rc は Linus が、最新の git ツリーがテスト目的であれば十分
     に安定した状態にあると判断したときにリリースされます。目標は毎週新
     しい -rc カーネルをリリースすることです。
-
   - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
     す。このプロセスはだいたい 6週間継続します。
 
 Andrew Morton が Linux-kernel メーリングリストにカーネルリリースについ
-て書いたことをここで言っておくことは価値があります-
-  「カーネルがいつリリースされるかは誰も知りません。なぜなら、これは現
-  実に認識されたバグの状況によりリリースされるのであり、前もって決めら
-  れた計画によってリリースされるものではないからです。」
+て書いたことをここで言っておくことは価値があります -
+
+        *「カーネルがいつリリースされるかは誰も知りません。なぜなら、
+        これは現実に認識されたバグの状況によりリリースされるのであり、
+        前もって決められた計画によってリリースされるものではないから
+        です。」*
 
-3.x.y -stable カーネルツリー
----------------------------
+4.x.y -stable カーネルツリー
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 バージョン番号が3つの数字に分かれているカーネルは -stable カーネルです。
-これには、3.x カーネルで見つかったセキュリティ問題や重大な後戻りに対
-する比較的小さい重要な修正が含まれます。
+これには、4.x カーネルで見つかったセキュリティ問題や重大な後戻りに対す
+る比較的小さい重要な修正が含まれます。
 
-これは、開発/実験的バージョンのテストに協力することに興味が無く、
-最新の安定したカーネルを使いたいユーザに推奨するブランチです。
+これは、開発/実験的バージョンのテストに協力することに興味が無く、最新
+の安定したカーネルを使いたいユーザに推奨するブランチです。
 
-もし、3.x.y カーネルが存在しない場合には、番号が一番大きい 3.x が
-最新の安定版カーネルです。
+もし、4.x.y カーネルが存在しない場合には、番号が一番大きい 4.x が最新
+の安定版カーネルです。
 
-3.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、必
-要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ
-た問題がなければもう少し長くなることもあります。セキュリティ関連の問題
-の場合はこれに対してだいたいの場合、すぐにリリースがされます。
+4.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、
+必要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差
+し迫った問題がなければもう少し長くなることもあります。セキュリティ関
+連の問題の場合はこれに対してだいたいの場合、すぐにリリースがされます。
 
-カーネルツリーに入っている、Documentation/process/stable-kernel-rules.rst ファ
-イルにはどのような種類の変更が -stable ツリーに受け入れ可能か、またリ
-リースプロセスがどう動くかが記述されています。
+カーネルツリーに入っている、
+Documentation/process/stable-kernel-rules.rst ファイルにはどのような種
+類の変更が -stable ツリーに受け入れ可能か、またリリースプロセスがどう
+動くかが記述されています。
 
-3.x -git パッチ
-------------------
+4.x -git パッチ
+~~~~~~~~~~~~~~~
 
 git リポジトリで管理されているLinus のカーネルツリーの毎日のスナップ
 ショットがあります。(だから -git という名前がついています)。これらのパッ
@@ -328,7 +336,7 @@ git リポジトリで管理されているLinus のカーネルツリーの毎�
 に生成されるので、より実験的です。
 
 サブシステム毎のカーネルツリーとパッチ
--------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
 サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
@@ -340,42 +348,45 @@ git リポジトリで管理されているLinus のカーネルツリーの毎�
 大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
 quilt シリーズとして公開されているパッチキューも使われています。これら
 のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
-ています。これらの多くは http://git.kernel.org/ で参照することができま
+ています。これらの多くは https://git.kernel.org/ で参照することができま
 す。
 
 提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
 リングリストで事前にレビューにかけられます（以下の対応するセクションを
-参照）。いくつかのカーネルサブシステムでは、このレビューは patchwork
-というツールによって追跡されます。Patchwork は web インターフェイスに
-よってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そして
-メンテナはパッチに対して、レビュー中、受付済み、拒否というようなマーク
-をつけることができます。大部分のこれらの patchwork のサイトは
-http://patchwork.kernel.org/ でリストされています。
-
-統合テストのための 3.x -next カーネルツリー
----------------------------------------------
-
-サブシステムツリーの更新内容がメインラインの 3.x ツリーにマージされ
-る前に、それらは統合テストされる必要があります。この目的のため、実質的
-に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリ
-ポジトリが存在します-
-       http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
+参照）。いくつかのカーネルサブシステムでは、このレビューは patchworkと
+いうツールによって追跡されます。Patchwork は web インターフェイスによっ
+てパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そしてメン
+テナはパッチに対して、レビュー中、受付済み、拒否というようなマークをつ
+けることができます。大部分のこれらの patchwork のサイトは
+https://patchwork.kernel.org/ でリストされています。
+
+統合テストのための 4.x -next カーネルツリー
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+サブシステムツリーの更新内容がメインラインの 4.x ツリーにマージされる
+前に、それらは統合テストされる必要があります。この目的のため、実質的に
+全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリポジ
+トリが存在します-
+
+       https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
 
 このやり方によって、-next カーネルは次のマージ機会でどんなものがメイン
-ラインカーネルにマージされるか、おおまかなの展望を提供します。-next 
-カーネルの実行テストを行う冒険好きなテスターは大いに歓迎されます
+ラインカーネルにマージされるか、おおまかなの展望を提供します。-next カー
+ネルの実行テストを行う冒険好きなテスターは大いに歓迎されます。
 
 バグレポート
 -------------
 
-bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する
-場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。
-どう kernel bugzilla を使うかの詳細は、以下を参照してください-
-	http://bugzilla.kernel.org/page.cgi?id=faq.html
-メインカーネルソースディレクトリにあるファイル admin-guide/reporting-bugs.rst はカーネ
-ルバグらしいものについてどうレポートするかの良いテンプレートであり、問
-題の追跡を助けるためにカーネル開発者にとってどんな情報が必要なのかの詳
-細が書かれています。
+https://bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを追跡する
+場所です。ユーザは見つけたバグの全てをこのツールで報告すべきです。どう
+kernel bugzilla を使うかの詳細は、以下を参照してください -
+
+	https://bugzilla.kernel.org/page.cgi?id=faq.html
+
+メインカーネルソースディレクトリにあるファイル
+admin-guide/reporting-bugs.rstはカーネルバグらしいものについてどうレポー
+トするかの良いテンプレートであり、問題の追跡を助けるためにカーネル開発
+者にとってどんな情報が必要なのかの詳細が書かれています。
 
 バグレポートの管理
 -------------------
@@ -383,74 +394,78 @@ bugzilla.kernel.org は Linux カーネル開発者がカーネルのバグを�
 あなたのハッキングのスキルを訓練する最高の方法のひとつに、他人がレポー
 トしたバグを修正することがあります。あなたがカーネルをより安定化させる
 こに寄与するということだけでなく、あなたは 現実の問題を修正することを
-学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつき
-ます。バグを修正することは、多くの開発者の中から自分が功績をあげる最善
-の道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好ま
-ないからです。
+学び、自分のスキルも強化でき、また他の開発者があなたの存在に気がつきま
+す。バグを修正することは、多くの開発者の中から自分が功績をあげる最善の
+道です、なぜなら多くの人は他人のバグの修正に時間を浪費することを好まな
+いからです。
 
 すでにレポートされたバグのために仕事をするためには、
-http://bugzilla.kernel.org に行ってください。もし今後のバグレポートに
+https://bugzilla.kernel.org に行ってください。もし今後のバグレポートに
 ついてアドバイスを受けたいのであれば、bugme-new メーリングリスト(新し
 いバグレポートだけがここにメールされる) または bugme-janitor メーリン
 グリスト(bugzilla の変更毎にここにメールされる)を購読できます。
 
-	http://lists.linux-foundation.org/mailman/listinfo/bugme-new
-	http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
+	https://lists.linux-foundation.org/mailman/listinfo/bugme-new
+
+	https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
 
 メーリングリスト
--------------
+----------------
 
 上のいくつかのドキュメントで述べていますが、コアカーネル開発者の大部分
 は Linux kernel メーリングリストに参加しています。このリストの登録/脱
 退の方法については以下を参照してください-
+
 	http://vger.kernel.org/vger-lists.html#linux-kernel
 
 このメーリングリストのアーカイブは web 上の多数の場所に存在します。こ
 れらのアーカイブを探すにはサーチエンジンを使いましょう。例えば-
+
 	http://dir.gmane.org/gmane.linux.kernel
 
 リストに投稿する前にすでにその話題がアーカイブに存在するかどうかを検索
-することを是非やってください。多数の事がすでに詳細に渡って議論されて
-おり、アーカイブにのみ記録されています。
+することを是非やってください。多数の事がすでに詳細に渡って議論されてお
+り、アーカイブにのみ記録されています。
 
 大部分のカーネルサブシステムも自分の個別の開発を実施するメーリングリス
 トを持っています。個々のグループがどんなリストを持っているかは、
 MAINTAINERS ファイルにリストがありますので参照してください。
 
 多くのリストは kernel.org でホストされています。これらの情報は以下にあ
-ります-
+ります -
+
 	http://vger.kernel.org/vger-lists.html
 
-メーリングリストを使う場合、良い行動習慣に従うようにしましょう。
-少し安っぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合の
-シンプルなガイドラインを示しています-
+メーリングリストを使う場合、良い行動習慣に従うようにしましょう。少し安っ
+ぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合のシンプル
+なガイドラインを示しています -
+
 	http://www.albion.com/netiquette/
 
 もし複数の人があなたのメールに返事をした場合、CC: で受ける人のリストは
-だいぶ多くなるでしょう。良い理由がない場合、CC: リストから誰かを削除を
-しないように、また、メーリングリストのアドレスだけにリプライすることの
-ないようにしましょう。1つは送信者から、もう1つはリストからのように、メー
-ルを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追加し
-てこの状態を変えようとしないように。人々はそのようなことは好みません。
+だいぶ多くなるでしょう。正当な理由がない限り、CC: リストから誰かを削除
+をしないように、また、メーリングリストのアドレスだけにリプライすること
+のないようにしましょう。1つは送信者から、もう1つはリストからのように、
+メールを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追
+加してこの状態を変えようとしないように。人々はそのようなことは好みませ
+ん。
 
 今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
 "John Kernelhacker wrote ...:" の行をあなたのリプライの先頭行にして、
 メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
 す。
 
-もしパッチをメールに付ける場合は、Documentation/process/submitting-patches.rst に提
-示されているように、それは プレーンな可読テキストにすることを忘れない
-ようにしましょう。カーネル開発者は 添付や圧縮したパッチを扱いたがりま
-せん-
-彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
-るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
-に確認した方が良いです。最初の良いテストとしては、自分にメールを送って
-みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
-ら、あな�