Re: [dpdk-dev] [RFC PATCH v1] build: kni gcc cross-compilation support
From: Bruce Richardson <hidden>
Date: 2021-01-29 14:43:00
On Fri, Jan 29, 2021 at 02:36:58PM +0000, Juraj Linkeš wrote:
quoted
-----Original Message----- From: Bruce Richardson <redacted> Sent: Friday, January 29, 2021 2:51 PM To: Juraj Linkeš <redacted> Cc: thomas@monjalon.net; Ruifeng.Wang@arm.com; jerinjacobk@gmail.com; hemant.agrawal@nxp.com; ferruh.yigit@intel.com; aboyer@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:quoted
quoted
-----Original Message----- From: Bruce Richardson <redacted> Sent: Friday, January 29, 2021 12:44 PM To: Juraj Linkeš <redacted> Cc: thomas@monjalon.net; Ruifeng.Wang@arm.com; jerinjacobk@gmail.com; hemant.agrawal@nxp.com; ferruh.yigit@intel.com; aboyer@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: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 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š <redacted> --- 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.buildb/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 -ifget_option('kernel_dir') == '' and meson.is_cross_build() - error('Need "kernel_dir" option for kmod compilation when cross-compiling')quoted
+if meson.is_cross_build() + if get_option('kernel_dir') == '' + error('Need "kernel_dir" option for kmod compilation whencross-compiling')quoted
+ 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 anarrayquoted
+ # nor does it support slicing, so do it on our own + foreach element : cross_compiler.split('-') + if element != 'gcc' + cross_prefix += '@0@-'.format(element)quoted
+ endif + endforeach + else + error('Unsupported cross compiler:@0@'.format(cross_compiler))quoted
+ endifRather 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.quoted
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 anexternal tool.quoted
On top of that, this would save lines and wouldn't need as many codecomments. I'll change it.quoted
quoted
quoted
+ 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' endifThe 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".quoted
quoted
Ah, I see. The modules will be installed during meson install. This should alsobe 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?quoted
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?quoted
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?
A note: all this works just for gcc. Should I also add support for clang?
If possible, that would be great. /Bruce