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

Mark Brown broonie at kernel.org
Fri Feb 10 06:51:17 PST 2023


On Fri, Feb 10, 2023 at 02:34:03PM +0100, Arnd Bergmann wrote:

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

You can do a hack with removing all the options that are defined in one
config file from another but yes, the tooling isn't ideal for that right
now AFAICT.

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

That does knock out quite a lot of stuff (about 2400 options), but
there's still a bunch of widely deployed architecture neutral stuff -
it's about 25% of the build time of defconfig for me, whereas the
virtconfig in these patches is about 50% of the build time.  It's a 
combination of widely used IPs, subsystems that can't be used in
mach-virt and off SoC devices.  We can obviously build on that approach
though, and 25% of a big number is still a win.

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

That should already be true AFAIR for defconfig, I don't bother with
modules for testing on virtual systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230210/d626586a/attachment.sig>


More information about the linux-arm-kernel mailing list