Kernel/Gentoo Kernel Configuration Guide/ja

この文書は手動でのカーネル設定の概念を紹介することを目的とし、また最も一般的な設定の落とし穴のいくつかを詳しく説明します.

はじめに
Gentoo はカーネルの設定、インストール、アップグレードを処理する2つの方法をユーザーに提供します: 自動(genkernel)と手動です. 自動的な方法がほとんどのユーザーにとってより容易であると考えられるにもかかわらず、Gentooユーザーの多くがカーネルの手動設定を選ぶのにはたくさんの理由があります:


 * 1) よりよい柔軟性
 * 2) より小さな(カーネルの)サイズ
 * 3) より短いコンパイル時間
 * 4) 学習経験
 * 5) ひどい退屈
 * 6) カーネル設定の絶対的な知識
 * 7) 完全なコントロール

このガイドでは自動的な方法(genkernel)は扱いません. genkernel を使った方法でカーネル関係のことを処理したい場合は、Genkernel の記事に進んで詳細を確認してください.

このガイドは手動設定の過程を始まりから終わりまですべて文書化することは意図していません - 設定の過程は常識や使っているシステムについての相対的に高度な技術的知識に大いに依存しているからです. その代わりに、このガイドでは手動設定の概念を紹介し、またユーザーが直面するもっとも一般的な落とし穴について詳細を説明します.

この時点で、ユーザーは解凍済みの Linux kernel のソースをハードディスク(通常は の下のどこか)に持っているものと推定します. また、 設定ユーティリティに入る方法や ncurses ベースのメニューシステム内を移動する方法を知っていることが期待されます. ユーザーがまだこの段階に達していないなら、他の文書がお役に立てるでしょう. 以下の記事を読んでからこのガイドに戻って来てください:


 * カーネルソースの概要の記事には Portage ツリーで利用可能なさまざまなカーネルソースパッケージの情報が含まれています.
 * カーネルのアップグレードの記事では、カーネルをアップグレードしたりあるカーネルから別のカーネルに切り替える方法を説明しています.
 * Gentoo ハンドブックのカーネル設定の節はカーネルのインストールの一側面を扱っています. 適切なアーキテクチャを選択して"カーネルの設定"という節に移動してください.

基本
一般的な過程は実際のところかなり単純です: 各メニューとサブメニューに分類された一連のオプションが提示され、希望するハードウェアサポートやそのシステムに関係のあるカーネルの機能を選択します.

カーネルはあるソースのセットについて menuconfig を初めて実行した時に提示されるデフォルト設定を含んでいます. デフォルトは一般的に広汎で賢明ですので、ユーザーの多くは基本設定にわずかな変更を加えるだけで足ります. カーネルのデフォルト設定で有効化されているオプションを無効化しようとする場合には、そのオプションが正確に何をするのか、またそれを無効化した結果についてよく理解するようにしてください.

初めての Linux カーネルの設定の間は、保守的であるように心がけ、冒険的になりすぎないようにし、またできるだけデフォルト設定へ加える変更を少なくするようにしましょう. 同時に、システムの設定の中にはシステムが実際にブートできるようにするためカスタマイズしなければならない部分があることを覚えておいてください.

ビルトインかモジュールか
多くの設定オプションは3つの状態をとります: それらはまったくビルドしない  か、カーネル内に直接ビルドするか  、またはモジュールとしてビルドするか   になります. ビルトインの項目はカーネルイメージ自体の中に直接ビルドされるのに対し、モジュールは外部のファイルシステムに保管されます.

ビルトインとモジュールとの間には重要な違いがあります: いくつかの例外はありますが、カーネルはシステムがモジュールを必要とするときでも一切のモジュールについてロードを全く試みません; いつモジュールをロードするか、あるいはいつロードしないかの決定はユーザーに委ねられています. システムの他のある部分には必要に応じてロードする機能があるかもしれませんし、自動的にモジュールをロードするユーティリティもいくつかありますが、ハードウェアサポートやカーネル機能はカーネル内に直接ビルドすることをおすすめします. そうすれば、カーネルは機能やハードウェアサポートを必要な時に利用可能にしておけます. これは、各カーネル機能を  にセットすることで実現できます. こうした構成を一貫させるためには、カーネル内ファームウェアのサポートも含める必要があります. このためにはカーネルの で   と   をセットするか、または以下のようにします:

設定の他の部分では、ビルトインが絶対的な要件になっています. たとえば root パーティションが btrfs ファイルシステムの場合、btrfs がモジュールとしてビルドされているとシステムはブートできません. (モジュールは root パーティションに保管されているため)システムは btrfs モジュールを探すために root パーティションを見なければなりませんが、btrfs サポートが既にロードされていない限り root パーティションは見られないのです！ btrfs がビルトインされていなければ init プロセスは root デバイスの探索に失敗するでしょう.

ハードウェアサポート
システムのアーキテクチャタイプの検知よりほかには、設定ユーティリティは実際にシステムでどのようなハードウェアが提供されているか識別しません. いくつかのハードウェアサポートにはデフォルト設定がありますが、ほぼ間違いなくユーザーは各システムのハードウェア構成に関連する設定オプションを探し、選択する必要があります.

適切な設定オプションを選択するにはコンピューター内部にある、あるいは接続されたコンポーネントの知識が必要になります. たいていの場合、これらのコンポーネントはシステムの蓋を開けることなく識別可能です. ほとんどの内部コンポーネントについては、ユーザーは販売時の製品名ではなく各デバイスで使われているチップセットを識別する必要があります. 多くの拡張カードは一定のブランド名で売られていますが、他の製造業者のチップセットを使用しています.

ユーザーがどのカーネル設定オプションを使うか決める助けになるユーティリティーがいくつかあります. ( パッケージの一部)はPCIおよびAGPベースのハードウェアを識別します. これにはマザーボード自体に内蔵されたコンポーネントも含まれます. ( パッケージにあります)はシステムのUSBポートに接続されたさまざまなデバイスを識別します.

状況はハードウェアの世界における標準化の度合いによっていくらかわかりにくくなっています. ユーザーがデフォルト設定から極端に逸脱しようとしたのでなければ、IDE ハードディスクは　PS/2 や USB のキーボードとマウスと同様、とにかく使えるはずです. 基本的な VGA ディスプレイサポートも含まれています. しかしながら、イーサネットアダプターのようないくつかのデバイスはほとんど全く標準化されていません; これらのデバイスについては、ネットワークアクセスを得るためにはユーザーがイーサネットチップセットを識別し、特定のカードについて適切なハードウェアサポートを選択する必要があります.

加えて、いくつかのものはデフォルト設定で大体動作するものの、システムの潜在能力を引き出すためにはより特化したオプションを選択する必要があるでしょう. たとえば、適切な IDE チップセットのサポートが有効化されていないと IDE ハードディスクはとても低速に動作するでしょう.

カーネル機能
ハードウェアサポートに加えて、ユーザーはカーネル内で必要なソフトウェア機能を決める必要があります. そのような機能の重要な一例はファイルシステムのサポートです: ユーザーは自身のハードディスクで使用しているファイルシステムのサポートを選択しなければいけません. 外部ストレージデバイスで使用するファイルシステム(例: USB ドライブ上の VFAT)についても同様です.

もう一つの一般的なソフトウェア機能の例は応用的なネットワーク機能です. ある種のルーティングやファイヤーウォールを行うには関連する設定項目をカーネル設定に含める必要があります.

準備はできましたか？
これで概念は説明し終わりました. システムのハードウェアの識別、menuconfig インターフェースのブラウジング、そしてシステムに必要なカーネルオプションの選択を簡単に始められるはずです.

このガイドの残りの部分では、一般的な混乱を解消し、どのようにしてユーザーがしばしば直面する一般的な問題を避けるかについての助言を提供します. 皆さんの成功をお祈りしています！

SATA ディスクは SCSI です
最も現代的なデスクトップシステムは旧式な IDE (リボンケーブル) バスではなくSerial ATA バスのストレージデバイス(ハードディスクや CD/DVD ドライブ)を備えています.

Linux の SATA サポートは SCSI サブシステムの下に位置する libata と呼ばれるレイヤーで実装されています. このため、SATA ドライバーは設定の SCSI driver の項にあります. さらにシステムのストレージデバイスは SCSI デバイスとして扱われるため、SCSI ディスク/CDROM サポートも必要になります. 最初の SATA ハードディスクは と命名され、また最初の SATA CD/DVD ドライブは  と命名されます.

これらのドライバーの多くは SATA コントローラー向けですが、libata は SATA に特有のものとして設計されたわけではありません. すべての一般的な IDE ドライバーも近い将来に libata に移行するでしょう. その時点で上で述べた注意事項は IDE ユーザーにも適用されるようになります.

IDE チップセットと DMA
SATAの導入にもかかわらずIDE デバイスはいまだ非常に一般的であり、多くのシステムがこれを信頼しています. IDE はかなり汎用的な技術なので、Linux はほぼすべての IDE コントローラーをコントローラー特有のオプションが何も選択されていなくてもそのまま動作するようにサポートしています.

しかしながら、IDE は古い技術であり初期のProgrammed Input/Outputを実現したものなので、現代のストレージデバイスへの高速なアクセスに必要な転送レートを提供できません. 汎用 IDE ドライバーはこれらの PIO 通信モードに限定されているので、低速なデータ転送レートとディスクとの通信時の顕著に高い CPU 使用率をもたらします.

ユーザーが1995年以前のシステムを取り扱っているのでない限り、IDE コントローラーはDirect Memory Access (DMA)として知られている代替の転送モードもサポートしているでしょう. DMA はとてもとても高速で、またデータ転送中であっても CPU の使用にほとんど影響しません. システムがIDEディスクを使用している際に全体的に本当に貧弱なパフォーマンスで悩まされている場合、おそらくDMAが使用されていないため有効化する必要があります.

IDE ディスクで libata を使用していない場合、DMA が使用されているか確認して有効化してください. 以下のコマンドを使用して DMA が使用されているか判断できます:

DMA を古い IDE デバイス(非推奨になっている設定)で有効化するには、以下のカーネル機能を有効化します.

USB ホストコントローラー
USB はコンピューターに外部周辺機器を接続するために広く採用されているバスです. USB の成功の背後にある理由の一つはそれが標準化されたプロトコルであることですが、ホストコンピューターで実装されている USB host controller devices (HCDs) には少し違いがあります. 主に4つの種類があります:


 * 1)   は Universal Host Controller Interface です. USB 1.1 をサポートしており、通常は VIA や Intel のチップセットベースのマザーボードで見つけることができます.
 * 2)   は Open Host Controller Interface です. USB 1.1 をサポートしており、通常は Nvidia や SiS のチップセットベースのマザーボードで見つけることができます.
 * 3)   は Extended Host Controller Interface です. USB 2.0 をサポートするために広く使われている唯一のホストコントローラーであり、概して USB 2.0 をサポートするあらゆるコンピューターで見つけることができます.
 * 4)   は eXtensible Host Controller Interface です. USB 3.0 用のホストコントローラーであり、USB 1.0、1.1、2.0、3.0 および次世代のスピードと互換性があります. ボードがUSB 3.0 をサポートしている場合これを選択してください.

多くのシステムは上記のインターフェースのうち2つを持っています: XHCI (USB 3.0) および EHCI (USB 2.0) です. XHCI はより低速な USB コントローラーと互換性があるので、USB デバイスを使うために両方のオプションを選択する必要はもはやありません. ユーザーは更なる安全のために EHCI も有効化することができます; USB 2.0 コントローラーがなくてもこれによる害はありません.

システムで提供されている USB HCD に対応する関連オプションが選択されていない場合、'死んだ' USB ポートを体験することになるでしょう. 動作している USB デバイスを挿しても電源が入らなかったりどうしても反応しないなら、このケースだと判断できます.

(に含まれます) を使ったうまいやり方で、どの HCD がシステムで提供されているか比較的簡単に調べることができます. 同様にマッチした SATA コントローラーを無視すれば、このシステムが EHCI や XHCI のサポートを必要としているか見分けるのは簡単です:

システムで提供されている HCD を選択します. 一般的に、最大のサポートを得るためには、あるいは正しいオプションが不確かな場合には、3つのオプションすべてを選択してください:

Linux カーネル 3.12.13 以降では、USB コントローラーが OHCI でかつ USB キーボードやマウスを使用するなら  を有効にする必要があります.

マルチプロセッサー、ハイパースレッディングおよびマルチコアシステム
多くのコンピューターシステムは複数のプロセッサーをベースにしていますが、必ずしもすぐにそれとわかるというわけではありません.


 * Intel の CPU の多くは彼らがハイパースレッディングと呼ぶ技術をサポートしています. この技術は1つの CPU をシステムからは2つの論理プロセッサーに見せることができます.
 * ほとんどの Intel/AMD の CPU は実際には1つのパッケージの中にある複数の物理プロセッサーから構成されており、こうしたプロセッサーはマルチコアプロセッサーとして知られています.
 * いくつかのハイエンドなコンピューターシステムでは、ユニプロセッサーシステムに比べ顕著なパフォーマンスの改善を提供するために実際に複数の物理プロセッサーが特殊なマザーボード上にインストールされています. 安価なものではないので、システムユーザーはこのようなシステムを持っていればおそらくそのことをわかっているでしょう.

これらすべてのケースで、構成から最適なパフォーマンスを得るためには適切なカーネルオプションを選択する必要があります:

次のオプションは電源管理機能を有効化するだけでなく、すべての CPU をシステムで利用可能にするための必要条件でもあります:

x86 大容量メモリーのサポート
アーキテクチャの32ビットアドレス空間の制約のため、デフォルト設定のカーネルは最大896MBの RAM しかサポートできません. 大容量メモリーサポートが有効化されていない限り、システムがもっと大容量のメモリーを搭載していても見えるのは最初の896MBのみです.

大容量メモリーのサポートはシステムにわずかなオーバーヘッドをもたらすため、デフォルトでは有効になっていません. これに惑わされないでください、このオーバーヘッドはより多くのメモリーが使用可能になることによるパフォーマンスの改善に比べれば些細なことです！

システムに4GBを超えるメモリーがあるのでなければ、4GBのオプションを選択しましょう:

圧縮されたカーネルモジュール
カーネルのバージョン 3.18.x (以上)では、カーネルモジュールの圧縮が可能になっています. gzip と xz 圧縮が利用できます. カーネルを圧縮されたモジュールありでコンパイルする前に、適切な USE フラグと共に を emerge することが重要です:

If is a directory, the following is an alternative:

を再度 emerge します:

モジュールの圧縮を有効化し、希望する圧縮方法を選択します:

通常、 は を実行します. 初めて実行したときに で適切な USE フラグがセットされていない(上の  の手順を参照)場合、依存関係リストは空になります. したがって、システムは圧縮ビルドされたすべてのモジュールをロードできなくなるでしょう.

この問題への解決策として、kmod を再コンパイルした後 を再実行してください:

はじめに
カーネル設定についての文章を読んでみると、しばしば設定が CONFIG_ のように表記されています. この略記法はカーネル設定の内部で実際に使用されているもので、カーネルの設定ファイル( か、または自動生成された の中にあります)でも見られるものです. もちろん、略記法の使用はそれをカーネル設定の中の実際の場所に変換できなければあまり役には立ちません. ツールではそれが可能です.

CONFIG_FOO を現実の設定の位置に変換する
CONFIG_TMPFS_XATTR という機能を有効化する必要があると仮定しましょう. カーネル設定メニューを起動し、 キーを押します. これで検索ボックスが開くはずです. 検索ボックスに CONFIG_TMPFS_XATTR と打ち込んでください.

以下はその検索結果の出力です:

この出力は多くの興味深い情報をもたらしてくれます.

この情報を使って、すべての必要な CONFIG_* をかなり簡単に変換できるはずです. 要するに、ユーザーは以下の事をしなければなりません:


 * 1) Depends on フィールドに記されている設定を有効化する
 * 2) Location: が指す場所に移動する
 * 3) Prompt: で参照されている値を切り替える

他のカーネル設定についての文書
ここまで、一般的な概念とカーネル設定に関連した特定の問題までしか説明していません: より正確な詳細はユーザーの探索に委ねられています. しかしながら、Gentoo のドキュメントコレクションの他の文書は手近な話題に特化した詳細を提供しています.

こうした文書はカーネルの特定分野を設定する際に役に立つかもしれません. このガイドで既に触れた警告ではありますが、もう一度思い出してください: カーネル設定に慣れていないユーザーは設定を試みるにあたって冒険的にならないようにしましょう. まずは基本的なシステムを立ち上げ走らせることから始めてください、オーディオや印刷その他のサポートは後でいつでも追加できます.

カーネルの基礎部分を使用できるようにすることで、ユーザーは何をするとシステムが壊れるか、また何ならそうならないかがわかるようになるので、後ほどの設定過程で助けになるでしょう. 新しい機能やハードウェアを追加する前に基本の(動作する)カーネル設定をカーネルのソールフォルダー以外のフォルダーに保存しておくのは、常に賢明なことです.


 * ALSA の記事はサウンドカードのサポートに必要な設定オプションを詳しく説明しています. ALSA は、モジュールとしてビルドしないというスキームの例外であることに注意してください: ALSA は実際のところモジュールになっている方が設定がはるかに簡単になります.


 * Bluetooth の記事では Bluetooth デバイスを使用するために必要なオプションが詳細に解説されています.


 * IPv6 router guide では、カーネルを次世代のネットワークアドレススキームを使ったルーティング用に設定する方法を説明しています.


 * 3Dグラフィックの性能を改善するために nVidia のクローズドソースのグラフィックドライバーを使うなら、nVidia Guide がそうしたシステムで選択すべき、あるいはすべきでないオプションをリストしています.


 * 数ある中でも、電力管理ガイド はカーネルを CPU の周波数スケーリングやサスペンド、ハイバネート機能のために設定する方法を説明しています.


 * PowerPC システムを実行している場合、PPC FAQ には PPC カーネル設定についてのいくつかの節があります.


 * 印刷ガイドは Linux で印刷をサポートするのに必要なカーネルオプションをリストしています.


 * USB ガイド は、キーボード、マウス、ストレージデバイス、USB プリンターといった一般的な USB デバイスを使うのに必要な設定について詳しく説明しています.

設定の変更が反映されない
設定変更をするのはユーザーにとってはよくあることですが、そうはいっても新しく設定したカーネルに実際にブートする過程で小さなミスをすることもあります. 再設定したばかりのものとは別のカーネルイメージでリブートしてしまい、解決しようとしていた問題がまだ存在することに気付いて、その設定変更では問題が解決されなかったと結論づけてしまうのです.

カーネルをコンパイル、インストールする過程はこの文書の範囲外です; 一般的な手引きについてはカーネルアップグレードガイドを参照してください. 簡単に言うと、変更されたカーネルを得る過程は以下のとおりです: 1. 設定する、2. コンパイルする、3. (もしまだマウントされていなければ) をマウントする、4. 新しいカーネルイメージを にコピーする、5. ブートローダーが新しいカーネルを参照するようにする、6. 再起動. これらの最終段階のうち1つが欠けると、変更は正しく反映されないでしょう.

ブートしたカーネルがハードディスク上の新しくコンパイルしたカーネルと一致しているか確認することができます. これはカーネルをコンパイルした日時を検証することで行います. システムアーキテクチャが 、カーネルソースが にインストールされていると仮定すると、以下のコマンドが使用できます:

上のコマンドは現在ブートしているカーネルがコンパイルされた日時を表示します.

上のコマンドはハードディスク上のカーネルイメージが最後にコンパイルされた日時を表示します.

上の各コマンドのタイムスタンプが2分以上違っていたら、それはカーネルの再インストールの間にミスが起こり、システムが新たに変更されたカーネルイメージからブートされなかったことを示しています.

モジュールが自動的にロードされない
この文書で先ほど触れたように、カーネルの設定システムはカーネルのコンポーネントをビルトイン  ではなくモジュール   として選択した際の大きな振舞いの変化を明示していません. 数多くのユーザーがこの罠に引っかかるので、このことはもう一度繰り返しておく価値があるでしょう.

コンポーネントをビルトインとして選択すると、コードはカーネルイメージ (bzImage) の中にビルドされます. そのコンポーネントを使用する必要があるときには、カーネルはユーザーの介在なしに自動的にそれを初期化しロードできます.

コンポーネントをモジュールとして選択すると、コードはカーネルモジュールファイルの中にビルドされファイルシステムにインストールされます. 一般的に、そのコンポーネントを使用する必要があるときでも、カーネルはそれを見つけることができません. いくつかの例外はありますが、カーネルは実際にこれらのモジュールをロードしようとはしません — この作業はユーザーに任されています.

ネットワークカードのサポートをモジュールとしてビルドしたのにネットワークにアクセスできないと気付いたのなら、それはおそらくモジュールがロードされていないせいです — 手動で行うか、あるいはブート時にモジュールが自動的にロードされるようにシステムを設定しなければなりません.

他のやり方にする理由がユーザーにない限り、カーネルが自動的にこれらのちょっとした設定をできるようにコンポーネントをカーネルイメージの中に直接ビルドすることで、いくらかの時間が節約できます.

参考

 * genkernel - カーネルや initramfs のビルド工程を自動化するために使用されるツール.
 * proc filesystem (Security Handbook) - カーネルパラメーターや変数を実行中に動的に変更する.