% % This is part of CLFSja package. % % This is a CTIE change file for the original XML source of the CLFSbook. % @x @y @z @x Device and Module Handling on a CLFS System @y デバイスとモジュールの扱いについて @z @x usage @y 利用方法 @z @x In , we installed the Eudev package. Before we go into the details regarding how this works, a brief history of previous methods of handling devices is in order. @y にて Eudev パッケージをインストールしました。 このパッケージがどのように動作するかの詳細を説明する前に、デバイスを取り扱うかつての方法について順を追って説明していきます。 @z @x History @y 開発経緯 @z @x Static Device Nodes @y スタティックデバイスノード @z @x Linux systems in general traditionally use a static device creation method, whereby a great many device nodes are created under /dev (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually exist. This is typically done via a MAKEDEV script, which contains a number of calls to the mknod program with the relevant major and minor device numbers for every possible device that might exist in the world. @y Linux システムは一般に、スタティックなデバイス生成方法を採用していました。 この方法では /dev のもとに膨大な量の (場合によっては何千にもおよぶ) デバイスノードが生成されます。 現実に存在するハードウェアデバイスが存在するかどうかに関わらずです。 これは MAKEDEV スクリプトを通じて生成されます。 このスクリプトからは mknod プログラムが呼び出されますが、その呼び出しは、この世に存在するありとあらゆるデバイスのメジャー/マイナー番号を用いて行われます。 @z @x Devfs @y Devfs ファイルシステム @z @x In February 2000, a new filesystem called devfs, which dynamically created device nodes as devices were found by the kernel, was merged into the 2.3.46 kernel and was made available during the 2.4 series of stable kernels. Although it was present in the kernel source itself, this method of creating devices dynamically never received overwhelming support from the core kernel developers. @y 2000年2月に新しいファイルシステム devfs がカーネル 2.3.46 に導入され、2.4系の安定版カーネルにて利用できるようになりました。 このファイルシステムはカーネルのソース内に含まれ実現されていましたが、デバイスを動的に生成するこの手法は、主要なカーネル開発者の十分な支援は得られませんでした。 @z @x The main problem with the approach adopted by devfs was the way it handled device detection, creation, and naming. The latter issue, that of device node naming, was perhaps the most critical. It is generally accepted that if device names are allowed to be configurable, then the device naming policy should be up to a system administrator, not imposed on them by any particular developer(s). The devfs file system also suffered from race conditions that were inherent in its design and could not be fixed without a substantial revision to the kernel. It was marked deprecated with the release of the 2.6 kernel series, and was removed entirely as of version 2.6.18. @y devfs が採用した手法で問題になるのは、主にデバイスの検出、生成、命名の方法です。 特にデバイスの命名方法がおそらく最も重大な問題です。 一般的に言えることとして、デバイス名が変更可能であるならデバイス命名の規則はシステム管理者が考えることであって、特定の開発者に委ねるべきことではありません。 また devfs にはその設計に起因した競合の問題があるため、根本的にカーネルを修正しなければ解消できる問題ではありません。 そこでカーネル 2.6 系において保守されることがなかったために非推奨 (deprecated) として位置づけられ、最終的にカーネル 2.6.18 から取り除かれました。 @z @x Sysfs @y Sysfs ファイルシステム @z @x With the development of the unstable 2.5 kernel tree, later released as the 2.6 series of stable kernels, a new virtual filesystem called sysfs came to be. The job of sysfs is to export a view of the system's hardware configuration to userspace processes. Drivers that have been compiled into the kernel directly register their objects with sysfs as they are detected by the kernel. For drivers compiled as modules, this registration will happen when the module is loaded. Once the sysfs filesystem is mounted (on /sys), data which the built-in drivers registered with sysfs are available to userspace processes. With this userspace-visible representation, the possibility of seeing a userspace replacement for devfs became much more realistic. @y 開発版の 2.5 系カーネルと、後にリリースされた安定版のカーネル 2.6 系を経て、新しい仮想ファイルシステム sysfs が登場しました。 sysfs が実現したのは、システムのハードウェア設定をユーザー空間のプロセスとして表に出したことです。 カーネルに直接組み込まれて構築されたドライバーの場合は、対象のオブジェクトをカーネルが検出し、そのオブジェクトを sysfs に登録します。 モジュールとしてコンパイルされたドライバーの場合は、その登録がモジュールのロード時に行われます。 sysfs ファイルシステムが (/sys に) マウントされると、ドライバーによって sysfs に登録されたデータは、ユーザー空間のプロセスにて利用可能となります。 ユーザー空間での設定を可視化したことによって devfs が為していたことを、ユーザー空間にて開発することが可能になったわけです。 @z @x Udev Implementation @y Udev の実装 @z @x Shortly after the introduction of sysfs, work began on a program called Udev to advantage of it. The udev daemon made calls to mknod() to create device nodes in /dev dynamically, based on the information from sysfs, in /sys. For example, /sys/class/tty/vcs/dev contains the string 7:0. This string was used by udev to create a device node with major number 7 and minor number 0. @y sysfs の概要を示しましたが、さっそくながら Udev の話に入ります。 Udev には優位な特徴があります。 udev デーモンが mknod() を呼び出すことによりファイルシステム sysfs/sys ディレクトリにある情報に基づいて /dev 内に動的にデバイスノードを生成します。 例えば /sys/class/tty/vcs/dev というファイルには7:0という文字列が含まれています。 この文字列を udev が読み取り、メジャー番号 7 、マイナー番号 0 のデバイスノードを生成します。 @z @x Linux kernel version 2.6.32 introduced a new virtual file system called devtmpfs, an improved replacement for devfs. This allows device nodes to once again be dynamically created by the kernel, without many of the problems of devfs. As of version 176, Udev no longer creates device nodes itself, instead relying on devtmpfs to do so. @y Linux カーネル 2.6.32 になって新たに仮想ファイルシステム devtmpfs が導入されました。 これは devfs を改良したものです。 これによって数々の devfs 上での問題は解消され、カーネルによって何度でもデバイスノードを再生成できるようにもなりました。 Udev 176 以降、Udev はデバイスノード自体は生成しなくなり、devtmpfs がそれを行うようになりました。 @z @x Systemd and Eudev @y Systemd と Eudev @z @x In 2010, development began on systemd, an alternate init implementation. Starting with Udev 183, Udev's source tree was merged with systemd. Several Gentoo developers who disagreed with this merge announced a project fork called Eudev in December 2012, created by extracting the Udev code from systemd. One of the goals of Eudev is to allow for easier installation and usage of udevd without the need for the rest of systemd. @y 2010年になると systemd が開発されるようになりました。 これは init に代わるものです。 Udev 183 からは、そのソースが systemd にマージされます。 Gentoo 開発者の中にこのマージに反対する方々がおり、2012年12月にプロジェクトをフォークして Eudev の開発に分かれました。 そこでは Systemd から Udev のコード部分を抜き出して開発が進められています。 Eudev の開発目標は udevd のインストールもその利用も簡易なものとすることです。 そしてそれが Systemd の他の機能部分の助けを得ることなく実現できることです。 @z @x Device Node Creation @y デバイスノードの生成 @z @x By default, device nodes created by the kernel in a devtmpfs are owned by root:root and have 600 permissions. udevd can modify ownership and permissions of the nodes under the /dev directory, and can also create additional symlinks, based on rules specified in the files within the /etc/udev/rules.d, /lib/udev/rules.d, and /run/udev/rules.d directories. The names for these files start with a number, to indicate the order in which they are run, and they have a .rules extension (udevd will ignore files with any other extension). All of the rules files from these directories are combined into a single list, sorted by filename, and run in that order. In the event of a conflict, where a rules file with the same name exists in two or more of these directories, the rules in /etc take the highest priority, followed by rules files in /run, and finally /lib. Any device for which a rule cannot be found will just be ignored by udevd and be left at the defaults defined by the kernel, as described above. @y デバイスノードはカーネルにより devtmpfs ファイルシステム内に作り出されます。 デフォルトでデバイスノードの所有者は root:root でありパーミッションは 600 です。 udevd/dev 内のノードについてその所有とパーミッションを変更できます。 また /etc/udev/rules.d, /lib/udev/rules.d, /run/udev/rules.d の各ディレクトリ内にあるファイルが示す規則に基づいて、シンボリックリンクを追加することができます。 この規則を示すファイルの名前は数字で始まります。 その数値が実行順を表わします。 そして .rules という拡張子を持ちます。 (Udev はこれ以外の拡張子は無視します。) 各ディレクトリ内のこの規則ファイルは名前順に並び替えられ一つのリストとして統合されて、その順に実行されます。 上記ディレクトリのいずれかにて同一名称の規則ファイルが存在した場合は /etc にある規則ファイルが最優先に扱われます。 次に /run にあるファイル、最後に /lib にあるファイルが採用されます。 規則ファイルが見つからなかったデバイスは udevd が無視します。 そして上に示したようにカーネルにより定義されたデフォルト値のままとなります。 @z @x Module Loading @y モジュールのロード @z @x Device drivers compiled as modules may have aliases built into them. Aliases are visible in the output of the modinfo program and are usually related to the bus-specific identifiers of devices supported by a module. For example, the snd-fm801 driver supports PCI devices with vendor ID 0x1319 and device ID 0x0801, and has an alias of pci:v00001319d00000801sv*sd*bc04sc01i*. For most devices, the bus driver exports the alias of the driver that would handle the device via sysfs. E.g., the /sys/bus/pci/devices/0000:00:0d.0/modalias file might contain the string pci:v00001319d00000801sv00001319sd00001319bc04sc01i00. The default rules provided by Eudev will cause udevd to call out to /sbin/modprobe with the contents of the MODALIAS uevent environment variable (that should be the same as the contents of the modalias file in sysfs), thus loading all modules whose aliases match this string after wildcard expansion. @y モジュールとしてコンパイルされたデバイスドライバーの場合、デバイス名の別名が作り出されています。 その別名は modinfo プログラムを使えば確認することができます。 そしてこの別名は、モジュールがサポートするバス固有の識別子に関連づけられます。 例えば snd-fm801 ドライバーは、ベンダーID 0x1319 とデバイスID 0x0801 の PCI ドライバーをサポートします。 そしてpci:v00001319d00000801sv*sd*bc04sc01i*というエイリアスがあります。 たいていのデバイスでは、sysfs を通じてドライバーがデバイスを扱うものであり、ドライバーのエイリアスをバスドライバーが提供します。 /sys/bus/pci/devices/0000:00:0d.0/modalias ファイルならばpci:v00001319d00000801sv00001319sd00001319bc04sc01i00という文字列を含んでいるはずです。 Eudev が提供するデフォルトの生成規則によって udevd から /sbin/modprobe が呼び出されることになり、その際には uevent に関する環境変数 MODALIAS の設定内容が利用されます。 (この環境変数の内容は sysfs 内の modalias ファイルの内容と同じはずです。) そしてワイルドカードが指定されているならそれが展開された上で、エイリアス文字列に合致するモジュールがすべてロードされることになります。 @z @x In this example, this means that, in addition to snd-fm801, the obsolete (and unwanted) forte driver will be loaded if it is available. See below for ways in which the loading of unwanted drivers can be prevented. @y 上の例で forte ドライバーがあったとすると、snd-fm801 の他にそれもロードされてしまいます。 これは古いものでありロードされて欲しくないものです。 不要なドライバーのロードを防ぐ方法については後述しているので参照してください。 @z @x The kernel itself is also able to load modules for network protocols, filesystems and NLS support on demand. @y カーネルは、ネットワークプロトコル、ファイルシステム、NLS サポートといった各種モジュールも、要求に応じてロードすることもできます。 @z @x Problems with Loading Modules and Creating Devices @y モジュールロードとデバイス生成の問題 @z @x There are a few possible problems when it comes to automatically creating device nodes. @y 自動的にデバイスが生成される際には、いくつか問題が発生します。 @z @x A kernel module is not loaded automatically @y カーネルモジュールが自動的にロードされない問題 @z @x Eudev will only load a module if it has a bus-specific alias and the bus driver properly exports the necessary aliases to sysfs. In other cases, one should arrange module loading by other means. With Linux-&linux-version2;, Eudev is known to load properly-written drivers for INPUT, IDE, PCI, USB, SCSI, SERIO and FireWire devices. @y Eudev がモジュールをロードできるためには、バス固有のエイリアスがあって、バスドライバーが sysfs に対して適切なエイリアスを提供していることが必要です。 そうでない場合は、別の手段を通じてモジュールのロードを仕組まなければなりません。 Linux-&linux-version2; においての Eudev は、INPUT、IDE、PCI、USB、SCSI、SERIO、FireWire の各デバイスに対するドライバーをロードします。 それらのデバイスドライバーが適切に構築されているからです。 @z @x To determine if the device driver you require has the necessary support for Eudev, run modinfo with the module name as the argument. Now try locating the device directory under /sys/bus and check whether there is a modalias file there. @y 目的のデバイスドライバーが Eudev に対応しているかどうかは、modinfo コマンドに引数としてモジュール名を与えて実行します。 /sys/bus ディレクトリ配下にあるそのデバイス用のディレクトリを見つけ出して、modalias ファイルが存在しているかどうかを見ることで分かります。 @z @x If the modalias file exists in sysfs, the driver supports the device and can talk to it directly, but doesn't have the alias, it is a bug in the driver. Load the driver without the help from Eudev and expect the issue to be fixed later. @y sysfsmodalias ファイルが存在しているなら、そのドライバーはデバイスをサポートし、デバイスとの直接のやり取りが可能であることを表します。 ただしエイリアスを持っていなければ、それはドライバーのバグです。 その場合は Eudev に頼ることなくドライバーをロードするしかありません。 そしてそのバグが解消されるのを待つしかありません。 @z @x If there is no modalias file in the relevant directory under /sys/bus, this means that the kernel developers have not yet added modalias support to this bus type. With Linux-&linux-version2;, this is the case with ISA busses. Expect this issue to be fixed in later kernel versions. @y /sys/bus ディレクトリ配下の対応するディレクトリ内に modalias ファイルがなかったら、これはカーネル開発者がそのバス形式に対する modalias のサポートをまだ行っていないことを意味します。 Linux-&linux-version2; では ISA バスがこれに該当します。 最新のカーネルにて解消されることを願うしかありません。 @z @x Eudev is not intended to load wrapper drivers such as snd-pcm-oss and non-hardware drivers such as loop at all. @y Eudev は snd-pcm-oss のようなラッパー (wrapper)ドライバーや loop のような、現実のハードウェアに対するものではないドライバーは、ロードすることができません。 @z @x A kernel module is not loaded automatically, and Eudev is not intended to load it @y カーネルモジュールが自動的にロードされず Eudev もロードしようとしない問題 @z @x If the wrapper module only enhances the functionality provided by some other module (e.g., snd-pcm-oss enhances the functionality of snd-pcm by making the sound cards available to OSS applications), configure modprobe to load the wrapper after Eudev loads the wrapped module. To do this, add an install line to a file in /etc/modprobe.d. For example: @y ラッパー (wrapper)モジュールが単に他のモジュールの機能を拡張するだけのものであるなら (例えば snd-pcm-osssnd-pcm の機能拡張を行うもので、OSS アプリケーションに対してサウンドカードを利用可能なものにするだけのものであるため) modprobe の設定によってラッパーモジュールを先にロードし、その後でラップされるモジュールがロードされるようにします。 これは以下のように /etc/modprobe.d/ ディレクトリ内のファイルにてinstallの記述行を加えることで実現します。 @z @x If the module in question is not a wrapper and is useful by itself, configure the S05modules bootscript to load this module on system boot. To do this, add the module name to the /etc/sysconfig/modules file on a separate line. This works for wrapper modules too, but is suboptimal in that case. @y 問題のモジュールがラッパーモジュールではなく、単独で利用できるものであれば、 S05modules ブートスクリプトを編集して、システム起動時にこのモジュールがロードされるようにします。 これは /etc/sysconfig/modules ファイルにて、そのモジュール名を単独の行に記述することで実現します。 この方法はラッパーモジュールに対しても動作しますが、この場合は次善策となります。 @z @x Eudev loads some unwanted module @y Eudev が不必要なモジュールをロードする問題 @z @x Either don't build the module, or blacklist it in /etc/modprobe.d file as done with the forte module in the example below: @y 不必要なモジュールはこれをビルドしないことにするか、あるいは /etc/modprobe.d/にてブラックリスト化します。 例えば forte モジュールをブラックリストに登録するには以下のようにします。 @z @x Blacklisted modules can still be loaded manually with the explicit modprobe command. @y ブラックリストに登録されたモジュールは modprobe コマンドを使えば手動でロードすることもできます。 @z @x Eudev makes a wrong symlink @y Eudev が誤ったシンボリックリンクを生成する問題 @z @x This usually happens if a rule unexpectedly matches a device. For example, a poorly-written rule can match both a SCSI disk (as desired) and the corresponding SCSI generic device (incorrectly) by vendor. Find the offending rule and make it more specific, with the help of udevadm info. @y デバイス生成規則が意図したデバイスに合致していないと、この状況が往々にして起こります。 例えば生成規則の記述が不十分であった場合、SCSI ディスク (本来望んでいるデバイス) と、それに対応づいたものとしてベンダーが提供する SCSI ジェネリックデバイス (これは誤ったデバイス) の両方に生成規則が合致してしまいます。 記述されている生成規則を探し出して正確に記述してください。 その際には udevadm info コマンドを使って情報を確認してください。 @z @x Eudev rule works unreliably @y Eudev 規則が不審な動きをする問題 @z @x This may be another manifestation of the previous problem. If not, and your rule uses sysfs attributes, it may be a kernel timing issue, to be fixed in later kernels. For now, you can work around it by creating a rule that waits for the used sysfs attribute and appending it to the /etc/udev/rules.d/10-wait_for_sysfs.rules file. Please notify the CLFS Development list if you do so and it helps. @y この問題は、一つ前に示したものが別の症状となって現れたものかもしれません。 そのような理由でなく、生成規則が正しく sysfs の属性を利用しているのであれば、それはカーネルの処理タイミングに関わる問題であって、カーネルを修正すべきものです。 今の時点では、該当する sysfs の属性の利用を待ち受けるような生成規則を生成し、/etc/udev/rules.d/10-wait_for_sysfs.rules ファイルにそれを追加することで対処できます。 もしこれを実施してうまくいった場合は CLFS 開発メーリングリストにお知らせください。 @z @x Device naming order changes randomly after rebooting @y 再起動後にデバイスの命名順がランダムに変わってしまう問題 @z @x This is due to the fact that Eudev, by design, handles uevents and loads modules in parallel, and thus in an unpredictable order. This will never be fixed. You should not rely upon the kernel device names being stable. Instead, create your own rules that make symlinks with stable names based on some stable attributes of the device, such as a serial number or the output of various *_id utilities installed by Eudev. See and for examples. @y これは Eudev の設計仕様に従って発生するもので、uevent の扱いとモジュールのロードが平行して行われるためです。 このために命名順が予期できないものになります。 これを固定的にすることはできません。 ですからカーネルがデバイス名を固定的に定めるようなことを求めるのではなく、シンボリックリンクを用いた独自の生成規則を作り出して、そのデバイスの固定的な属性を用いた固定的な名前を用いる方法を取ります。 固定的な属性とは例えば Eudev によってインストールされるさまざまな *_id という名のユーティリティが出力するシリアル番号などです。 設定例については を参照してください。 @z @x Useful Reading @y 参考情報 @z @x Additional helpful documentation is available at the following sites: @y さらに参考になるドキュメントが以下のサイトにあります: @z @x A Userspace Implementation of devfs @y devfs のユーザー空間での実装方法 @z @x The sysfs Filesystem @y sysfs ファイルシステム @z