Linux Certif

Toute la documentation sur la certification Linux LPI

depmod

名前

depmod - ローダブルカーネルモジュールの依存関係の記述を扱う

書式

depmod [-aA] [-ehnqrsuvV] [-C configfile] [-F kernelsyms] [-b basedirectory] [forced_version]
depmod [-enqrsuv] [-F kernelsyms] module1.o module2.o ...

説明

depmod および modprobe は、 Linux のモジュール化カーネルを管理するための、 ユーザー・管理者・ディストリビューションメンテナ向けユーティリティである。

depmod は、コマンドラインで指定されたモジュール (あるいは設定ファイルで指定されたディレクトリにあるモジュール) のセットにあるシンボルに基づき、 "Makefile" 的な依存関係ファイルを作成する。

depmod の普通の使い方は、 /etc/rc.d にある rc ファイルのどれかに

/sbin/depmod -a

という行を入れることである。 これにより、正しいモジュールの依存関係をシステムの起動直後に使用できる。 現在は -a オプションは省略可能である。 起動時には、 -q オプションの方がより適切である。 こちらは解決できなかったシンボルに関するワーニングを出力しない。

新しいカーネルのコンパイル直後に依存関係ファイルを作成することもできる。 例えば 2.2.98 カーネルのもとで カーネル 2.2.99 とそのモジュールを初めてコンパイルしたとき、 "depmod -a 2.2.99" とすれば、正しい位置にファイルが作成される。 しかしこの場合、 カーネルへの依存関係は正しいとは保証されない。 この扱いに関しては、上記の -F, -C, -b 各オプションの説明を参照のこと。

モジュールと、他のモジュールからエクスポートされたシンボルとの関係を 構築する際に、 depmod はモジュールやエクスポートされたシンボルの GPL 状態を考慮しない。 つまり、depmod は GPL 互換でないライセンスのモジュールが GPL 専用シンボル (カーネル中の EXPORT_SYMBOL_GPL)を参照してもエラーを出さない。 しかし、insmod は 非 GPL モジュールを GPL 専用シンボルで解決することを 拒否するので、実際の読み込みは失敗する。

オプション

-a, --all

設定ファイル /etc/modules.conf があれば、そこで指定されている全てのディレクトリでモジュールを検索する。

-A, --quick

ファイルのタイムスタンプを比較し、さらに必要ならば depmod -a と同じように振る舞う。 このオプションは、何か変更があった場合にのみ 依存関係ファイルを更新する。

-e, --errsyms

各モジュールごとに、解決されていない全てのシンボルを表示する。

-h, --help

オプションの一覧を表示して直ちに終了する。

-n, --show

依存関係ファイルを/lib/modules以下ではなく標準出力に書き出す。

-q, --quiet

quiet モード。見付からないシンボルがあっても文句を言わない。

-r, --root

ユーザによっては、モジュールを root 以外のユーザー ID でコンパイルし、 そのモジュールを root でインストールすることがある。 このプロセスでは、モジュールの所有者が root 以外のユーザー ID のままになることがある (ディレクトリの所有者が root であっても)。 非 root のユーザー ID を許してしまうと、 侵入者がそのユーザー ID 保有のモジュールを置き換えることが 可能になるかもしれず、 これをきっかけに root アクセスを奪取されてしまうかもしれない。

デフォルトでは、 modutils は root の所有でないモジュールの利用を 拒否しようとする。 -r を指定すると、このエラーを抑制し、 root 以外の所有するモジュールを root がロードできるようになる。

-r の利用は大きなセキュリティ上の危険を招く可能性があり、推奨できない。

-s, --syslog

全てのエラーメッセージを、標準出力ではなく syslog デーモン経由で書き出す。

-u, --unresolved-error

depmod 2.4 は解決できないシンボルがあったときには返り値を設定しない。 次の modutils のメジャーリリース (2.5) では、 解決できないシンボルに対して返り値を設定する予定である。 modutils 2.4 に対して非ゼロの返り値を期待している ディストリビューションもあるが、 この変更は古い動作を期待しているユーザに対して問題を引き起こすかもしれない。 depmod 2.4 に非ゼロの返り値を希望する場合は -u を指定すること。 depmod 2.5 は -u フラグを黙って無視し、 解決できないシンボルがあった場合には常に非ゼロの返り値を戻す。

-v, --verbose

各モジュールを処理するごとに、それらのモジュールの名前を表示する。

-V

depmod のバージョンを表示する。

以下のオプションは、ディストリビューションを管理する人々に便利であろう。

-b basedirectory, --basedir basedirectory

環境を変更するために、モジュールのサブツリーが含まれるディレクトリツリー /lib/modules をどこか別の場所に移したい場合、 その移動された /lib/modules イメージを探す場所を -b オプションを使って depmod に伝える。 depmod が出力するファイル modules.dep におけるファイル参照は、 basedirectory パスを含まない。 すなわち、最終的なディストリビューションでファイルツリーが basedirectory/lib/modules から /lib/modules に戻されても、全ての参照は正しく利用できる。

-C configfile, --config configfile

configfile を /etc/modules.conf の代わりに用いる。 環境変数 MODULECONF を使っても、設定ファイルを /etc/modules.conf (あるいは /etc/conf.modules (使わないほうが良い)) 以外に指定できる。

環境変数

UNAME_MACHINE をセットすると、modutils は uname() システムコールの machine フィールドの 代わりにこの変数の値を用いる。 これは主に 32 ビットユーザー空間で 64 ビットモジュールをコンパイルする (またはその逆)場合に用いる。 現在の modutils はモジュールに対する完全なクロスビルドモードに対応しておらず、 ホストアーキテクチャの 32 ビット版と 64 ビット版を選択できるだけである。

-F kernelsyms,--filesyms kernelsyms

現在実行されているカーネルとは 別のカーネルに対して依存関係ファイルを作成する場合、 depmod に正しいカーネルシンボルのセットを利用させ、 各モジュールのカーネル参照を正しく解決させることが重要である。 これらのシンボルには、他のカーネルの System.map のコピーか、あるいは /proc/ksyms の出力のコピーを使える。 利用しているカーネルがバージョン付きのシンボルを使っている場合は、 /proc/ksyms の出力を用いるのがもっともよい。なぜならこのファイルには カーネルシンボルのシンボルバージョンが含まれているからである。 しかしバージョン付きのシンボルに対して System.map を使ってもかまわない。

設定

depmod と modprobe の動作は、設定ファイル /etc/modules.conf によって調整できる (このファイルは無くても良い)。 詳細は modprobe(8) および modules.conf(5) を参照のこと。

方針

新しいカーネルをコンパイルして、 コマンド "make modules_install" を実行すると、 新しいディレクトリが作成されるがデフォルトは変更されない。

カーネル配布に含まれないモジュールを利用したい場合は、 そのファイルは、 /lib/modules 以下の、 カーネルバージョンに関係しないディレクトリに置くのが良い。

これはデフォルトの方針であるが、 /etc/modules.conf によって変更できる。

ファイル

 /etc/modules.conf(あるいは/etc/conf.modules(非推奨)),
 /lib/modules/*/modules.dep,
 /lib/modules/*
 

関連項目

modules.conf(5), modprobe(8), modinfo(8), lsmod(8), ksyms(8)

バグ

depmod [ -V | --version ] は直ちに終了するべきである。 しかしながら、現在はバージョン情報を表示した後、 何もオプションが指定されなかったかのように振舞う。

著者

Jacques Gelinas (jack@solucorp.qc.ca)
Bjorn Ekwall (bj0rn@blox.se)