More agressive kernel configuration merges
Tim Gardner
tim.gardner at canonical.com
Mon Jun 15 20:10:27 UTC 2009
Andy Whitcroft wrote:
> While looking at Amit's configuration merging changes, and while trying
> to set some configuration items I realised that there was a further
> trick we could play to further merge the configurations.
>
> If we consider the update I was making. I had just updated all instances
> of CONFIG_PCI_IOV to enable it where 'everywhere', well anywhere it
> was supported. As this option only exists on x86 we end up with three
> copies of this option as below:
>
> debian/config/amd64/config.common.amd64:CONFIG_PCI_IOV=y
> debian/config/i386/config.common.i386:CONFIG_PCI_IOV=y
> debian/config/lpia/config.common.lpia:CONFIG_PCI_IOV=y
>
> It would be nice if this would only appear in one place. One way to
> allow this would be to inject yet a further level containing all x86
> architectures and allow this to merge up to there, on the assumption
> that commonality is most likely within similar architectures. Another
> would be to allow this to trickle up to the top of the hierachy, to the
> config.common.ubuntu configuration. Putting it at the top level it would
> apply to all architectures, including those which start to support it
> later, which much better meets my intent. This would be particularly
> valuable for security options like CONFIG_DEBUG_RODATA which would get
> set immediatly when an architecture started supporting it.
>
> Ok, back to the trick. When we build configs from the split configs for
> update, edit, or for a build we merge the various component parts and then
> run 'make oldconfig' over that merged configuration. The config system
> understands which options are valid and ignores any attempt to set the
> value of any option which is invalid in this configuration. This means
> that actually we could safely merge the CONFIG_PCI_IOV up to the top level
> as those architectures which do support it (i386, amd64 and lpia) would
> take the merged value, and those which do not (armel) will just ignore it.
>
> what did that mean? It means that when splitconfig is merging common
> options it could consider a 'missing' (ie. completly absent) option in one
> source as a match to any value rather than a missmatch when considering
> common options, and the resulting split configurations will still generate
> the same actual configurations. As a bonus we will have many more options
> merged up to the top levels.
>
> Using the same example, this approach we end up with the following for
> the CONFIG_PCI_IOV option:
>
> debian/config/config.common.ubuntu:CONFIG_PCI_IOV=y
>
> It should also make it simpler to change options as more of them should
> trickle up to the top.
>
> So what might this gain us. If we allow merging of of 'missing' with
> any value we get (with identicle actual confiurations):
>
> debian/config/amd64/config.common.amd64 | 2418 -----------------------
> debian/config/amd64/config.flavour.generic | 2 -
> debian/config/armel/config.common.armel | 181 --
> debian/config/config.common.ubuntu | 2893 ++++++++++++++++++++++++++++
> debian/config/i386/config.common.i386 | 2651 +-------------------------
> debian/config/i386/config.flavour.generic | 17 -
> debian/config/i386/config.flavour.server | 22 -
> debian/config/lpia/config.common.lpia | 2273 ----------------------
> 8 files changed, 2897 insertions(+), 7560 deletions(-)
>
> Obviously there is a flip-side which it is slightly less obvious which
> architectures are implementing an option if we merge them up to the top.
> So we might consider only merging those which are disabled, though we
> now lose the security advantages:
>
> If we only allow merging of 'missing' with 'is not set' we get:
>
> debian/config/amd64/config.common.amd64 | 328 --------------------
> debian/config/amd64/config.flavour.generic | 2 -
> debian/config/armel/config.common.armel | 96 ------
> debian/config/config.common.ubuntu | 459 ++++++++++++++++++++++++++++
> debian/config/i386/config.common.i386 | 349 +---------------------
> debian/config/i386/config.flavour.generic | 5 -
> debian/config/i386/config.flavour.server | 2 -
> debian/config/lpia/config.common.lpia | 308 -------------------
> 8 files changed, 460 insertions(+), 1089 deletions(-)
>
> I have preliminary patches implementing this scheme. What do people
> thing of the tradeoffs here? I am thinking that the full merge would
> allow us to better describe our intent when changing options.
>
> -apw
>
Thats an interesting thought. If I understand correctly, all config
options that have the same value everywhere (where 'not present' is a
wildcard match) would get collated to config.common.ubuntu ?
Lets start with that patch and see how it works out. I think we'll get
some odd stuff in config.common.ubuntu such as config options that apply
to only one arch (LPIA for example).
rtg
--
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team
mailing list