Re: [PATCH] Add image configuration option

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 6015 bytes --]

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?

[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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]