Re: [PATCH 3/3] host/rootfs: switch to systemd-udevd

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2502 bytes --]

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.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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]