Re: [dpdk-dev] [RFC PATCH v4] build: kni cross-compilation support

08/02/2021 12:45, Bruce Richardson:

On Mon, Feb 08, 2021 at 12:21:17PM +0100, Thomas Monjalon wrote:

quoted

08/02/2021 12:05, Bruce Richardson:

quoted

On Mon, Feb 08, 2021 at 11:56:21AM +0100, Thomas Monjalon wrote:

quoted

08/02/2021 11:26, Bruce Richardson:

quoted

On Mon, Feb 08, 2021 at 10:17:56AM +0000, Juraj Linkeš wrote:

quoted

From: Bruce Richardson <redacted>

quoted

On Fri, Feb 05, 2021 at 04:04:32PM +0100, Juraj Linkeš wrote:

quoted

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

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.