Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use hooks for main kernel/u-boot version defaulting/overriding; remove symlink usage from many families #6100

Conversation

rpardini
Copy link
Member

@rpardini rpardini commented Dec 28, 2023

use hooks for main kernel/u-boot version defaulting/overriding; remove symlink usage from many families

  • core: semantic change, KERNELSOURCE must be explicitly 'none' to avoid kernel compilation (not unset)
  • main-config: mark mirror variables readonly; add todo's
  • lib/family config: remove resquices of KERNELDIR which is completely unused for a long time
    • also MAINLINE_KERNEL_DIR not needed then
  • main-config: arches: don't default KERNELSOURCE to mainline (already done in common), cleanup comments
  • main-config: arch common: kernel/u-boot config defaulting+overriding via hook instead of pre-setting
    • common.conf delegating to new mainline_kernel_decide_version hooks
    • special case handling for v6.7-rc7
    • some examples
    • late-stage "use rolling branch version"
  • uefi: don't spell out KERNELBRANCH anymore, KERNEL_MAJOR_MINOR is sufficient now
  • meson64: family common: drop KERNELBRANCH, rely on KERNEL_MAJOR_MINOR only, no more symlinks
  • rockchip64: family common: drop KERNELBRANCH, rely on KERNEL_MAJOR_MINOR only, no more symlinks
    • rockchip64_common is used by BOARDFAMILY's with their own LINUXFAMILY, so we can't be very generic here
  • meson (32-bit): family common: drop KERNELBRANCH, rely on KERNEL_MAJOR_MINOR only, no more symlinks
  • [move] rockchip-rk3588 edge 6.7: move patches to archive, do not add symlinks
  • sunxi/sunxi64: move version locking to shared hook in mainline-kernel.conf.sh
  • rockchip (32-bit): move version locking to shared hook in mainline-kernel.conf.sh
  • main-config: arch common: review logging levels, squash some todo, add some todo
  • lib: implement and sprinkle some very basic config var change-tracking across board/family sourcing and several hook calls
  • main-config: arch common: check LINUXFAMILY is set before using it
  • sunxi/sunxi64: move version locking back to family code
  • rockchip (32-bit): move version locking back to family code
  • mainline-kernel.conf.sh: explain better why we need to handle 6.7-rc7 in a special way
  • mainline-kernel.conf.sh: we don't need the 6.7-rc7 hack anymore, comment it out and leave it as an example for future occurences

@github-actions github-actions bot added size/large PR with 250 lines or more Hardware Hardware related like kernel, U-Boot, ... Framework Framework components labels Dec 28, 2023
@rpardini rpardini force-pushed the pr/use-hooks-for-main-kernelu-boot-version-defaultingoverriding-remove-symlink-usage-from-many-families branch from 267a25e to 247bd9d Compare December 28, 2023 00:13
@rpardini
Copy link
Member Author

Yeah I guess everyone is affected here, but mostly @viraniac @paolosabatino @igorpecovnik

  • families now only set KERNEL_MAJOR_MINOR, and the framework resolves KERNELBRANCH for us in a centralized way, including -rc handling, fixed/tagged versions, and per-release version locking if necessary
  • The hooks doing the resolution are in config/sources/mainline-kernel.conf.sh, with forced-tags for sunxi* and rockchip.
    • user config / etc can also add more hooks to do more tricks if necessary.
  • We're also moving away from using symlinks in patches/kernel, to directly or automatically pointing KERNELPATCHDIR to the patches/kernel/archive/xxx-6.7 directory directly.
  • That way bumping kernels is standardized across all families. The few special cases left I will handle soon.
    • To bump kernels (edge from 6.6 to 6.7): 1) copy 6.6 to 6.7 in archive; 2) change a single line in family config.
    • To rollover kernels (current becomes legacy, edge becomes current): two line change in family config, and .config copy or update.
  • better/similar handling for u-boot parameters

For reviews: please review the commits individually

  • also: change-tracking code with white checkmarks tracking changes to relevant variables, so we can know who is setting what where

image

@viraniac
Copy link
Collaborator

Is it possible to split this into 2 seperate PRs - one for cleanup and one for the kernel version related changes? That way we can merge the cleanup code immediately. That part seems to look ok

@rpardini
Copy link
Member Author

Is it possible to split this into 2 seperate PRs - one for cleanup and one for the kernel version related changes? That way we can merge the cleanup code immediately. That part seems to look ok

Sure, I will remove the cleanups if possible. Sorry for mixing it up -- it was a long day.

@rpardini rpardini force-pushed the pr/use-hooks-for-main-kernelu-boot-version-defaultingoverriding-remove-symlink-usage-from-many-families branch from 247bd9d to c1da30c Compare December 28, 2023 09:22
@rpardini
Copy link
Member Author

Is it possible to split this into 2 seperate PRs - one for cleanup and one for the kernel version related changes? That way we can merge the cleanup code immediately. That part seems to look ok

There, cleanups removed.

# If the family does NOT define them, assume sane defaults.
function late_family_config__common_defaults_for_mainline_kernel() {
# @TODO: if KERNELSOURCE is 'none', don't do anything; config is explicitly asking to skip kernel compilation.
if [[ "${KERNELSOURCE}" == "none" ]]; then
Copy link
Collaborator

@viraniac viraniac Dec 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole function looks like a validation function to check if all the required things are present or not. I think this should be moved out of config and to libs perhaps

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this PR, having KERNELSOURCE unset meant don't build a kernel.
After this PR, having KERNELSOURCE unset means use a mainline kernel, and to avoid building a kernel, KERNELSOURCE must be set to none. This is the same logic as was used for BOOTCONFIG=none to avoid building u-boot.
Also, yes, those are hooks (functions) and can be moved around from config to libs or anywhere that is sourced before exts initialize.

config/sources/common.conf Outdated Show resolved Hide resolved
# If the branch is unset, auto-determine it based on KERNEL_MAJOR_MINOR; allow hooks to customize
if [[ -z ${KERNELBRANCH} ]]; then
declare original_kernelsource="${KERNELSOURCE}" # store for later comparing
call_extension_method "mainline_kernel_decide_version" <<- 'MAINLINE_KERNEL_DECIDE_VERSION'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if this should be after all the checks you are adding. Someone can end up using this to unset all the variables that are being set. For example whats stopping me from putting unset LINUXCONFIG and unset LINUXFAMILY into this extension call.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I see you are not adding a hook function for the uboot equivalent of this function. So why do we need it here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of this has the pretense of being resistant to such unset's. None of Armbian is. Users can use lib.config to unset the hell out of everything anyway.

Ref u-boot: I have moved the minimal set of pre-settage that was done in common to a hook. U-boot does not entail the same level of "auto-updating" that kernel does (eg receives no point releases, only major.minor) so it's actually much simpler.


# call hooks to do late validation/mutation of sources, branches, patch dirs, etc.
call_extension_method "late_family_config" <<- 'LATE_FAMILY_CONFIG'
*late defaults/overrides, main hook point for KERNELSOURCE/BRANCH and BOOTSOURCE/BRANCH etc*
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need another hook function? Can't we do the same thing with post_family_confg function. I get the validation part. But why mutate things now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A separate hook is required, otherwise ordering the hooks would be a huge mess.
It also helps to understand that this logic is shared and global across all families, and not part of a single family's handling (which is what post_family_config is for).

Copy link
Collaborator

@viraniac viraniac Dec 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I failed to see why its required. The validation part can be moved into this file. For the default values parrt as I understand we load the family source file first, then common and then arch specific one. So we do already have common.conf and <arch>.conf files to set defaults. Why do we need another hook?

Could you please share the use case so that I can try to see what exactly you are trying to solve by adding another hook function?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The case: centralized, non-family specific, management of mainline kernel versions.
The late_family_config hook was introduced to keep post_family_config logic and ordering unaltered but do global changes to all families / kernels / even vendor ones.
The mainline_kernel_decide_version is specific to mainline kernels.

@viraniac viraniac self-requested a review December 28, 2023 10:29
Copy link
Collaborator

@viraniac viraniac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hit approved by mistake instead of changes requested. See above comments

@rpardini rpardini force-pushed the pr/use-hooks-for-main-kernelu-boot-version-defaultingoverriding-remove-symlink-usage-from-many-families branch 2 times, most recently from 0d7f4de to 9c4c680 Compare December 28, 2023 11:16
…y unused for a long time

- also `MAINLINE_KERNEL_DIR` not needed then
…via hook instead of pre-setting

- common.conf delegating to new `mainline_kernel_decide_version` hooks
- special case handling for v6.7-rc7
- some examples
- late-stage "use rolling branch version"
…NOR only, no more symlinks

- rockchip64_common is used by BOARDFAMILY's with their own LINUXFAMILY, so we can't be very generic here
…g across board/family sourcing and several hook calls
…ent it out and leave it as an example for future occurences
@rpardini rpardini force-pushed the pr/use-hooks-for-main-kernelu-boot-version-defaultingoverriding-remove-symlink-usage-from-many-families branch from 9c4c680 to da1de25 Compare December 28, 2023 11:28
@rpardini
Copy link
Member Author

I don't have it in me to further defend these changes. Closing.

@rpardini rpardini closed this Dec 28, 2023
@rpardini rpardini deleted the pr/use-hooks-for-main-kernelu-boot-version-defaultingoverriding-remove-symlink-usage-from-many-families branch December 28, 2023 11:59
@igorpecovnik
Copy link
Member

igorpecovnik commented Dec 28, 2023

I don't have it in me to further defend these changes.

Those changes affect all people so its better to add more (perhaps useless) then less / no questions. Just to make sure. Currently compilation does't work as hack for 6.7.rc is required after your previous PR and is part of this PR.

@igorpecovnik
Copy link
Member

After #6087 was merged, current Rpi hack stop working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Framework components Hardware Hardware related like kernel, U-Boot, ... size/large PR with 250 lines or more
Development

Successfully merging this pull request may close these issues.

4 participants