09 にはさまざまな代替手段があります そこに。 Gentoo は 18 と呼ばれるものを使用できるようです .別のオプションは、 26 を使用することです の前任者 30 .最後に、48 を使用して、必要なすべてのデバイス ファイルをいつでも作成できます。 .
後者の場合、他のオプションのように一時ファイル システムではなく、ディスク上にノードを作成できるため、ブート時にすべてを作成する必要がないことに注意してください。もちろん、新しいハードウェア (USB スティックなど) を接続すると、デバイス ファイルを動的に作成するという柔軟性が失われます。この時代の標準的なアプローチは、合理的に必要となるすべてのデバイス ファイルを 56 の下に作成することだったと思います。 (つまり、多くのデバイス ファイル)。
もちろん、これらのアプローチを最新のディストリビューションで機能させることの難しさは、おそらくかなり高いでしょう。 Gentoo wiki では、69 を取得する際の困難について言及しています。 デスクトップ環境で作業するため (Gentoo 以外は言うまでもありません)。最後の 71 リリースは 2002 年でしたが、最新のカーネルで動作するかどうかはわかりません。ノードを手動で作成するのがおそらく最も実行可能な方法ですが、87 を無効にすることもできます 特に 97 を使用する distos では、課題になる可能性があります (105 112 の一部になりました 、これは強い依存関係を示唆しています)。
私のアドバイスは 127 に固執することです;)
最新の Linux カーネルは 132 をサポートしています ファイル システム 。カーネルがデバイス ノードを検出するとすぐに、すべてのデバイス ノードを動的に作成します。 (実際、最新の 144 リリース必須 これ; udev はもうデバイス ノードを作成せず、シンボリック リンクのみを作成することがわかります。)
同様に、ファームウェアのロードもカーネルに移動したため、残りのタスクは 157 のみです。 実行するのは、(modaliases による) モジュールの読み込みと、デバイスのアクセス許可とその他の udev ルールの適用です。
したがって、理論的には、完全にモノリシックなカーネルは 起動 する必要があります udev がなくても問題ありません。
ただし、ここでの本当の問題は、後で何が起こるかです。
<オール>
163 を介してアクセス可能なデバイス データベースを維持する udev に依存するユーザー空間プログラムはかなりの数あります。 .デバイスの列挙と、追加/削除されたイベントのリッスンは、カーネル インターフェイス (sysfs と netlink) を使用して直接行うことができますが、さまざまな udev ルールが添付されているすべてのメタデータがないままになります。
udev ルールは、177 でさまざまな「永続的な」シンボリック リンクも維持します。 、 184 、 195 、 200 、 等々。たとえば、2 つのディスクが接続されている場合、最初のディスクが常に 217 になるという保証はありません。 または 227 、しかし udev は 236 のシンボリックリンクを保証します 正しいものを指し続けます.
デバイスノードはカーネルによって作成されるようになったため、もはや問題ではありませんが、動的に割り当てられたメジャー/マイナー番号を使用し始めたデバイスタイプがあることに注意することが重要です。 10,228 および 259 として 今日の 10,229 人は そう 再起動するたびに番号が異なるため、263 または (古いシステムでは) uevents をリッスンするプログラムが必要 .
これらの多くは、277 などの他のプログラムで簡単に実行できます。 、 もちろん。私のポイントは、静的な 282 スクリプトはもう機能しません...
したがって、基本的に、ブートの複雑さに関して言えば、udev はおそらく 最小 です。
いくつかの代替手段があります:
- 適切な
293のセットを用意するだけです 、302、315、およびブートストラップの一部として実行されるスクリプト内の同様のコマンド。 325を使用 systemd プロジェクトの一部であるプラグアンドプレイ マネージャー。- Gentoo の
338を使用する 、これは342のフォークです そこから systemd が大幅に分岐しました。 - Devuan の
353を使用 は、Devuan の一部である、Jude Nelson によって開発されたプラグアンドプレイ マネージャーです。 364を使用 、別の答えに反して、これはGentooのものではありません。 BusyBox に組み込まれているプラグアンドプレイ マネージャーです。- Suckless
376を使用 Dimitris Papastamos によって開発されたプラグアンドプレイ マネージャーです。 - Laurent Bercot の
385を使用 、BusyBox の391と互換性のある構成です ただし、独自のソケット処理を行い、LISTEN プロトコルを理解していません。
これらのすべては、最初のものを除いて、デバイスに関するカーネル通知イベントにどのように反応するかを記述した一連のルールを必要とします。もちろんです。
404 用に設計されたプログラムを使用するツールもあります 、2 つの 418 など s であり、netlink ソケットをリッスンしてそれらのプログラムを生成することにより、それらを適応させてシリアル化します:
- ローラン・ベルコの古い
421と435 444と452nosh ツールセットから