On Mon, Feb 08, 2021 at 10:17:56AM +0000, Juraj Linkeš wrote:
> 
> 
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richard...@intel.com>
> > Sent: Friday, February 5, 2021 4:27 PM
> > To: Juraj Linkeš <juraj.lin...@pantheon.tech>
> > Cc: tho...@monjalon.net; ruifeng.w...@arm.com;
> > honnappa.nagaraha...@arm.com; jerinjac...@gmail.com;
> > hemant.agra...@nxp.com; ferruh.yi...@intel.com; abo...@pensando.io;
> > dev@dpdk.org; david.march...@redhat.com; bl...@debian.org
> > Subject: Re: [RFC PATCH v4] build: kni cross-compilation support
> > 
> > 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.


> > , but I'm
> > not sure if changing the behaviour counts as an "ABI" change or not, and
> > whether it needs to wait for a new LTS release. Any scripts that were 
> > compiling
> > using e.g. kernel_dir='/lib/modules/<version>' need to be changed to use
> > kernel_dir='/lib/modules/<version>/build' instead.
> > 
> 
> I'm not sure what to do with this. Should I make it backwards compatible by 
> checking the build dir as well (i.e. trying make kernelversion in both 
> $kernel_dir and $kernel_dir/build)?
> 
That's an interesting proposal. Might be worth doing to check both.

Reply via email to