デーモンの実行や、カーネル空間に適していない (複雑すぎる、またはポリシーに関連する) 相互作用の一部を処理するなど、ユーザー空間のサポートを必要とするハードウェア デバイスがあります。
ユーザー空間に到達すると、そのようなデーモンを実行するのは簡単です。ホットプラグ イベントの結果としてそれらを実行することができ、あまり心配する必要はありません。
initramfs が見えてくると、すべてが突然バラバラになります: デーモンが initramfs から実行されている場合、実行が通常の rootfs に切り替えられたときに実行を継続する必要があります。これは特に困難です。 rootfs から実行して、それ自体の別のコピーに状態を送信します。どちらのソリューションも、洗練されておらず、ハッキリしているように見えます。
私が見落としていたそのようなデバイスとそれらをサポートするデーモンを管理する明確な方法はありますか?
実際のルート デバイスをマウントするには、このデーモンが必要ですか? 答えはイエスだと思います。それ以外の場合、解決策は実際のルートを待つことです。
私はあなたのデバイスが非常に複雑で、機能するためにデーモンが必要です。カーネルでジョブの一部を実行し、sysfs 属性を介してポリシーを処理できますか? 動作するためにデーモンを必要とする実際のルート デバイスのマウントに関与するハードウェアの例は見当たりません。デバイスの検出は適用されますが、デバイスが実際に機能するためにデーモンは必要ありません。例を歓迎します。
また、本当に root を切り替える必要がありますか? initramfs を保持し、完全に機能するシステムを /usr/ の下に配置するために必要なものをすべてマウントすることができます。
更新 : mdev は udev の代わりに組み込まれたもので、2 つのモードで実行されます。sysfs をスキャンしてデバイスを追加し、もう 1 つは hotplug イベントのために実行されます。すべての情報は引き続きsysfsで利用できるため、ホットプラグイベントを「保存」する必要はないと思います。したがって、解決策は次のようになります。
具体的なケースはありますか？他のディストリビューションはこれをどのように処理しましたか?
Fedora がどのように udev を実行するかを見ると、initramfs から起動し、実際のルート fs をマウントできるように Fedora に処理を実行させ、切り替え前に再度シャットダウンします。