「udev」を使用する代替手段はありますか？

私はudevの素晴らしさを理解し、開発者の努力に感謝していますが、それに代わるものがあるのか​​どうか疑問に思っていました。

たとえば、システム（ハードウェアの変更なし）でとにかくほとんど同じであるほとんどのデバイスノードを作成するスタートアップスクリプトを作成する方法があるはずだと思います。

スキップしudevたい利点または理由は、スキップの場合と同じですdbus。つまり、複雑さを軽減し、それによってシステムをより安全にセットアップするための変更を増やします。

そこにはさまざまな選択肢がudevあります。どうやらGentooはと呼ばれるものを使用できるようですmdev。別のオプションは、udev前任者の使用を試みることdevfsdです。最後に、必要なすべてのデバイスファイルをいつでも作成できますmknod。

後者では、他のオプションのように一時ファイルシステムではなくディスク上にノードを作成できるため、ブート時にすべてを作成する必要がないことに注意してください。もちろん、新しいハードウェア（USBスティックなど）を接続すると、デバイスファイルを動的に作成する柔軟性が失われます。この時代の標準的なアプローチは、合理的に必要となる可能性のあるすべてのデバイスファイル/dev（つまり、多数のデバイスファイル）を作成することだったと思います。

もちろん、これらのアプローチのいずれかを現代のディストリビューションで機能させるのは難しいでしょう。Gentoo wikiはmdev、デスクトップ環境で作業するのが難しいことについて言及しています（Gentooの外部はもちろんです）。最後のdevfsdリリースは2002年で、最新のカーネルでも動作するかどうかはわかりません。ノードを手動で作成することはおそらく最も実行可能なアプローチですがudev、特にdistosを使用する場合は、無効化することさえ難しい場合がありますsystemd（udev現在、の一部でsystemdあり、強い依存関係を示唆しています）。

私のアドバイスは固執しudevます;）

最新のLinuxカーネルは、カーネルがそれらを検出するとすぐにすべてのデバイスノードを動的に作成するdevtmpfsファイルシステム^{（古代と混同しないでくださいdevfs）を}サポートします。（実際、最新のudevリリースではこれが必要です。udevはもはやデバイスノードを作成せず、シンボリックリンクのみを作成することがわかります。）

同様に、ファームウェアのロードもカーネルに移動されたため、udev実行される残りのタスクは、モジュールのロード（モダリアによる）およびデバイスのアクセス許可と他のudevルールの適用のみです。

したがって、理論的には、完全にモノリシックなカーネルは、udevなしで正常に起動するはずです。

ただし、ここでの本当の問題は後で起こることです。

1. かなりの数のユーザースペースプログラムは、デバイスデータベースを維持するudevに依存していlibudevます。デバイスの列挙と追加/削除されたイベントのリッスンは、カーネルインターフェイス（sysfsとnetlink）を使用して直接行うことができますが、さまざまなudevルールが添付したすべてのメタデータが残ったままになります。

2. udevのルールはまた、様々な「持続的」シンボリックリンクを維持/dev/disk/by-*、/dev/mapper、/dev/input/by-path、/dev/snd/by-path、などを。たとえば、2つのディスクが接続されている場合、最初のディスクが常にsdaor sdbになるという保証はありませんが、udevは、symlinksが/dev/disk/by-uuid正しいディスクを指すことを保証します。

3. デバイスノードは、今はもう、あなたの懸念カーネルによって作成されたので、されていませんが、いくつかのデバイスタイプは、あなたが持っているにもかかわらずそう、動的に割り当てられたメジャー/マイナー番号を使用して開始していることを、まだ注意することが重要である/dev/fuse10228として/dev/hpet10229として、今日、彼らは意志再起動のたびに異なる番号になるため、devtmpfsまたは（古いシステムでは）ueventsをリッスンするプログラムが必要です。

これらのことの多くはmdev、もちろん、他のプログラムによって簡単に実行できます。私のポイントは、静的/etc/MAKEDEVスクリプトはもう機能しないということです...

したがって、基本的に、ブートの複雑さに関しては、udevが最も懸念されることはほとんどありません。

いくつかの選択肢があります。

• 単に適切なセットを持ってchmod、chown、ln、およびブートストラップの一部として実行されるスクリプトではそのようなもののコマンド。
• systemd-udevsystemdプロジェクトの一部であるプラグアンドプレイマネージャーを使用します。
• 使用Gentooのeudevのフォークで、systemd-udevそこからsystemdには今大幅に発散しています。
• Devuanをvdev使用します。これは、Devuanの一部であるJude Nelsonによって開発されたプラグアンドプレイマネージャーです。
• を使用しますmdev。これは、別の答えに反してGentooのものではありません。BusyBoxに組み込まれているプラ​​グアンドプレイマネージャーです。
• 使用SucklessmdevディミトリスPapastamosによって開発されたプラグアンドプレイマネージャです。
• Laurent Bercotをmdevd使用します。これはBusyBoxと互換性のある構成ですmdevが、独自のソケット処理を行い、LISTENプロトコルを理解しません。

これらのすべては、最初のものを除いて、デバイスに関するカーネル通知イベントに反応する方法を説明する一連のルールを必要とします。明らかに。

また/proc/sys/kernel/hotplug、2 mdevのような向けに設計されたプログラムを使用し、netlinkソケットをリッスンしてからそれらのプログラムを生成することにより、それらを適応およびシリアル化するツールもあります。

• ローランBercotの古いs6-netlink-listenerとs6-uevent-spawner
• netlink-datagram-socket-listen そして、noshツールセットplug-and-play-event-handlerから

udev？最善の選択肢は、使用しないことです。そして、それを使わない方法を学ぶことにより、Linuxと* NIXの世界はより論理的な意味を持ち始めます。

最良の長期的な代替手段は、静的デバイスを使用することです（注を参照）。ドライバーがあれば、Linuxカーネルがホットプラグを管理します。私は、udevdを実行させないことを好みます。

dbusは別の問題です。システムの速度は低下しますが、絶えず変化するスクリプトの世界ではそれが大好きです。そのため、Webブラウザやスクリプトバックエンドを備えたアプリケーションなど、慣れ親しんだ多くのことを修正する必要があります（そのようなものなしで起動または再構築するか、別のアプリケーション用にダンプします）。

注：フラッシュドライブまたはDVDデバイスを接続するだけの場合は、を使用dmesg|tailして、マウントするデバイスの名前を確認します。デバイスがキャラクターまたはブロックデバイスである場合の学習は、コンピューターハードウェアの世界における基本的なシステム知識です。Linuxでは、オープンソースです。これは、組み込みだけでなく、Linuxについてもよく確認してください。Linux（Solaris、HPUX、AIXなど）のようなすべての* NIXの単純なロジック（哲学ではない）をより深く理解するのに最適です。

Udev、dbus、gconf / dconf、systemd、gnome-shell、Gnome、Glib、mono、およびFedoraは、RTFMを使用できない、または自動的に更新される本当に滑らかな（見た目）が遅い、時間がかかるユーザー向けです。糖蜜、バギー、中途半端なLinuxよりも。（本当にひどい場所です。同様の体験をウェブで探しましょう）。

システムが起動し、udevdを実行します。しかし、will change再起動時のデバイスのマイナー番号のため、udevが必要であると主張されています。Udevの存在理由は、あらゆる場面で矛盾しているようです。また、ファイルの場所は、誰に相談しても常に間違っているようです。freedesktop.orgを信頼しないでください。

systemdとして知られるその恐怖にudevが吸収されていることに加えて、/ etc / udevのジャンクを使って何をするのかわかりません。そして、udevルールを書くことは何よりも優れていると言うのは非常に残念です。gentooの人たちはsystemdをする必要はなく、それに固執したいようですので、eudevにフォークしました。

途方もなく高速で厄介なサプライズシステムが必要な場合は、Linuxの基本を使用してください。