> -----Original Message-----
> From: Bruce Richardson <bruce.richard...@intel.com>
> Sent: Friday, January 29, 2021 3:42 PM
> To: Juraj Linkeš <juraj.lin...@pantheon.tech>
> Cc: tho...@monjalon.net; ruifeng.w...@arm.com; jerinjac...@gmail.com;
> hemant.agra...@nxp.com; ferruh.yi...@intel.com; abo...@pensando.io;
> dev@dpdk.org
> Subject: Re: [RFC PATCH v1] build: kni gcc cross-compilation support
>
> On Fri, Jan 29, 2021 at 02:36:58PM +0000, Juraj Linkeš wrote:
> >
> >
> > > -----Original Message-----
> > > From: Bruce Richardson <bruce.richard...@intel.com>
> > > Sent: Friday, January 29, 2021 2:51 PM
> > > To: Juraj Linkeš <juraj.lin...@pantheon.tech>
> > > Cc: tho...@monjalon.net; ruifeng.w...@arm.com;
> > > jerinjac...@gmail.com; hemant.agra...@nxp.com;
> > > ferruh.yi...@intel.com; abo...@pensando.io; dev@dpdk.org
> > > Subject: Re: [RFC PATCH v1] build: kni gcc cross-compilation support
> > >
> > > On Fri, Jan 29, 2021 at 12:33:06PM +0000, Juraj Linkeš wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Bruce Richardson <bruce.richard...@intel.com>
> > > > > Sent: Friday, January 29, 2021 12:44 PM
> > > > > To: Juraj Linkeš <juraj.lin...@pantheon.tech>
> > > > > Cc: tho...@monjalon.net; ruifeng.w...@arm.com;
> > > > > jerinjac...@gmail.com; hemant.agra...@nxp.com;
> > > > > ferruh.yi...@intel.com; abo...@pensando.io; dev@dpdk.org
> > > > > Subject: Re: [RFC PATCH v1] build: kni gcc cross-compilation
> > > > > support
> > > > >
> > > > > On Fri, Jan 29, 2021 at 11:29:19AM +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 and
> > > > > > CROSS_COMPILE. 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.
> > > > > >
> > > > > > Signed-off-by: Juraj Linkeš <juraj.lin...@pantheon.tech>
> > > > > > ---
> > > > > > kernel/linux/kni/meson.build | 4 ++--
> > > > > > kernel/linux/meson.build | 33 +++++++++++++++++++++++++++++---
> -
> > > > > > 2 files changed, 31 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/kernel/linux/kni/meson.build
> > > > > > b/kernel/linux/kni/meson.build index 07e0c9dae..0fbf52c93
> > > > > > 100644
> > > > > > --- a/kernel/linux/kni/meson.build
> > > > > > +++ b/kernel/linux/kni/meson.build
> > > > > > @@ -13,7 +13,7 @@ kni_sources = files( custom_target('rte_kni',
> > > > > > input: kni_sources,
> > > > > > output: 'rte_kni.ko',
> > > > > > - command: ['make', '-j4', '-C', kernel_dir + '/build',
> > > > > > + command: ['make', '-j4', '-C', kernel_dir,
> > > > > > 'M=' + meson.current_build_dir(),
> > > > > > 'src=' + meson.current_source_dir(),
> > > > > > 'MODULE_CFLAGS=-include ' + meson.source_root() +
> > > > > > '/config/rte_config.h' + @@ -21,7 +21,7 @@ custom_target('rte_kni',
> > > > > > ' -I' + meson.source_root() + '/lib/librte_kni' +
> > > > > > ' -I' + meson.build_root() +
> > > > > > ' -I' + meson.current_source_dir(),
> > > > > > - 'modules'],
> > > > > > + 'modules'] + cross_args,
> > > > > > depends: kni_mkfile,
> > > > > > install: true,
> > > > > > install_dir: kernel_dir + '/extra/dpdk', diff --git
> > > > > > a/kernel/linux/meson.build b/kernel/linux/meson.build index
> > > > > > 5c864a465..57ed9bc48 100644
> > > > > > --- a/kernel/linux/meson.build
> > > > > > +++ b/kernel/linux/meson.build
> > > > > > @@ -3,20 +3,45 @@
> > > > > >
> > > > > > subdirs = ['kni']
> > > > > >
> > > > > > +cross_args = []
> > > > > > # if we are cross-compiling we need kernel_dir specified -if
> > > > > > get_option('kernel_dir') == '' and meson.is_cross_build()
> > > > > > - error('Need "kernel_dir" option for kmod compilation when
> cross-
> > > > > compiling')
> > > > > > +if meson.is_cross_build()
> > > > > > + if get_option('kernel_dir') == ''
> > > > > > + error('Need "kernel_dir" option for kmod compilation
> when
> > > > > cross-compiling')
> > > > > > + else
> > > > > > + cross_compiler = find_program('c').path()
> > > > > > + if cross_compiler.endswith('gcc')
> > > > > > + cross_prefix = ''
> > > > > > + # remove the 'gcc' suffix
> > > > > > + # meson doesn't support removing elements
> from an
> > > > > array
> > > > > > + # nor does it support slicing, so do it on our
> > > > > > own
> > > > > > + foreach element : cross_compiler.split('-')
> > > > > > + if element != 'gcc'
> > > > > > + cross_prefix += '@0@-
> > > > > '.format(element)
> > > > > > + endif
> > > > > > + endforeach
> > > > > > + else
> > > > > > + error('Unsupported cross compiler:
> > > > > @0@'.format(cross_compiler))
> > > > > > + endif
> > > > >
> > > > > Rather than splitting manually, might it be better to just
> > > > > define a new property in the cross-file to hold the prefix?
> > > >
> > > > That would by one more unnecessary input, so I don't like that.
> > > >
> > > > > Alternatively, rather than meson looping, why not just use
> > > > > "run_command" to use shell or python to do the job, e.g.
> > > > > [untested]
> > > > >
> > > > > run_command([py3, '-c',
> > > > > 'print("-".join("' + cross_compiler + '".split("-")[:-1]))')
> > > > >
> > > > > run_command('bash', '-c',
> > > > > 'echo ' + cross_compiler + ' | sed "s/gcc$//"')
> > > > >
> > > >
> > > > Since there isn't a better way to do this in Meson, it makes sense
> > > > to use an
> > > external tool.
> > > > On top of that, this would save lines and wouldn't need as many
> > > > code
> > > comments. I'll change it.
> > > >
> > > > > > + if host_machine.cpu_family() == 'aarch64'
> > > > > > + cross_arch = 'arm64'
> > > > > > + else
> > > > > > + cross_arch = build_machine.cpu_family()
> > > > > > + endif
> > > > > > + cross_args = ['ARCH=@0@'.format(cross_arch),
> > > > > > + 'CROSS_COMPILE=@0@'.format(cross_prefix)]
> > > > > > + endif
> > > > > > endif
> > > > > >
> > > > > > kernel_dir = get_option('kernel_dir') if kernel_dir == ''
> > > > > > # use default path for native builds
> > > > > > kernel_version = run_command('uname', '-r').stdout().strip()
> > > > > > - kernel_dir = '/lib/modules/' + kernel_version
> > > > > > + kernel_dir = '/lib/modules/' + kernel_version + '/build'
> > > > > > endif
> > > > >
> > > > > The reason we don't keep the "build" off the kernel_dir is to
> > > > > ensure that the kernel modules install to the correct place.
> > > > > With this change the modules will go in
> > > > > "/lib/modules/<version>/build/extra/dpdk", rather than
> > > "/lib/modules/<version>/extra/dpdk".
> > > > >
> > > >
> > > > Ah, I see. The modules will be installed during meson install.
> > > > This should also
> > > be changed, then, as we always want to install them to
> '/lib/modules/<version>'
> > > (not necessarily to 'kernel_dir', as the user may change that) and
> > > only for native builds, right?
> > > >
> > > Well, we definitely want it for native builds, but I'd imagine it
> > > would be useful for cross-builds too, no?
> >
> > I guess it would be useful for setups with shared storage. Did you have
> something else in mind?
> >
> > > Can we find some way of getting it working for both cases.
> > > For native builds we want:
> > >
> > > * build kernel-dir = /lib/modules/<ver>/build
> > > * install dir = /lib/modules/<ver>/extra/dpdk
> > >
> > > What are the expected equivalent paths for cross building?
> > >
> >
> > The ubuntu1804 packages are installing aarch64 cross files to /usr/aarch64-
> linux-gnu, so we could install it to /usr/aarch64-linux-
> gnu/lib/modules/<ver>/extra/dpdk, or
> /usr/<cross_triple>/lib/modules/<ver>/extra/dpdk in general. I think we can
> get
> <ver> from 'make kernelversion', so that would work, although I'm not sure
> this
> is the right place.
> >
> So what do you specify as the "kernel_dir" for the cross compile?
>
The place where I cloned (and cross-compiled) linux sources: $HOME/linux.
> > A note: all this works just for gcc. Should I also add support for clang?
> >
> If possible, that would be great.
>
Ok, I'll look into it.
> /Bruce
