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=-2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,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 BFB0061CD0; Thu, 15 Sep 2022 13:48:19 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 1630461CC9; Thu, 15 Sep 2022 13:48:17 +0000 (UTC) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by atuin.qyliss.net (Postfix) with ESMTPS id 6B45D61CC8 for ; Thu, 15 Sep 2022 13:48:13 +0000 (UTC) Received: by mail-lj1-x22c.google.com with SMTP id j13so7555019ljh.4 for ; Thu, 15 Sep 2022 06:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie.com; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=OMsOOpRBlzUQOJNISNYHh8yCoI71pD9X8Oyxr3Gf2Gs=; b=Cj8emZWq6fYLIhmCOMbwvzKbM4Hek94tOXKvjW3gQ+EulaZUwGqJVi31Z5ZSXg6M71 na5Kb/rzs9/0GRNqLJbTeLCDfpxraEMG0pLm7THAF6+2XNCEfU9/7E67D8ynCQGnTIi0 IeM3nj/bCqDywwoKQ1p4iGLPnvD0+x0T3URdBrCu20fbJLUiIeF933nUHW4ZMAijDspW Vat4hTRPigF6//7wjKYSdgeaaVpdBIxhAiJ9RdwhlZ6jFJFqaaeZj6DS/4wHHHCzjjXB 5PYhheu9u5MSV+xIxraEPOLaa1iCoY8k91uH98pq45/eHKcSh6+COCKD/NSn58fMEdVs uhSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=OMsOOpRBlzUQOJNISNYHh8yCoI71pD9X8Oyxr3Gf2Gs=; b=CIf/2R/Holipg08TqgkiJ44u+T081G4m/OSwvm4K6GyrpnFKXzo9/gUoKZCZCLSQ3E 1c2vlba9U/4BkXNBqTik2iC+rtiEtLmGIGa2etOh3XuKm950ZMrskBrRc6dMxHTRpjRV 5vl2hs6ujZ0Ca17YYJHFMaxt38TOVpMt3HouFcO3TOdgq7hE+uuIHgu3qnVl/iXA4IMY Cjj256HhxLMOJxjsURb+o4inB9+y9Ptth9E7VLtA9GC6CriuNuPY136nFuzYy1GyZLNN wVYUOtur1gY/8UufShX7nXtihJSHVHr69d5dhtIldf0Wj3vxFY5figziotTfIHLoBETd 6ohg== X-Gm-Message-State: ACgBeo3/AtGrfCMh+yUlTh+jH5+e66aRQpEWqHDgOQJtw6/qIEd1KvJE s18sJg8VX3/7JF9xG8R1pnxYRA== X-Google-Smtp-Source: AA6agR6pKb8m/N93XLUuiWfe5Q7LTEy+aHP4oFm73OPGkFQibN5lPrQi67+DMeLX2zJUA92aSsywkA== X-Received: by 2002:a05:651c:1147:b0:26b:e6b4:6d34 with SMTP id h7-20020a05651c114700b0026be6b46d34mr9749947ljo.209.1663249690235; Thu, 15 Sep 2022 06:48:10 -0700 (PDT) Received: from [192.168.1.26] (mobile-access-6df011-52.dhcp.inet.fi. [109.240.17.52]) by smtp.gmail.com with ESMTPSA id f16-20020a056512361000b0049b8c0571e5sm1981733lfs.113.2022.09.15.06.48.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Sep 2022 06:48:09 -0700 (PDT) Message-ID: <302c49ae-fef5-2e36-f573-88b00f5af9cc@unikie.com> Date: Thu, 15 Sep 2022 16:48:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH] Add image configuration option Content-Language: en-US To: Alyssa Ross , =?UTF-8?Q?Jos=c3=a9_Pekkarinen?= References: <20220915073515.47855-1-jose.pekkarinen@unikie.com> <87mtb1xd38.fsf@alyssa.is> <87h718yiuk.fsf@alyssa.is> <87zgf0vklc.fsf@alyssa.is> From: Ville Ilvonen In-Reply-To: <87zgf0vklc.fsf@alyssa.is> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID-Hash: YYWGTBGDMEJSIT3Q27AM5GHEK2I3DL2V X-Message-ID-Hash: YYWGTBGDMEJSIT3Q27AM5GHEK2I3DL2V X-MailFrom: ville.ilvonen@unikie.com X-Mailman-Rule-Hits: header-match-devel.spectrum-os.org-0 X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1 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: On 9/15/22 16:22, Alyssa Ross wrote: > José Pekkarinen writes: > >> On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross wrote: >> >>> [...] >>> Okay, thanks for the explanation. I think we can group some of these >>> together: >>> >>> • Stuff that's already Nixpkgs configuration options or can be >>> expressed through an overlay. Whether to cross compile, what >>> architecture to build for, whether to use a vendor kernel, etc. This >>> can already be handled through the existing configuration mechanism. >>> >>> • VM customisation, including extra VMs, disabling Wayland, etc. In my >>> mind there are still some open questions around how this should be >>> implemented exactly, but this is definitely something that needs to >>> be more configurable. >>> >>> • Whether to install extra stuff on the host system. This covers >>> things like debugging symbols and tools. >>> >>> Does that sound right to you? Are there more that you can think of? >>> I'd like to understand the requirements here better, to help think about >>> what sort of configuration mechanisms might be required. >> >> This is a good summary, currently I can think of a coupel of more, >> which is a mechanism to provide upstream project configuration artifacts >> when nix allow to bypass their automated configs, for example, a kernel >> config when using manual config kernel nix package, a bit more unclear >> is how to provide upstream configs when nix is not flexible enough. > > 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? > >> A mechanism to generate a full image from the nix generated artifacts >> putting together kernel, initrd, rootfs and ext partition so that the >> full image can be flashed in a sdcard of choice and use it. This would >> require to be configurable so that you can modify the partition table >> to suit vendor needs. > > We've had some discussion about that already on the list and on IRC. My > current view is that early boot firmware (U-Boot etc.) doesn't really > have anything to do with Spectrum. They both run at different times, > and they communicate over a standard interface (EBBR [1]), so the > specifics of the firmware aren't really in scope for Spectrum itself and > belong elsewhere. It doesn't make sense for Spectrum to be installing > U-Boot any more than it makes sense for U-Boot to be installing > Spectrum, or for Linux to be installing U-Boot — they are two separate > components. (This isn't an approach unique to Spectrum — Fedora is > doing something similar.) > > It can make sense to make an image that is a combination of U-Boot and > Spectrum, but that process should be part of an integration between the > two that exists one layer up, rather than part of either project. For > example, you could do something like this: > > let > spectrum = import { > # config could either be loaded using the standard mechanism > # or inlined here. > }; > # It would also be possible to import individual components of > # Spectrum and assemble them manually if even greater > # flexibility was required, but I doubt that would be common. > > inherit (spectrum) pkgs; > # I don't think a pkgs attribute currently exists on the > # spectrum-live.img derivation, but it might make sense to add > # for this sort of use case. > > uboot = pkgs.ubootRockPro64; > in > > pkgs.runCommand "uboot+spectrum.img" {} '' > # Use sfdisk (or maybe there's some better tool) > # to create a partition table, and copy the U-boot image > # and the Spectrum images into place. > # > # Spectrum is designed to accomodate this by not expecting > # any of its partitions to be at any particular location > # on disk. > '' > > Maybe this is another case where documentation and a worked example > would help? Documented example case would help. It's good to scope but in the big picture it's hard to see early boot firmware would have *nothing* to do with Spectrum. That's not the case with x86_64 either. Let me clarify. On x86 traditionally people can't change early bootloading. -> Spectrum assumes UEFI OS loading because UEFI is just there and can't be changed On arm traditionally people can and will change early bootloading. -> Spectrum has assumed UEFI but UEFI is just not there. It's must be put there - typically on device SD card or eMMC image. On riscv assumption is more like on arm. So the mechanism is essential, even when not *provided* by Spectrum it should be acknowledged. Documenting Spectrum reqs to boot itself with example determines how easily people can make their devices run Spectrum. -Ville > > [1]: https://arm-software.github.io/ebbr/index.html > >> [...] >>> You're right — it's generally a bad thing if people have to patch >>> Spectrum to make it fit their needs. I want to avoid that. But most of >>> the things we've talked about so far don't feel to me like they're going >>> to lead to massive configuration files. The exception is all the stuff >>> that's either Nixpkgs configuration or overlays, but the mechanism you >>> proposed here wouldn't help with that, because only a single >>> configuration file would be able to change anything in "pkgs", due to >>> the configuration files being merged using the non-recursive // >>> operator. That's exactly why it's important to understand what the >>> needs are before we consider specific configuration mechanisms. It's >>> difficult to figure out if an idea will actually make things easier >>> without seeing an example of the problem, and what difference to it the >>> proposed solution would make. >> >> Well, the exact point of that is to give you a small next step to move >> towards a more flexible configuration system, without loosing control >> to revert back if the situation doesn't look better. It is unlikely a more >> complex contribution would be acceptable for you if even a little one >> like this wouldn't make it. > > 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! > > But you've definitely pushed the conversation forward towards a more > flexible configuration system. In particular, we definitely need to > think better about custom VMs and especially optional host components, > and it seems to me that we need good, task-oriented documentation about > how to accomplish things that are already possible using the existing > mechanisms.