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.richard...@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.lin...@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.
/Bruce
