From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v2] kni: Use utsrelease.h to determine Ubuntu kernel version Date: Wed, 4 Nov 2015 10:21:02 -0800 Message-ID: <20151104102102.2697bdd4@xeon-e3> References: <20150820085106.32188573@miho> <4456769.s2fEOyVAiF@xps13> <5639EBFD.3030206@netinsight.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: Simon =?UTF-8?B?S8OlZ3N0csO2bQ==?= Return-path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by dpdk.org (Postfix) with ESMTP id BE33F8E9E for ; Wed, 4 Nov 2015 19:20:51 +0100 (CET) Received: by pasz6 with SMTP id z6so61595546pas.2 for ; Wed, 04 Nov 2015 10:20:51 -0800 (PST) In-Reply-To: <5639EBFD.3030206@netinsight.net> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 4 Nov 2015 12:29:01 +0100 Simon K=C3=A5gstr=C3=B6m 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>/d= ev/null),Ubuntu) > >> +ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu) > >> MODULE_CFLAGS +=3D -DUBUNTU_RELEASE_CODE=3D$(shell lsb_release -sr | = tr -d .) > >> -UBUNTU_KERNEL_CODE :=3D $(shell cut -d' ' -f2 /proc/version_signature= | \ > >> - cut -d'~' -f1 | cut -d- -f1,2 | tr .- $(comma= )) > >> +UBUNTU_KERNEL_CODE :=3D $(shell echo `grep UTS_RELEASE $(RTE_KERNELDI= R)/include/generated/utsrelease.h \ > >> + | cut -d '"' -f2 | cut -d- -f1,2 | tr .- $(comma)`,1) > >> MODULE_CFLAGS +=3D -D"UBUNTU_KERNEL_CODE=3DUBUNTU_KERNEL_VERSION($(UB= UNTU_KERNEL_CODE))" > >> endif > >=20 > > 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. >=20 > 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. >=20 > 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. >=20 > // Simon >=20 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.