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 することが重要です:

を再度 emerge します:

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

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

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

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

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

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

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

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


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

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

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

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


 * The ALSA article details the configuration options required for sound card support. Note that ALSA is an exception to the suggested scheme of not building things as modules: ALSA is actually much easier to configure when the components are modular.


 * The Bluetooth article details the options needed in order to use Bluetooth devices.


 * The IPv6 router guide describes how to configure the kernel for routing using the next generation network addressing scheme.


 * If the closed-source nVidia graphics drivers will be used for improved 3D graphics performance, the nVidia Guide lists the options that should and should not be selected on such a system.


 * Amongst other things, the Power Management guide explains how to configure the kernel for CPU frequency scaling, and for suspend and hibernate functionality.


 * If running a PowerPC system, the PPC FAQ has a few sections about PPC kernel configuration.


 * The Printing guide lists the kernel options needed to support printing in Linux.


 * The USB Guide details the configuration settings required to use common USB devices such as keyboards, mice, storage devices, and USB printers.

Configuration changes do not take effect
It is very common for users to make a configuration change, but then make a small mistake in the process of actually booting to their newly configured kernel. They reboot into a kernel image that is not the one they just reconfigured, observe that whatever problem they were trying to solve is still present, and conclude that the configuration change does not solve the problem.

The process of compiling and installing kernels is outside the scope of this document; refer to the Kernel Upgrade Guide for general guidance. In short, the process to get a modified kernel is the following: 1) configure, 2) compile, 3) mount (if not already mounted), 4) copy new kernel image to, 5) Make sure the bootloader will reference the new kernel, 6) reboot. If one of those final stages has been missed, then the changes will not properly take effect.

It is possible to verify if the kernel that has booted matches the newly kernel compiled on the hard disk. This is performed by examining the date and time of the kernel's compilation. Assuming the system architecture is and the kernel sources are installed at, the following command can be used:

The above command will display the date and time the currently booted kernel was compiled.

The above command displays the date and time that the kernel image on the hard disk was last compiled.

If the time stamps from the above commands differ by more than 2 minutes, it indicates a mistake was made during kernel reinstallation and the system has not booted from the newly modified kernel image.

Modules do not get loaded automatically
As mentioned earlier in this document, the kernel configuration system hides a large behavioral change when selecting a kernel component as a module  rather than built-in. It is worth repeating this again because so many users fall into this trap.

When selecting a component as built-in, the code is built into the kernel image (bzImage). When the kernel needs to use that component, it can initialize and load it automatically, without any user intervention.

When selecting a component as a module, the code is built into a kernel module file and installed on the filesystem. In general, when the kernel needs to use that component, it will not be able to find it. With some exceptions, the kernel makes no effort to actually load these modules — this task is left up to the user.

If building support for a network card as a module, and it is discovered the network is not accessible, it is probably because the module is not loaded — either this must be done manually or the system must be configured to autoload the module at boot time.

Unless a user has reason to do otherwise, some time can be saved by building these components directly into the kernel image, so that the kernel can automatically configure these small settings by itself.

参考

 * genkernel - A tool used to automate the build process of the kernel and initramfs.
 * proc filesystem (Security Handbook) - Dynamically change kernel parameters and variables on the fly.