DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
	"Ruifeng.Wang@arm.com" <Ruifeng.Wang@arm.com>,
	"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"aboyer@pensando.io" <aboyer@pensando.io>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH v1] build: kni gcc cross-compilation support
Date: Fri, 29 Jan 2021 14:42:25 +0000	[thread overview]
Message-ID: <20210129144225.GH929@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <bb861ebbc32d41a283b4fb48d3fdb500@pantheon.tech>

On Fri, Jan 29, 2021 at 02:36:58PM +0000, Juraj Linkeš wrote:
> 
> 
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > Sent: Friday, January 29, 2021 2:51 PM
> > To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > 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:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bruce Richardson <bruce.richardson@intel.com>
> > > > Sent: Friday, January 29, 2021 12:44 PM
> > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > 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:
> > > > > 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.linkes@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?

> A note: all this works just for gcc. Should I also add support for clang?
> 
If possible, that would be great.

/Bruce

  reply	other threads:[~2021-01-29 14:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-29 10:29 Juraj Linkeš
2021-01-29 11:43 ` Bruce Richardson
2021-01-29 12:33   ` Juraj Linkeš
2021-01-29 13:51     ` Bruce Richardson
2021-01-29 14:36       ` Juraj Linkeš
2021-01-29 14:42         ` Bruce Richardson [this message]
2021-01-29 14:47           ` Juraj Linkeš
2021-01-29 15:01             ` Bruce Richardson
2021-01-29 15:17               ` Juraj Linkeš
2021-01-29 15:39                 ` Bruce Richardson
2021-02-01  7:48                   ` Juraj Linkeš
2021-02-04  9:51 ` [dpdk-dev] [RFC PATCH v2] build: kni " Juraj Linkeš
2021-02-04 17:33   ` Bruce Richardson
2021-02-05  9:26     ` Juraj Linkeš
2021-02-05  9:38       ` Bruce Richardson
2021-02-05  9:44         ` Thomas Monjalon
2021-02-05  9:42       ` Bruce Richardson
2021-02-05 14:46   ` [dpdk-dev] [RFC PATCH v3] " Juraj Linkeš
2021-02-05 14:52     ` Bruce Richardson
2021-02-05 15:02       ` Juraj Linkeš
2021-02-05 15:04     ` [dpdk-dev] [RFC PATCH v4] " Juraj Linkeš
2021-02-05 15:27       ` Bruce Richardson
2021-02-08 10:17         ` Juraj Linkeš
2021-02-08 10:26           ` Bruce Richardson
2021-02-08 10:56             ` Thomas Monjalon
2021-02-08 11:05               ` Bruce Richardson
2021-02-08 11:21                 ` Thomas Monjalon
2021-02-08 11:45                   ` Bruce Richardson
2021-02-08 17:23                     ` Thomas Monjalon
2021-02-09  8:47       ` [dpdk-dev] [PATCH v5] " Juraj Linkeš
2021-02-09 11:50         ` Bruce Richardson
2021-02-09 12:07           ` Juraj Linkeš
2021-02-09 12:39             ` Bruce Richardson
2021-02-11 12:59         ` [dpdk-dev] [PATCH v6] " Juraj Linkeš
2021-03-09  8:47           ` Juraj Linkeš
2021-03-09 16:26             ` Andrew Boyer
2021-03-15 22:45           ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210129144225.GH929@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=aboyer@pensando.io \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinjacobk@gmail.com \
    --cc=juraj.linkes@pantheon.tech \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).