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)