kernel: run kernel_copy_extra_sources hooks after kernel_maybe_clean#121
kernel: run kernel_copy_extra_sources hooks after kernel_maybe_clean#121iav wants to merge 1 commit into
kernel_copy_extra_sources hooks after kernel_maybe_clean#121Conversation
- otherwise changes done to kernel dir go away if cleaning is requested, which has been forcing family and board code to use unrelated hooks to workaround it, which in turn requires causes CONFIG_DEFS_ONLY=yes hacks which then causes hashes to differ from actual build runs - with this, now any source-level changes (incl generating patches) can now be done using `kernel_copy_extra_sources`; make sure to include all hashing-related code and references (eg: source SHA1 from external repos) into that hook, so changes there cause a change to the `-HK` - Fixes: c47c937 "Add new hook to allow copying code into kernel"
9a4e580 to
3102e96
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3102e967e9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| LOG_SECTION="kernel_maybe_clean" do_with_logging do_with_hooks kernel_maybe_clean | ||
|
|
||
| # Call extension method to prepare extra sources | ||
| call_extension_method "kernel_copy_extra_sources" <<- 'ARMBIAN_KERNEL_SOURCES_EXTRA' |
There was a problem hiding this comment.
Move extra-source hook past patch cleanup
When this hook copies untracked source trees (for example kernel_copy_extra_sources__khadas_common_drivers creates common_drivers under the kernel tree), the next step still calls kernel_main_patching, whose Python patcher resets to kernel_git_revision and removes untracked files before configuration. So with CLEAN_LEVEL=make-kernel the hook now survives kernel_maybe_clean only to have its files deleted by the patching cleanup, leaving the later kernel config/build without the copied sources; the hook needs to run after that cleanup if its output must be present for the build.
Useful? React with 👍 / 👎.
Codex review trap for upstream armbian#9830 by @rpardini.
What
Two-line swap in
lib/functions/compilation/kernel.sh: moveLOG_SECTION="kernel_maybe_clean" do_with_logging do_with_hooks kernel_maybe_cleanto run before
call_extension_method "kernel_copy_extra_sources".Why it matters
kernel_maybe_cleandoesgit clean -xfdqon the kernel work tree whenCLEAN_LEVELcontainsmake-kernel. With the previous ordering, anyfiles copied into the kernel tree by extensions/board code via the
kernel_copy_extra_sourceshook were immediately wiped, forcingcontributors to copy from unrelated hooks together with the
CONFIG_DEFS_ONLY=yesworkaround — which in turn causes the kernelartifact
-HKhash to diverge from the actual build, poisoning theartifact cache.
After this PR
kernel_copy_extra_sourcesactually does what its namesays, and contributors can drop the workarounds. Cache-correctness is
preserved iff the hook author folds the source SHA1 of whatever is
being copied into the hash material — explicitly called out in the
upstream commit message.
Upstream
armbian#9830
Fixes upstream commit c47c937
("Add new hook to allow copying code into kernel").
Asking codex
Please verify:
(
kernel_main_patching,kernel_prepare_build_and_package)?extensions/or board code thatdepend on the old (broken) ordering?
artifact hash sufficiently captured today, or does this PR need
a companion hardening change?