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が使用されていないため有効化する必要があります.

When not using libata for IDE disks check for DMA usage and enable it. The following command can be used to determine if DMA is being used:

To enable DMA for older IDE devices (which is a deprecated setting), enable the following kernel features.

USB host controllers
USB is a widely adopted bus for connecting external peripherals to a computer. One of the reasons behind the success of USB is that it is a standardized protocol, however the USB host controller devices (HCDs) implemented on the host computer do vary a little. There are 4 main types:


 * 1)   is the Universal Host Controller Interface. It supports USB 1.1, and is usually found on motherboards based on a VIA or Intel chipset.
 * 2)   is the Open Host Controller Interface. It supports USB 1.1 and is usually found on motherboards based on an Nvidia or SiS chipset.
 * 3)   is the Extended Host Controller Interface. It is the only common host controller to support USB 2.0, and can typically be found on any computer that supports USB 2.0.
 * 4)   is the eXtensible Host Controller Interface. It is the host controller for USB 3.0 and is compatible with USB 1.0, 1.1, 2.0, 3.0 and future speeds. Enable this feature when the board supports USB 3.0.

Most systems come with two of the above interface types: XHCI (USB 3.0) and EHCI (USB 2.0). To use USB devices, it is no longer necessary to select both options since XHCI is compatible with slower USB-controllers. Users can also enable EHCI to be "extra" safe; it does no harm if USB 2.0 controllers are unavailable.

If the relevant options corresponding to the USB HCD types present on the system are not selected, then 'dead' USB ports may be experienced. This case can be determined if a working USB device is plugged in, but it does not get power or respond in any way.

A neat trick (from the  package) makes it relatively easy to detect which HCDs are present on system. Ignoring the SATA controller which was also matched, it is easy to spot that this system requires EHCI and XHCI support:

Select the HCDs present on the system. In general select all three options for maximum support, or if the correct option is uncertain:

In Linux kernel 3.12.13 and later,   has to be enabled if the USB controller is OHCI and a USB keyboard or mouse is used.

Multiprocessor, Hyper-Threading and multi-core systems
Many computer systems are based on multiple processors, but not always in an immediately obvious way.


 * Many of Intel's CPUs support a technology which they call hyper-threading. This technology enables a single CPU to be viewed by the system as two logical processors.
 * Most Intel/AMD CPUs actually consist of multiple physical processors inside a single package, these processors are known as multi-core processors.
 * Some high-end computer systems actually have multiple physical processors installed on specialized motherboards to provide a significant performance increase over a uniprocessor system. System users will probably know if they have such a system, since they are not cheap.

In all of these cases, the appropriate kernel options must be selected to obtain optimum performance from these setups:

The next option not only enables power management features, but might also be a requirement for making all CPUs available to the system:

x86 High Memory support
Due to limitations in the 32-bit address space of the architecture, a kernel with default configuration can only support up to 896 MB RAM. If a system has more memory, only the first 896 MB will be visible, unless high memory support has been enabled.

High memory support is not enabled by default, because it introduces a small system overhead. Do not be distracted by this, the overhead is insignificant when compared to the performance increase of having more memory available!

Choose the 4 GB option, unless the system has more than 4 GB of RAM:

Compressed kernel modules
From kernel version 3.18.x (and up) compression of kernel modules has been possible. gzip and xz compression are available. It is important to emerge with the proper USE flags before compiling a kernel with compressed modules:

Re-emerge :

Enable module compression and select a preferred compression method:

Usually runs. If did not have the proper USE flags set (see the  step above) the first time it was run, then the dependency list will be empty. The system will therefore be unable to load any modules that were built compressed.

After kmod has been recompiled, re-run as a solution to this problem:

はじめに
When reading about kernel configuration, often times settings are described as CONFIG_. This short-hand notation is what the kernel configuration actually uses internally, and is what will be found in the kernel configuration file (be it or in the auto-generated  file). Of course, using short-hand notation would not do much good if this cannot translate this to the real location in the kernel configuration. The tool makes this possible.

Translating CONFIG_FOO to the real configuration location
Suppose the CONFIG_TMPFS_XATTR feature needs to be enabled. Launch the kernel configuration menu and press the  key. This will open a search box. In the search box, type CONFIG_TMPFS_XATTR.

The following is an output of the result of this search:

This output yields lots of interesting information.

With this information, it should be possible to translate any CONFIG_* requirements fairly easily. In short, it means a user must:


 * 1) Enable the settings described in the Depends on field
 * 2) Navigate where Location: points
 * 3) Toggle the value referred to by Prompt:

Other kernel configuration documentation
So far only general concepts and specific problems related to kernel configuration has been discussed; precise details have been left up to the user to discover. However, other parts of the Gentoo documentation collection provide specialized details for the topics at hand.

Such documents may be helpful while configuring specific areas of the kernel. Although this warning was mentioned previously in this guide, remember: users who are new to kernel configuration should not be adventurous when attempting to configure their kernels. Start by getting a basic system up and running, support for audio, printing, etc., can always be added at a later date.

Getting the basics of a kernel operational will help users in later configuration steps because the user will know what is breaking their system and what is not. It is always wise to save the base (working) kernel configuration in a folder other than the kernel's sources folder before attempting to add new features or hardware.


 * 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.