diff --git a/ja/handbook/kernelopts.sgml b/ja/handbook/kernelopts.sgml
index 2312b73103..cbe9ff855a 100644
--- a/ja/handbook/kernelopts.sgml
+++ b/ja/handbook/kernelopts.sgml
@@ -1,5 +1,153 @@
-<!-- $Id: kernelopts.sgml,v 1.2 1996-12-23 21:19:30 max Exp $ -->
-<!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 0 -->
+<!-- $Id: kernelopts.sgml,v 1.3 1996-12-30 18:55:17 max Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+<!-- Original revision: 1.1 -->
 
-<chapt><heading>* Adding New Kernel Configuration Options<label id="kernelopts"></heading>
+<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
+
+<chapt><heading>カーネルコンフィグレーションの新しいオプションを追加する
+<label id="kernelopts"></heading>
+
+<p><em>原作: &a.joerg;</em>
+
+<p><em>訳: &a.yoshiaki; . <newline> 29 December 1996.</em>
+
+<em/注:/ この章をお読みになる前に <ref id="kernelconfig" 
+name="FreeBSDカーネルのコンフィグレーション"> の章の内容を
+理解しておいてください. 
+
+<sect><heading>そもそも<em>カーネル オプション</em>って何?</heading>
+
+  <p>カーネルオプションの使い方は基本的には <ref
+  id="kernelconfig:options" name="FreeBSDカーネルのコンフィグレーション"> 
+  の章に書いてあります. 
+  そこには「伝統的な形式」と「新しい形式」のオプションの説明があります. 
+  すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル
+  を修正して <tt/config(8)/ を実行した後にカーネルのコンパイルディレクトリで 
+  <tt/make depend/ を実行すれば, ビルドプロセスが自動的に変更された
+  オプションを検出し, 必要なファイルだけを再コンパイルするようにすることが
+  最終的な目的です. <tt/config(8)/ を実行するたびに古いコンパイルディレクトリ
+  を消してしまう現在のやりかたは, やがておこなわれなくなるでしょう. 
+
+  <p>基本的に, カーネルオプションはカーネルのコンパイルプロセスの
+  C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる
+  ようにするためには, 対応する部分のカーネルソース (またはカーネルの 
+  <tt/.h/ ファイル) がオプションを使えるようにあらかじめ書かれていなければ
+  なりません. つまりデフォルト値をコンフィグファイルのオプションで置き換え
+  られるようになっていなければなりません. これは普通は次のようになっています. 
+
+<verb>
+#ifndef THIS_OPTION
+#define THIS_OPTION (some_default_value)
+#endif /* THIS_OPTION */
+</verb>
+  <p>この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば, 
+  デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, 
+  新しい値はプリプロセッサによってソースコード中で置き換えられるため, 
+  デフォルトの値が使われていた場所において C の式として有効な値でなければ
+  なりません. 
+
+  <p>また, 単に特定のコードを有効にするか無効にするかを設定するための
+  値を持たないオプションも作ることができます.
+
+<verb>
+#ifdef THAT_OPTION
+
+...
+
+#endif
+</verb>
+  <p>コンフィグファイルに <tt/THAT_OPTION/ と記述するだけで (値の有無
+  にかかわらず) 対応する部分のコードが組み込まれます.
+
+  <p>C 言語にくわしい人であれば「コンフィグオプション」とされているもの
+  は少なくとも一つの <tt/#ifdef/ で参照されているということはすぐに理解
+  できるでしょう. ところで, ごく一部の人たちは次のようなものを試して
+  みようとするかもしれません.
+
+<verb>
+	options		notyet,notdef
+</verb>
+  <p>このようにコンフィグファイルをしておくと, カーネルのコンパイルは
+  うまく行きません. :-)
+
+  <p> (訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを
+  持たないオプションの場合, 無効とするためのパラメタをつけて, オプション
+  で「無効とする」と明示することはできないという意味です)
+
+  <p>明らかに, 任意のオプション名がカーネルソースツリー全体でどのように
+  使われているかを追いかけることは非常に難しいことです. このことが 
+  <em/新しい形式/ のオプションの機構を採り入れる理由の背景です. 
+  ここではそれぞれのオプションはカーネルコンパイルディレクトリにある別々の 
+  <tt/.h/ ファイルとなり, <tt>opt_<em>foo</em>.h</tt> という名前に
+  されます. この方法では, 通常の Makefile の依存関係が適用され, 
+  <tt/make/ プログラムはオプションが変更された時に再コンパイルが必要な
+  ものを見つけることができます.
+
+  <p>古い形式のオプションの機構は, 局部的なオプションや実験的なオプション
+  のような一時的に利用されると考えられるオプションにおいては有効です. 
+  つまり <tt/#ifdef/ をカーネルのソースに追加するのは簡単であり, 
+  必要なことはそれで全部ですから, すぐにカーネルコンフィグオプションを
+  作ることができます. この場合, 管理者はオプションの利用において
+  依存関係を把握しておく責任があります (また, 手動でカーネルの一部分を
+  強制的に再コンパイルする必要があるかもしれません).  サポートされている
+  オプションのすべてについて一つでも変更があると, <tt/config(8)/ は
+  サポートされていないオプションがコンフィグファイルの中にあるという警告
+  を出しますが, カーネルの Makefile 内にはそれを含めます. 
+ 
+<sect><heading>ではどのようにして追加するのでしょう?</heading>
+
+  <p>最初に <tt>sys/conf/options</tt> (または
+  <tt>sys/i386/conf/options.<em>&lt;arch&gt;</em></tt>, たとえば
+  <tt>sys/i386/conf/options.i386</tt>) を編集し, 新しいオプション
+  を含めるのに最適な <tt>opt_<em>foo</em>.h</tt> ファイルを選びます. 
+
+  <p>新しいオプションの必要がなくなったとしたら, これを取り除きます.
+  たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション
+  の変更は <tt/opt_scsi.h/ に入れられます. デフォルトでは, 適切
+  なオプションファイルに単に記述されます. たとえば <tt/FOO/ であれば
+  値は対応するファイルの <tt/opt_foo.h/ に格納されます. これは右端に別
+  のファイル名を書いて置き換えることができます. 
+
+  <p>新しいオプションを加えるのに使えそうな 
+  <tt>opt_<em>foo</em>.h</tt> がない場合は新しい名前を作ってください. 
+  意味のある名前を作り <tt>options[<em>.&lt;arch&gt;</em>]</tt> ファイル
+  に新しいセクションのコメントをつけてください. <tt/config(8)/ は自動的
+  に変更を検出して, 次の実行からは (訳注: 新しい <tt/.h/) ファイル
+  を作ります. ほとんどのオプションはヘッダファイルに入れられます. 
+
+  <p>大量のオプションを一つの <tt>opt_<em>foo</em>.h</tt> にまとめると
+  コンフィグファイルの一つのオプションを変更したときに多くのファイルが
+  再コンパイルされる原因になります.
+
+  <p>新しいオプションに依存するカーネルファイルは最終的には見つけ出
+  されます. ただし, オプションを作っただけで対応するソースがどこにも
+  ない場合は別です. 
+
+<verb>
+        find /usr/src/sys -name type f | xargs fgrep NEW_OPTION
+</verb>
+  <p>オプションに対応するソースを見つけるのに上記のコマンドは便利です. 
+  見つけたすべてのファイルで編集, 追加をおこないます. 
+
+<verb>
+#include "opt_foo.h"
+</verb>
+  <p><em>ファイルの先頭の</em>, すべての <tt/#include &lt;xxx.h&gt;/
+  より前に入れます. この場合, オプションによって次のようにしてデフォルト値
+  を持たせている標準のヘッダファイル内の値を置き換えるため, 順番は非常に
+  重要です. 
+
+<verb>
+#ifndef NEW_OPTION
+#define NEW_OPTION (something)
+#endif
+</verb>
+
+
+  <p>システムヘッダファイル (たとえば <tt>/usr/include/sys/</tt> にある
+  ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します. 
+  そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include 
+  しないとオプションの値によって不整合が起きてしまう場合を除き, それらの
+  ファイルに <tt>opt_<em>foo</em>.h</tt> を include しないでください. 
+  そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法
+  ではありません. 
diff --git a/ja_JP.EUC/handbook/kernelopts.sgml b/ja_JP.EUC/handbook/kernelopts.sgml
index 2312b73103..cbe9ff855a 100644
--- a/ja_JP.EUC/handbook/kernelopts.sgml
+++ b/ja_JP.EUC/handbook/kernelopts.sgml
@@ -1,5 +1,153 @@
-<!-- $Id: kernelopts.sgml,v 1.2 1996-12-23 21:19:30 max Exp $ -->
-<!-- The FreeBSD Japanese Documentation Project -->
-<!-- Original revision: 0 -->
+<!-- $Id: kernelopts.sgml,v 1.3 1996-12-30 18:55:17 max Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+<!-- Original revision: 1.1 -->
 
-<chapt><heading>* Adding New Kernel Configuration Options<label id="kernelopts"></heading>
+<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
+
+<chapt><heading>カーネルコンフィグレーションの新しいオプションを追加する
+<label id="kernelopts"></heading>
+
+<p><em>原作: &a.joerg;</em>
+
+<p><em>訳: &a.yoshiaki; . <newline> 29 December 1996.</em>
+
+<em/注:/ この章をお読みになる前に <ref id="kernelconfig" 
+name="FreeBSDカーネルのコンフィグレーション"> の章の内容を
+理解しておいてください. 
+
+<sect><heading>そもそも<em>カーネル オプション</em>って何?</heading>
+
+  <p>カーネルオプションの使い方は基本的には <ref
+  id="kernelconfig:options" name="FreeBSDカーネルのコンフィグレーション"> 
+  の章に書いてあります. 
+  そこには「伝統的な形式」と「新しい形式」のオプションの説明があります. 
+  すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル
+  を修正して <tt/config(8)/ を実行した後にカーネルのコンパイルディレクトリで 
+  <tt/make depend/ を実行すれば, ビルドプロセスが自動的に変更された
+  オプションを検出し, 必要なファイルだけを再コンパイルするようにすることが
+  最終的な目的です. <tt/config(8)/ を実行するたびに古いコンパイルディレクトリ
+  を消してしまう現在のやりかたは, やがておこなわれなくなるでしょう. 
+
+  <p>基本的に, カーネルオプションはカーネルのコンパイルプロセスの
+  C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる
+  ようにするためには, 対応する部分のカーネルソース (またはカーネルの 
+  <tt/.h/ ファイル) がオプションを使えるようにあらかじめ書かれていなければ
+  なりません. つまりデフォルト値をコンフィグファイルのオプションで置き換え
+  られるようになっていなければなりません. これは普通は次のようになっています. 
+
+<verb>
+#ifndef THIS_OPTION
+#define THIS_OPTION (some_default_value)
+#endif /* THIS_OPTION */
+</verb>
+  <p>この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば, 
+  デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, 
+  新しい値はプリプロセッサによってソースコード中で置き換えられるため, 
+  デフォルトの値が使われていた場所において C の式として有効な値でなければ
+  なりません. 
+
+  <p>また, 単に特定のコードを有効にするか無効にするかを設定するための
+  値を持たないオプションも作ることができます.
+
+<verb>
+#ifdef THAT_OPTION
+
+...
+
+#endif
+</verb>
+  <p>コンフィグファイルに <tt/THAT_OPTION/ と記述するだけで (値の有無
+  にかかわらず) 対応する部分のコードが組み込まれます.
+
+  <p>C 言語にくわしい人であれば「コンフィグオプション」とされているもの
+  は少なくとも一つの <tt/#ifdef/ で参照されているということはすぐに理解
+  できるでしょう. ところで, ごく一部の人たちは次のようなものを試して
+  みようとするかもしれません.
+
+<verb>
+	options		notyet,notdef
+</verb>
+  <p>このようにコンフィグファイルをしておくと, カーネルのコンパイルは
+  うまく行きません. :-)
+
+  <p> (訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを
+  持たないオプションの場合, 無効とするためのパラメタをつけて, オプション
+  で「無効とする」と明示することはできないという意味です)
+
+  <p>明らかに, 任意のオプション名がカーネルソースツリー全体でどのように
+  使われているかを追いかけることは非常に難しいことです. このことが 
+  <em/新しい形式/ のオプションの機構を採り入れる理由の背景です. 
+  ここではそれぞれのオプションはカーネルコンパイルディレクトリにある別々の 
+  <tt/.h/ ファイルとなり, <tt>opt_<em>foo</em>.h</tt> という名前に
+  されます. この方法では, 通常の Makefile の依存関係が適用され, 
+  <tt/make/ プログラムはオプションが変更された時に再コンパイルが必要な
+  ものを見つけることができます.
+
+  <p>古い形式のオプションの機構は, 局部的なオプションや実験的なオプション
+  のような一時的に利用されると考えられるオプションにおいては有効です. 
+  つまり <tt/#ifdef/ をカーネルのソースに追加するのは簡単であり, 
+  必要なことはそれで全部ですから, すぐにカーネルコンフィグオプションを
+  作ることができます. この場合, 管理者はオプションの利用において
+  依存関係を把握しておく責任があります (また, 手動でカーネルの一部分を
+  強制的に再コンパイルする必要があるかもしれません).  サポートされている
+  オプションのすべてについて一つでも変更があると, <tt/config(8)/ は
+  サポートされていないオプションがコンフィグファイルの中にあるという警告
+  を出しますが, カーネルの Makefile 内にはそれを含めます. 
+ 
+<sect><heading>ではどのようにして追加するのでしょう?</heading>
+
+  <p>最初に <tt>sys/conf/options</tt> (または
+  <tt>sys/i386/conf/options.<em>&lt;arch&gt;</em></tt>, たとえば
+  <tt>sys/i386/conf/options.i386</tt>) を編集し, 新しいオプション
+  を含めるのに最適な <tt>opt_<em>foo</em>.h</tt> ファイルを選びます. 
+
+  <p>新しいオプションの必要がなくなったとしたら, これを取り除きます.
+  たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション
+  の変更は <tt/opt_scsi.h/ に入れられます. デフォルトでは, 適切
+  なオプションファイルに単に記述されます. たとえば <tt/FOO/ であれば
+  値は対応するファイルの <tt/opt_foo.h/ に格納されます. これは右端に別
+  のファイル名を書いて置き換えることができます. 
+
+  <p>新しいオプションを加えるのに使えそうな 
+  <tt>opt_<em>foo</em>.h</tt> がない場合は新しい名前を作ってください. 
+  意味のある名前を作り <tt>options[<em>.&lt;arch&gt;</em>]</tt> ファイル
+  に新しいセクションのコメントをつけてください. <tt/config(8)/ は自動的
+  に変更を検出して, 次の実行からは (訳注: 新しい <tt/.h/) ファイル
+  を作ります. ほとんどのオプションはヘッダファイルに入れられます. 
+
+  <p>大量のオプションを一つの <tt>opt_<em>foo</em>.h</tt> にまとめると
+  コンフィグファイルの一つのオプションを変更したときに多くのファイルが
+  再コンパイルされる原因になります.
+
+  <p>新しいオプションに依存するカーネルファイルは最終的には見つけ出
+  されます. ただし, オプションを作っただけで対応するソースがどこにも
+  ない場合は別です. 
+
+<verb>
+        find /usr/src/sys -name type f | xargs fgrep NEW_OPTION
+</verb>
+  <p>オプションに対応するソースを見つけるのに上記のコマンドは便利です. 
+  見つけたすべてのファイルで編集, 追加をおこないます. 
+
+<verb>
+#include "opt_foo.h"
+</verb>
+  <p><em>ファイルの先頭の</em>, すべての <tt/#include &lt;xxx.h&gt;/
+  より前に入れます. この場合, オプションによって次のようにしてデフォルト値
+  を持たせている標準のヘッダファイル内の値を置き換えるため, 順番は非常に
+  重要です. 
+
+<verb>
+#ifndef NEW_OPTION
+#define NEW_OPTION (something)
+#endif
+</verb>
+
+
+  <p>システムヘッダファイル (たとえば <tt>/usr/include/sys/</tt> にある
+  ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します. 
+  そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include 
+  しないとオプションの値によって不整合が起きてしまう場合を除き, それらの
+  ファイルに <tt>opt_<em>foo</em>.h</tt> を include しないでください. 
+  そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法
+  ではありません.