ユーデブ

udev (ユーザー空間/dev ) は、 Linux カーネルのデバイス マネージャーです。devfsdと hotplug の後継として、udev は主に /dev ディレクトリ内のデバイス ノードを管理します。同時に、 udevは、ハードウェア デバイスがシステムに追加または削除されたときに発生するすべてのユーザー空間イベント (特定のデバイスで必要なファームウェアのロードを含む) も処理します。

オペレーティングシステムのカーネルは、ハードウェアの抽象インターフェースをソフトウェアの残りの部分に提供する役割を担っています。モノリシックカーネルであるLinuxカーネルは、まさにその役割を果たしています。デバイスドライバーはLinuxカーネルの一部であり、そのソースコードの半分以上を占めています。^{[2]ハードウェアには、}システムコールまたはデバイスノードを介してアクセスできます。

ホットプラグ対応の周辺機器をユーザーフレンドリーな方法で扱えるように、これらすべてのホットプラグ対応ハードウェア デバイスの処理の一部がカーネルからユーザー空間で実行されるデーモンに引き継がれました。ユーザー空間で実行することで、セキュリティと安定性が向上します。

デバイス ドライバーはLinux カーネルの一部であり、その主な機能には、デバイスの検出、デバイスの状態変化の検出、および同様の低レベルのハードウェア機能が含まれます。デバイス ドライバーをカーネルからメモリにロードした後、検出されたイベントはユーザー空間デーモン udevd に送信されます。デバイス マネージャーudevdは、これらすべてのイベントをキャッチし、次に何が起こるかを決定します。このため、udevd には非常に包括的な構成ファイルのセットがあり、コンピューター管理者は必要に応じてこれらをすべて調整できます。

• 新しいストレージ デバイスが USB 経由で接続された場合、カーネルによってudevdに通知され、udisksd デーモンに通知されます。その後、そのデーモンはファイル システムをマウントできます。
• 新しいイーサネット ケーブルがイーサネット NIC に差し込まれた場合、カーネルによってudevdに通知され、それ自体が NetworkManager デーモンに通知します。NetworkManager デーモンは、その NIC に対して dhclient を起動するか、手動構成に従って構成することができます。

これを行うのは複雑であるため、アプリケーション作成者はハードウェア サポート ロジックを再実装する必要がありました。一部のハードウェア デバイスでは、使用準備のために特権ヘルパー プログラムも必要でした。これらのヘルパー プログラムは、Unix のパーミッション モデルでは表現しにくい方法で呼び出す必要がある場合がよくあります (たとえば、ユーザーがビデオ コンソールにログインしている場合にのみワイヤレス ネットワークに参加できるようにするなど)。アプリケーション作成者は、 setuidバイナリを使用するか、サービスデーモンを実行して独自のアクセス制御と権限分離を提供していましたが、そのたびにセキュリティ ホールが生じる可能性がありました。^[3]

HAL はこれらの課題に対処するために作成されましたが、現在ではほとんどの Linux ディストリビューションで非推奨となっており、その機能は udevd に置き換えられています。

/devディレクトリ内のデバイス ノードが静的なファイル セットである従来のUnixシステムとは異なり、Linux udev デバイス マネージャーは、実際にシステムに存在するデバイスのノードのみを動的に提供します。devfsは同様の機能を提供していましたが、Greg Kroah-Hartman は、 devfs よりも udev を好む理由として ^[4]をいくつか挙げています。

• udev は永続的なデバイス命名をサポートします。これは、たとえば、デバイスがシステムに接続された順序に依存しません。デフォルトの udev セットアップでは、ストレージ デバイスに永続的な名前が提供されます。ハード ディスクは、一意のファイル システム ID、ディスクの名前、および接続されているハードウェア上の物理的な場所によって認識されます。
• udev は、devfs のカーネル空間とは対照的に、完全にユーザー空間で実行されます。その結果、udev は命名ポリシーをカーネルの外に移動し、ノードが作成される前に、デバイスのプロパティからデバイスの名前を作成する任意のプログラムを実行できるようになりました。この場合、プロセス全体も割り込み可能になり、低い優先度で実行されます。

udev は全体として、次の 3 つの部分に分かれています。

• デバイス情報へのアクセスを可能にするライブラリ libudev。systemd 183ソフトウェアバンドルに組み込まれました。^[5]
• 仮想/dev を管理するユーザー空間デーモン udevd。
• 診断用の管理コマンドライン ユーティリティ udevadm。

システムは、 netlinkソケットを介してカーネルから呼び出しを受け取ります。以前のバージョンでは、この目的で hotplug を使用して、 /etc/hotplug.d/ default にリンクを追加しました。

udev は、 Linux システム上でデーモンとして実行され、新しいデバイスが初期化されたり、デバイスがシステムから削除されたりした場合にカーネルが送信する uevents を ( netlinkソケット経由で) リスニングする汎用デバイスマネージャーです。udev パッケージには、検出されたデバイスのイベントおよびプロパティのエクスポートされた値と一致する広範なルール セットが付属しています。一致するルールは、デバイス ノードに名前を付けて作成し、構成されたプログラムを実行してデバイスをセットアップおよび構成します。

udev ルールは、カーネル サブシステム、カーネル デバイス名、デバイスの物理的な場所、デバイスのシリアル番号などのプロパティに一致できます。ルールでは、外部プログラムからデバイスに名前を付けるための情報を要求したり、システムによってデバイスが検出される順序に関係なく常に同じになるカスタム名を指定したりすることもできます。

かつては、Linuxシステムでudevを使用する一般的な方法は、ソケットを介してHALにイベントを送信し、HALがデバイス固有のアクションをさらに実行することでした。たとえば、HALは、D -Bus IPCシステムですべての関心のあるプロセスにブロードキャストメッセージを発行することにより、システムで実行されている他のソフトウェアに新しいハードウェアが到着したことを通知します。このようにして、 GNOMEやKデスクトップ環境3などのデスクトップは、ファイルブラウザを起動して、新しく接続されたUSBフラッシュドライブやSDカードのファイルシステムを参照できます。^[6]

^{2011年半ばまでに、HALはほとんどのLinuxディストリビューション、KDE、GNOME [7]}、Xfce ^[8]デスクトップ環境などでも廃止されました。以前HALに組み込まれていた機能はudev自体に統合されたり、udisksやupowerなどの別のソフトウェアに移行されたりしました。

• udev は、Linux デバイス ツリーへの低レベル アクセスを提供します。プログラムがデバイスとそのプロパティを列挙し、デバイスが接続されたり切断されたりしたときに通知を受け取ることを可能にします。
• dbus は、プログラムが安全かつ確実に、高レベルのオブジェクト指向プログラミング インターフェイスを使用して相互に通信できるようにするフレームワークです。
• udisks (旧称 DeviceKit-disks) は、libudev およびその他のカーネル インターフェイスの上に配置され、ストレージ デバイスへの高レベル インターフェイスを提供し、アプリケーションから dbus 経由でアクセスできるデーモンです。
• upower (旧称 DeviceKit-power) は、libudev およびその他のカーネル インターフェイスの上に配置され、電源管理への高レベル インターフェイスを提供し、dbus 経由でアプリケーションにアクセスできるデーモンです。
• NetworkManagerは、libudevやその他のカーネルインターフェース（および他のいくつかのデーモン）の上に位置するデーモンであり、ネットワーク構成とセットアップへの高レベルインターフェースを提供し、dbus経由でアプリにアクセスできます。^[9]

udev はカーネルからメッセージを受信し、それを Network Manager などのサブシステム デーモンに渡します。アプリケーションは D-Bus を介して Network Manager と通信します。

${\displaystyle {\ce {Kernel -> udev -> Network Manager <=> D-Bus <=> Firefox}}}$

HAL は廃止されており、レガシー コードでのみ使用されます。Ubuntu 10.04 は HAL なしで出荷されました。当初、新しいデーモン DeviceKit が HAL の特定の側面を置き換える予定でしたが、2009 年 3 月に、DeviceKit は廃止され、代わりに同じコードがパッケージとして udev に追加されました: udev-extras。一部の関数は現在、udev 本体に移動されています。

udev はLinux 2.5で導入されました。Linux カーネル バージョン 2.6.13 では、uevent インターフェイスの新しいバージョンが導入または更新されました。udev の新しいバージョンを使用するシステムは、udev を無効にして、デバイス アクセスに従来の/devディレクトリを使用しない限り、2.6.13 より古いカーネルでは起動しません。

2012年4月、udevのコードベースがsystemdソースツリーに統合され、systemd 183がudevを含む最初のバージョンとなった。^{[5] [10] [11]} 2012年10月、Linus TorvaldsはKay Sieversのudevメンテナンスとファームウェアの読み込みに関するバグ修正に対するアプローチを批判し、次のように述べた。^[12]

はい、カーネルで行う方が「より堅牢」です。しかし、ごまかしはやめてください。嘘はやめてください。カーネルで行う方が堅牢なのは、気にかけているメンテナーがいるからであり、また、リグレッションはいい加減に扱うべきものではないとわかっているからです。何かが壊れ、その破損に対する正しい修正方法がわからない場合は、壊れたものを元に戻します。ですから、カーネルで行う方が明らかに優れています。ファームウェアの読み込みがユーザー空間で実行できないからではありません。Greg が udev を放棄して以来、udev のメンテナンスが下降しているからです。

2012年、Gentoo Linuxプロジェクトは、systemdアーキテクチャへの依存を避けるために、systemdのudevコードベースのフォークを作成しました。その結果生じたフォークはeudevと呼ばれ、systemdなしでudevの機能を利用できるようになります。プロジェクトの目標は、eudevをLinuxディストリビューションやinitシステムから独立させることです。^[13] Gentooプロジェクトはeudevを次のように説明しています。^[14]

eudev は、OpenRCやUpstartなどの既存のソフトウェア、古いカーネル、さまざまなツールチェーン、およびユーザーやさまざまなディストリビューションで必要とされるその他のものとの互換性を向上させることを目的とした systemd-udev のフォークです。

2014 年 5 月 29 日、ファームウェアのロードはカーネルのタスクであると決定されたため、systemd から udev を介したファームウェアのロードのサポートが削除されました。^[15] 2 日後、Lennart Poettering は、このパッチを udev がkdbusを利用し始めるまで延期することを提案しました。その時点では、udev を切り替えて、基盤となるメッセージング システムとして kdbus を使用し、ユーザー空間間のネットリンク ベースのトランスポートを取り除く計画でした。^[16]

udev は、Greg Kroah-HartmanとKay Sieversによって開発され、Dan Stekloff らの多大な協力を得ました。

• 公式サイト