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

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

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

On 9/21/25 08:18, 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:
>>>
>>>> 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.
> 
> Right, I get why we need to run it, but why do we need to block other
> services on it?

systemd uses this ordering and libudev and/or libsystemd might rely
on it.  I don't know if it does, but I also don't want to risk problems.

>>>> ---
>>>>  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.
> 
> Sounds good.

Unfortunately it conflicts with the current build system,
which assumes that /usr/lib only has kernel modules.  I'll
use /usr/libexec/spectrum for now.

>>> Can we remove our own static-nodes implementation?
>>
>> Yes, and I think it was never needed anyway as
>> the kernel populates devtmpfs automatically.
> 
> It doesn't create static nodes though!  It's very annoying.

That really stinks!
-- 
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 --]