その点については、静的ファイルの束で何が正確に間違っていました/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つのプログラムになる特別な理由はありますか？

さらに2つのこと：Linuxがエンタープライズおよびその他の大規模サーバーに移行したことで、静的なデータ/devが破壊される可能性がありました。消費者と企業の両方で進歩している技術は、静的な/ devを冗談として公開していました。[この回答は、特にdevfsがudevに置き換えられた理由ではなく、より多くのバックストーリーを埋めます]。

メジャーおよびマイナー番号スペースの枯渇

/devファイルはカーネル内でメジャー番号とマイナー番号で識別されます。カーネルは名前を実際に気にかけたことはありません（そして、たとえば、あなたはmv /dev/sda /dev/disk-1それが動作し続けることができます-もちろん、プログラムはそれを見つける場所を知りません）。

static /devを使用すると、存在する可能性のあるすべてのデバイスにメジャー/マイナー番号を割り当てる必要があります。これらの番号は、オンデマンドで作成されるのではなく、ディストリビューションの一部として出荷されるため、グローバルに一意である必要があります。問題は、それらがそれぞれ8ビットの数値であるということです。範囲は0〜255です。

もともと、たとえば、Linuxは8,0がsda、8,1がsda1、8,16がsdbなどで始まりました。しかし、特にファイバーチャネルのようなものを考えると、人々はマシンにますます多くのディスクを追加し続けました。そのため、ある時点で、より多くのディスクにメジャー番号65〜71が追加されました。その後、メジャー番号128〜135。それでも、人々はもっとディスクを欲しがっていました...

また、GPTなどのパーティションテーブル形式が登場し、ディスクあたりのパーティション数が増えました。そしてもちろん、他のデバイスが番号空間を食い尽くしていました：さまざまなRAIDコントローラー、論理ボリューム管理など。

最終結果は、LANANA Linux Device Listで確認できます。2.6リスト（まだ1つだけ）を見ると、ブロックメジャー番号の200（最大：255）までが多く使用されています。明らかに、数字はなくなっていただろう。

大きな数字に変更するのは簡単ではありませんでした。カーネルABIを変更します。ファイルシステムに応じて、ディスク上のレイアウトが変更されます。しかし、もちろん、これらのデバイスのほとんどはどのシステムにも存在しませんでした。たとえば、SCSIディスクを使い果たしたシステムでも、おそらく十分な空き容量がありました。おそらく、IBM XTハードディスクは必要ありません。例えば。

dynamicを使用する/devと、ディストリビューションはデバイス番号を出荷する必要がありません。それらはもはやグローバルに一意である必要はありません。それらはブーツ全体で一意である必要さえありません。

デバイス名は予測不能でした

以前は、すべてに番号を割り当てるのは本当に簡単でした。ボードには2つのIDEチャネルがありました。各IDEチャネルは、1つのマスターと1つのスレーブをサポートしていました。チャネル順、およびマスター、スレーブ順で割り当てることができます。だから、hda最初のチャンネル、マスターになり、hdb最初のチャネル、スレーブ。hdc2番目のチャネル、マスター。など。それらは予測可能で安定していました。新しいドライブを追加したり、削除したりしても、ハードウェアの変更がなければ静的なものになります。

少なくともハードウェアの変更がなければ/dev/hda1、あなたはそれを入れて、/etc/fstab動作し続けると確信できます。

IDEはそのように機能しました。その後は何もしません。

SATAは単純なように見えます：1つのポート、1つのディスク。しかし、そうではありません。ポートの乗数を許可します。また、ホットスワップが可能です。それでも、ハードウェアの変更がなくても、実際にマッピングを機能させ続けることができます。

USBはさらに悪い。ホットスワップを許可するだけでなく、一般的です。人々は常にUSBフラッシュドライブを接続します。さらに、デバイスはプローブに時間がかかる可能性があります。また、実際に変更したい場合（たとえば、電話機のUSBストレージモードをオンまたはオフにした場合）に変更できます。Firewireも同様です。どちらを使用しても、安定したマッピングを実際に思いつくことはできません。

ネットワーク接続ディスクには、固有のポート順序はありません。カーネルが使用する唯一の順序は、それらが現れた順序です。論理ボリュームと同じです。

起動速度の探求も事態を悪化させました。もともと、カーネルは喜んで座って、たとえばすべてのUSBデバイスが初期化されるまでかなり長い時間待機していました。すべてのSCSIバスなどを完全にプローブするため。これらのプローブはバックグラウンドタスクになりました。ブートはそれらを待機しなくなりました。プローブが完了すると、デバイスが追加されます。

そのため、カーネルには、多少なりとも「それらが現れる順序」が残されていました。1つのブート上にあったすべてのブート何このデバイスには多くの種類ができることを意味していた変更命令は、/dev/sdb別のブートにありました/dev/sdc。これにより、静的なアイデアが/dev冗談になります。

概要

/dev予測できないデバイスプローブの順序によって静的がますます意味を失い、静的なメジャー/マイナー番号を割り当て続けると、実質的な作業が不足しないようになると、Linuxの開発者が動的に切り替えることを選んだ理由が明らかになり/devます。

良い質問。

ように、この引数は振り向いことができます：カーネル2.6.13は、新しいバージョンを導入するのでuevent、それはそれが起こるにバインドされたdevfsインターフェースの新しい機能を活用する書き換えることする必要があります。したがって、ある意味では、問題はカーネルの変更の理由であるはずです。

しかし、額面通りに考えて、あなたの質問はこのウィキペディアの記事で回答されています：

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

1）udevは永続的なデバイスの命名をサポートします。これは、たとえば、デバイスがシステムに接続される順序に依存しません。デフォルトのudevセットアップは、ストレージデバイスの永続的な名前を提供します。ハードディスクは、一意のファイルシステムID、ディスクの名前、および接続先のハードウェア上の物理的な場所によって認識されます。

2）devfsのカーネルスペースとは対照的に、udevは完全にユーザースペースで実行されます。結果の1つは、ノードが作成される前に、udevが命名ポリシーをカーネルから移動し、任意のプログラムを実行してデバイスのプロパティからデバイスの名前を作成できることです。そこでは、プロセス全体も中断可能であり、より低い優先度で実行されます。

私はおそらく、udevを使用してrace condition、devfsおよびhotplugでのデバイスの命名を基本的に損なうaの可能性を回避する必要があります。言い換えると、devfsでは、左端のイーサネットポートが呼び出されeth0、その右端のポートが呼び出されることを保証する方法がありませんでしたeth1（純粋な例として）。実装します。

GUIDに基づくディスクの命名スキームの採用はもう1つのプラスであり、プロセス全体をさらに大きなユーザースペースに移動します。このサイトを検索して、独自のudevルールを記述する人数を確認しましたか？

ユーザー空間にudevを使用することの本質的な利点の簡単な例として、このサイトでこの質問またはこの他の質問を確認してください。