カーネル/Gentoo カーネルコンフィギュレーションガイド

From Gentoo Wiki
< Kernel
Jump to:navigation Jump to:search
This page is a translated version of the page Kernel/Gentoo Kernel Configuration Guide and the translation is 100% complete.
Other languages:


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

はじめに

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

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

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

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

メモ
このガイドは、最近のカーネルについて一般的なコンピューターアーキテクチャを念頭において執筆されています。より古いカーネルやより珍しいアーキテクチャではいくつかの詳細は異なっているかもしれません; しかしながら、内容の多くはその場合でもあてはまります。

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

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

設定の概念

基本

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

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

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

ビルトインかモジュールか

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

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

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

さらなる情報についてはカーネルモジュールについての記事と、カーネルを設定するために menuconfig を使う方法をお読みください。

ハードウェアサポート

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

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

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

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

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

ファームウェアを必要とするドライバは、ディスクからファームウェアをより簡単にロードできるように、モジュールとして構成するのをおすすめします。この類のドライバでよくあるのは、GPU と、ネットワーキングドライバ (ただし NFS または同様のネットワークベース rootfs を使用しない場合) です。

カーネル機能

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

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

準備はできましたか？

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

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

一般的な問題と混乱

SATA ディスクは SCSI です

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

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

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

カーネル libata用の設定オプション
Device Drivers  --->
   SCSI device support  --->
      <*> SCSI device support
      <*> SCSI disk support
      <*> SCSI CDROM support
 
      [ ] SCSI low-level drivers  --->
 
   <*> Serial ATA and Parallel ATA drivers (libata)  --->
メモ
標準的でないチップセットは上の Serial ATA and Parallel ATA drivers (libata) カーネルボックスの中の SCSI low-level drivers の下にリストされています。

USB ホストコントローラー

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

  1. UHCI は Universal Host Controller Interface です。USB 1.1 をサポートしており、通常は VIA や Intel のチップセットベースのマザーボードで見つけることができます。
  2. OHCI は Open Host Controller Interface です。USB 1.1 をサポートしており、通常は NVIDIA や SiS のチップセットベースのマザーボードで見つけることができます。
  3. EHCI は Extended Host Controller Interface です。USB 2.0 をサポートするために広く使われている唯一のホストコントローラーであり、概して USB 2.0 をサポートするあらゆるコンピューターで見つけることができます。
  4. XHCI は 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 デバイスを挿しても電源が入らなかったりどうしても反応しないなら、このケースだと判断できます。

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

root #lspci -v | grep HCI
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) (prog-if 30 [XHCI])
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) (prog-if 20 [EHCI])
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) (prog-if 20 [EHCI])
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])

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

カーネル USB HCD の設定
Device Drivers  --->
   USB support  --->
      <*> Support for Host-side USB
      ---   USB Host Controller Drivers
      <*>   xHCI HCD (USB 3.0) support
      <*>   EHCI HCD (USB 2.0) support
      < >   OHCI HCD  (USB 1.1) support
      < >   UHCI HCD (most Intel and VIA) support

Linux カーネル 3.12.13 以降では、USB コントローラーが OHCI でかつ USB キーボードやマウスを使用するなら OHCI support for PCI-bus USB controllers (USB_OHCI_HCD_PCI)を有効にする必要があります。

マルチプロセッサー、ハイパースレッディング、およびマルチコアシステム

多くのコンピューターシステムは複数のプロセッサーをベースにしていますが、必ずしもすぐにそれとわかるというわけではありません。

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

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

カーネル マルチプロセッシングサポート用の設定
Processor type and features  --->
 [*] Symmetric multi-processing support
 [*]   SMT (Hyperthreading) aware nice priority and policy support
 [*]   Multi-core scheduler support (NEW)

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

カーネル マルチプロセッサーシステム用の電源管理
Power management and ACPI options  --->
 [*] ACPI (Advanced Configuration and Power Interface) Support

x86 大容量メモリーのサポート

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

メモ
この制約は x86 (IA32)アーキテクチャに特有のものです。他のアーキテクチャは設定の微調整の必要なしに大量のメモリを本来サポートしています。

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

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

カーネル x86 での大容量メモリーのサポートを有効にする
Processor type and features  --->
 High Memory Support  --->
  (X) 4GB
  ( ) 64GB

圧縮されたカーネルモジュール

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

ファイル /etc/portage/package.use/kmodkmod の圧縮サポートを有効にする
sys-apps/kmod lzma zlib

sys-apps/kmodを再度 emerge します:

root #emerge --ask --oneshot --changed-use sys-apps/kmod

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

カーネル モジュールの圧縮を有効化する
[*] Enable loadable module support --->
  Module compression mode () --->
    ( ) None
    (X) GZIP
    ( ) XZ
    ( ) ZSTD

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

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

root #depmod -a
root #modprobe <module_name>

カーネル設定の略記法

はじめに

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

CONFIG_FOO を現実の設定の位置に変換する

CONFIG_TMPFS_XATTR という機能を有効化する必要があると仮定しましょう。カーネル設定メニューを起動し(make menuconfig)、/ キーを押します。これで検索ボックスが開くはずです。検索ボックスに CONFIG_TMPFS_XATTR と打ち込んでください。

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

カーネル "CONFIG_TMPFS_XATTR"をmenuconfigで検索した結果
Symbol: TMPFS_XATTR [=n]
Type  : boolean
Prompt: Tmpfs extended attributes
  Defined at fs/Kconfig:138
  Depends on: TMPFS [=y]
  Location:
    -> File systems
      -> Pseudo filesystems
(1)     -> Virtual memory file system support (former shm fs) (TMPFS [=y])
  Selected by: TMPFS_POSIX_ACL [=n] && TMPFS [=y]

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

記載 詳細
Symbol: TMPFS_XATTR [=n] 検索されたカーネルの設定項目を識別します。この設定が現在有効になっていない ([=n])ことも表示されています。
Type: boolean 検索された設定は boolean (つまり、この設定は2つのオプションのいずれかになります: 有効か、無効か)です。いくつかの設定は数値や文字列です。
Prompt: Tmpfs extended attributes .config ファイルの変数 (TMPFS_XATTR) を制御する make menuconfig の項目に表示されるテキストです。これは本質的に、より人間にとって読みやすい形式の変数名です。
Depends on: TMPFS [=y] この項目が見られるようにするには CONFIG_TMPFS を有効にする必要があります。今回は ([=y]となっているので) 既にそうなっていますが、そうでない場合はまず CONFIG_TMPFS を探す (そして有効にする) 必要があります。
Location: ... make menuconfig の構造の中でこの設定が見つかる位置です。探している設定は Tmpfs extended attributes であることを覚えておいてください。
Selected by: TMPFS_POSIX_ACL [=n] && TMPFS [=y] ここに記されている設定がいずれも有効になっている場合(今回は1つ目がそうなっていません)、CONFIG_TMPFS_XATTR は自動的に有効になり、これらの設定の1つが無効化されない限り無効にすることはできなくなります。

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

  1. Depends on フィールドに記されている設定を有効化する
  2. Location: が指す場所に移動する
  3. Prompt: で参照されている値を切り替える
ヒント
括弧の中にある数字を見てください; ユーザーは検索中にその番号を押すことでそのオプションまたは有効化されたメニューのなるべく近くにジャンプできます。上の例では、キーボードの 1 を押すとそのオプションの近くにジャンプします。

他のカーネル設定についての文書

ここまで、一般的な概念とカーネル設定に関連した特定の問題までしか説明していません: より正確な詳細はユーザーの探索に委ねられています。しかしながら、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. (もしまだマウントされていなければ) /boot をマウントする
  4. 新しいカーネルイメージを /boot にコピーする
  5. ブートローダーが新しいカーネルを参照するようにする
  6. 再起動

これらの最終段階のうち 1 つが欠けると、変更は正しく反映されないでしょう。

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

root #uname -v
#4 SMP PREEMPT Sat Jul 15 08:49:26 BST 2006

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

root #ls -l /usr/src/linux/arch/i386/boot/bzImage
-rw-r--r-- 1 dsd users 1504118 Jul 15 08:49 /usr/src/linux/arch/i386/boot/bzImage

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

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

モジュールが自動的にロードされない

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

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

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

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

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

関連項目


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Daniel Drake, Curtis Napier, Justin Robinson, Lukasz Damentko, Jonathan Smith, nightmorph
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.

Retrieved from "https://wiki.gentoo.org/index.php?title=Kernel/Gentoo_Kernel_Configuration_Guide/ja&oldid=1282211"