モジュールの確認と操作
モジュールはコマンドで一覧・調査・着脱ができます。lsmod でいま組み込まれているモジュールの一覧を見て、modinfo で個々のモジュールの情報（作者・ライセンス・依存）を調べます。組み込みは insmod（単体）か modprobe（依存も自動解決）で行い、取り外しは rmmod か modprobe -r を使います。実務では依存関係を自動でたどる modprobe を使うのが基本で、insmod / rmmod は単一の .ko を直接扱う学習・検証向けです。
前のトピックで「モジュールは着脱できる」と知った。では、その着脱は具体的にどう行うのか。
カーネルモジュールは、専用のコマンド群で一覧を見たり、中身を調べたり、組み込み・取り外しをしたりできる。デバイスドライバの開発や調査では、これらの操作が日々の基本動作になる。
やることを整理すると、「いま何が組み込まれているかを見る」「個々のモジュールの素性を調べる」「組み込む」「取り外す」の4つになる。
それぞれに対応するコマンドがあり、このうち組み込みと取り外しはシステム全体に影響するため、管理者権限（sudo）を付けて実行する必要がある。
ここでは lsmod・modinfo・insmod・rmmod・modprobe の5つを順に見ていく。どれも、操作の前後に状態を確かめることをセットにすると、何が起きたのかを目で追えて理解が早まる。
📋 いま何が動いているか — lsmod
lsmod は、現在カーネルに組み込まれているモジュールの一覧を表示するコマンドだ。
出力は3つの列から成り、左からモジュール名、そのモジュールが使っているメモリのサイズ、そして「使用カウントと、それを使っている他のモジュールの名前」が並ぶ。
とくに3列目が読み解きの鍵だ。あるモジュールを別のモジュールが頼っている（依存している）場合には、ここにその頼っている側の名前が出る。
この数字は何の役に立つのか。使用カウントが0でなければ「いま誰かに使われている最中」という意味になり、これは後で触れる「取り外しが拒まれる」現象の理由を読み解く手がかりになる。
組み込んだはずの自作モジュールがこの一覧に出てくるかどうかを見るだけでも、ロードが成功したのかどうかをすぐに確かめられる。
なお lsmod が見せている内容は、実体としては /proc/modules というファイルの情報を、人間に読みやすく整形したものだ。
🪪 素性を調べる — modinfo
lsmod が「いま何が動いているか」を教えるのに対し、modinfo は「その一個一個が何者か」を教えてくれる。
modinfo は、個々のモジュールに書き込まれた情報を取り出して表示するコマンドだ。モジュールの中には、誰が作ったのか（author）、どんなライセンスで配布されるのか（license）、何をするものなのか（description）、バージョン、受け付けるパラメータといった「自己紹介」を埋め込めるようになっていて、modinfo はそれを一覧で見せてくれる。
便利なのは、すでに組み込まれているかどうかに関わらず、.ko ファイルそのものを引数に渡して調べられる点だ。これから組み込もうとしているモジュールが何者なのか、依存している別モジュール（depends として表示される）は何か、を事前に確かめられる。
とりわけライセンスの表示は、そのモジュールがGPLを名乗っているかどうかを示し、カーネル内部の機能をどこまで利用できるかにも関わる、見落とせない情報だ。
📥 組み込む — insmod と modprobe
モジュールをカーネルに組み込む（ロードする、と言う）コマンドは2つある。なぜ2つも要るのか。
まずひとつめの insmod は、指定した .ko ファイルを「そのまま挿す」素朴なコマンドだ。sudo insmod hello.ko のようにファイルを直接指定して読み込み、成功すると登録されている初期化関数が走る。
動きが分かりやすい反面、依存関係は自分では面倒を見てくれない。あるモジュールが別のモジュールを必要としていても、insmod はそれを先に読み込んでくれないため、必要なものを手で先に組み込んでおく必要がある。
そのぶん、手元にある単一の .ko を直接扱って挙動を確かめる、という学習・検証の用途には素直で向いている。
では、その面倒な依存関係を肩代わりしてくれる道はないのか。もうひとつの modprobe が、依存関係を自動で解決してくれる賢いコマンドだ。
あらかじめ depmod という仕組みが作っておいた依存表（modules.dep というファイル）を参照し、「このモジュールにはあのモジュールが要る」と判断して、必要な別モジュールを先に組み込んでから目的のモジュールを読み込む。
指定の仕方も insmod とは異なり、ファイルのパスではなく、拡張子 .ko を付けないモジュール名で指定する。対象になるのは、/lib/modules/$(uname -r) というカーネルのバージョンごとのディレクトリの下に、正しく配置されたモジュールだけだ。
実務では、この自動的な依存解決のおかげで modprobe を使うのが基本になる。
📤 取り外す — rmmod と modprobe -r
組み込んだモジュールを取り外す（アンロードする）には、rmmod を使う。sudo rmmod hello のように、こちらも拡張子を付けないモジュール名を指定する。
成功すると、登録されている終了関数が走って後始末が行われ、モジュールがメモリから取り除かれる。
ところが、すんなり外れないことがある。なぜ拒まれるのか。そのモジュールが他のモジュールに使われている最中、つまり先ほどの lsmod で使用カウントが0でない状態だと、巻き添えで不具合が起きるのを防ぐために取り外しは拒否されるのだ。
依存関係をたどってまとめて外したいときは modprobe -r を使うと、目的のモジュールに加えて、それに引きずられて不要になった依存モジュールも併せて片付けられる。
🧭 結局、どれをいつ使えばいいのか
整理すると、依存関係を自動でたどる modprobe と modprobe -r が実務の基本であり、単一の .ko を直接扱って挙動を確かめたい学習・検証の場面では insmod と rmmod が手軽だ、ということになる。
そして、組み込みや取り外しの前後には lsmod で状態を確かめ、組み込む前には modinfo で素性を見ておく。この確認とセットにすると、何が起きたのかを目で追いながら安全に進められる。
さらに、組み込みや取り外しがうまくいかないときは、カーネルがエラーの理由をログに残していることが多いので、dmesg と組み合わせて確認するのが定石だ。
これらのコマンドはカーネルモジュールを扱うあらゆる作業の入口になる。つまずいたら、まず lsmod で状態を、dmesg で理由を見る。この2つを手に馴染ませておこう。