[PATCH 0/2] arm64: configs: Provide slimmed down configuration for guests

[Arnd Bergmann]

On Mon, Feb 6, 2023, at 17:26, Mark Brown wrote:
> It has been noted that due to the extensive platform support it
> enables the arm64 defconfig is rather large and takes a while to
> build in comparison with other architectures which can be a
> burden when doing cross architecture work, especially when
> testing is mainly in emulation.  We can mitigate this by providing
> a configuration that only enables the support required to run in
> mach-virt, this will be much smaller and quicker to build.
>
> Having two completely separate configurations would mean that we'd
> need to make any changes to the architecture wide configuration in
> both the existing defconfig and the new configuration if we wanted to
> ensure consistent default behaviour.  We can reduce this by splitting
> the existing defconfig into a base fragment which enables options for
> the architecture itself and one for platform configuration which has
> all the platform enablement options, merging them to produce
> defconfig.  We can then add another fragment enabling only options for
> mach-virt and merge that with the base config to provide a new
> virtconfig configuration.
>
> The split of configurations is somewhat arbitrary, there will be some
> room for discussion there, and it may be that splitting things up in
> this manner is considered more trouble than it's worth.  If we're
> going to start doing this then there may also be some desire for other
> configurations. 
>
> This is based on current -next since it's very late in the
> release cycle.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>

I definitely like the idea of splitting the platform specific
options from generic settings, that seems extremely useful. My fear
with your specific patch is that this will lead to the config
getting out of sync because it is very hard to compare the
contents with the 'make savedefconfig' output, at least with
the tools I usually use.

I wonder if we could get to a similar result by having 'defconfig'
still contain all platform support, but then use a fragment to
turn off most of the CONFIG_ARCH_* symbols which in theory
should also disable any platform specific drivers, provided
they have the usual 'depends on ARCH* || COMPILE_TEST' guard.

A related fragment we could have would be to configure anything
as built-in that is needed for booting a typical Debian rootfs
in a virtual machine, and then just run 'make Image' to boot
that without having to even build the modules.

      Arnd