Provide an option to rebuild the kernel without downloading it again

[olivier-singla]

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]

Can anybody take a look at this PR?

[yxieca]

@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?

[olivier-singla]

@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.

[yxieca]

@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.

[olivier-singla]

retest this please

[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.

[lguohan]

in this incremetal build, it looks like we are not re-applying the patch series. what if the developer add a new kernel patch? Can you do stg pop and then re-apply all the patches?

[rajendra-dendukuri]

The theory is that, the user will first try the patch by directly applying the changes to the staged repo "sonic-linux-kernel/linux-4.9.189". Re-build, test the image. In fact, to create the patch itself, the staged repo "sonic-linux-kernel/linux-4.9.189" shall be used and when all change set is ready the patches are moved to the patch directory and series file updated. The staged repo is transient in nature till the point patches are tried manually, tested and finalized.

[jarias-lfx]

/easycla

[linux-foundation-easycla]

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