From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS 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 9BAA566158; Fri, 16 Sep 2022 07:26:05 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id CD3F7660E0; Fri, 16 Sep 2022 07:26:02 +0000 (UTC) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by atuin.qyliss.net (Postfix) with ESMTPS id 8D9E3660DF for ; Fri, 16 Sep 2022 07:25:59 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 17E723200A53; Fri, 16 Sep 2022 03:25:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 16 Sep 2022 03:25:57 -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=fm1; t=1663313156; x=1663399556; bh=83BZCevYxH vdwzrVgI1WV9pZw46tL6XUS3fIpTYpYNg=; b=aC9MeOpThHitTIMb/zfXVFRjIY TKnM/V3EG5UKTCMi7eS9sxsx3ScAvmK2sDndCHFh5Zozw+kd4tOxS+8GbHy2GVmo yN917ws2t5QeHFqrGdvms8Q8R0GHpK3Ei23oWWOMrfxbqgJJtTXEU+DeAJij1hYs oy/Tv28KmwbZx6LJsCPZz5fMAH5GWOl8SBLTtCeT8FqrvkB7VGl4/5a0EkV7mOhh u8HKWiVkgEL7IYUZFtB8ocgr2QJd77yGrYWBh8TOhMgwZu8Sjega9SZ5rfYEvTNe zcv8nCa10ZsaO8gzJiWgPDXB2Kw1uEY1cn37CQtNRR/iTEIFKCkjLxhcOwjQ== 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= fm2; t=1663313156; x=1663399556; bh=83BZCevYxHvdwzrVgI1WV9pZw46t L6XUS3fIpTYpYNg=; b=XpZKRmSOa7bpjtrWVBRp9y6W9YverNpB/uGs5P9w+VqS nWvDG3m5aYEj0DyHOlXgK/HTqhruDf+ww/LK1j8KLpXhBcRsMAab9z+7Nxibn6sr KHSNfrfkdSFXs4pcr70XgMkla2vfheVvr+ziGYdmkxCmoAr4AeVqiMp41o0eiect 629IBJtzmW6XHprSZ0wH5H6qUiJoOMEFiUuiHAwxtmaLBgZMYeiAaY4g3V4AcwKv 258eDiO/pobMn+Jet6vf2Ash7H0pj09b8lLNle80SL09WwWTLZK1aAmNZ9CF2tZj Kze94/BYDykOcD0eJMZhJNRYSG4PSbK4akJ1gOZ13Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduledguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihs shgrucftohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepte ehvedugfejgfehhfeijeduleekleejgedvkeeuuefhhfegvdevfeetveegteeinecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihsh hsrgdrihhs X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Sep 2022 03:25:55 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 110D149C; Fri, 16 Sep 2022 07:25:54 +0000 (UTC) From: Alyssa Ross To: =?utf-8?Q?Jos=C3=A9?= Pekkarinen Subject: Re: [PATCH] Add image configuration option In-Reply-To: References: <20220915073515.47855-1-jose.pekkarinen@unikie.com> <87mtb1xd38.fsf@alyssa.is> <87h718yiuk.fsf@alyssa.is> <87zgf0vklc.fsf@alyssa.is> Date: Fri, 16 Sep 2022 07:25:42 +0000 Message-ID: <87wna3n5l5.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: DVGH3UE3UBAUMNMEHABBF3TUV4ZTSLND X-Message-ID-Hash: DVGH3UE3UBAUMNMEHABBF3TUV4ZTSLND X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.5 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 Jos=C3=A9 Pekkarinen writes: > On Thu, Sep 15, 2022 at 4:22 PM Alyssa Ross wrote: > >> Jos=C3=A9 Pekkarinen writes: >> >> > On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross wrote: >> >> [...] >> >> You mean you'd like to manually provide a Kconfig file, rathen than >> using Nixpkgs' (not very good) structured config mechanism, right? >> That should be possible with an overlay, but maybe some documentation >> with an example would be a good idea? >> > > Yes, but, for example, if I provide the overlay that uses that > that Kconfig, the Kconfig should be present in your system, as some > sort of default configuration for the developer to consume if they want > to use the overlay in question, otherwise, the developer needs to fetch > spectrum sources, and then fetch out the default configuration somewhere > else, put them together and test. The goal would be to upstream the overl= ay > so that one can take spectrum source code, make a config.nix to select > the overlay, and build, without extra steps to fetch other artifacts. > > [...] >> >> Well, it's not the size of the change that's important, but whether it >> can be demonstrated that the change solves a problem. A big change to >> fix a clear problem is fine! >> > > It is offering a way to template configurations for the cases > we were commenting before. So it solves a problem, the problem is > that currently the source code doesn't ship default configurations for > developers to test, so I can create a config.nix file downstream that > makes the overlay for the hardened kernel use case, and now, instead > of upstreaming and shipping it with any spectrum checkout, I have > to publish it somewhere else, and document how to put the puzzle > together so that a developer can test, use, and develop further. For > now, it doesn't let combine configuration files, so these templates > may be fat, because you can only make one template per case, > and choose it. In the future it would be good if they are small snippets > that do a particular purpose, and we list all the snippets we want > to make the full use case the user want(for ex. making a cross compiled > build from x86_64 of arm64 which includes security plus debugging). Well, it's not true that it doesn't let you combine files =E2=80=94 it lets= you do that just as much as your patch would (and more flexibly). For example: # config1.nix import ./config2.nix // { # other config goes here } # config2.nix { pkgs =3D ...; } But I understand what you're saying about wanting to keep reusable bits of configuration in the Spectrum repository. I think it would be reasonable to have a "contrib" directory, where extra stuff (like reusable config snippets) that aren't part of the default system but might be useful to people working with it could live, as long as everything required to build a system with that configuration was already present and working in Spectrum so it could be tested (so no aarch64 configs before we have aarch64 support, for example). It's also going to be worth considering when it just makes more sense for things to be first class options instead of reusable configuration modules. Those would be easier to use in a configuration file, but if we end up with too many of them I think it'll be a maintainability problem. One thing I'm already thinking is that maybe it would be an improvement to allow setting individual Nixpkgs options in the configuration file, and have the import handled by Spectrum by default, rather than making the configuration file do the pkgs import as we currently do. Because if the configuration file has to import pkgs, that prevents the Spectrum build system from setting any configuration of its own. That prevents us doing smart things that I think we'd like to do at some point. For example, it would be nice at some point to support cross-compiling from non-Linux machines. And in that case, it would be nice if Spectrum was automatically cross-compiled, for Linux on whatever architecture the build machine is using by default. That would look something like: let splitCurrentSystem =3D builtins.split "-" builtins.currentSystem; currentArch =3D builtins.head splitCurrentSystem; currentKernel =3D builtins.tail splitCurrentSystem; in import ((if currentKernel !=3D "linux" then { crossSystem.system =3D "${currentArch}-linux"; } else {}) // { # other config }) Which would be unacceptably horrible to make people specify in their configuration files when it's something the build system could be doing for them automatically. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmMkJPkACgkQ+dvtSFmy ccBCZg/9HjfvACxbjKiL2u4aIKqTSY5UBvIY/QlfttAWt8eA9S2rdwttx8jEMLiK dPITibeO60opG2Wrp8NA9HQ6N1Lpln6wt1Uoh61A6BneC1VvTl4udGPeqoQwRZPb 1hglO5IOVJwGs/BTx0ZUbGmXemwf/p7OrcJOuWCNC96MOLw8Fb3wPBMcU0i1CLN2 23t8QpsT1tLZkNdpg6vvRDnnWIERjAWU89vPHljoqHJuQxy/ydr4pFMp52L6XQN/ 6ZTVlgKiIDrglOdJvxShAW4mstp5Sd59fQPKxedrHxPe+yTrJkAm8d8r48jU1w1d HZedGPNTaWYwyZnclOVpzykx5gZgWnASvKi/MilS7NsnqO8a9xTZQh1vXMc7NnVQ HE/s6uyNbLCxBBdZ6Rog8en6+BmW1nv3AVzl6ZhptgCAAVsLomo1NV2FCfR69jOf JKz87qblusvIoQiCSRUJEFJ+y/hBl9QAW2Y/8p/N3o64Bq39S+tXHeCUsIra/q4X /JP2O6+j+cugvu2hhGPEyw4sguIgrQLmi9qEnO1C5qnJ27nvk7Zo0si18rIBOtM5 QhdDzAo2BwdY/HfTxDfCuRlKSvMg+vu0OlEKPoaPOw1HsVW46S3HwxfPae2WFeXL 08PxxCgus4CzTNFQNGgo88VAv2yrNVze08FMJNJjE0ZU05e//yE= =nZgD -----END PGP SIGNATURE----- --=-=-=--