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