User:Ollieparanoid/kconfig-fragments-2021-10-05

From postmarketOS

We had a ~3 hour meeting to discuss how to move kernel config fragments in pmaports/pmbootstrap forward. Here are the notes.

People (some only were in part of the meeting):

  • Alexey Min
  • Caleb
  • Clayton
  • Dylan
  • Henri
  • Luca
  • Martijn
  • ollie

Brainstorming

postmarketOS kconfig fragments discussion
---

Henri's merge requests:
* https://gitlab.com/postmarketOS/pmbootstrap/-/merge_requests/2006
* https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1812

#### Brainstorming

where to store kconfig fragments?
    -> pmaports?
        seems like best solution:
        - can have different configs per branch (edge vs stable)
        - kernels are there too, fits in well

Support downstream kernels?
    * Can deprecate "pmbootstrap kconfig check"

How fragmented should kernels be?
    * Completely built from fragments?
    * Fragments on top of the given kernels defconfig

How can we still keep kernels distro-agnostic?

How do we handle changes to config fragments which affect many kernels?
    * Ensuring they don't cause breakages
    * Handling rebuilding many kernels on BPO

Where should fragments which enable a given SoC go? If they exist?
    * We could have a defconfig, an SoC fragment and ~~per-device fragments~~
        * no, device doesn't need specific fragment. everything for all devices should be in SoC config fragment

How do we deal with teaching new people how to package their kernels?
    * Already somewhat confusing for newbies to deal with pmbootstrap/pmaports/envkernel
        Also having to deal with fragments somehow would be added confusion and doesn't
        actually represent the state of "mainline kernel development", this is a distro
        feature.

Scrape cateee.net to handle versioning config options?

have a simple approach, so it's feasible to implement and maintain

where to put the kconfig fragments?
  * a) like patch files, with a symlink <---
      * advantage: one less thing to think about
      * this seems to be the better one
  * b) in packages
      * advantage: no checksum

how to version the configs?
* one config per kernel version?
* or maybe add diffs for future kernel versions where configs change, and get everybody to upgrade and then throw it out all at once?
    * nah too complex, maybe later, but not in the initial version


Concept

#### Concept

* mainline only, for downstream: keep using "pmbootstrap kconfig check" instead
* put kconfig fragments in pmaports, as symlinks
* don't split fragments per feature (anbox, nftables, ...), have one config
* pmbootstrap kconfig edit + fragments kernel: should save a diff

##### Updating kernel config fragments
* edit the fragment
* update checksums of all kernels that use it
* bump pkgrel of all kernels that use it
* if it becomes a problem in terms of rebuild time, we could batch it in every 1-2 weeks

##### How to apply the kernel config fragments

a) short term, practical approach
  * defconfig from kernel git repo
  * SoC on top of defconfig
  * postmarketOS kconfig fragment on top
  * advantage: kernel can be used in multiple distros, less effort

b) mid-term, super clean approach
  * postmarketOS maintains defconfig
      * start from disabled state (allnoconfig?/tinytinyconfig?)
      * get one device booting from it
      * separate out soc specific bits from it
  * kernel has fragment for SoC + device features
  * check that after merging pmOS + SoC config, that all bits from SoC config are still enabled in the full config
  * advantage: we can disable noveau and lots of other things we don't need, will yield slimmest config?
      * this is even somewhat automated with:
      * scripts/dtc/dt_to_config - https://github.com/torvalds/linux/blob/master/scripts/dtc/dt_to_config
  * Luca wants to do it for one kernel, but having another person do it and compare notes would be great
  * idea is to not have device specific kconfig fragments

##### what to put in the kconfig fragments?

* everything from "pmbootstrap kconfig check"
* additional drivers like usb cameras too, as modules
    * that makes it consistent and in theory you could use your phone as PC and plug everything in
* no PCI stuff for now (ignore pinebook pro)
    * later: kconfig fragment for pci
        * "random pci drivers" config
        * or alternatively, one "-extras" config that would be used by laptops etc?
    * => so we'll need support for multiple kconfig fragments in the future, but that doesn't need to be solved now.

##### what should "kconfig edit" do with kernels using kconfig fragments?
* generate the full config and run it through menuconfig, then diff that against the existing config after saving and just show that diff so a maintainer can make a good decision on what to do with those options.

#### Versioning

Have fragments be versioned, some folder heirachy like the following:
```
./device/.shared-kernel-fragments
├── 5.10.fragment
├── 5.12.fragment
├── 5.13.fragment
├── 5.14.fragment
├── 5.9.fragment
└── mainline.fragment
```

(maybe change .shared-* to _shared-* in a MR)

With every kernel release, copy the `mainline` dir for that release as the version number.

Kernel packages specify the fragments they use, when building kernel packages we look for the fragments under the given version, default to mainline/ otherwise.

*who would use the mainline fragments? just -rc kernels? how do we deal with -rc kernels when the actual release comes out? a -rc1 kernel may not work with fragments for the final release?*
=> -rc1 kernels not allowed

### TODOs

* implement a)
    * pmaports: something like mainline_kernel_config_prepare
    * pmbootstrap: kconfig edit
* implement b) later on :)