[dpdk-dev] [PATCH v2] kni: Use utsrelease.h to determine Ubuntu kernel version

[Stephen Hemminger]

On Wed, 4 Nov 2015 12:29:01 +0100
Simon Kågström <simon.kagstrom at netinsight.net> wrote:

> On 2015-11-04 11:35, Thomas Monjalon wrote:
> > 2015-08-20 08:51, Simon Kagstrom:
> >> -ifeq ($(shell test -f /proc/version_signature && lsb_release -si 2>/dev/null),Ubuntu)
> >> +ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu)
> >>  MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .)
> >> -UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature | \
> >> -                        cut -d'~' -f1 | cut -d- -f1,2 | tr .- $(comma))
> >> +UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE $(RTE_KERNELDIR)/include/generated/utsrelease.h \
> >> +	 | cut -d '"' -f2 | cut -d- -f1,2 | tr .- $(comma)`,1)
> >>  MODULE_CFLAGS += -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))"
> >>  endif
> > 
> > Yes we must check RTE_KERNELDIR instead of the running kernel.
> > But it is still checking lsb_release for the running system.
> > It seems not consistent.
> 
> I don't think so: the case the patch addresses is where the running
> kernel and rootfs doesn't match, like in a chroot environment.
> 
> So lsb_release will come from the chroot, as it should, but without the
> patch, the kernel version will not come from the installed kernel
> headers in the chroot, but the running kernel - which might even not be
> Ubuntu.
> 
> // Simon
> 

The danger here is starting to assume the build machine is the same as the
running image. Using /proc to determine runtime environment is wrong.