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

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

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

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:
> 
>> The dependency on /dev/dri/card0 being present is eliminated, and
>> whatever devices the user has are now picked up by the compositor.  New
>> dependencies are added to ensure that udev coldplug has finished before
>> any non-trivial services are started.  systemd-udev-trigger.service runs
>> 'udevadm trigger' and has Before=sysinit.target, so anything that is not
>> an early boot service can assume 'udevadm trigger' has run.
> 
> If software is expected to integrate with udev to discover new devices
> at runtime, why do we need to introduce new dependencies?

I believe 'udevadm trigger' is needed to process devices that are
already plugged when systemd-udevd starts.  Otherwise, they will
never appear.

>> systemd-udevd doesn't set PATH to anything useful, presumably because
>> under NixOS this is handled some other way.  Therefore, explicitly set
>> it to /usr/bin in the scripts systemd-udevd calls.
> 
> It empties it, or it just passes it through?  The former would be very
> strange to me, but why isn't adding -p /usr/bin to the s6-linux-init
> invocation enough?

I will do some more debugging here, but I distinctly remember this being
the case.

>> ---
>>  host/rootfs/Makefile                               | 17 ++--
>>  host/rootfs/default.nix                            | 94 ++++++----------------
>>  host/rootfs/etc/init                               |  2 +-
>>  host/rootfs/etc/mdev.conf                          |  7 --
>>  host/rootfs/etc/mdev/listen                        |  2 +-
>>  host/rootfs/etc/mdev/net/add                       |  1 +
> 
> We probably ought to rename /etc/mdev… is there an idiomatic place to
> put these sorts of things with udev?

/usr/lib/spectrum is the idiomatic place for this stuff.

>>  host/rootfs/etc/s6-rc/mdevd-coldplug/dependencies  |  4 -
>>  host/rootfs/etc/s6-rc/mdevd-coldplug/up            |  4 -
>>  host/rootfs/etc/s6-rc/mdevd/run                    |  5 --
>>  host/rootfs/etc/s6-rc/ok-all/contents              |  2 +-
>>  .../dependencies.d/systemd-udevd                   |  0
>>  .../type                                           |  0
>>  .../type.license                                   |  0
>>  host/rootfs/etc/s6-rc/systemd-udevd-coldplug/up    |  3 +
>>  host/rootfs/etc/s6-rc/systemd-udevd/flag-essential |  0
> 
> Is it really that essential in comparison to other system services?  Why
> would we need to keep udevd around but not all other services?
systemd-udevd.service doesn't have RefuseManualStop=,
so I will drop this.

>>  .../s6-rc/{mdevd => systemd-udevd}/notification-fd |  0
>>  .../notification-fd.license                        |  0
>>  host/rootfs/etc/s6-rc/systemd-udevd/run            | 10 +++
>>  .../rootfs/etc/s6-rc/{mdevd => systemd-udevd}/type |  0
>>  .../s6-rc/{mdevd => systemd-udevd}/type.license    |  0
>>  host/rootfs/etc/s6-rc/vmm-env/contents             |  1 +
>>  host/rootfs/etc/s6-rc/weston/dependencies          |  4 -
>>  .../weston/dependencies.d/systemd-udevd-coldplug   |  0
>>  host/rootfs/etc/udev/rules.d/99-spectrum.rules     |  5 ++
>>  24 files changed, 56 insertions(+), 105 deletions(-)
>>
>> 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?

I will see if this is necessary.  It might be that this was broken due
to wrong permissions or something like that.

> 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?
> 
> Is there some standard tool to block until a device becomes available in
> udev, that we could use to replace the kvm service?  (Can be follow-up.)

I believe 'udevadm wait' does the job.

> Can we remove our own static-nodes implementation?

Yes, and I think it was never needed anyway as
the kernel populates devtmpfs automatically.

> You're more familiar with it that me: usually we do CC0 for plain config
> files, but EUPL for anything (except Nix) that's more like programming.
> Are udev rules more programming-y than they are plain config?

Udev rules are a programming language.
They even have goto statements 🤣.
-- 
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 --]