[PATCH RFC 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[PATCH RFC 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[California Sullivan]

The kernel being built should match what the recipe claims it is
building. This function ensures that happens for anyone using
LINUX_VERSION as they should. As it will likely break outside kernels
not using LINUX_VERSION, only enable the function for linux-yocto for
now.

Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
---
I'm not absolutely sure this is the correct path to solve the issue.
This patch relies on LINUX_VERSION being set which isn't a guarantee.
There is probably a more general solution that I'm not thinking of.

 meta/classes/kernel.bbclass               | 21 +++++++++++++++++++++
 meta/recipes-kernel/linux/linux-yocto.inc |  1 +
 2 files changed, 22 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index db42744..ac2611f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -330,6 +330,27 @@ kernel_do_install() {
 }
 do_install[prefuncs] += "package_get_auto_pr"
 
+# Must be ran some time after do_kernel_checkout or else Makefile won't be in ${S}/Makefile
+do_kernel_version_sanity_check() {
+	# The Makefile determines the kernel version shown at runtime
+	# Don't use KERNEL_VERSION because the headers it grabs the version from aren't generated until do_compile
+	VERSION=$(grep "^VERSION =" ${S}/Makefile | sed s/.*=\ //)
+	PATCHLEVEL=$(grep "^PATCHLEVEL =" ${S}/Makefile | sed s/.*=\ //)
+	SUBLEVEL=$(grep "^SUBLEVEL =" ${S}/Makefile | sed s/.*=\ //)
+
+	# If SUBLEVEL is zero or doesn't exist we ignore it as VERSION.PATCHLEVEL is normal
+	if [ -n "${SUBLEVEL}" ] && [ "${SUBLEVEL}" != "0" ]; then
+		if [ "${VERSION}.${PATCHLEVEL}.${SUBLEVEL}" != "${LINUX_VERSION}" ]; then
+			bbfatal "LINUX_VERSION (${LINUX_VERSION}) does not match kernel being built (${VERSION}.${PATCHLEVEL}.${SUBLEVEL}).\nTo fix this correct the LINUX_VERSION variable in your kernel recipe."
+		fi
+	else
+		if [ "${VERSION}.${PATCHLEVEL}" != "${LINUX_VERSION}" ]; then
+			bbfatal "LINUX_VERSION (${LINUX_VERSION}) does not match kernel being built (${VERSION}.${PATCHLEVEL}).\nTo fix this correct the LINUX_VERSION variable in your kernel recipe."
+		fi
+	fi
+	exit 0
+}
+
 addtask shared_workdir after do_compile before do_compile_kernelmodules
 addtask shared_workdir_setscene
 
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 98a48ec..d979662 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -55,6 +55,7 @@ do_install_append(){
 }
 
 # extra tasks
+addtask kernel_version_sanity_check after do_kernel_checkout before do_compile
 addtask kernel_link_images after do_compile before do_install
 addtask validate_branches before do_patch after do_kernel_checkout
 addtask kernel_configcheck after do_configure before do_compile
-- 
2.5.5

Re: [PATCH RFC 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Bruce, can you have a look at this?

Ross

On 17 August 2016 at 06:25, California Sullivan <
california.l.sullivan@intel.com> wrote:

> The kernel being built should match what the recipe claims it is
> building. This function ensures that happens for anyone using
> LINUX_VERSION as they should. As it will likely break outside kernels
> not using LINUX_VERSION, only enable the function for linux-yocto for
> now.
>
> Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
> ---
> I'm not absolutely sure this is the correct path to solve the issue.
> This patch relies on LINUX_VERSION being set which isn't a guarantee.
> There is probably a more general solution that I'm not thinking of.
>

[-- Attachment #2: Type: text/html, Size: 1272 bytes --]

Re: [PATCH RFC 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[Bruce Ashfield]

On 2016-08-24 5:56 PM, Burton, Ross wrote:
> Bruce, can you have a look at this?

Wow. 8 days ago, and I admit that I didn't notice it go past.

Yes, I'll have a look at this during the day on Thursday.

Bruce

>
> Ross
>
> On 17 August 2016 at 06:25, California Sullivan
> <california.l.sullivan@intel.com
> <mailto:california.l.sullivan@intel.com>> wrote:
>
>     The kernel being built should match what the recipe claims it is
>     building. This function ensures that happens for anyone using
>     LINUX_VERSION as they should. As it will likely break outside kernels
>     not using LINUX_VERSION, only enable the function for linux-yocto for
>     now.
>
>     Signed-off-by: California Sullivan <california.l.sullivan@intel.com
>     <mailto:california.l.sullivan@intel.com>>
>     ---
>     I'm not absolutely sure this is the correct path to solve the issue.
>     This patch relies on LINUX_VERSION being set which isn't a guarantee.
>     There is probably a more general solution that I'm not thinking of.
>
>
>

Re: [PATCH RFC 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4477 bytes --]

On Wed, Aug 17, 2016 at 1:25 AM, California Sullivan <
california.l.sullivan@intel.com> wrote:

> The kernel being built should match what the recipe claims it is
> building. This function ensures that happens for anyone using
> LINUX_VERSION as they should. As it will likely break outside kernels
> not using LINUX_VERSION, only enable the function for linux-yocto for
> now.
>
> Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
> ---
> I'm not absolutely sure this is the correct path to solve the issue.
> This patch relies on LINUX_VERSION being set which isn't a guarantee.
> There is probably a more general solution that I'm not thinking of.
>

I can't say that I know of all the options either, but I can ask questions
and perhaps
others will have more ideas.


>
>  meta/classes/kernel.bbclass               | 21 +++++++++++++++++++++
>  meta/recipes-kernel/linux/linux-yocto.inc |  1 +
>  2 files changed, 22 insertions(+)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index db42744..ac2611f 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -330,6 +330,27 @@ kernel_do_install() {
>  }
>  do_install[prefuncs] += "package_get_auto_pr"
>
> +# Must be ran some time after do_kernel_checkout or else Makefile won't
> be in ${S}/Makefile
> +do_kernel_version_sanity_check() {
> +       # The Makefile determines the kernel version shown at runtime
> +       # Don't use KERNEL_VERSION because the headers it grabs the
> version from aren't generated until do_compile
>
+       VERSION=$(grep "^VERSION =" ${S}/Makefile | sed s/.*=\ //)
> +       PATCHLEVEL=$(grep "^PATCHLEVEL =" ${S}/Makefile | sed s/.*=\ //)
> +       SUBLEVEL=$(grep "^SUBLEVEL =" ${S}/Makefile | sed s/.*=\ //)
>

I was also trying to think of a way to avoid duplicating code that is
yanking out version
numbers, but yes if we depend on utsrelease, we also have to do some level
of
building .. but that can actually be pretty lightweight.

Have you tried just invoking the prepare1 target in the kernel build ? That
should
generate the utsrelease, and not much more.


> +
> +       # If SUBLEVEL is zero or doesn't exist we ignore it as
> VERSION.PATCHLEVEL is normal
> +       if [ -n "${SUBLEVEL}" ] && [ "${SUBLEVEL}" != "0" ]; then
> +               if [ "${VERSION}.${PATCHLEVEL}.${SUBLEVEL}" !=
> "${LINUX_VERSION}" ]; then
> +                       bbfatal "LINUX_VERSION (${LINUX_VERSION}) does not
> match kernel being built (${VERSION}.${PATCHLEVEL}.${SUBLEVEL}).\nTo fix
> this correct the LINUX_VERSION variable in your kernel recipe."
>

I know that I use LINUX_VERSION in the linux-yocto recipes, but it isn't
something
enforced or widespread (as far as I know). Since this is kernel.bbclass
versus kernel-yocto.bbclass
should this be checking against PV versus LINUX_VERSION ? Alternatively,
this could just
move to kernel-yocto.bbclass as we try and make it more general.

Bruce



> +               fi
> +       else
> +               if [ "${VERSION}.${PATCHLEVEL}" != "${LINUX_VERSION}" ];
> then
> +                       bbfatal "LINUX_VERSION (${LINUX_VERSION}) does not
> match kernel being built (${VERSION}.${PATCHLEVEL}).\nTo fix this correct
> the LINUX_VERSION variable in your kernel recipe."
> +               fi
> +       fi
> +       exit 0
> +}
> +
>  addtask shared_workdir after do_compile before do_compile_kernelmodules
>  addtask shared_workdir_setscene
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 98a48ec..d979662 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -55,6 +55,7 @@ do_install_append(){
>  }
>
>  # extra tasks
> +addtask kernel_version_sanity_check after do_kernel_checkout before
> do_compile
>  addtask kernel_link_images after do_compile before do_install
>  addtask validate_branches before do_patch after do_kernel_checkout
>  addtask kernel_configcheck after do_configure before do_compile
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 6321 bytes --]

Re: [PATCH RFC 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[Cal Sullivan]

[-- Attachment #1: Type: text/plain, Size: 5993 bytes --]



On 08/25/2016 07:54 AM, Bruce Ashfield wrote:
>
>
> On Wed, Aug 17, 2016 at 1:25 AM, California Sullivan 
> <california.l.sullivan@intel.com 
> <mailto:california.l.sullivan@intel.com>> wrote:
>
>     The kernel being built should match what the recipe claims it is
>     building. This function ensures that happens for anyone using
>     LINUX_VERSION as they should. As it will likely break outside kernels
>     not using LINUX_VERSION, only enable the function for linux-yocto for
>     now.
>
>     Signed-off-by: California Sullivan
>     <california.l.sullivan@intel.com
>     <mailto:california.l.sullivan@intel.com>>
>     ---
>     I'm not absolutely sure this is the correct path to solve the issue.
>     This patch relies on LINUX_VERSION being set which isn't a guarantee.
>     There is probably a more general solution that I'm not thinking of.
>
>
> I can't say that I know of all the options either, but I can ask 
> questions and perhaps
> others will have more ideas.
>
>
>      meta/classes/kernel.bbclass               | 21 +++++++++++++++++++++
>      meta/recipes-kernel/linux/linux-yocto.inc |  1 +
>      2 files changed, 22 insertions(+)
>
>     diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>     index db42744..ac2611f 100644
>     --- a/meta/classes/kernel.bbclass
>     +++ b/meta/classes/kernel.bbclass
>     @@ -330,6 +330,27 @@ kernel_do_install() {
>      }
>      do_install[prefuncs] += "package_get_auto_pr"
>
>     +# Must be ran some time after do_kernel_checkout or else Makefile
>     won't be in ${S}/Makefile
>     +do_kernel_version_sanity_check() {
>     +       # The Makefile determines the kernel version shown at runtime
>     +       # Don't use KERNEL_VERSION because the headers it grabs
>     the version from aren't generated until do_compile
>
>     +       VERSION=$(grep "^VERSION =" ${S}/Makefile | sed s/.*=\ //)
>     +       PATCHLEVEL=$(grep "^PATCHLEVEL =" ${S}/Makefile | sed
>     s/.*=\ //)
>     +       SUBLEVEL=$(grep "^SUBLEVEL =" ${S}/Makefile | sed s/.*=\ //)
>
>
> I was also trying to think of a way to avoid duplicating code that is 
> yanking out version
> numbers, but yes if we depend on utsrelease, we also have to do some 
> level of
> building .. but that can actually be pretty lightweight.
>
> Have you tried just invoking the prepare1 target in the kernel build ? 
> That should
> generate the utsrelease, and not much more.
I preferably didn't want to build anything. This is really just a check 
to make sure the recipe information keeps up with the kernel, so ideally 
we don't want to add much or any time to the builds. I'm also not 
familiar with the prepare1 process or the magic that goes into building 
the yocto kernel, so I'm not sure what all invoking prepare1 process 
would entail.

A simple solution would be to yank the version from the KERNEL_VERSION 
variable after compilation, but that would also mean you don't get the 
error until after you successfully build, which would be rather annoying.

>     +
>     +       # If SUBLEVEL is zero or doesn't exist we ignore it as
>     VERSION.PATCHLEVEL is normal
>     +       if [ -n "${SUBLEVEL}" ] && [ "${SUBLEVEL}" != "0" ]; then
>     +               if [ "${VERSION}.${PATCHLEVEL}.${SUBLEVEL}" !=
>     "${LINUX_VERSION}" ]; then
>     +                       bbfatal "LINUX_VERSION (${LINUX_VERSION})
>     does not match kernel being built
>     (${VERSION}.${PATCHLEVEL}.${SUBLEVEL}).\nTo fix this correct the
>     LINUX_VERSION variable in your kernel recipe."
>
>
> I know that I use LINUX_VERSION in the linux-yocto recipes, but it 
> isn't something
> enforced or widespread (as far as I know). Since this is 
> kernel.bbclass versus kernel-yocto.bbclass
> should this be checking against PV versus LINUX_VERSION ? 
> Alternatively, this could just
> move to kernel-yocto.bbclass as we try and make it more general.
>
> Bruce
>

PV is probably the better choice. I had some reasons I didn't want to 
use it before but I can't think of them now, and I can see some fairly 
simple ways to implement a sane matching. PV would also make it more 
widely applicable.

Thanks,
Cal

>     +               fi
>     +       else
>     +               if [ "${VERSION}.${PATCHLEVEL}" !=
>     "${LINUX_VERSION}" ]; then
>     +                       bbfatal "LINUX_VERSION (${LINUX_VERSION})
>     does not match kernel being built (${VERSION}.${PATCHLEVEL}).\nTo
>     fix this correct the LINUX_VERSION variable in your kernel recipe."
>     +               fi
>     +       fi
>     +       exit 0
>     +}
>     +
>      addtask shared_workdir after do_compile before
>     do_compile_kernelmodules
>      addtask shared_workdir_setscene
>
>     diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
>     b/meta/recipes-kernel/linux/linux-yocto.inc
>     index 98a48ec..d979662 100644
>     --- a/meta/recipes-kernel/linux/linux-yocto.inc
>     +++ b/meta/recipes-kernel/linux/linux-yocto.inc
>     @@ -55,6 +55,7 @@ do_install_append(){
>      }
>
>      # extra tasks
>     +addtask kernel_version_sanity_check after do_kernel_checkout
>     before do_compile
>      addtask kernel_link_images after do_compile before do_install
>      addtask validate_branches before do_patch after do_kernel_checkout
>      addtask kernel_configcheck after do_configure before do_compile
>     --
>     2.5.5
>
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>     <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>
>
>
>
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await 
> thee at its end"


[-- Attachment #2: Type: text/html, Size: 10923 bytes --]