José Pekkarinen <jose.pekkarinen@unikie.com> writes:

> On Thu, Sep 15, 2022 at 4:22 PM Alyssa Ross <hi@alyssa.is> wrote:
>
>> José Pekkarinen <jose.pekkarinen@unikie.com> writes:
>>
>> > On Thu, Sep 15, 2022 at 2:31 PM Alyssa Ross <hi@alyssa.is> 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 overlay
> 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 — 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 = ...;
	}

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 = builtins.split "-" builtins.currentSystem;
          currentArch = builtins.head splitCurrentSystem;
          currentKernel = builtins.tail splitCurrentSystem;
	in

	import <nixpkgs> ((if currentKernel != "linux" then {
          crossSystem.system = "${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.