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?

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.

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.