`udev`を使用する代わりの方法はありますか？
私はudevの素晴らしさを理解しており、開発者の努力に感謝していますが、私にはそれに対する代替策があるかどうか疑問に思っていました。
たとえば、私のシステム（ハードウェアの変更なし）でほとんどのデバイスノードを作成する起動スクリプトを作成する方法があるはずだと想像するかもしれません。
udevをスキップする利点または理由は、dbusをスキップする場合と同じです。つまり、複雑さを減らし、システムをより安全にセットアップするための変更を増やします。
udevに代わるさまざまな方法があります。 Gentooは mdev と呼ばれるものを使用できるようです。別のオプションは、udevの前任者devfsdを使用することです。最後に、mknodを使用して、必要なすべてのデバイスファイルをいつでも作成できます。
後者の場合、ノードは他のオプションのように一時ファイルシステムではなくディスク上に作成できるため、ブート時にすべてを作成する必要はありません。もちろん、新しいハードウェア（USBスティックなど）を差し込むと、デバイスファイルを動的に作成する柔軟性が失われます。この時代の標準的なアプローチは、合理的に必要なすべてのデバイスファイルを/dev（多くのデバイスファイル）。
もちろん、これらのアプローチのいずれかを現代のディストリビューションで機能させることの難しさはおそらくかなり高いでしょう。 Gentoo wikiは、mdevをデスクトップ環境（Gentoo以外ではもちろん）で動作させることの難しさについて言及しています。最後のdevfsdリリースは2002年でしたが、最新のカーネルでまったく機能するかどうかはわかりません。ノードを手動で作成することはおそらく最も実行可能なアプローチですが、udevを無効にすることさえも、特にsystemdを使用するdistosで難しい場合があります（udevはsystemd、これは強い依存関係を示唆しています）。
私のアドバイスはudevに固執しています;）
最新のLinuxカーネルはdevtmpfsファイルシステムをサポートしています （古代のdevfsと混同しないでください）、カーネルがそれらを発見するとすぐにすべてのデバイスノードを動的に作成します。 （実際、最新のudevリリースrequireこれ。udevがデバイスノードを作成せず、シンボリックリンクのみを作成することがわかります。）
同様に、ファームウェアのロードもカーネルに移動されているため、udevが実行する残りのタスクは、モジュールのロード（modaliasesによる）と、デバイスのアクセス許可およびその他のudevルールの適用のみです。
したがって、理論的には完全にモノリシックなカーネルはbootであり、udevがなくても問題ありません。
ただし、ここでの実際の問題は、後で何が起こるかです。
かなりの数のユーザースペースプログラムが、
libudevからアクセス可能なデバイスデータベースを維持するudevに依存しています。デバイスの列挙と追加/削除されたイベントのリッスンは、カーネルインターフェイス（sysfsとnetlink）を使用して直接行うことができますが、さまざまなudevルールがアタッチしたすべてのメタデータがなくても残ります。udevルールは、
/dev/disk/by-*、/dev/mapper、/dev/input/by-path、/dev/snd/by-pathなどのさまざまな「永続的」シンボリックリンクも維持します。たとえば、2つのディスクが接続されている場合、最初のディスクが常にsdaまたはsdbである保証はありませんが、udevは/dev/disk/by-uuidのシンボリックリンクが引き続きポイントすることを保証します右のものに。デバイスノードはカーネルによって作成されたため、もう心配する必要はありませんが、一部のデバイスタイプは動的に割り当てられたメジャー/マイナー番号の使用を開始したため、
/dev/Fuseが10,228および/dev/hpet現在の10,229とはwillはリブートごとに異なる番号になるため、devtmpfsまたは（古いシステムでは）ueventsをリッスンするプログラムは必須。
もちろん、これらの多くはmdevなどの他のプログラムで簡単に実行できます。私のポイントは、静的な/etc/MAKEDEVスクリプトが機能しなくなることです...
したがって、基本的に、ブートの複雑さに関しては、udevが懸念のleastである可能性が非常に高いです。
いくつかの選択肢があります：
- ブートストラップの一部として実行されるスクリプトに、適切な
chmod、chown、lnなどのコマンドのセットを含めるだけです。 - Systemdプロジェクトの一部であるプラグアンドプレイマネージャーである
systemd-udevを使用します。 - Gentooの
eudevを使用します。これは、systemdが大幅に分岐したsystemd-udevのフォークです。 - Devuanの
vdevを使用します。これは、Devuanの一部であるJude Nelsonによって開発されたプラグアンドプレイマネージャーです。 mdevを使用してください。これは、他の回答とは逆に、Gentooではありません。 BusyBox に組み込まれているのはプラグアンドプレイマネージャーです。- Dimitris Papastamosによって開発されたプラグアンドプレイマネージャーである Suckless
mdevを使用します。 - Laurent Bercotの
mdevdを使用します。これはBusyBoxのmdevと構成互換ですが、独自のソケット処理を行い、理解しません。 LISTENプロトコル。
これらすべては、最初のものを除いて、デバイスに関するカーネル通知イベントへの対応方法を説明する一連のルールを必要とします。明らかに。
2つのmdevsなどの/proc/sys/kernel/hotplug用に設計されたプログラムを使用するツールもあります。これらのツールは、netlinkソケットをリッスンしてからそれらのプログラムを生成することにより、それらを適応させてシリアル化します。
- Laurent Bercotの古い
s6-netlink-listenerおよびs6-uevent-spawner netlink-datagram-socket-listenおよびplug-and-play-event-handlerfrom noshツールセット
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の基本を使用してください。