I’ve noticed the Linaro’s Linux kernel build use KERENELRELEASE build parameter. What is the benefit using such parameter compared to just using the real kernel version. By that I mean both release 18.01 and 19.01 used the same version:
KERNELRELEASE=4.14.0-qcomlt-arm64
even though the kernels are different? That means it’s not possible to find out the kernel patch version by using ‘uname -a’. Or is there another way? Could anybody explain the reason behind that? Thanks.
KERNELRELEASE is used to represent the kernel “ABI”, it’s the same because the kernel ABI hasn’t changed. In other words you should be able to upgrade the kernel. We followed the same convention used in debian. For example:
https://packages.debian.org/sid/linux-image-5.9.0-3-amd64
We can push updates/fixes and build a new version of the same package.
You can potentially install several kernel packages for different kernel versions (different ABI).
If you want to know more details about the version, you can use dpkg -l to list all packages, and you will see something like this:
ii linux-image-4.14.0-qcomlt-arm64 4.14.96-00726-g8bdd343f96dc-45 arm64 Linux kernel, version 4.14.0-qcomlt-arm64
We put the commit hash in the version string, along with the exact kernel version (4.14.96) and our build number. That string tells you the kernel commit is 8bdd343f96dc. e.g.
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/?id=8bdd343f96dc
Thank you for your reply.
So far I understand such option may have benefits only when using the kernel along with Debian distro while also being able to control the content of the distro server (issuing upgrades). For custom kernel / OS builds I can omit this parameter without functionality consequences. By that I mean the Qualcomm blobs (for wifi , gps etc) should still function even though the kernel reports different version (and still has the same ABI). Is that correct?
yes, this is correct. it has no impact on any software.
