From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?UTF-8?Q?Simon_K=c3=a5gstr=c3=b6m?= <simon.kagstrom@netinsight.net>
Subject: Re: [PATCH v2] kni: Use utsrelease.h to determine Ubuntu
 kernel version
Date: Wed, 4 Nov 2015 12:29:01 +0100
Message-ID: <5639EBFD.3030206@netinsight.net>
References: <20150820085106.32188573@miho> <4456769.s2fEOyVAiF@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from ernst.netinsight.se (ernst.netinsight.se [194.16.221.21])
 by dpdk.org (Postfix) with SMTP id 713628E7B
 for <dev@dpdk.org>; Wed,  4 Nov 2015 12:29:08 +0100 (CET)
In-Reply-To: <4456769.s2fEOyVAiF@xps13>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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