From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0E42DA04F1; Mon, 9 Dec 2019 13:12:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 342BA2BAB; Mon, 9 Dec 2019 13:12:23 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1CF2A1F5; Mon, 9 Dec 2019 13:12:20 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2019 04:12:19 -0800 X-IronPort-AV: E=Sophos;i="5.69,294,1571727600"; d="scan'208";a="206875885" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2019 04:12:17 -0800 Date: Mon, 9 Dec 2019 12:12:14 +0000 From: Bruce Richardson To: Ye Xiaolong Cc: Luca Boccassi , Ferruh Yigit , dev@dpdk.org, stable@dpdk.org, iryzhov@nfware.com Message-ID: <20191209121214.GB98@bricha3-MOBL.ger.corp.intel.com> References: <20191202061442.56964-1-xiaolong.ye@intel.com> <20191203155922.1565-1-xiaolong.ye@intel.com> <86964b5e0299150975d6cf7b68e5a6347cc98ef6.camel@debian.org> <20191204141821.GA26248@intel.com> <20191204151231.GB61@bricha3-MOBL.ger.corp.intel.com> <20191208012657.GA47073@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191208012657.GA47073@intel.com> User-Agent: Mutt/1.12.1 (2019-06-15) Subject: Re: [dpdk-dev] [PATCH v3] kernel/linux: fix kernel dir for meson X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sun, Dec 08, 2019 at 09:26:57AM +0800, Ye Xiaolong wrote: > On 12/04, Bruce Richardson wrote: > >On Wed, Dec 04, 2019 at 10:18:21PM +0800, Ye Xiaolong wrote: > >> On 12/04, Luca Boccassi wrote: > >> >On Tue, 2019-12-03 at 23:59 +0800, Xiaolong Ye wrote: > >> >> kernel_dir option in meson build is equivalent to RTE_KERNELDIR in > >> >> make > >> >> system, for cross-compilation case, users would specify it as local > >> >> kernel src dir like > >> >> > >> >> //target-arm_glibc/linux-arm/linux-4.19.81/ > >> >> > >> >> Current meson build would fail to compile kernel module if user > >> >> specify > >> >> kernel_dir as above, this patch fixes this issue. > >> >> > >> >> After this change, for normal build case, user can specify > >> >> /lib/modules/ or /lib/modules//build > >> >> as > >> >> kernel_dir. For cross compilation case, user can specify any > >> >> directory > >> >> that contains kernel source code as the kernel_dir. > >> >> > >> >> Fixes: 317832f97c16 ("kernel/linux: fix modules install path") > >> >> Cc: > >> >> stable@dpdk.org > >> >> > >> >> Cc: > >> >> iryzhov@nfware.com > >> >> > >> >> > >> >> Signed-off-by: Xiaolong Ye < > >> >> xiaolong.ye@intel.com > >> > > >> >The convention used by upstream and all distros is that kernel headers > >> >are in /build. Why can't the cross compilation case also > >> >follow this convention, rather than adding complications to the > >> > >> Yes, cross-compilation can follow this convention, but one common case is that > >> users download and put kernel src (the same kernel that's running in the target machine) > >> to one arbitrary dir, he then use this dir as kernel_dir to build kernel modules, > >> it's extra burden for users to create extra build dir to hold the kernel headers. > >> > > > >As part of the build of the kernel, do you not do a "modules_install" step, > >which should set up things correctly for later builds? > > Yes, this cmd helps. But for make build, user could specify both > /lib/modules//build and any kernel src dir as RTE_KERNELDIR, I > think this patch can help give user consistent experience when they migrate from make > to meson build. > Issues like specifying the wrong directory when switching over are a) short term, once off issue in the conversion from make to meson and b) fixed by just looking at the documentation for the build option. On the other hand, maintaining code supporting both options is complexity that, if added to meson builds, needs to be maintained going forward. While we can expect users to have to make changes when switching build system, we should not require them later to make changes based on us arbitrarily changing the allowed values of options. Therefore, unless your build system absolutely cannot be set up to support the existing build configuration, I would rather we not accept changes here, and we try and keep the code simpler. Regards, /Bruce