From: Alyssa Ross <hi@alyssa.is>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Spectrum OS Development <devel@spectrum-os.org>
Subject: Re: [PATCH 3/3] host/rootfs: switch to systemd-udevd
Date: Fri, 19 Sep 2025 16:12:57 +0200 [thread overview]
Message-ID: <87ikhesf86.fsf@alyssa.is> (raw)
In-Reply-To: <20250913-udev-v1-3-eade4ab8f2b4@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4190 bytes --]
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?
> 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?
> ---
> 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?
> 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?
> .../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?
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.)
Can we remove our own static-nodes implementation?
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?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2025-09-19 14:13 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-14 3:16 [PATCH 0/3] Switch from mdevd to systemd-udevd in root filesystem Demi Marie Obenour
2025-09-14 3:16 ` [PATCH 1/3] host/rootfs: Add early serial output Demi Marie Obenour
2025-09-17 11:45 ` Alyssa Ross
2025-09-18 2:44 ` Demi Marie Obenour
2025-09-19 14:21 ` Alyssa Ross
2025-09-19 14:49 ` Alyssa Ross
2025-09-14 3:16 ` [PATCH 2/3] tools: Add adapter tool for services using sd_notify Demi Marie Obenour
2025-09-14 3:16 ` [PATCH 3/3] host/rootfs: switch to systemd-udevd Demi Marie Obenour
2025-09-19 14:12 ` Alyssa Ross [this message]
2025-09-19 19:32 ` Demi Marie Obenour
2025-09-21 12:18 ` Alyssa Ross
2025-09-21 17:02 ` Demi Marie Obenour
2025-09-21 16:27 ` Demi Marie Obenour
2025-09-21 16:28 ` Demi Marie Obenour
2025-09-23 18:39 ` Alyssa Ross
2025-09-23 19:18 ` Demi Marie Obenour
2025-09-24 10:32 ` [PATCH v2 0/3] Switch from mdevd to systemd-udevd in root filesystem Demi Marie Obenour
2025-09-24 10:32 ` [PATCH v2 1/3] tools: Add adapter tool for services using sd_notify Demi Marie Obenour
2025-09-25 10:29 ` Alyssa Ross
2025-09-25 16:54 ` Demi Marie Obenour
2025-09-24 10:32 ` [PATCH v2 2/3] host/rootfs: Switch to systemd-udevd Demi Marie Obenour
2025-09-25 10:53 ` Alyssa Ross
2025-09-25 17:53 ` Demi Marie Obenour
2025-09-26 14:56 ` Alyssa Ross
2025-09-28 22:51 ` [PATCH v3 0/2] Switch from mdevd to systemd-udevd in root filesystem Demi Marie Obenour
2025-09-28 22:51 ` [PATCH v3 1/2] tools: Add adapter tool for services using sd_notify Demi Marie Obenour
2025-10-01 16:06 ` Alyssa Ross
2025-09-28 22:51 ` [PATCH v3 2/2] host/rootfs: Switch to systemd-udevd Demi Marie Obenour
2025-10-01 14:24 ` Alyssa Ross
2025-10-01 14:39 ` Alyssa Ross
2025-10-01 17:40 ` Demi Marie Obenour
2025-10-02 9:53 ` Alyssa Ross
2025-10-02 10:34 ` Alyssa Ross
2025-10-02 10:36 ` [PATCH v3 0/2] Switch from mdevd to systemd-udevd in root filesystem Alyssa Ross
2025-10-03 21:42 ` [PATCH v4 " Demi Marie Obenour
2025-10-03 21:42 ` [PATCH v4 1/2] tools: Add adapter tool for services using sd_notify Demi Marie Obenour
2025-10-28 15:38 ` Alyssa Ross
2025-10-28 22:56 ` Demi Marie Obenour
2025-10-29 11:26 ` Alyssa Ross
2025-10-31 4:34 ` Demi Marie Obenour
2025-10-31 8:54 ` Alyssa Ross
2025-11-01 18:23 ` Demi Marie Obenour
2025-10-03 21:42 ` [PATCH v4 2/2] host/rootfs: Switch to systemd-udevd Demi Marie Obenour
2025-10-28 16:02 ` Alyssa Ross
2025-10-28 22:56 ` Demi Marie Obenour
2025-10-29 9:31 ` Alyssa Ross
2025-10-29 9:55 ` Demi Marie Obenour
2025-09-24 10:32 ` [PATCH v2 3/3] host/rootfs: Simplify s6-rc dependencies Demi Marie Obenour
2025-09-25 11:07 ` Alyssa Ross
2025-09-25 15:50 ` Demi Marie Obenour
2025-10-02 10:37 ` Alyssa Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ikhesf86.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).