From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id B23E520A47; Fri, 19 Sep 2025 14:13:30 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 5CCF120AAA; Fri, 19 Sep 2025 14:13:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-b2-smtp.messagingengine.com (fout-b2-smtp.messagingengine.com [202.12.124.145]) by atuin.qyliss.net (Postfix) with ESMTPS id 03F5D20AA9 for ; Fri, 19 Sep 2025 14:13:26 +0000 (UTC) Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id A521B1D001CC; Fri, 19 Sep 2025 10:13:25 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Fri, 19 Sep 2025 10:13:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1758291205; x=1758377605; bh=k+RM8J4K1h Ob6GRPIJ6fFs5cX39M8mKXFACPZkhcru8=; b=iH+TJqoSmNMDn6ZwitCqMqgcWv MqW30jfjq+wWHWihjCWof4J5Fd28FbPfJ5I9MwBcXxn3G4+9uN08ZwvcAdNzlIZ/ +XRgqMmxBWRxHea7R4FpHl+LoDSeJc8H7be5JAYp8iH8vXgmieZD5/P/037dNVNG yRYqlZVGlQli2pCRoHKvbY8G/62CMQFgGCprZox3PNCfi0kvAAyz3ARK+DXdXW4b oWodNTa1vHSgm0aPyZtrXTSZa5V24okItotYEjDCofUkCuDXsA8CwI6AokwnEeUK SYmhKMBGynOyShMCfnQAZRB2pVd5FzeTNGVEFrmpsjDdYWTfV7Shdj/E2j1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1758291205; x=1758377605; bh=k+RM8J4K1hOb6GRPIJ6fFs5cX39M8mKXFAC PZkhcru8=; b=oDo3HYhWWnNTdSUaCykjjR/amLyos4oP+IfvrR2Mq0a99nZJo52 v1fniUzNVUFXVmZtuyWVPRTzb3xhhSC7AYJWyFyWbruzEQpI4Miuxtnb89x2s+4b YdV4KBSu7yAleGF3IkkvPopiL4f0WH3oPBt426bn1oEIqmUrBNls+eu9Z9yeZOE0 kwbb1lZyDxP1EF3/7g2z/cgqVGEyuCpP3nfB3Q/q9y0AtMwwso+HOhW2BOWfKhpw m97GQDUhyOl8Mtg0w0WYNemslri3eDTTJkRoB2lJJWIA4vxSY5M5KGDmhDgiXkdv SA+u6fQm3k3leGUvoEGla04iTzYpYBS2HMQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegleegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgrucft ohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepteehvedugf ejgfehhfeijeduleekleejgedvkeeuuefhhfegvdevfeetveegteeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrgdrih hspdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegu vghmihhosggvnhhouhhrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepuggvvhgvlhessh hpvggtthhruhhmqdhoshdrohhrgh X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 19 Sep 2025 10:13:24 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 8A14F1FB9963; Fri, 19 Sep 2025 16:12:58 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: [PATCH 3/3] host/rootfs: switch to systemd-udevd In-Reply-To: <20250913-udev-v1-3-eade4ab8f2b4@gmail.com> References: <20250913-udev-v1-0-eade4ab8f2b4@gmail.com> <20250913-udev-v1-3-eade4ab8f2b4@gmail.com> Date: Fri, 19 Sep 2025 16:12:57 +0200 Message-ID: <87ikhesf86.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: PVJURM4GRWTA5BAILRDCJ2OABYUM6AUA X-Message-ID-Hash: PVJURM4GRWTA5BAILRDCJ2OABYUM6AUA X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Spectrum OS Development X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=3Dsysinit.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=E2=80=A6 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 =3D> systemd-udevd}/notification-fd | 0 > .../notification-fd.license | 0 > host/rootfs/etc/s6-rc/systemd-udevd/run | 10 +++ > .../rootfs/etc/s6-rc/{mdevd =3D> systemd-udevd}/type | 0 > .../s6-rc/{mdevd =3D> 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..199397bc26874a261c9e1ea17= 78207fdb0d8ad39 > --- /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!=3D"remove", KERNEL=3D=3D"kvm", RUN+=3D"/etc/mdev/listen kvm" > +ACTION!=3D"remove", ENV{PCI_CLASS}=3D=3D"2????", RUN+=3D"/etc/mdev/net/a= dd" > +ACTION!=3D"remove", ENV{MODALIAS}=3D=3D"?*", RUN+=3D"/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=3D=3D"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? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRV/neXydHjZma5XLJbRZGEIw/wogUCaM1k6QAKCRBbRZGEIw/w oo4eAP0TtJV9sJeeHk6vsE3FZyLd/M/jW4CEgYv5vHqEhSdQ7AEAhj+vTEqDbE1P d4BNbTT3VEgnJnTvbSPYztjzNVcUdws= =MTp8 -----END PGP SIGNATURE----- --=-=-=--