From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 To: Thomas Monjalon Cc: Juraj =?utf-8?Q?Linke=C5=A1?= , "Ruifeng.Wang@arm.com" , "Honnappa.Nagarahalli@arm.com" , "jerinjacobk@gmail.com" , "hemant.agrawal@nxp.com" , "ferruh.yigit@intel.com" , "aboyer@pensando.io" , "dev@dpdk.org" , "david.marchand@redhat.com" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > > > > 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š > > > > > > > --- > > > > > > > > > > > > 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/ 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/" 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