On 9/23/25 14:39, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 9/19/25 10:12, Alyssa Ross wrote:
I'm pleasantly surprised by how straightforward this is (mostly)!
Demi Marie Obenour <demiobenour@gmail.com> writes:
diff --git a/host/rootfs/etc/udev/rules.d/99-spectrum.rules b/host/rootfs/etc/udev/rules.d/99-spectrum.rules new file mode 100644 index 0000000000000000000000000000000000000000..199397bc26874a261c9e1ea1778207fdb0d8ad39 --- /dev/null +++ b/host/rootfs/etc/udev/rules.d/99-spectrum.rules @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: EUPL-1.2+ +# SPDX-FileCopyrightText: 2025 Demi Marie Obenour <demiobenour@gmail.com> +ACTION!="remove", KERNEL=="kvm", RUN+="/etc/mdev/listen kvm" +ACTION!="remove", ENV{PCI_CLASS}=="2????", RUN+="/etc/mdev/net/add" +ACTION!="remove", ENV{MODALIAS}=="?*", RUN+="/usr/bin/modprobe -q $env{MODALIAS}"
Can't we rely on the default rule in 80-drivers.rules to load modules based on modalias?
Would ACTION=="add" be more appropriate for the PCI devices? I don't think we'd want to re-add them to a VM on any other action?
'udevadm trigger' generates change events. Generally, one should only distinguish between ACTION=="remove" and ACTION!="remove", and make rules idempotent so that it is okay if they are triggered more than once. Anything else is considered a bug by upstream.
Got a link to somewhere I can read more about that?
https://lists.freedesktop.org/archives/systemd-devel/2023-December/049873.ht...
Would not currently be good to re-run /etc/mdev/net/add, because it would unplug and replug the device. I can probably take a look at that if you want.
That's definitely not great. I think the expectation of upstream is to use a persistent daemon for this, sadly. Qubes OS uses scripts of various types and has run into multiple bugs as a result. A daemon can respond not only to events, but also know the overall state of the system. As far as I can tell, everything upstream provides takes this approach.
It's not ideal to run /etc/mdev/listen multiple times either, but if I understood one of your other messages correctly there's some better udev thing we can switch to for that anyway.
'udevadm wait' does the job. /etc/mdev/listen and /etc/mdev/wait can be removed. -- Sincerely, Demi Marie Obenour (she/her/hers)