「udev」を使用する以外に、別の選択肢がありますか?

「udev」を使用する以外に、別の選択肢がありますか?

udevの偉大さを理解し、開発者の努力に感謝しますが、代替案があるかどうか疑問に思います。

たとえば、(ハードウェアを変更せずに)自分のシステムで最も同じほとんどのデバイスノードを生成する起動スクリプトを作成する方法が必要であると想像できます。

スキップしたい利点や理由は、udevスキップと同じですdbus。これは、変更を増やして複雑さを減らし、システムをより安全に設定するためのものです。

答え1

最新のLinuxカーネルは、カーネルが発見したすべてのデバイスノードを動的に生成するファイルdevtmpfsシステム(古代のファイルシステムと混同しないでくださいdevfsをサポートしています。 (実際の最新udev版は必要これは、udevがデバイスノードを作成せずにシンボリックリンクのみを生成することを意味します。 )

同様に、ファームウェアのロードがカーネルに移動されたため、udev実行される唯一の作業は、モジュールのロード(モーダルエイリアスに応じて)、デバイスの権限、およびその他のudevルールの適用です。

したがって、理論的に完全に統一されたカーネルは始めるudevがなくても大丈夫です。

しかし、ここで本当の問題は後で起こるものです。

  1. 多くのユーザースペースプログラムは、デバイスデータベースを維持するためにudevに依存していますlibudev。すべてのさまざまなudevルールがメタデータに添付されています。

  2. /dev/disk/by-*udevルールはまた、、、、などのさまざまな「/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(以前のシステムの場合)、ueventを受け取るプログラムは次のいずれかです。必須

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


したがって、基本的に起動の複雑さに関して、udevはおそらく少なくともあなたの懸念。

答え2

いくつかの選択肢がありますudev。 Gentooは次のツールを使用できるようです。mdev。別のオプションは、udev以前のバージョンを試すことですdevfsd。最後にいつでもmknod

後者の場合、他のオプションと同様に、一時ファイルシステムではなくディスクにノードを作成できるため、起動時にすべてを作成する必要はありません。もちろん、新しいハードウェア(USBスティックなど)を接続すると、デバイスファイルをすぐに作成できる柔軟性が失われます。私は今日の標準的なアプローチが合理的に必要なすべてのデバイスファイル/dev(例えば、多くのデバイスファイル)をすでに生成していると信じています。

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

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

答え3

いくつかのオプションがあります:

  • ブートローダの一部として実行されるスクリプトに適切なchmodchownなどの命令セットを含めるだけです。ln
  • systemd-udevsystemdプロジェクトの一部であるプラグアンドプレイマネージャを使用してください。
  • 使用ルート図eudev、これはsystemdのフォークであり、systemd-udev今ではそれとは大きく異なります。
  • 使用ドワンスvdevはJude Nelsonによって開発されたプラグアンドプレイマネージャであり、Devuanの一部です。
  • mdev他の答えとは異なり、使用してください。これはGentooのものではありません。組み込みのプラグアンドプレイマネージャです。忙しい箱
  • 使用吸入なしmdevこれはDimitris Papastamosによって開発されたプラグアンドプレイマネージャです。
  • 使用ローランベルコmdevd、その構成はBusyBoxと互換性がありますが、mdev独自のソケット処理機能があり、LISTENプロトコルを理解していません。

最初を除くすべての項目には、デバイスのカーネル通知イベントに反応する方法を説明する一連の規則が必要です。確かに。

/proc/sys/kernel/hotplugtwo mdevsなどのために設計されたプログラムをインポートし、netlinkソケットから受信し、生成して調整して直列化することができるツールもあります。

答え4

これは古いですが、他の人が無駄に検索できるように、ここに私のソリューションをキャプチャしたかったのです。
udevを避けるのは簡単ではありません。構成から DEVTMPFS を除外しても、カーネルが /dev に RAM ディスクをマウントして埋めるのを防ぎません。残念ながら、必要な/dev/shmおよび/dev/ptsマウントポイントは作成されません。必要なのは、ブートパラメータにdevtmpfs.mount = 0を追加することです。

関連情報