change kernel config system

[Jan200101]

Config change suggestions

The OGC Kernel currently provides a set of plain files to set and unset kernel configurations based on the desired distro however the system is fairly inflexible and has many shortcomings that make it less attractive for downstream consumers.

Prelude

Kconfig

To get people up to speed:

The Linux kernel uses a config system called Kconfig which allows various subcomponents (such as drivers) to be enabled, disabled or otherwise configured during compilation.

The config file used is a singular file with options in the format of CONFIG_OPTION=VALUE being separated by newlines i.e.

CONFIG_FOO=y # bool/tristate
CONFIG_BAR=2000 # int
CONFIG_MOD=m # tristate

For distributions one config is usually not enough so there are multiple ways this is solved:

• Arch: only supports x86_64 so only needs one config
• Debian: has a predefined config per architecture (source)
• Fedora: Keeps a hiarchical folder based structure to have one filer per config with the ability to inherit from different trees, architecture dependent configs, support for flavor configuration (i.e. Real-Time, Debug, etc.) (source)
• Ubuntu: uses a custom python based annotation system to create a config. Launchpad does not provide a web interface for the git repo anymore so here is a snippet:

# Menu: HEADER
# FORMAT: 4
# ARCH: amd64 arm64 armhf ppc64el s390x
# FLAVOUR: amd64-generic amd64-lowlatency arm64-generic arm64-generic-64k arm64-lowlatency arm64-lowlatency-64k armhf-generic armhf-generic-lpae ppc64el-generic s390x-generic

CONFIG_ACCESSIBILITY                            policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'ppc64el': 'y', 's390x': 'n'}>
CONFIG_ACCESSIBILITY                            note<'LP: #1967702'>

CONFIG_ACPI_CUSTOM_DSDT_FILE                    policy<{'amd64': '""'}>
CONFIG_ACPI_CUSTOM_DSDT_FILE                    note<'might allow hardware damage'>

CONFIG_ACPI_CUSTOM_METHOD                       policy<{'amd64': 'n', 'arm64': 'n'}>
CONFIG_ACPI_CUSTOM_METHOD                       note<'SECURITY: allows arbitrary execution'>

CONFIG_AGP                                      policy<{'amd64': 'y', 'ppc64el': 'y'}>
CONFIG_AGP                                      note<'not autoloadable'>

Possible Changes

Option 1 - plain

Keep everything as is and keep separate configs per architectures and required feature set.

Different distros usually enable different options per architecture so having one universal config may not always be feasible in terms of compatibility.

Option 2 - hierarchical Kconfig

Do it similar to how Fedora does, keep every option as a dedicated file as part of a bigger tree that can then be used directly or inherited from other trees.

This option would require custom tooling but would make it feasible for downstream consumers to easily layer their own configuration ontop of the OGC and base distro configs.

Option 3 - Custom Format

The KConfig system can in many ways be considered dated but not really replacable due to how flexible it is, since we are a downstream consumer with their own needs a custom format (likely based on an existing file format) could be made to make the creation of KConfig files easier

Here is one mockup of what such a custom format could look like using TOML, this does not represent how this implementation would look:

FB_SIMPLE = "n"

[arch.x86]
USB_DWC3 = "m"  

Up- and downstreams would need to be considered because existing systems will need to be migrated.

Some consideration needs to be taken when this is implemented due to the fact that all current up- and potential downstreams make use of the kconfig system, an automatic conversion system would make it easier to adopt the ogc kernel and even allow themto keep their existing tools and workflows.

Implementation

I already wrote my own tools for kernel-blu so I volunteer to write any additional tooling needed to implement this.

[pastaq]

For reference, here is the current kconfig policy:
https://github.com/OpenGamingCollective/organization-governance/tree/main/kernel#52-repository-structure
Currently there are no distros utilizing the policy for a custom config.

[nothingneko]

a note on the hierarchical config's layering: while it's appealing to me to be able to add tweaks on top of the OGC kernel, i fear that building the OGC kernel on top of the existing distro kernel may lead to it varying across distros, which defeats the purpose of it a bit

[Jan200101]

a note on the hierarchical config's layering: while it's appealing to me to be able to add tweaks on top of the OGC kernel, i fear that building the OGC kernel on top of the existing distro kernel may lead to it varying across distros, which defeats the purpose of it a bit

sure but this is already being done regardless of the config system, the CI downloads the distro specific config and then patches it with additional functionality ontop

I think at the end it should be up to any downstream consumer to how they use it, including having the ability to use existing configurations which we could simplify for them.

There is also the factor of wanting to provide compatibility for what a distro already provides and depends on, I know for a fact that Fedora and Ubuntu have some conflicting kernel configs that are incompatible with each other and would break something on both ends if changed.

[KyleGospo]

I like both option 2 and option 3, I think option 3 is a little closer to what we're already doing

Are there any reasons you would want one over the other?

[Jan200101]

I like both option 2 and option 3, I think option 3 is a little closer to what we're already doing

Are there any reasons you would want one over the other?

Option 2 is just am abstraction over the existing Kconfig format which would make it easier to work with for anyone already familiar with it and allow any tools that expect that format to continue working

Option 3 would essentially be starting from scratch with a new format that is later translated to a config, in practice this would allow for more modern tooling to be developed around it and avoids common pitfalls that someone new to Kconfig would experience.

[pastaq]

a note on the hierarchical config's layering: while it's appealing to me to be able to add tweaks on top of the OGC kernel, i fear that building the OGC kernel on top of the existing distro kernel may lead to it varying across distros, which defeats the purpose of it a bit

I disagree. The point of this kernel is that the source and development target is consistent between distros to reduce duplication of effort and to streamline a path towards upstreaming. If each distro wants to ship that source with a different config to meet their own needs then they should.

[pastaq]

I like both option 2 and option 3, I think option 3 is a little closer to what we're already doing
Are there any reasons you would want one over the other?

Option 2 is just am abstraction over the existing Kconfig format which would make it easier to work with for anyone already familiar with it and allow any tools that expect that format to continue working

Option 3 would essentially be starting from scratch with a new format that is later translated to a config, in practice this would allow for more modern tooling to be developed around it and avoids common pitfalls that someone new to Kconfig would experience.

Can you give an example of modern tooling? I'm personally of the opinion that learning kconfig is step 1 of getting into kernel development/maintenance and not really that difficult.

[Jan200101]

Can you give an example of modern tooling? I'm personally of the opinion that learning kconfig is step 1 of getting into kernel development/maintenance and not really that difficult.

What I mean is that more modern tooling can be developed, not that any exists already.

The kconfig format is very dated and in many ways obtuse and hard to automate

one example of a footgun is disabling a config key, which is done by marking it as unset i.e. # CONFIG_BLA is unset
these days there is some support for disabling it by value i.e. CONFIG_BLA="n" but last I checked this isn't universally supported

more established formats (TOML, YAML, JSON, maybe not XML) are a lot easier to work with as a human while also being able to be reliably parsed by a program which would simplify workloads for us and give downstream consumers the ability to create their own tools to make nessary changes or even add their own sections.