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
