☰

`udev` を使用する代わりになるものはありますか?

tag-icon • tag-icon linux devices udev
`udev` を使用する代わりになるものはありますか?

私は udev の素晴らしさを理解し、開発者の努力に感謝していますが、単にそれに代わるものがあるかどうか疑問に思いました。

たとえば、私のシステム（ハードウェアを変更していない）では、ほとんどのデバイス ノードはほとんど同じであるにもかかわらず、それらを作成する起動スクリプトを作成する方法があるはずだと想像できます。

スキップしたい利点または理由は、udevスキップする場合と同じですdbus。つまり、複雑さが軽減され、それによってシステムをより安全にセットアップするための変更が増えることです。

答え1

最近のLinuxカーネルはdevtmpfsファイルシステム（古いものと混同しないでくださいdevfs）をサポートしており、カーネルがデバイスノードを検出するとすぐにすべてのデバイスノードを動的に作成します。（実際、最新のudevリリースでは必要とするこうすると、udev はデバイス ノードを作成しなくなり、シンボリック リンクのみを作成することがわかります。

同様に、ファームウェアのロードもカーネルに移動されたため、udev実行される残りのタスクは、モジュールのロード (modaliases に従って) と、デバイスのアクセス許可とその他の udev ルールの適用だけです。

理論上は完全にモノリシックなカーネルはブートudev がなくても大丈夫です。

しかし、ここでの本当の問題は、その後に何が起こるかということです。

  1. かなりの数のユーザー空間プログラムは、 を通じてアクセスできるデバイス データベースを維持する udev に依存していますlibudev。デバイスの列挙と追加/削除されたイベントのリッスンをカーネル インターフェイス (sysfs および netlink) を使用して直接実行することもできますが、さまざまな udev ルールによって添付されたすべてのメタデータが失われます。

  2. udev ルールは/dev/disk/by-*、、、、など/dev/mapperのさまざまな「永続的な」シンボリックリンクも維持します。たとえば、2 つのディスクが接続されている場合、最初のディスクが常にまたはである保証はありませんが、udev は、 のシンボリックリンクが正しいディスクを指し続けることを保証します。/dev/input/by-path/dev/snd/by-pathsdasdb/dev/disk/by-uuid

  3. デバイスノードはカーネルによって作成されるため、もはや心配する必要はありませんが、一部のデバイスタイプでは動的に割り当てられるメジャー/マイナー番号が使用されるようになったことに注意することが重要です。そのため、現在/dev/fuse10,228と10,229の番号がある場合でも、/dev/hpet意思再起動のたびに番号が異なるため、devtmpfs（古いシステムでは）ueventsを監視するプログラムが必須。

mdevもちろん、これらの多くは、 などの他のプログラムで簡単に実行できます。私が言いたいのは、静的/etc/MAKEDEVスクリプトはもう機能しないということです...

つまり、基本的に、起動の複雑さに関しては、udevが少しでもあなたの懸念について。

答え2

他にも様々な代替手段がありますudev。どうやらGentooでは、mdevudev. もう 1 つのオプションは、 の前身である を使用することですdevfsd。最後に、 を使用すると、必要なすべてのデバイス ファイルをいつでも作成できますmknod。

後者の場合、ノードは他のオプションのように一時ファイル システムではなくディスク上に作成できるため、起動時にすべてを作成する必要はありません。もちろん、新しいハードウェア (USB スティックなど) が接続されたときにデバイス ファイルを動的に作成する柔軟性は失われます。この時代の標準的なアプローチは、合理的に必要になる可能性のあるすべてのデバイス ファイル (つまり、/dev多数のデバイス ファイル) をあらかじめ作成しておくことだったと思います。

もちろん、これらのアプローチのいずれかを最新のディストリビューションで動作させることは、おそらくかなり困難です。Gentoo wiki には、mdevデスクトップ環境で動作させることの難しさ (Gentoo の外部ではなおさら) について言及されています。最後のdevfsdリリースは 2002 で、最新のカーネルで動作するかどうかはまったくわかりません。ノードを手動で作成するのがおそらく最も実行可能なアプローチですが、特に(は現在 の一部であり、強い依存関係があることを示唆しています)udevを使用しているディストリビューションでは、無効にすることさえ困難になる可能性があります。systemdudevsystemd

私のアドバイスは、続けることですudev;)

答え3

いくつかの選択肢があります:

  • ブートストラップの一部として実行されるスクリプトに、適切な、、などのコマンドchmodのchownセットを用意するだけです。ln
  • systemd-udevsystemd プロジェクトの一部であるプラグアンドプレイ マネージャーを使用します。
  • 使用ジェンツーのeudevは のフォークであり、systemd-udevsystemd は現在では大幅に分岐しています。
  • 使用デヴアンのvdevこれは、Jude Nelson によって開発されたプラグアンドプレイ マネージャーであり、Devuan の一部です。
  • を使用してくださいmdev。これは他の回答とは異なり、Gentooのものではありません。これは、ビジーボックス。
  • 使用吸わないmdevこれは、Dimitris Papastamos によって開発されたプラグアンドプレイ マネージャーです。
  • 使用ローラン・ベルコのmdevdこれは BusyBox と設定互換性がありますmdevが、独自のソケット処理を行い、LISTEN プロトコルを理解しません。

最初のものを除き、これらすべてには、デバイスに関するカーネル通知イベントにどのように反応するかを記述する一連のルールが必要です。当然です。

/proc/sys/kernel/hotplugまた、 2 つの など、用に設計されたプログラムを取得しmdev、netlink ソケットをリッスンしてそれらのプログラムを生成することで、それらを適応およびシリアル化するツールもあります。

答え4

これは古いですが、無駄に検索している人のために、ここで私の解決策を記録しておきたいと思います。udev
を避けるのは簡単ではありません。DEVTMPFS を構成から除外しても、カーネルが /dev に RAM ディスクをマウントしてそこにデータを入れるのを止めることはできません。残念ながら、必要な /dev/shm および /dev/pts マウント ポイントは作成されません。必要なのは、ブート引数に devtmpfs.mount=0 を追加することです。

関連情報