Re: [PATCH] Add image configuration option

[Ville Ilvonen <ville.ilvonen@unikie.com>]

On 9/15/22 16:22, Alyssa Ross wrote:
> José Pekkarinen <jose.pekkarinen@unikie.com> writes:
> 
>> On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross <hi@alyssa.is> 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 <spectrum/img/live> {
>              # 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.