-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
267a25e
to
247bd9d
Compare
Yeah I guess everyone is affected here, but mostly @viraniac @paolosabatino @igorpecovnik
For reviews: please review the commits individually
|
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. |
247bd9d
to
c1da30c
Compare
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
# 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' |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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* |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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
0d7f4de
to
9c4c680
Compare
…d kernel compilation (not unset)
…y unused for a long time - also `MAINLINE_KERNEL_DIR` not needed then
…done in common), cleanup comments
…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"
… only, no more symlinks
…NOR only, no more symlinks - rockchip64_common is used by BOARDFAMILY's with their own LINUXFAMILY, so we can't be very generic here
…R_MINOR only, no more symlinks
…g across board/family sourcing and several hook calls
… in a special way
…ent it out and leave it as an example for future occurences
9c4c680
to
da1de25
Compare
I don't have it in me to further defend these changes. Closing. |
Those changes affect all people so its better to add more (perhaps useless) then less / no questions. Just to make sure. |
After #6087 was merged, current Rpi hack stop working. |
use hooks for main kernel/u-boot version defaulting/overriding; remove symlink usage from many families
KERNELDIR
which is completely unused for a long timeMAINLINE_KERNEL_DIR
not needed thenmainline_kernel_decide_version
hooks