2
udevは実際にどのような問題を解決しますか？
その点については、静的ファイルの束で何が正確に間違っていました/devか？開発者がこのホイールを私のカウントで3回（devfs-> udev + HAL-> udev）再発明したことは明らかに不十分であり、現在ではGrand Unified Init Programにも4回入っているようです。 何年も前にLinuxを使い始めたとき、「すべてがファイルである」と主張しているにもかかわらず/dev/eth0、「パケット」デバイスタイプではなく、文字デバイスまたはブロックデバイスではないので、後で意味をなさないことに驚きました。面白いでしょう...）。それを考えると、なぜcharとblockデバイスファイルツリーを処理するプログラムがネットワークデバイスにも責任があるのですか？私は「柔軟性」へのあいまいな参照を見てきましたが、これはifconfig（8）が単に見るだけで何をするのかを追加し/proc/net/devますか？たとえば、NetworkManagerはudev、どちらのチームも書きたくないに依存しているため、近いうちにNetまたはOpenBSDにならないことを知っています。私がしないこと/devこれらはすでにカーネルによって複数の方法で公開されています（/dev！ ホットプラグのためだけですか？カーネルが物理バスをリッスンし、「device added」メッセージに適切なモジュールをロードするだけで問題がありましたか？または、実際の管理者がそうすることを禁じていますか？2000年代前半にサーバーがネットワークカードを予期しない順序で初期化することがあったことを覚えています。ユーザーランドで命名を決定することは理にかなっていると思います（ただし、当時の修正はそれほど難しくありませんでしたが）これはゴキブリの大ハンマーのようです。（または、その問題のヒットユースケースでは、ラックマウントサーバーやPCよりもそれほど難しいとは考えていません。これは私の経験です）。 それで、私の質問をわかりやすく述べると、udevは実際にどのような問題を解決し、devfs、HAL、および/または普通の古いファイルはそれらを解決できなかったのでしょうか？多くの異なるもの（ホットプラグ、一般的なデバイス管理、ネットワークデバイス管理、デバイスの命名、ドライバーの優先順位など）がすべて1つのプログラムになる特別な理由はありますか？