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

WIP: Allow reusing existing kernel tree as-is #6469

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

matthijskooijman
Copy link
Collaborator

@matthijskooijman matthijskooijman commented Apr 4, 2024

This skips all git checkout, patching, configuring and cleaning when USE_EXISTING_KERNEL_TREE=yes is passed.

This can be useful when doing kernel development by making changes directly to the kernel sourcetree in cache/sources, while still allowing to use the compile.sh to use the same compilation commands, deb package building, ccache, etc. It is also useful when bisecting a kernel issue.

Can be used something like this:

USE_EXISTING_KERNEL_TREE=yes ./compile.sh default kernel

To produce a kernel deb in a few minutes ready to be installed on a device.

This is mostly a proof of concept to explore the usecase. In particular:

  • I am not happy with the USE_EXISTING_KERNEL_TREE name yet.
  • I wonder if this variable should maybe be split into different ones (e.g. for skipping git checkout, patching, config, clean already has one that can be used).
  • Or maybe it would be better to split off some code out of compile_kernel() and expose a kernel_build and/or kernel_package command from ./compile.sh instead?

This skips all git checkout, patching, configuring and cleaning when
USE_EXISTING_KERNEL_TREE=yes is passed.

This can be useful when doing kernel development by making changes
directly to the kernel sourcetree in `cache/sources`, while still
allowing to use the `compile.sh` to use the same compilation commands,
deb package building, ccache, etc. It is also useful when bisecting
a kernel issue.

Can be used something like this:

	USE_EXISTING_KERNEL_TREE=yes ./compile.sh default kernel

To produce a kernel deb in a few minutes ready to be installed on
a device.

This is mostly a proof of concept to explore the usecase. In particular:
 - I am not happy with the USE_EXISTING_KERNEL_TREE name yet.
 - I wonder if this variable should maybe be split into different ones
   (e.g. for skipping git checkout, patching, config, clean already
   has one that can be used).
 - Or maybe it would be better to split off some code out of
   compile_kernel() and expose a kernel_build and/or kernel_package
   command from ./compile.sh instead?
@github-actions github-actions bot added the size/small PR with less then 50 lines label Apr 4, 2024
@matthijskooijman
Copy link
Collaborator Author

As the commit message indicates, this PR is mostly a call for feedback on how to properly implement this. While testing this, I already ran into an issue with the current implementation - the artifact_version is generated based on remote querying of the git repo based on the configured git ref, so that will not see local changes to the kernel tree and conclude that the previous version is fine. On my first attempt, this was not a problem because applying this commit also changed bash files, a hash of which is included in artifact_version. For now I'm working around this by removing the cache manually:

 rm output/packages-hashed/global/linux-* output/packages-hashed/kernel-sunxi-edge_6.7.12-Sdacf-D0000-Pab93-C0cf3Hfe66-HK01ba-V014b-Bc114-R448a_armhf.tar  output/debs/linux-*

@ColorfulRhino ColorfulRhino added the Needs Documentation New feature needs documentation entry label Apr 4, 2024
@ColorfulRhino
Copy link
Collaborator

Added documentation label to make sure this new option won't be forgotten once implemented.

@rpardini
Copy link
Member

rpardini commented Apr 5, 2024

  • maybe it would be better to split off some code out of compile_kernel() and expose a kernel_build and/or kernel_package command from ./compile.sh instead

Yeah would need to refactor in a such a way that we can do the if check the minimum amount of times possible, ideally once.

the artifact_version is generated based on remote querying of the git repo based on the configured git ref

yeah, but the calc function should be easy to replace with something that produces the head sha1 from the "current" tree.

It's the rest of the versioning that makes no sense -- since it's building & packaging "whatever is in there", and the system is no longer in control of what's in there, the whole versioning is bogus / shouldn't apply. the versioning/hashing exists for consistency (and later when .debs published to repo, for re-versioning), in this scenario it is simply not necessary.

maybe it is easier to add a separate CLI command that uses parts of kernel-*.sh but is not an artifact, instead just produces adhoc .deb's. look into maybe the cli-patch -- not saying that's a good example, lotsa duplicated code, but could be a start, since it's essentially a variation of this ("just patch, don't build")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Documentation New feature needs documentation entry size/small PR with less then 50 lines
Development

Successfully merging this pull request may close these issues.

3 participants