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 80457A0547; Mon, 8 Feb 2021 18:23:52 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F2012160722; Mon, 8 Feb 2021 18:23:51 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id B39C716071A for ; Mon, 8 Feb 2021 18:23:50 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id BE9CE5800C6; Mon, 8 Feb 2021 12:23:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 08 Feb 2021 12:23:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= EYyWq+ickRReOIqzSbFQ9pV0rkER/Oy2RRVKTPYKDsU=; b=gY1BXCCc1L3PtRCw lmtpyyZyvD7K/wGYp6UHbAsq8llMv684MxZZGN4Q8m/3ZAK6Qm+Op6NhpDsk7os0 WuBwPYLuwCtBUdMLpqO0SNGnwS2++LggyKc8/VkAyI/NZcvDiGCkvrFwnO/QIz1Q N8y4cgO9uVFsrYvt54U602h5Q11/UJBSPoOfzV1/ita9pjvWDbleUGgkb5/bKCz3 0lhP78o18iO2zNv+FAJRg8zy78jjHhvHot/1m116V2lDILqVfaV/msrMJz1UwKuX Qg0qGu5nehZcq53oa77dnBI74kT7K6hwBZWsKP4voeVkHDakjKBbWqn58gqSCVoM 8/EZJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=EYyWq+ickRReOIqzSbFQ9pV0rkER/Oy2RRVKTPYKD sU=; b=nWA3CvuyMHlBkJr/QjFHgAk34iAHYgXsGvYQBeTHZCeJrCMbyN9EhTrFX sz/C/okA9J1D+ESSsgn2WlsOOcrtyucU7uUw+cIRi26RNdAblPtZlDIEfWv7qauz jIHVTsMHxAahp86dae5mCx2BcaOlJwoqxitKt3pReLvyZPwJrvYG+zJfYK6pGX94 yJKq86KUKLJAqB32OhtWA/y5B9htVcyxg6M/DFHWpSAhin3qTb+g05WssFml4614 TKweDbyDyR9QjpSha+/GuOJ/sIQUrtpUGxXweOX70B5HLcLI0nhTiFoBZch4g1Ft 3mRFFlk2jMKE3EY9Y0XVO4sXLE+tg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrheefgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 90FEB108005B; Mon, 8 Feb 2021 12:23:47 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson Cc: Juraj =?utf-8?B?TGlua2XFoQ==?= , "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" Date: Mon, 08 Feb 2021 18:23:45 +0100 Message-ID: <3396526.GAzMcWYPvv@thomas> In-Reply-To: <20210208114525.GC2020@bricha3-MOBL.ger.corp.intel.com> References: <1612536397-18008-1-git-send-email-juraj.linkes@pantheon.tech> <1912027.TsnqTu0DiD@thomas> <20210208114525.GC2020@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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" 08/02/2021 12:45, Bruce Richardson: > 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=C5=A1 wrote: > > > > > > From: Bruce Richardson > > > > > > > On Fri, Feb 05, 2021 at 04:04:32PM +0100, Juraj Linke=C5=A1 w= rote: > > > > > > > > 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, cla= ng) 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' director= y, such as > > > > > > > > when using cross-compiled headers, so only append that in t= he default > > > > > > > > case (when no path is supplied in native builds) and use the > > > > > > > > unmodified path from the user otherwise. Also modify the in= stall path > > > > > > > > accordingly. > > > > > > > > > > > > > > > > Signed-off-by: Juraj Linke=C5=A1 > > > > > > > > --- > > > > > > >=20 > > > > > > > Thanks, this all looks ok to me now, bar one very minor nit b= elow. Doing a native > > > > > > > build on my system with the running kernel also works fine. > > > > > > >=20 > > > > > > > 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= =2E \ > > > > > > > Headers must be in $kernel_dir/build. Modules will be instal= led \ > > > > > > > in $DEST_DIR/$kernel_dir/extra/dpdk.') > > > > > > >=20 > > > > > > > Obviously the description now needs an update to reflect the = new use > > > > > >=20 > > > > > > I'll change the description. The current patch version is alway= s installing the modules into '/lib/modules/' + kernel_version + '/extra/dp= dk', 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/' + kerne= l_version + '/extra/dpdk' when kernel_dir is not supplied, kernel_dir + '/e= xtra/dpdk' when it is). > > > > > >=20 > > > > >=20 > > > > > In the absense of an explicit kernel_install_dir, I actually thin= k the new > > > > > way is better. However, I'd be interested in other opinions on th= is. > > > >=20 > > > > I'm not following. What do you call the "new way"? > > >=20 > > > Setting the install path to /lib/modules/ for native builds = ignoring > > > kernel_dir value. > >=20 > > What is the advantage of ignoring an user parameter? > >=20 > 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 c= an > 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. In the case of native build, isn't the src directory standardized? In my case, it is /lib/modules/version/kernel/ so I would assume that giving a kernel_dir means both src and install directories are requested to be somewhere else. If there is no standard kernel source path, then I understand kernel_dir may be used without assuming the install directory would take kernel_dir into account.