On 9/23/25 14:39, Alyssa Ross wrote: > Demi Marie Obenour writes: > >> On 9/19/25 10:12, Alyssa Ross wrote: >>> I'm pleasantly surprised by how straightforward this is (mostly)! >>> >>> Demi Marie Obenour 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 >>>> +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.html > 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)