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

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

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"?