sonic-linux-kernel icon indicating copy to clipboard operation
sonic-linux-kernel copied to clipboard

Provide an option to rebuild the kernel without downloading it again

Open olivier-singla opened this issue 5 years ago • 8 comments

Normally, rebuilding the kernel involves removing the previously built kernel source tree, downloading the stock kernel, applying all the SONiC patches, and compiling the kernel and the kernel modules. In a development environment, you might want to skip downloading the kernel and applying all the patches, and just rebuild the kernel. This option is enabled by setting the value for DEFAULT_KERNEL_PROCURE_METHOD to "incremental" in the rules/config file.

Procedure to rebuild the kernel:

make target/debs/stretch/linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u5_all.deb-clean make target/debs/stretch/linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u5_all.deb

You can then upload and install the kernel archive in the switch: target/debs/stretch/linux-image-4.9.0-9-2-amd64_4.9.168-1+deb9u5_amd64.deb

olivier-singla avatar Oct 04 '19 01:10 olivier-singla

Can anybody take a look at this PR?

olivier-singla avatar Nov 25 '19 14:11 olivier-singla

@olivier-singla sorry for the delay.

What if the incremental change was to either (or combination of):

  1. Change a patch file.
  2. Delete a patch file.
  3. Add a patch file.

Will this change still build kernel as expected?

yxieca avatar Nov 25 '19 21:11 yxieca

@yxieca The patches are applied only once when the directory linux-4.9.168 is not detected. Next builds will just rebuild the kernel.

To make advantage of the incremental kernel procure method, I would advise to first apply the patches manually, and then build the kernel (with make target/debs/stretch/linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u5_all.deb). That would save a significant amount of time. Once your patches are finalized you can then delete the linux directory and start a full build for verification.

olivier-singla avatar Dec 15 '19 22:12 olivier-singla

@olivier-singla Sorry I think you took my question to an unintended direction. I was saying that the incremental build should have the capability of detecting rebuild is needed when new patch is applied. Otherwise incremental build will miss any newly added/changed/deleted patches.

yxieca avatar Jan 06 '20 16:01 yxieca

retest this please

olivier-singla avatar Apr 16 '20 14:04 olivier-singla

@olivier-singla Sorry I think you took my question to an unintended direction. I was saying that the incremental build should have the capability of detecting rebuild is needed when new patch is applied. Otherwise incremental build will miss any newly added/changed/deleted patches.

How that would be useful? If you add a new kernel patch, or fixing an existent kernel patch , that means that typically you are already rebuilding the kernel, right? This patch is really intended for people developing or fixing a kernel patch, so they are in control when to rebuild the kernel. And this patch provides the ability to rebuild the kernel without having to reload the kernel, unpacking and applying all the patches.

olivier-singla avatar Apr 16 '20 18:04 olivier-singla

/easycla

jarias-lfx avatar Jul 19 '23 19:07 jarias-lfx

CLA Not Signed

  • :x: - login: @olivier-singla / name: Olivier Singla . The commit (b08ce3cefa3f5688e97829e769366ef9e00913bc, a6777499e9ccf135ffc9ab2f59070d5f95f179db, 101c5895a89f2574a6e390c35a0fe7dd182e9996, d4d8781392ac4c62a4544f98d79400233350afd3) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.