On 9/19/25 10:12, Alyssa Ross wrote: > I'm pleasantly surprised by how straightforward this is (mostly)! > > Demi Marie Obenour 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 >> +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)