WIP: Use config fragments for kernel configuration

added 1 commit

5f9ab601 - WIP: Use config fragments for kernel configuration

Compare with previous version

By HenriDellal on 2020-12-14T15:50:58

This seems to work pretty well for me, converted linux-postmarketos-allwinner for me locally using megi's defconfig

How would this work with kernel packages that support multiple arches?

edit: the kconfig check at the end of the edit is broken and I can't disable CONFIG_ANDROID_BINDERFS

By Martijn Braam on 2020-12-17T15:22:10

It doesn't work with multiple arches, currently I use this: !2006 (diffs)

Speaking of kconfig check, I guess it's broken because of not being able to disable that option. Does this issue change if you set the option value manually in the diff file?

By HenriDellal on 2020-12-17T15:22:10

Seems like I found the cause of problem with kernel config option not being applied. make savedefconfig loses the option's state. According to example from initial post, CONFIG_VT is not saved, because there are known changed states of the inheriting options. Though, when the config and diff are merged and make is done on the resulted config, the VT option's state is lost.

If the uncompressed kernel configs are compared, the bigger diff is generated, but it can be modified manually to minify still and it is reliable.

Diff example:

CONFIG_VT=y
# CONFIG_CONSOLE_TRANSLATIONS is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
# CONFIG_FRAMEBUFFER_CONSOLE is not set
CONFIG_HW_CONSOLE=y
# CONFIG_SPEAKUP is not set
# CONFIG_VT_CONSOLE is not set
# CONFIG_VT_HW_CONSOLE_BINDING is not set

By HenriDellal on 2020-12-17T18:53:30

added 3 commits

5f9ab601...1eac61bc - 2 commits from branch postmarketOS:master
51ca873d - WIP: Use config fragments for kernel configuration

Compare with previous version

By HenriDellal on 2020-12-17T19:48:01

added 1 commit

2234cca3 - WIP: Use config fragments for kernel configuration

Compare with previous version

By HenriDellal on 2020-12-17T19:54:24

added 31 commits

2234cca3...69b75432 - 29 commits from branch postmarketOS:master
55303c77 - WIP: Use config fragments for kernel configuration
16c55eb4 - WIP: Add support for multiple arches (untested)

Compare with previous version

By HenriDellal on 2021-02-02T17:17:17

added 21 commits

16c55eb4...5c1c1266 - 19 commits from branch postmarketOS:master
88e08fa1 - WIP: Use config fragments for kernel configuration
ca3896dc - WIP: Add support for multiple arches (untested)

Compare with previous version

By HenriDellal on 2021-03-17T13:48:47

added 5 commits

ca3896dc...2406597f - 4 commits from branch postmarketOS:master
4ce4736e - WIP: Use config fragments for kernel configuration

Compare with previous version

By HenriDellal on 2021-03-20T22:41:15

added 1 commit

e0d581bd - WIP: Use config fragments for kernel configuration

Compare with previous version

By HenriDellal on 2021-03-21T07:58:17

changed the description

By HenriDellal on 2021-03-22T09:17:12

added 7 commits

e0d581bd...a440556a - 6 commits from branch postmarketOS:master
7c9623dc - WIP: Use config fragments for kernel configuration

Compare with previous version

By HenriDellal on 2021-03-30T22:27:54

Afaik msm8916-mainline folks generate defconfig by make msm8916_defconfig pmos.config without usage of scripts like diffconfig, mergeconfig.

Also this implementation lacks the pmos.config file with default required pmos options for mainline kernel. For example: https://github.com/msm8916-mainline/linux/blob/master/kernel/configs/pmos.config

The way I see how kernel fragments support should be done is that it should be somehow generated using pmos.config for kernel APKBUILDs that declare support for config fragments. This would obviously work for mainline kernels only, (otherwise we'll have to keep multiple versions of pmos.config files for each kernel version range).

By Alexey Min on 2021-04-30T16:42:32

That is a good point, thanks. This way it should be possible to get rid of kconfig check for mainline kernels, I guess? I think that pmos.config can be created from pmb.config information, this way it could be more flexible, e.g. Anbox-related config options can be disabled if needed. The only concern I have is that make defconfig config won't work on downstream, but that is still to be checked.

By HenriDellal on 2021-04-30T16:42:32

This way it should be possible to get rid of kconfig check for mainline kernels, I guess?

For those who declare support for config fragments at least

without usage of scripts like diffconfig, mergeconfig.

Btw I'm not saying those scripts are completely useless, maybe there is no way to implement saving config frmagment in kconfig edit without them. I'm not sure what is the best way to do it.

To extend my thoughts above: as I remember from previous discussuions, the resulting config should be generated as a sum of:

linux kernel defconfig (example is arm64 defconfig for arm64) which comes from kernel itself
pmos.config fragment with OS-specific options, presumably this file is stored in pmbootstrap (or generated, maybe)
package-specific config fragment that comes from the package (with SoC-specific options, and drivers for peripherals supported by this kernel package)

By Alexey Min on 2021-04-30T17:10:15

added 17 commits

7c9623dc...4eba7f62 - 14 commits from branch postmarketOS:master
a7ce89f7 - WIP: Use config fragments for kernel configuration
53235c94 - Move code for getting required kernel options in separate function
0f930465 - Add support for pmos.config

Compare with previous version

By HenriDellal on 2021-05-17T12:08:08

The current state is: kconfig edit and build seem to work, kconfig check doesn't. The weird thing is that kconfig edit runs check in the end and it works as well.

Check related pmaports!1812 for updated devicepkg-dev and testing commits.

By HenriDellal on 2021-05-17T12:31:38

added 37 commits

0f930465...6afd35eb - 34 commits from branch postmarketOS:master
19a3ad15 - WIP: Use config fragments for kernel configuration
cb8a3a7e - Move code for getting required kernel options in separate function
d8ac3442 - Add support for pmos.config

Compare with previous version

By HenriDellal on 2021-06-26T07:25:27

So I can tell that kconfig check works as expected now, review can be started, I think.

By HenriDellal on 2021-06-26T07:36:58

Thanks for working on this!

I have a bit mixed feelings about this magic auto-generated pmos.config (generated by the create_pmos_config()). It's nice to avoid the duplication given we already have the existing lists from kconfig check.

On the other hand, this looks like it makes building the kernel packages entirely dependent on pmbootstrap, they can no longer be built properly without it. I think so far most of the pmbootstrap-specific features were optional addons (e.g. building with native gcc, kconfig check, ...). The APKBUILDs itself were mostly standalone and could theoretically be built outside of postmarketOS, or upstreamed to Alpine.

This also requires pmbootstrap changes for all kernel config changes, which should generally be something pmaports-specific (e.g. slightly different on stable/edge branch for new experimental things).

I wonder if there is a good way to have the kconfig check configuration, or config fragments in some pmaports package (e.g. devicepkg-dev, though I'd prefer if it was a separate package). The kconfig check in pmbootstrap could parse it from there.

Also, somehow we need to keep envkernel in mind. At the moment it's convenient to do make msm8916_defconfig pmos.config in envkernel when building linux-postmarketos-qcom-msm8916 but I'm not sure how to do this with the automatically generated pmos kernel config fragment.

By Minecrell on 2021-06-26T14:53:17

Using pmos.config is not mandatory. At this moment, if APKBUILD's options contain !pmb:kconfigcheck, pmos.config is empty. New option can be created to handle this case and to not affect kconfig check availability.

Moving kernel config requirements to separate package is a good idea, the question is what is the best way to implement this change.

By HenriDellal on 2021-06-26T16:04:40

added 1 deleted label

added 34 commits

d8ac3442...ba07c4cf - 31 commits from branch postmarketOS:master
f3a41ea7 - WIP: Use config fragments for kernel configuration
545b1fb7 - Move code for getting required kernel options in separate function
a4139b95 - Add support for pmos.config

Compare with previous version

By HenriDellal on 2021-08-02T11:54:40

removed 1 deleted label

I think we should definitively move the kernel config fragments into pmaports. As minecrell said, they should be tied to different branches / postmarketOS releases, if we change something for edge it shouldn't affect kernels in other branches.

Regarding where to put them, I think devicepkg-dev makes sense. Most/all downstream kernels depend on this already as it provides downstreamkernel_prepare and some mainline kernels depend on it too. I thought about introducing another package for the kconfig fragments, but I don't think there's an advantage; we'd have to adjust all kernel apkbuilds that use it without benefit.

So this is how I would put it in devicepkg-dev:

make a subdir kconfig-fragments
put the fragments there, split up by feature, arch and required kernel versions (see below)
install all kernel configs to /usr/share/kconfig-fragments
- (with a for i in kconfig-fragments/*.config; do install ... done loop)
create a new shell script in devicepkg_dev, which makes the base kernel config fragment available for the current kernel + arch.
- Parse the kernel's version from the topdir's Makefile (VERSION, PATCHLEVEL, SUBLEVEL)
- Go through all kernel config fragments and cat the ones that are relevant (based on version + arch) into a kernel/configs/devicepkg-dev.config file in the source tree
  - (note that apk has a command to compare two versions, we could use that here)
call this script in downstreamkernel_prepare.sh so all the downstream kernels have it
call the script in mainline linux APKBUILDs which don't use downstreamkernel_prepare.sh (or maybe rename downstreamkernel_prepare.sh to kernel_prepare.sh, leave a symlink behind, auto-detect if the kernel is close to mainline and don't do some of the legacy stuff? but I'm already proposing a lot here, that's probably out of scope)

EDIT: we'll need more than one directory for shared configs, so we can have more shared configs per SoC. Something like /usr/share/kconfig-fragments/all/, /usr/share/kconfig-fragments/soc-qcom-sdm845/, ... - see comment.

envkernel integration:

install devicepkg-dev as dependency (it's tiny anyway)
conveniently call the new script somewhere. I guess it makes sense to call it when sourcing envkernel, and copying the generated config fragment to the source tree? (@Minecrell would probably know a good workflow for users since he actually uses this script)

With this approach, it would be possible to build it completely without pmbootstrap too - either install devicepkg-dev and run the script to generate a merged kconfig fragment based on version and arch, or cat relevant ones together manually if needed (-> kconfig fragments are not translated from another format or something, simple cat is enough ).

Regarding pmbootstrap integration:

pmbootstrap kconfig edit should generate a fragment, that is the diff to what was selected in kconfig edit vs. the defconfig in the kernel source tree + the fragment from devicepkg-dev (if the kernel uses kconfig fragments; it needs to keep working with the old format too until we've converted all kernels)
- we can print a note that the kernel is still using the old format once the feature is proven to work, so people see that we have this cool new thing and migrate their kernels
pmbootstrap kconfig check ... I saw this differently in the past, but if we manage to neatly organize our kconfig fragments in pmaports.git, the check really seems unnecessary for the kernels that use fragments. It would only mean we would need to duplicate everything to pmb/config/__init__.py. So I'd say once this is all working, if pmbootstrap kconfig check encounters a kernel that uses config fragments, it should print out a message and do nothing (not throw an error, think of CI), and moving forward we would only adjust the kernel config fragments in pmaports and not touch the kconfig check code in pmaports. Eventually, when all kernels are migrated to config fragments, we can remove this from pmbootstrap.
pmbootstrap aportgen code should generate kernel APKBUILDs that make use of kconfig fragments

EDIT: since we do need to include the full kernel config (comment), it would make sense to check with pmbootstrap kconfig check if the full kernel config needs to be updated or not (also described in that comment below). This would cause CI to fail if only kernel config fragments were updated without updating affected kernels.

Documentation:

Let's automatically add a header on top of the kernel config fragments, that points to a wiki page where people can read how all this works. Like we do it for deviceinfo, device package etc.
- # Reference: https://postmarketos.org/kconfig-fragment
- (url does not exist yet, as I'm just proposing stuff)
- (I used to add < > around URLs in source code and such references, but it doesn't add anything/makes it harder to read, so don't add it here either.)
Add this on top of the fragments in devicepkg-dev and on top of the automatically generated fragments by pmbootstrap kconfig edit.

proposed kconfig fragment file names

EDIT: see comment below for a slight variation introducing + and using _ instead of comma. I prefer that version.

Proposed format:

ID_NAME.config for all arches and versions
ID_NAME,VERSION.config for specific versions
ID_NAME,VERSION,ARCHES.config for specific arches

Parts:

ID: increasing number for each name, base starts at 00
NAME: short human readable name, e.g. base. Must not contain a comma.
VERSION: a version range in the style of cut -f parameter:
- 0.0.0-: >= 0.0.0 (all kernel versions)
- 4.0.0-: >= 4.0.0
- -5.2.0: < 5.2.0 (notably this version is not included. that's where the kernel option was dropped)
- 3.7.0-5.0.0: >= 3.7.0 and < 5.0.0
ARCHES: allowed arches joined by -, e.g. armv7-aarch64

Files would look like this (based on master's config/__init__.py):

devicepkg-dev/
  kconfig-fragments/
    00_base.config
    00_base,4.0.0-.config
    00_base,-4.7.0.config
    00_base,-5.2.0,armhf-armv7-x86.config
    01_anbox.config
    02_nftables,all,3.13.0-.config
    03_containers.config
    03_containers,3.2.0-.config
    03_containers,3.3.0-.config
    03_containers,3.6.0-.config
    03_containers,3.6.0-,x86-x86_64.config
    03_containers,3.7.0-5.0.0.config
    03_containers,3.7.0-.config
    03_containers,3.9.0-.config
    03_containers,3.14.0-.config
    03_containers,3.18.0-.config
    03_containers,3.19.0-.config
    03_containers,4.4.0-.config
    04_zram,3.14.0-.config

Thoughts?

Personally I'm very excited about this feature. Thanks a bunch for pressing this forward @HenriDellal, this will improve greatly how we handle kernel configs in postmarketOS!

By Oliver Smith on 2021-08-10T10:17:21

I think using all underscores for the naming is neater, it also frees up the comma as arch seperator:

    00_base.config
    00_base_4.0.0-.config
    00_base_-4.7.0.config
    00_base_-5.2.0_armhf,armv7,x86.config
    01_anbox.config
    02_nftables_all_3.13.0-.config
    03_containers.config
    03_containers_3.2.0-.config
    03_containers_3.3.0-.config
    03_containers_3.6.0-.config
    03_containers_3.6.0-_x86,x86_64.config
    03_containers_3.7.0-5.0.0.config
    03_containers_3.7.0-.config
    03_containers_3.9.0-.config
    03_containers_3.14.0-.config
    03_containers_3.18.0-.config
    03_containers_3.19.0-.config
    03_containers_4.4.0-.config
    04_zram_3.14.0-.config

It might also be slightly neater to replace VER- with VER+. I understand it's - so it matches up with the VER-VER variant, but in isolation the VER+ makes more sense.

By Martijn Braam on 2021-08-07T11:08:27

I think using all underscores for the naming is neater, it also frees up the comma as arch seperator:

Fine with me! we just need to prohibit underscore in the NAME field then, but that shouldn't be a problem. (Otherwise parsing gets more complicated than necessary.)

It might also be slightly neater to replace VER- with VER+. I understand it's - so it matches up with the VER-VER variant, but in isolation the VER+ makes more sense.

Yeah it probably makes it easier to understand in the "one version or higher" case. So I'd use the + there, and keep the minus for other cases. The examples above turn into:

0.0.0+: >= 0.0.0 (all kernel versions)
4.0.0+: >= 4.0.0
-5.2.0: < 5.2.0 (notably this version is not included. that's where the kernel option was dropped)
3.7.0-5.0.0: >= 3.7.0 and < 5.0.0

By Oliver Smith on 2021-08-07T13:07:46

This sounds like quite a nice feature! I just have a few thoughts -

How easy would it be to create and maintain fragments for different kernel versions? Would it be up to device maintainers to generate these?
We (the SDM845 kernel maintainers) already use a fragment in our kernel fork to disable other architectures and enable the features we need, this could quite easily be split out into several fragments (disable_unused_archs.config, sdm845_features.config) and then have fragments for e.g. waydroid, nftables applied on top. This quite quickly leads to more separation (all qcom kernels could use the fragment to disable other architectures and stuff like nouveau), at this point it's worth considering why we'd use a fragment to disable unused options from the defconfig, instead of generating the config entirely from fragments?
It's possible I missed some explanation previously, but wouldn't this allow changes to the fragments to break kernel packages? Some way to have the kernel package fix the "version" of a fragment might be needed to avoid this kind of confusion.

Overall, I'm super keen on seeing something like this become available, it opens up a lot of opportunities.

By Caleb Connolly on 2021-08-07T16:47:42

I think trying to capture that much info in file names makes it really annoying to read/maintain. What about using directories/symlinks, where configs are grouped by the minimum kernel version.

devicepkg-dev/
  kconfig-fragments/
    all/
      00_base.config
      01_anbox.config
      02_nftables.config
      03_containers.config
    3.2.0/
      03_containers.config
    3.3.0/
      03_containers.config
    3.6.0/
      03_containers.config
      03_containers-x86.config
      03_containers-x86_64.config-->03_containers-x86.config
    3.7.0-5.0.0/
      03_containers.config
    3.7.0/
      03_containers.config
    3.9.0/
      03_containers.config
    3.13.0/
      02_nftables.config --> ../all/02_nftables.config
    3.14.0/
      03_containers.config
      04_zram.config
    3.18.0/
      03_containers.config
    3.19.0/
      03_containers.config
    4.0.0/
      00_base.config
    4.4.0/
      03_containers.config
    4.7.0/
      00_base.config
    5.2.0/
      00_base-armhf.config
      00_base-armv7.config-->00_base-armhf.config
      00_base-x86.config-->00_base-armhf.config

I'm sure someone will complain that this "looks longer" than the example earlier, but I think this is more readable (and wouldn't be hard to parse with a python or shell script).

Oh, I just realized my proposal doesn't currently handle this case:

-5.2.0: < 5.2.0 (notably this version is not included. that's where the kernel option was dropped)

Maybe that could be done with adding a - at the end of the kernel version dir to denote "less than this version" ? e.g. 5.2.0-/?

By clayton craft on 2021-08-08T03:19:06

Thanks for the feedback! (I'll add "EDIT:" marks in my original proposal above to point down here where some parts are more refined now.)

@calebccff wrote:

How easy would it be to create and maintain fragments for different kernel versions? Would it be up to device maintainers to generate these?

We (the SDM845 kernel maintainers) already use a fragment in our kernel fork to disable other architectures and enable the features we need, this could quite easily be split out into several fragments (disable_unused_archs.config, sdm845_features.config) and then have fragments for e.g. waydroid, nftables applied on top. This quite quickly leads to more separation (all qcom kernels could use the fragment to disable other architectures and stuff like nouveau), [...]

I didn't think this part through when I wrote the above listing. But now I'm thinking about it and I'd:

put the kconfig fragments for that specific SoC either in the SoC specific package, or also in devicepkg-dev
put the SoC specific kconfig fragments into a separate directory
pass this directory to the script that builds the final kernel config from the defconfig + all the fragments (the shared ones and the one in the kernel package)
it would need to be passed in a way that works well with envkernel.sh as well, and so envkernel.sh can read it from the APKBUILD. maybe put it in a variable and pass that.
(note that we can't just put the SoC specific fragments in the same dir as the other fragments and only install them on demand, then use all files that are present in the directory at build time. Because this would be too error prone, if one has still installed a package from another SoC in the chroot because they just built another kernel, the same fragments would be used for an unrelated kernel. That's why I proposed to store a list of directories in the APKBUILD instead.)

[...] at this point it's worth considering why we'd use a fragment to disable unused options from the defconfig, instead of generating the config entirely from fragments?

From personal experience, because there are soooooooo many options that I'd rather go with a default config and work from there. But if it's feasible for you to really put all of them into fragments, it would surely be elegant and a lot easier to understand all of them, so would be fine with me.

It's possible I missed some explanation previously, but wouldn't this allow changes to the fragments to break kernel packages? Some way to have the kernel package fix the "version" of a fragment might be needed to avoid this kind of confusion.

Yes, good point! IMHO having kernels depend on specific versions of the fragments is not so great, because then we can't enable features consistently across all kernels.

So after a lot of thinking I realized that to solve this properly... we actually do need to include the generated kernel config in the repository, next to the config fragment. Only then it is possible to detect if the kernel needs to be rebuilt or not after something was changed in the shared fragments.

Example:

linux-postmarketos-qcom-sdm845/
  config-postmarketos-qcom-sdm845.aarch64   # full config
  fragment-postmarketos-qcom-sdm845.aarch64 # kernel config fragment *new*
  APKBUILD

So config-postmarketos-qcom-sdm845.aarch64 is the result of:

defconfig from the kernel repository (not included in pmaports.git)
merge with shared fragments from devicepkg-dev
merge with fragment-postmarketos-qcom-sdm845.aarch64

With a script we should be able to verify whether changes in the shared config are compatible with the result in config-postmarketos-qcom-sdm845.aarch64 or not:

iterate over all shared fragments from the relevant files (kernel version, arch matches) in devicepkg-dev
for each line in that result:
- check if fragment-postmarketos-qcom-sdm845.aarch64 changes this option
  - if it does change this option, either complain (to forbid this), or just ignore it / print a warning
  - if it does not change this option, look for the option in the final config-postmarketos-qcom-sdm845.aarch64. If it has the same value than what we get from the shared fragments, then the generated kernel config is up to date. Otherwise it needs to be regenerated.

It sucks that this makes it necessary to have the full kernel config included, but on the other hand this really allows to add a feature and rebuild all kernels that need it in one step. And it makes sure that we don't have silent breakage by updating the shared fragments and figuring out much later that the kernel doesn't build anymore.

@craftyguy wrote:

I think trying to capture that much info in file names makes it really annoying to read/maintain. What about using directories/symlinks, where configs are grouped by the minimum kernel version.

Thanks for taking the time to propose this. I think this makes it more complicated though:

Let's take the "base" config as example, from pmb/config/__init__.py:

    ">=0.0.0": {  # all versions
        "all": {  # all arches
            "ANDROID_PARANOID_NETWORK": False,
            "BLK_DEV_INITRD": True,
            "CGROUPS": True,
            "CRYPTO_XTS": True,
            "DEVTMPFS": True,
            "DM_CRYPT": True,
            "EXT4_FS": True,
            "KINETO_GAN": False,
            "PFT": False,
            "SAMSUNG_TUI": False,
            "SEC_RESTRICT_ROOTING": False,
            "SYSVIPC": True,
            "TMPFS_POSIX_ACL": True,
            "TZDEV": False,
            "USE_VFB": False,
            "VT": True,
        }
    },
    ">=4.0.0": {
        "all": {
            "UEVENT_HELPER": True,
            "USER_NS": True,
        },
    },
    "<4.7.0": {
        "all": {
            "DEVPTS_MULTIPLE_INSTANCES": True,
        }
    },
    "<5.2.0": {
        "armhf armv7 x86": {
            "LBDAF": True
        }
    }
}

With the above proposals (what I wrote + Martijn's changes), we get these files (leaving out comments like the reference url at the top):

$ cat 00_base.config
# CONFIG_ANDROID_PARANOID_NETWORK is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_CRYPTO_XTS=y
CONFIG_DEVTMPFS=y
CONFIG_DM_CRYPT=y
CONFIG_EXT4_FS=y
# CONFIG KINETO_GAN is not set
# CONFIG_PFT is not set
# CONFIG_SAMSUNG_TUI is not set
# CONFIG_SEC_RESTRICT_ROOTING is not set
CONFIG_SYSVIPC=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_TZDEV is not set
# CONFIG_USB_VFB is not set
CONFIG_VTY=y

$ cat 00_base_4.0.0+.config
CONFIG_UEVENT_HELPER=y
CONFIG_USER_NS=y

$ cat 00_base_-4.7.0.config
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

$ cat 00_base_-5.2.0_armhf,armv7,x86.config
CONFIG_LBDAF=y

So each option is only in one of the files and overall it's pretty similar to the python config thing we already have.

Maybe I don't understand what you meant correctly, but it looks like in your proposal we would define all possible ranges for which we have custom options, then symlink the config files in those ranges that use the unmodified config from "all", but have some merged config instead of the symlinks for other cases?

If that's right, we would end up with lots of long config files which have most options duplicated and differ only slightly, which appears to be much more effort to maintain. One example, how I understood it:

$ cat all/00_base.config
# CONFIG_ANDROID_PARANOID_NETWORK is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_CRYPTO_XTS=y
CONFIG_DEVTMPFS=y
CONFIG_DM_CRYPT=y
CONFIG_EXT4_FS=y
# CONFIG KINETO_GAN is not set
# CONFIG_PFT is not set
# CONFIG_SAMSUNG_TUI is not set
# CONFIG_SEC_RESTRICT_ROOTING is not set
CONFIG_SYSVIPC=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_TZDEV is not set
# CONFIG_USB_VFB is not set
CONFIG_VTY=y

$ cat 4.0.0/00_base.config
# CONFIG_ANDROID_PARANOID_NETWORK is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_CRYPTO_XTS=y
CONFIG_DEVTMPFS=y
CONFIG_DM_CRYPT=y
CONFIG_EXT4_FS=y
# CONFIG KINETO_GAN is not set
# CONFIG_PFT is not set
# CONFIG_SAMSUNG_TUI is not set
# CONFIG_SEC_RESTRICT_ROOTING is not set
CONFIG_SYSVIPC=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_TZDEV is not set
# CONFIG_USB_VFB is not set
CONFIG_VTY=y

# >= 4.0.0
CONFIG_UEVENT_HELPER=y
CONFIG_USER_NS=y

# < 4.7.0
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

# < 5.2.0
# here comes armhf,armv7,x86 only... so would we need two versions of this file
# and symlinks for all other arches to one of both?

$ cat 4.7.0/00_base.config
# CONFIG_ANDROID_PARANOID_NETWORK is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CGROUPS=y
CONFIG_CRYPTO_XTS=y
CONFIG_DEVTMPFS=y
CONFIG_DM_CRYPT=y
CONFIG_EXT4_FS=y
# CONFIG KINETO_GAN is not set
# CONFIG_PFT is not set
# CONFIG_SAMSUNG_TUI is not set
# CONFIG_SEC_RESTRICT_ROOTING is not set
CONFIG_SYSVIPC=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_TZDEV is not set
# CONFIG_USB_VFB is not set
CONFIG_VTY=y

# >= 4.0.0
CONFIG_UEVENT_HELPER=y
CONFIG_USER_NS=y

# Now this block is excluded from the file, since it's 4.7.0 or higher
# # < 4.7.0
# CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

# < 5.2.0
# here comes armhf,armv7,x86 only... so would we need two versions of this file
# and symlinks for all other arches to one of both?

By Oliver Smith on 2021-08-10T00:10:14

Thank you everyone for such valuable feedback. Here is my input on this.

create a new shell script in devicepkg_dev, which makes the base kernel config fragment available for the current kernel + arch.

Parse the kernel's version from the topdir's Makefile (VERSION, PATCHLEVEL, SUBLEVEL)

I suppose that it's not needed as long as we call fragment_prepare from linux package's APKBUILD.

pmbootstrap kconfig edit should generate a fragment, that is the diff to what was selected in kconfig edit vs. the defconfig in the kernel source tree + the fragment from devicepkg-dev (if the kernel uses kconfig fragments; it needs to keep working with the old format too until we've converted all kernels)

This is the current way of doing things with the only difference to use pmbootstrap-generated config instead of one from devicepkg-dev.

pmbootstrap kconfig check ... I saw this differently in the past, but if we manage to neatly organize our kconfig fragments in pmaports.git, the check really seems unnecessary for the kernels that use fragments. It would only mean we would need to duplicate everything to pmb/config/__init__.py. So I'd say once this is all working, if pmbootstrap kconfig check encounters a kernel that uses config fragments, it should print out a message and do nothing (not throw an error, think of CI), and moving forward we would only adjust the kernel config fragments in pmaports and not touch the kconfig check code in pmaports. Eventually, when all kernels are migrated to config fragments, we can remove this from pmbootstrap.

I'd say that removing kconfig check completely is not a good thing for two reasons. At first, the fragments feature (in my opinion) is targeted at advanced pmbootstrap users who have better understanding of configuring kernels. At second, there is no reason to expect all kernels to be migrated in the near future as migrating non-maintained downstream kernels would require an enormous effort. What I suggest in this case is to stop providing kernel config updates for such kernels(that's maintainer's job) as well as setting !pmb:kconfig-check for all abandoned linux kernel packages. At the same time, assuming that some maintainers want to keep updating kernels and given that we need to avoid duplication, I think it makes sense to move kconfig check to devicepkg-dev (e.g. in downstreamkernel_prepare).

Addressing the structure of kconfig fragments (filenames and folders): after reading the whole feedback I think that the best way is to have fragments in a separate package (not in devicepkg-dev). I see it as a package with a bunch of subpackages related to usecases in the following structure:

kconfig-fragments/
  anbox/
    0.0.0/
      all.config
      armv7.config
      ...
  base/
  containers/
  nftables/
  APKBUILD

Kconfig fragments for SoCs would be stored in SoC packages as subpackages as well and depend on kconfig-fragments subpackages. Linux kernel apkbuild depends on these subpackages as well. Contents of subpackages (no matter if they are from SoC package or kconfig-fragments) install to /usr/share/kconfig-fragments/$subpkgname.

Now, the question is: what if I want to use specific fragments in a build.

Examples:

I assume that changes to e.g. containers fragments caused a regression and therefore want to not use it.
I want a more minimal kernel due to size restrictions or personal preference.

In this case a new optional variable can be defined in APKBUILD and used by fragment_prepare to select only specific fragments. If the variable is not defined, all fragments from /usr/share/kconfig-fragments/ are used by default.

With a script we should be able to verify whether changes in the shared config are compatible with the result in config-postmarketos-qcom-sdm845.aarch64 or not:

I think this can be simplified a lot. Let's say that we have a kernel which is known to build with old set of fragments. Given that merging configs should produce the same resulting config every time (If I'm wrong here, please correct me), we can just store full kernel config's checksum in APKBUILD and check against it.

How easy would it be to create and maintain fragments for different kernel versions?

Creating fragments should be rather easy if there is a base fragment that can be used for all pkgvers + additional fragment with options required by specific pkgver range. Maintaining fragments is another thing, but shouldn't be harder than maintaining kernel configs now.

it's worth considering why we'd use a fragment to disable unused options from the defconfig, instead of generating the config entirely from fragments?

That is definitely possible and should be done.

It's possible I missed some explanation previously, but wouldn't this allow changes to the fragments to break kernel packages? Some way to have the kernel package fix the "version" of a fragment might be needed to avoid this kind of confusion.

Yes, but in this case it makes sense to fix the breakage with fragment change which reverts the breaking options.

By HenriDellal on 2021-08-10T13:40:29

Take a deep breath and take 1 step back...

Why are you all trying to support all kernel versions and even downstream kernels? There is no point, just keep them as-is, don't try to support building downstream 3.x kernels with fragments, keep them using current system. They have deviated from upstream too much and they're based on vendor-specific defconfig. Much easier to limit fragments support to only mainline kernels, even more, limiting version to >= latest upstream LTS (>= 5.10 in our case). So, there would be only 1 distro_defconfig (pmos.config), which should be stored in a separate package (I agree with @minecrell here). Separate package is needed so it is independent from pmbootstrap, and possible to keep distro defconfig different for stable and edge branches.
`containers/ ... nftables .. zram .. anbox``` no, no, no... these all should be united into one single distro_defconfig, we don't want to make some parts of it optional, do we? For all mainline (especially main/community) kernels the requirements for kernel config should be globally the same. So, there would be only 1 distro_defconfig (pmos.config) which should contain all features supported by distro, and be arch-independent and preferably require everything as modules (except vitally needed things like CRYPTO_XTS for fde unlocking or EXT2 filesystem driver, dunno). Keeping most things as module will allow to have minimal kernel binary if desired.
SoC-specific (package-specific) fragment should be in kernel package and it should contain all arch-specific and soc-specific options. It can also take care of minimizing kernel size (disabling things like Nouveau driver on QCOM MSM SoCs, etc). It should also contain all drivers for all devices supported by this package, again prefering modules where possible.

kconfig edit and kconfig check become useless for kernel packages with support for fragments. The whole point of fragments is to make kconfig human-readable and human-editable :)

for kconfig edit: maintainer runs make menuconfig manually, or just edits the fragment in text editor
kconfig check makes no sense, because all required options are guaranteed to be there from distro_defconfig

No need to overcoplicate things, invent directory structures and so on.

What am I missing?

By Alexey Min on 2021-10-05T17:21:58

added 1 deleted label

removed 1 deleted label

changed the description

By Alexey Min on 2021-10-05T20:17:23

added type::feature label

added 1 deleted label

Sorry to bother you @HenriDellal,

but we've detected that this merge request hasn't seen any recent activity. If you need help or want to discuss your approach with developers you can ping @postmarketOS. You can also ask on matrix in #devel:postmarketos.org or #postmarketos-devel on OFTC. If no further activity occurs in this MR, postmarketOS developers may close it in the future.

Thanks for your contribution.

By * postmarketOS Bot on 2021-11-04T21:00:04

Note: If somebody wants to continue this, see #1824 (comment 695534539)

By Oliver Smith on 2021-11-06T13:34:46

added status::mr-stale label

Sorry to bother you @HenriDellal,

but we've detected that this merge request hasn't seen any recent activity. If you need help or want to discuss your approach with developers you can ping @postmarketOS. You can also ask on matrix in #devel:postmarketos.org or #postmarketos-devel on OFTC. If no further activity occurs in this MR, postmarketOS developers may close it in the future.

Thanks for your contribution.

By * postmarketOS Bot on 2022-10-16T19:00:36

Just migrated pmbootstrap.git to SourceHut (#2181 (closed)). This is a pretty old patch, if somebody wants to create an updated version then please submit it there.

By Oliver Smith on 2022-10-25T21:40:50

closed

WIP: Use config fragments for kernel configuration

Merge request reports

Activity

proposed kconfig fragment file names