udevの偉大さを理解し、開発者の努力に感謝しますが、代替案があるかどうか疑問に思います。
たとえば、（ハードウェアを変更せずに）自分のシステムで最も同じほとんどのデバイスノードを生成する起動スクリプトを作成する方法が必要であると想像できます。
スキップしたい利点や理由は、udevスキップと同じですdbus。これは、変更を増やして複雑さを減らし、システムをより安全に設定するためのものです。
ベストアンサー1
最新のLinuxカーネルは、カーネルが発見したすべてのデバイスノードを動的に生成するファイルdevtmpfsシステム（古代のファイルシステムと混同しないでくださいdevfs）をサポートしています。 （実際の最新udev版は必要これは、udevがデバイスノードを作成せずにシンボリックリンクのみを生成することを意味します。 )
同様に、ファームウェアのロードがカーネルに移動されたため、udev実行される唯一の作業は、モジュールのロード（モーダルエイリアスに応じて）、デバイスの権限、およびその他のudevルールの適用です。
したがって、理論的に完全に統一されたカーネルは始めるudevがなくても大丈夫です。
しかし、ここで本当の問題は後で起こるものです。
多くのユーザースペースプログラムは、デバイスデータベースを維持するためにudevに依存しています
libudev。すべてのさまざまなudevルールがメタデータに添付されています。/dev/disk/by-*udevルールはまた、、、、などのさまざまな「/dev/mapper持続的」シンボリックリンクを維持します。たとえば、2つのディスクが接続されている場合、最初のディスクが常に同じであるという保証はありませんが、udevはシンボリックリンクが正しいディスクを指すようにし続けます。/dev/input/by-path/dev/snd/by-pathsdasdb/dev/disk/by-uuidデバイスノードはカーネルによって生成されるため、これ以上問題にはなりませんが、一部のデバイスタイプは動的に割り当てられたメジャー/マイナー番号の使用を開始したことに注意することは依然として重要です。したがって、現在
/dev/fuse10,228と10,229があっても/dev/hpet〜する再起動するたびに異なる数があるためdevtmpfs（以前のシステムの場合）、ueventを受け取るプログラムは次のいずれかです。必須。
mdevもちろん、これらの作業の多くは他のプログラムを使用して簡単に実行できます。私のポイントは、静的/etc/MAKEDEVスクリプトがもう機能しないということです...
したがって、基本的に起動の複雑さに関して、udevはおそらく少なくともあなたの懸念。