| Message ID | 20230203-arm64-defconfigs-v1-0-6d0d03a6dbd2@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: configs: Provide slimmed down configuration for guests | expand |
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@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
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.
On Fri, Feb 10, 2023 at 02:51:23PM +0000, Mark Brown wrote: > On Fri, Feb 10, 2023 at 02:34:03PM +0100, Arnd Bergmann wrote: > > 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. Ah, now I try it properly I remember the problem with this approach: the tooling doesn't like turning off configuration options that were explicitly set by the base configuration: | Value of CONFIG_ARCH_ZYNQMP is redefined by fragment ./arch/arm64/configs/virt.config: | Previous value: CONFIG_ARCH_ZYNQMP=y | New value: # CONFIG_ARCH_ZYNQMP is not set It produces the expected result but does so rather loudly. It looks like those warnings have just been there from the start and not thought about too hard so we should be able to fix the tool though.
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@kernel.org> --- Mark Brown (2): arm64: configs: Split defconfig into base and platform configs arm64: configs: Add virtconfig arch/arm64/Makefile | 10 ++ arch/arm64/configs/base.config | 169 +++++++++++++++++++++ arch/arm64/configs/{defconfig => platforms.config} | 169 --------------------- arch/arm64/configs/virt.config | 43 ++++++ 4 files changed, 222 insertions(+), 169 deletions(-) --- base-commit: 4fafd96910add124586b549ad005dcd179de8a18 change-id: 20230203-arm64-defconfigs-c04cf5fa6288 Best regards,