More agressive kernel configuration merges

[Andy Whitcroft]

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