Ubuntu Wiki

• Launchpad Entry: kernel-karmic-config-rework

• Created:

• Contributors:

• Packages affected:

Summary

The kernel configurations are currently independently specified per architecture. This means that changes need to be carefully coordinated between architectures. For example it is not simple to say "we need to turn option X on in all architectures" and ensure they are turned on in all current and future architectures.

The purpose of this blueprint is to evaluate options on how we might better handle the kernel configurations. This will involve evaluating the mechanisms used in other distros, particularly debian which is rumoured to have an override based system.

Release Note

No release note should be required as there should be no user visible change.

Rationale

The kernel configuration is currently hard to maintain in a consistent manner making it hard to ensure that security and other policy has been applied across all distro supported architectures.

Especially hard is enabling new kernel flavours (e.g. for an ARM SoC) where you start from a typical minimal config as embedded users are used to. As the entire distro is brought up on this kernel, one has to start enabling various features, e.g. Apparmor, security settings for preventing various exploits, etc. This is tedious as one goes over each setting in an existing flavour and makes corresponding changes in the new flavour. Besides being prone to human error, there is also the possibility that certain features are hardwired to x86 because the developers have never tested them on other architectures. So these will not be visible in the new flavour.

We need an easier way to say that our entire distro enables or disables certain config settings.

User stories

Aarron wants to ensure that CONFIG_DEBUG_RODATA is set in all architectures including new ones.

Brent wants to be able to tell quickly what options are common to all architectures and flavours.

Assumptions

Design

The bulk of the work would be to review how other projects approach config handling and see how we might use that to improve our handling.

Implementation

Stage 1

Currently we consolidate the common options between the flavours within an architecture. It would be logical to extend this one level further to consolidate the architectures into an ubuntu wide common configuration options. This would allow common changes to be made there, and where architectures are not consistent we should have greater visibility of the inconsistencies.

Stage 2

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 can safely merge options up where the other merge candidates have no value at all. This allows values to propogate further up the tree while maintaining the same resulting configurations.

Making use of this feature we can more agressivly merge the configurations pulling far more options up to the top level. This makes it much simpler to identify common options. It also provides for automatic default values for new architectures and flavours from the top level, rather than the new config simply creating a large split.

Test/Demo Plan

The built configurations should be the same before and after any changes to the source format and build methodology.

Unresolved issues

None at this time.

CategorySpec