DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "Juraj Linkeš" <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>
Subject: Re: [dpdk-dev] [RFC PATCH v4] build: kni cross-compilation support
Date: Mon, 08 Feb 2021 18:23:45 +0100	[thread overview]
Message-ID: <3396526.GAzMcWYPvv@thomas> (raw)
In-Reply-To: <20210208114525.GC2020@bricha3-MOBL.ger.corp.intel.com>

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š 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.

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.



  reply	other threads:[~2021-02-08 17:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 10:29 [dpdk-dev] [RFC PATCH v1] build: kni gcc " Juraj Linkeš
2021-01-29 11:43 ` Bruce Richardson
2021-01-29 12:33   ` Juraj Linkeš
2021-01-29 13:51     ` Bruce Richardson
2021-01-29 14:36       ` Juraj Linkeš
2021-01-29 14:42         ` Bruce Richardson
2021-01-29 14:47           ` Juraj Linkeš
2021-01-29 15:01             ` Bruce Richardson
2021-01-29 15:17               ` Juraj Linkeš
2021-01-29 15:39                 ` Bruce Richardson
2021-02-01  7:48                   ` Juraj Linkeš
2021-02-04  9:51 ` [dpdk-dev] [RFC PATCH v2] build: kni " Juraj Linkeš
2021-02-04 17:33   ` Bruce Richardson
2021-02-05  9:26     ` Juraj Linkeš
2021-02-05  9:38       ` Bruce Richardson
2021-02-05  9:44         ` Thomas Monjalon
2021-02-05  9:42       ` Bruce Richardson
2021-02-05 14:46   ` [dpdk-dev] [RFC PATCH v3] " Juraj Linkeš
2021-02-05 14:52     ` Bruce Richardson
2021-02-05 15:02       ` Juraj Linkeš
2021-02-05 15:04     ` [dpdk-dev] [RFC PATCH v4] " Juraj Linkeš
2021-02-05 15:27       ` Bruce Richardson
2021-02-08 10:17         ` Juraj Linkeš
2021-02-08 10:26           ` Bruce Richardson
2021-02-08 10:56             ` Thomas Monjalon
2021-02-08 11:05               ` Bruce Richardson
2021-02-08 11:21                 ` Thomas Monjalon
2021-02-08 11:45                   ` Bruce Richardson
2021-02-08 17:23                     ` Thomas Monjalon [this message]
2021-02-09  8:47       ` [dpdk-dev] [PATCH v5] " Juraj Linkeš
2021-02-09 11:50         ` Bruce Richardson
2021-02-09 12:07           ` Juraj Linkeš
2021-02-09 12:39             ` Bruce Richardson
2021-02-11 12:59         ` [dpdk-dev] [PATCH v6] " Juraj Linkeš
2021-03-09  8:47           ` Juraj Linkeš
2021-03-09 16:26             ` Andrew Boyer
2021-03-15 22:45           ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3396526.GAzMcWYPvv@thomas \
    --to=thomas@monjalon.net \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=aboyer@pensando.io \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinjacobk@gmail.com \
    --cc=juraj.linkes@pantheon.tech \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).