From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id BCC77A0547;
	Mon,  8 Feb 2021 12:45:37 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 599954014E;
	Mon,  8 Feb 2021 12:45:37 +0100 (CET)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151])
 by mails.dpdk.org (Postfix) with ESMTP id 1B2F840147
 for <dev@dpdk.org>; Mon,  8 Feb 2021 12:45:34 +0100 (CET)
IronPort-SDR: ZpSK3NYaG+7s/v9PSKztTx52eVDabZmIDnbp9iasaRvm6vxfhzeibOqfGdi7k7GahzSwH1bXHd
 HSun4K4JwvFw==
X-IronPort-AV: E=McAfee;i="6000,8403,9888"; a="161449023"
X-IronPort-AV: E=Sophos;i="5.81,161,1610438400"; d="scan'208";a="161449023"
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
 by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 08 Feb 2021 03:45:32 -0800
IronPort-SDR: ycnnJYehnjBonMwnSdfmZtW+3VQCqt+xXBAVNLU7hXMdaFt4vAzrlTBtQZj/O4i7U+oNEl89yL
 r4EewrSqYh9g==
X-IronPort-AV: E=Sophos;i="5.81,161,1610438400"; d="scan'208";a="377635737"
Received: from bricha3-mobl.ger.corp.intel.com ([10.252.0.47])
 by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA;
 08 Feb 2021 03:45:30 -0800
Date: Mon, 8 Feb 2021 11:45:25 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Juraj =?utf-8?Q?Linke=C5=A1?= <juraj.linkes@pantheon.tech>,
 "Ruifeng.Wang@arm.com" <Ruifeng.Wang@arm.com>,
 "Honnappa.Nagarahalli@arm.com" <Honnappa.Nagarahalli@arm.com>,
 "jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
 "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
 "aboyer@pensando.io" <aboyer@pensando.io>, "dev@dpdk.org" <dev@dpdk.org>,
 "david.marchand@redhat.com" <david.marchand@redhat.com>,
 "bluca@debian.org" <bluca@debian.org>
Message-ID: <20210208114525.GC2020@bricha3-MOBL.ger.corp.intel.com>
References: <1612536397-18008-1-git-send-email-juraj.linkes@pantheon.tech>
 <7945884.dXLI3N8YQt@thomas>
 <20210208110531.GB2020@bricha3-MOBL.ger.corp.intel.com>
 <1912027.TsnqTu0DiD@thomas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1912027.TsnqTu0DiD@thomas>
Subject: Re: [dpdk-dev] [RFC PATCH v4] build: kni cross-compilation support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, Feb 08, 2021 at 12:21:17PM +0100, Thomas Monjalon wrote:
> 08/02/2021 12:05, Bruce Richardson:
> > On Mon, Feb 08, 2021 at 11:56:21AM +0100, Thomas Monjalon wrote:
> > > 08/02/2021 11:26, Bruce Richardson:
> > > > On Mon, Feb 08, 2021 at 10:17:56AM +0000, Juraj Linkeš wrote:
> > > > > From: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > On Fri, Feb 05, 2021 at 04:04:32PM +0100, Juraj Linkeš wrote:
> > > > > > > The kni linux module is using a custom target for building, which
> > > > > > > doesn't take into account any cross compilation arguments. The
> > > > > > > arguments in question are ARCH, CROSS_COMPILE (for gcc, clang) and CC,
> > > > > > > LD (for clang). Get those from the cross file and pass them to the
> > > > > > > custom target.
> > > > > > >
> > > > > > > The user supplied path may not contain the 'build' directory, such as
> > > > > > > when using cross-compiled headers, so only append that in the default
> > > > > > > case (when no path is supplied in native builds) and use the
> > > > > > > unmodified path from the user otherwise. Also modify the install path
> > > > > > > accordingly.
> > > > > > >
> > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > ---
> > > > > > 
> > > > > > Thanks, this all looks ok to me now, bar one very minor nit below. Doing a native
> > > > > > build on my system with the running kernel also works fine.
> > > > > > 
> > > > > > However, the bigger question is one of compatibility for this change. The current
> > > > > > documentation for the kernel_dir option is:
> > > > > >   option('kernel_dir', type: 'string', value: '',
> > > > > > 	description: 'Path to the kernel for building kernel modules. \
> > > > > > 	Headers must be in $kernel_dir/build. Modules will be installed \
> > > > > > 	in $DEST_DIR/$kernel_dir/extra/dpdk.')
> > > > > > 
> > > > > > Obviously the description now needs an update to reflect the new use
> > > > > 
> > > > > I'll change the description. The current patch version is always installing the modules into '/lib/modules/' + kernel_version + '/extra/dpdk', though. I don't think we want to change the behavior this way, so I'll make the changes to preserve to original behavior ('/lib/modules/' + kernel_version + '/extra/dpdk' when kernel_dir is not supplied, kernel_dir + '/extra/dpdk' when it is).
> > > > > 
> > > > 
> > > > In the absense of an explicit kernel_install_dir, I actually think the new
> > > > way is better. However, I'd be interested in other opinions on this.
> > > 
> > > I'm not following. What do you call the "new way"?
> > 
> > Setting the install path to /lib/modules/<version> for native builds ignoring
> > kernel_dir value.
> 
> What is the advantage of ignoring an user parameter?
> 
Because the kernel_dir parameter is primarily specifying the build
directory for kmods, not the install dir. If kernel_dir is given as
"/home/user/kernel/src/linux", for example, the it's generally not wanted
to install the modules to a subdirectory of that path. If, on the other
hand, the kernel_dir value is given as "/lib/modules/<version>" then we can
use that as the basis for an install, but we also hit the challenge as to
whether the kernel_dir value should be with or without the "/build" suffix
for the /lib/modules directory.

/Bruce