adding CONFIG_MY_NEWCONFIG=y to defconfig considered harmful?

adding CONFIG_MY_NEWCONFIG=y to defconfig considered harmful?

[Nick Desaulniers]

Arnd,
I was looking through `git log arch/arm64/configs/defconfig` and
noticed a few commits like

41925a21 ("arm64: defconfig: Enable TI_SCI related configs")

that add new configs defaulted on.

How come these get turned on for the defconfigs vs a board specific config?

How come arch/arm64/config/ contains a lone defconfig (that appears to
be picking up everyone's wanted defaults) vs arch/arm/config/ having
many board specific configs?

From a continuous integration standpoint, I prefer a slimmer
defconfig, as the more we add to it, the slower the individual builds
get.  I would love to take a hacksaw to arch/arm64/configs/defconfig
(removing a bunch of stuff defaulted on), but maybe there's a strong
argument for this difference from arch/arm/configs/ that I'm not aware
of?

I was looking into this because I want to add CONFIG_RANDOMIZE_BASE=y
to the defaults, so RFC for that idea, too.
Thanks,
~Nick

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: adding CONFIG_MY_NEWCONFIG=y to defconfig considered harmful?

[Ard Biesheuvel]

On Sun, 2 Dec 2018 at 22:59, Nick Desaulniers
<nick.desaulniers@gmail.com> wrote:
>
> Arnd,
> I was looking through `git log arch/arm64/configs/defconfig` and
> noticed a few commits like
>
> 41925a21 ("arm64: defconfig: Enable TI_SCI related configs")
>
> that add new configs defaulted on.
>
> How come these get turned on for the defconfigs vs a board specific config?
>
> How come arch/arm64/config/ contains a lone defconfig (that appears to
> be picking up everyone's wanted defaults) vs arch/arm/config/ having
> many board specific configs?
>

The arm64 maintainers deliberately aim for a single config, since they
aim for a single binary Image that can run on all targets. Any
platform or SoC specific changes to the core are applied via code
patching (for errata workarounds etc). Everything else is pushed into
modules, which are only loaded on demand.

Note that this is a *huge* advantage also from CI/ test coverage
perspective, since you don't have to test 50 configs if you modify
something in the core.

> From a continuous integration standpoint, I prefer a slimmer
> defconfig, as the more we add to it, the slower the individual builds
> get.  I would love to take a hacksaw to arch/arm64/configs/defconfig
> (removing a bunch of stuff defaulted on), but maybe there's a strong
> argument for this difference from arch/arm/configs/ that I'm not aware
> of?
>

Yes. See above.

> I was looking into this because I want to add CONFIG_RANDOMIZE_BASE=y
> to the defaults, so RFC for that idea, too.

That would be an excellent idea, actually. I didn't propose it at the
time, since it was brand new code, but today, all the distros ship
with KASLR enabled as well, so it makes sense to turn it on in
defconfig.

What I would prefer is to enable CONFIG_RANDOMIZE_BASE and
CONFIG_RANDOMIZE_MODULE_REGION_FULL in the defconfig, and drop the
'default 'y for the latter in Kconfig, so that we keep exercising the
PLT code in our test builds (local but also kernelci, kbuild test
robot etc), but don't enable it in other cases (.e.g, distro configs).
The 'full' module randomization increases the number of random bits in
the module region address from 11 to 16, now that the full range is
limited to 4 GB, so the difference is not earth shattering.


On an unrelated but similar note, would anyone mind if we disable
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS in defconfig?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel