From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-4.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id C102C350AB; Thu, 18 Aug 2022 10:17:37 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id D526E350A6; Thu, 18 Aug 2022 10:17:35 +0000 (UTC) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by atuin.qyliss.net (Postfix) with ESMTPS id AF679350A5 for ; Thu, 18 Aug 2022 10:17:31 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 70CDE320095D; Thu, 18 Aug 2022 06:17:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 18 Aug 2022 06:17:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1660817847; x=1660904247; bh=6busyRkshq kzO5/L7WAarLrkT16HoJUYVywlAnCgLeE=; b=khZIMSv6g8N1g80dS8eebgxtLm HNKOhrERW3knFgd+0zAn8IoY+S+fyxzCb0kmWCOnwDVZ8dZZr8+TvklRSaYVTrkQ bYLVS56wIOuYs8rCL7qjO6hwoQk/+Tu/Ao2uk2IASx3vo84yaBmXzTp79ZswQgRA vnANEUjFL9Ft8lKI1d2EVGnSXVFxHM/hGBrKAcG2frbm5oXpykoYTqZ0EyzNAt7x 8qeke1XSWKVidX3lPuMGjv5LNz9tqBBrjrnKLejxlkGDVBOtwHnE9B/xLqUG3wfz JS5JyAcR6K55Ju4AbPT4SeSBT4eYAK1tKiMkvJPZq3dZPxYfjvjlP24g0Ufg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660817847; x=1660904247; bh=6busyRkshqkzO5/L7WAarLrkT16H oJUYVywlAnCgLeE=; b=e0vN//U1e26HptlEagbYRVJAWKdGF3LsDzoO5cOCIrD9 jYeDFstEwv+Z1c2JJQs9yUNCnsvbMzXiDAx76gS9AS3LSzYGkOqCzaZ2sruMDG3M xYm/OdA0TKU4QazyHAzVN4kG3vm0IQfZbEbJLa8fdFQdHFFgRrGy7WwRJ7e2HWLB +z/tLW8I8mGrIAAeumG3hWymLzlUP0T1zA5naNZGSKZr0FngoJX4Gylt38ZcOza2 Od6/jrOVUeYm8249bAKpDAPL7ncDUqCTmxQIdPgXZ1DZoeOhvybAueq53be8xvzP sQI6h+koHJzas6kv4sGshHA9NdH/vm0bgbgjKwikZA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehledgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomheptehlhihs shgrucftohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepge ejieegjefhgfffheeuleduvefhiefffedugedvgeduhfdujeehfefhuefggefhnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepqhihlhhishhsse gvvhgvrdhqhihlihhsshdrnhgvth X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Aug 2022 06:17:27 -0400 (EDT) Received: by eve.qyliss.net (Postfix, from userid 1000) id DEB7C540; Thu, 18 Aug 2022 10:17:13 +0000 (UTC) Date: Thu, 18 Aug 2022 10:17:13 +0000 From: Alyssa Ross To: Ville Ilvonen Subject: Development on the Spectrum host Message-ID: <20220818101713.ls23kzatcfbcbeau@eve> References: <20220817075255.wjw24mzuyyl3lhgz@eve> <20220817133935.js4f6ypqrgsov7m5@eve> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o66xty4kujxoollf" Content-Disposition: inline In-Reply-To: Message-ID-Hash: 6OPTRK5RNRLICJPMUINVN4IIHHRJBSKK X-Message-ID-Hash: 6OPTRK5RNRLICJPMUINVN4IIHHRJBSKK X-MailFrom: qyliss@eve.qyliss.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-discuss.spectrum-os.org-0; header-match-discuss.spectrum-os.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: discuss@spectrum-os.org X-Mailman-Version: 3.3.5 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --o66xty4kujxoollf Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2022 at 12:15:28PM +0300, Ville Ilvonen wrote: > On Wed, Aug 17, 2022 at 4:39 PM Alyssa Ross wrote: > > > Yeah, I agree something like this would be good. Especially when > > testing on hardware as you say. I would like to think more about > > exactly how this should work. Do you think that, if you it were > > possible to develop Spectrum on Spectrum, it would be acceptable to have > > to reboot into a new configuration if the host system was changed? > > (Assume that the process of actually building the new system is fast = =E2=80=94 > > the reboot would be the main overhead.) > > Option to develop on the target system is something people (not vocal > here) already expect. I think booting into a new configuration is MCU > style development process and not a fast enough iteration cycle on > Linux user space in all scenarios. Even in kernel driver development, > one may want to unload/load module during development but even disable > module loading as a security hardening mechanism in > deployment/production configuration. Another example is security > policies development (SELinux) - you want to iterate and test them in > user space during development but you want to deploy them immutable. > Then again, kernel or device tree changes will require rebooting. Okay. Obviously we can support booting with the filesystem mounted read-write and no dm-verity. But the problem with that is that then changes have to be manually copied back to the source tree. We could try to add some conveniences for that (e.g. a facility to diff the modified root filesystem with the orginal version). It still means making changes to the compiled system, rather than working on the source, but for the kind of changes you're talking about, maybe doing it that way and then integrating the changes into the Spectrum source at the end wouldn't be too bad? Ideally it would be nice to have something like nixos-rebuild switch, that can build a new system and then switch into it. But the problem is, you have to figure out how to *automatically* take the runtime state of the system (the processes and services that are running), and somehow carry that over into the new system, where anything could have changed. So I'm not sure how we'd do that. NixOS's implementation of this is massive, tightly coupled to both NixOS and systemd, and still it's not very difficult to get it into a weird state where you need to reboot anyway to get an accurate idea of what the change does (or, if you don't realise you need to do that, you just think the change hasn't worked). If a kernel module has changed, do you try to unload and reload it? That's pretty complicated to implement, because you have to unbind the devices from it, unload the module, then rebind them, and even then the module might have had important state that's been lost. If the developer is working on that kernel module it's probably okay, but what if they're working on something else and just pulled a bunch of changes that happened to include a kernel module change? Same with if e.g. the Weston service changes, except in that case we have no way to restore the previous state. So either we choose not to automatically restart Weston, in which case we're not really running the new system, but a weird hybrid that may have bugs not present in either the old or new system, or we do restart Weston, and risk an unsuspecting user losing their whole windowing session. If there's a way we could make this work well, I'm open to it, but it's not at all obvious to me what that would look like. --o66xty4kujxoollf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmL+EaMACgkQ+dvtSFmy ccCgXg/9EretmdI9YsAlAXdDVrXSoYCjy88gLsKh9Ud1OZ+AC4JR0GqNEE0EvAdI 8mC8qjJsxFZLboly2RIeDZA2b+b+P+AHAyTUV0ghhRCLfP8pSDgSlFX7KifZ96mC zy+MebELK7Lb4YQuRAGRqPIEGdJsf9kN3h85cCods6qg2gautZjh6m0upwq/8fKP y0QZCWXeKqISnSBqnhrFrbSaJexHpCnGF5OE7m5fdDUJ0JRaMT1hjoEL1U0K2nir +YUsOmO3lO6J3/QMcOnCk++wP4VEKaGybYOS76lq+Le/JJJn5qIgOnn/j3N+PmoO s0JlrwWf2bW1nLFpBQtG6Y0v2dGPmfIZGetRpjRGVWnLwDlCEClqH3BbHlRgnGPL L2zMADplpfMGn2aKUXtKJVaAIAZmfQRsBB8NG7jFY/cShesZLZhXAdjDybnqf3UB KJl/OsJkAzAg5ecIyJFOb/YmDXFu1m+41Cm03YQSpZ0TWuAOGXN/9OldTVZCfCOi j9kY8Tsq3bKk7G2II5nOS7uLakr55M2vsZ99a+xiZXxN1V5gHO5l2iBdh29O+Pk6 3fraE5fL6AB07ZUVuTRd9uBc5OvR/eX1qcSuQ8JP4/Hcie9kv0Npa+udZnM+fNQI doXgIequMcDCJdIDeLGUWtl7vQ55OlDTFsYwiT/8NEn2b0jkFIA= =7Nxh -----END PGP SIGNATURE----- --o66xty4kujxoollf--