「Modalias」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) |
Kusanaginoturugi (トーク | 投稿記録) (→modalias ファイルとは何か?: 校正) |
||
30行目: | 30行目: | ||
pci:v00008086d000024DBsv0000103Csd0000006Abc01sc01i8A |
pci:v00008086d000024DBsv0000103Csd0000006Abc01sc01i8A |
||
− | + | ほれ、この通り、PCI を見ることができます!それはわかるけど、その後の全ての意味不明な部分は何でしょうか? |
|
この意味不明な部分は実際には構造化されたデータです。繰り返しの文字/数字のパターンに気付くでしょう。これを分解して読みやすくします: |
この意味不明な部分は実際には構造化されたデータです。繰り返しの文字/数字のパターンに気付くでしょう。これを分解して読みやすくします: |
||
2023年5月29日 (月) 11:04時点における版
この文書は、Linux カーネルとモジュールがハードウェアをどのように認識し理解し、それがどのように sysfs の 'modalias' に変換されるかの入門ガイドです。
目次
modalias とは何か
Modalias は、ハードウェア情報を 'modalias' という名前のファイルにエクスポートする小さな sysfs のトリックです。このファイルは、通常のハードウェアが公開する情報のフォーマットされた形式を単純に含んでいます。
$ cat /sys/devices/pci0000:00/0000:00:1f.1/modalias
pci:v00008086d000024DBsv0000103Csd0000006Abc01sc01i8A
modalias ファイルとは何か?
上述の通り、modalias ファイルは、特定のハードウェアがすでにカーネルに伝えている情報を単純に公開します。このファイルは、この情報を公開するための構造を単純に指定します。上記の例に戻りましょう:
$ cat /sys/devices/pci0000:00/0000:00:1f.1/modalias
pci:v00008086d000024DBsv0000103Csd0000006Abc01sc01i8A
それを 1 つずつ分解してみましょう。まず、ファイル名、/sys/devices/pci0000:00/0000:00:1f.1/modalias
:
- pci0000:00は最初の PCI バスの id です。ほとんどのマシンではこれが唯一の PCI バスになりますが、pci0000:01 や pci0000:02 に拡張する可能性があります - 具体的な数字は重要ではなく、おそらく PCI バスは 1 つしか持っていないと推測されます(ヒント:
ls /sys/devices/pci*
で確認してみてください) - 0000:00:1f.1 は PCI バス上の特定のデバイスのインデックスです。具体的には、これはバス 0000:00 上にあり、インデックス 1f.1 を持っています。
- これらの数値がどこから来たのか知りたいのでなければ、これらはすべて重要なことではありません。 完全を期すために、
lspci
の出力をチェックすると、同じ情報が表示されます:
$ lspci
00:1f.1 IDE interface: Intel Corp.: Unknown device 24db (rev 02)
さて、デバイス 00:1f.1 のこの modalias ファイルの内容を覗いてみましょう:
pci:v00008086d000024DBsv0000103Csd0000006Abc01sc01i8A
ほれ、この通り、PCI を見ることができます!それはわかるけど、その後の全ての意味不明な部分は何でしょうか? この意味不明な部分は実際には構造化されたデータです。繰り返しの文字/数字のパターンに気付くでしょう。これを分解して読みやすくします:
v 00008086 d 000024DB sv 0000103C sd 0000006A bc 01 sc 01 i 8A
これらの識別子と、対応する 16 進数は、特定のデバイスが公開する情報の一部を表します。始めに、v は ベンダー ID であり、d は デバイス ID です - これらは非常に標準的な数字です。事実、hwdetect のようなツールはこれら、そして他の sysfs ファイルを使用して、デバイスに関する情報を提供します。ベンダー ID やデバイス ID を基に特定のハードウェアの識別を調べるウェブサイトさえ見つけることができます、例えば、https://devicehunt.com/
これらの数字をここでも見ることができます:
$ lspci -n
00:1f.1 Class 0101: 8086:24db (rev 02)
上記に列挙した v と d トークンに 8086:24db が一致しているのが分かりますか?
言及しておくべきは、sv と sd はベンダーとデバイスの "サブシステム" バージョンです。これらは大半の時間無視されます。主に、ハードウェア開発者が全体としてのデバイスを変えない内部の微妙な違いを区別するために使用されます。
bc(基本クラス)と sc(サブクラス)は、lspci
に表示される "クラス" を作成するために使用されます。順番に "bcsc" です。これはデバイスクラスで、かなり一般的です。この場合、"クラス" は通常の lspci
出力で調べられます。"Class 0101" が "IDE Interface" にマップされているのが見て取れます (lspci
はベンダーとデバイスの id も調べます - 8086 は "Intel Corp." にマップされ、24DB は 'Unknown Device' にマップされます、へへ)
i は "プログラミングインターフェース" で、これはいくつかのデバイスクラスに対してのみ意味を持ちます。
How is this information used?
Ok, now we all know what this information is. A bunch of obscure numbers that each device exposes. Big deal. How does this matter when talking about modules?
One thing which people tend to ignore, is all the work depmod
does. When you run depmod
, it builds a series of "map" files in /lib/modules/`uname -r`
which tell modprobe how to handle certain things it needs to do. In this case we can ignore most of them. The important one is modules.alias
. This file contains aliases, or secondary names for modules. Just for a demonstration, let us look at aliases for, say, snd_intel8x0m:
$ grep snd_intel8x0m /lib/modules/$(uname -r)/modules.alias
alias pci:v00008086d00002416sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d00002426sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d00002446sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d00002486sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d000024C6sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d000024D6sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d0000266Dsv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d000027DDsv*sd*bc*sc*i* snd_intel8x0m alias pci:v00008086d00007196sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00001022d00007446sv*sd*bc*sc*i* snd_intel8x0m alias pci:v00001039d00007013sv*sd*bc*sc*i* snd_intel8x0m alias pci:v000010DEd000001C1sv*sd*bc*sc*i* snd_intel8x0m alias pci:v000010DEd00000069sv*sd*bc*sc*i* snd_intel8x0m alias pci:v000010DEd00000089sv*sd*bc*sc*i* snd_intel8x0m alias pci:v000010DEd000000D9sv*sd*bc*sc*i* snd_intel8x0m
Hey, wait! I recognize that! That's the vendor/device id information from before!
Yes, it is. It is a rather simple format of "alias <something> <actual module>". In fact, you can alias just about anything you want. I can add "alias boogabooga snd_intel8x0m" and then safely "modprobe boogabooga".
The "*" indicates it will match anything, much like filesystem globbing (ls somedir/*
). As stated before, most aliases ignore sv, sd, bc, sc, and i by way of the "*" matching.
Where does this modules.alias file come from?
Ok, now you may be thinking "Well, hardware probe used to look things up based on a device table, what makes this any different?"
The difference is that this lookup table is not static. It is not maintained by hand. In fact, it is built dynamically whenever you run depmod
. "Where does this information come from?", you ask? Why, from the kernel modules themselves. When you think about it, each specific module should know what hardware it supports, as it is coded specifically for that hardware. I mean, the nvidia module developers know that their module only work with Nvidia (vendor) Graphics Cards (class). In fact, the module actually exports this information. It says "Hey, I can support this:".
$ modinfo nvidia filename: /lib/modules/2.6.14-ARCH/kernel/drivers/video/nvidia.ko license: NVIDIA alias: char-major-195-* vermagic: 2.6.14-ARCH SMP preempt 686 gcc-4.1 depends: agpgart alias: pci:v000010DEd*sv*sd*bc03sc00i00*
As you can see by the alias listed, it looks specifically for vendor "10DE" (Nvidia) and bc/sc 0300 (which is most likely 'graphics cards'). In fact, if you look at the modinfo for snd_intel8x0m:
$ modinfo snd_intel8x0m filename: /lib/modules/2.6.14-ARCH/kernel/sound/pci/snd-intel8x0m.ko author: Jaroslav Kysela <perex@suse.cz> description: Intel 82801AA,82901AB,i810,i820,i830,i840,i845,MX440; SiS 7013; NVidia MCP/2/2S/3 modems license: GPL vermagic: 2.6.14-ARCH SMP preempt 686 gcc-4.1 depends: snd-ac97-codec,snd-pcm,snd-page-alloc,snd alias: pci:v00008086d00002416sv*sd*bc*sc*i* alias: pci:v00008086d00002426sv*sd*bc*sc*i* alias: pci:v00008086d00002446sv*sd*bc*sc*i* alias: pci:v00008086d00002486sv*sd*bc*sc*i* alias: pci:v00008086d000024C6sv*sd*bc*sc*i* alias: pci:v00008086d000024D6sv*sd*bc*sc*i* alias: pci:v00008086d0000266Dsv*sd*bc*sc*i* alias: pci:v00008086d000027DDsv*sd*bc*sc*i* alias: pci:v00008086d00007196sv*sd*bc*sc*i* alias: pci:v00001022d00007446sv*sd*bc*sc*i* alias: pci:v00001039d00007013sv*sd*bc*sc*i* alias: pci:v000010DEd000001C1sv*sd*bc*sc*i* alias: pci:v000010DEd00000069sv*sd*bc*sc*i* alias: pci:v000010DEd00000089sv*sd*bc*sc*i* alias: pci:v000010DEd000000D9sv*sd*bc*sc*i*
It matches the aliases found by 'grep'ing the alias file. These aliases exported by each module, are gathered by depmod
and merged into the modules.alias
file dynamically. There is no hand-changing of a lookup table, as it is built on-the-fly. Each module knows exactly what it supports, and therefore depmod
can use that information to help load modules.
How does udev work?
udev is closely tied with sysfs (the filesystem which exposes the modalias in the firstplace). In fact, to load modules based on the modalias when a new device is added (or when udev is first started on boot), it is insanely simple:
DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}"
Yep, that's it. It is a one-liner. This simple line, which is part of the default udev rules replace hotplug. Amazing, is it not?
See also
This article shows others modalias templates, i.e. for usb, dmi and acpi subtypes
- Modalias strings - a practical way to map "stuff" to hardware by Petter Reinholdtsen