[v15,09/12] build: disable drivers in Arm builds
Checks
Commit Message
A few options that disabled drivers in the old makefiles were improperly
ported to the meson build system. Fix this by adding a to the list of
disabled drivers, similarly how the command line option works and remove
unneeded driver options ported from the old makefile system, since they
don't work in the current Meson build system.
Add support for removing drivers for cross builds so that we can disable
them in cross files.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
config/arm/arm64_armada_linux_gcc | 1 +
config/arm/meson.build | 7 +++----
doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 4 ++++
drivers/meson.build | 6 +++++-
meson.build | 1 +
5 files changed, 14 insertions(+), 5 deletions(-)
Comments
15/01/2021 14:26, Juraj Linkeš:
> A few options that disabled drivers in the old makefiles were improperly
> ported to the meson build system. Fix this by adding a to the list of
"by adding a" what?
> disabled drivers, similarly how the command line option works and remove
> unneeded driver options ported from the old makefile system, since they
> don't work in the current Meson build system.
> Add support for removing drivers for cross builds so that we can disable
> them in cross files.
Why disabling them?
If a driver is not supported it should disable itseld in its meson file.
[...]
> --- a/config/arm/arm64_armada_linux_gcc
> +++ b/config/arm/arm64_armada_linux_gcc
> @@ -18,3 +18,4 @@ implementer_id = '0x56'
> part_number = '0xd08'
> max_lcores = 16
> max_numa_nodes = 1
> +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
It's removing NXP drivers on Marvell SoC. Fine.
And what about other useless drivers?
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> +# disable Arm drivers for all builds
> +disabled_drivers += ['net/avp', 'net/fm10k']
Why disabling avp and fm10k? Did they do something wrong to be banned?
+ Liron, Allain
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 18, 2021 2:37 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com;
> Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com;
> vcchunga@amazon.com; Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com;
> ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in Arm builds
>
> 15/01/2021 14:26, Juraj Linkeš:
> > A few options that disabled drivers in the old makefiles were
> > improperly ported to the meson build system. Fix this by adding a to
> > the list of
>
> "by adding a" what?
This is a typo, the "a" should not be there. Would that be ok wording?
>
> > disabled drivers, similarly how the command line option works and
> > remove unneeded driver options ported from the old makefile system,
> > since they don't work in the current Meson build system.
> > Add support for removing drivers for cross builds so that we can
> > disable them in cross files.
>
> Why disabling them?
> If a driver is not supported it should disable itseld in its meson file.
>
This is helpful when building for an SoC where we don't want to build to build a driver, but the build machine actually supports the driver. I believe in this case the meson build system would find the dependencies and designate the driver to be build, but we don't want to build the driver for that SoC.
There may be other reasons as well - Honnappa or others from the Arm community may shed more light on this.
> [...]
> > --- a/config/arm/arm64_armada_linux_gcc
> > +++ b/config/arm/arm64_armada_linux_gcc
> > @@ -18,3 +18,4 @@ implementer_id = '0x56'
> > part_number = '0xd08'
> > max_lcores = 16
> > max_numa_nodes = 1
> > +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
>
> It's removing NXP drivers on Marvell SoC. Fine.
> And what about other useless drivers?
>
I only removed what was in the old Makefiles, so I don't really know. Liron or Jerin may be able to give us some insight.
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > +# disable Arm drivers for all builds
> > +disabled_drivers += ['net/avp', 'net/fm10k']
>
> Why disabling avp and fm10k? Did they do something wrong to be banned?
>
>
>
This config is not only in the old Makefiles, but also in the current meson build system. I believe Jerin and Allain are the original authors, so they may be able to answer.
-----Original Message-----
From: Juraj Linkeš <juraj.linkes@pantheon.tech>
Sent: Tuesday, 19 January 2021 17:36
To: Thomas Monjalon <thomas@monjalon.net>
Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com; Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com; vcchunga@amazon.com; Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com; hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com; ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org; Liron Himi <lironh@marvell.com>; allain.legacy@windriver.com
Subject: [EXT] RE: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in Arm builds
External Email
----------------------------------------------------------------------
+ Liron, Allain
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, January 18, 2021 2:37 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Cc: bruce.richardson@intel.com; Ruifeng.Wang@arm.com;
> Honnappa.Nagarahalli@arm.com; Phil.Yang@arm.com; vcchunga@amazon.com;
> Dharmik.Thakkar@arm.com; jerinjacobk@gmail.com;
> hemant.agrawal@nxp.com; ajit.khaparde@broadcom.com;
> ferruh.yigit@intel.com; aboyer@pensando.io; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 09/12] build: disable drivers in
> Arm builds
>
> 15/01/2021 14:26, Juraj Linkeš:
> > A few options that disabled drivers in the old makefiles were
> > improperly ported to the meson build system. Fix this by adding a to
> > the list of
>
> "by adding a" what?
This is a typo, the "a" should not be there. Would that be ok wording?
>
> > disabled drivers, similarly how the command line option works and
> > remove unneeded driver options ported from the old makefile system,
> > since they don't work in the current Meson build system.
> > Add support for removing drivers for cross builds so that we can
> > disable them in cross files.
>
> Why disabling them?
> If a driver is not supported it should disable itseld in its meson file.
>
This is helpful when building for an SoC where we don't want to build to build a driver, but the build machine actually supports the driver. I believe in this case the meson build system would find the dependencies and designate the driver to be build, but we don't want to build the driver for that SoC.
There may be other reasons as well - Honnappa or others from the Arm community may shed more light on this.
> [...]
> > --- a/config/arm/arm64_armada_linux_gcc
> > +++ b/config/arm/arm64_armada_linux_gcc
> > @@ -18,3 +18,4 @@ implementer_id = '0x56'
> > part_number = '0xd08'
> > max_lcores = 16
> > max_numa_nodes = 1
> > +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
>
> It's removing NXP drivers on Marvell SoC. Fine.
> And what about other useless drivers?
>
I only removed what was in the old Makefiles, so I don't really know. Liron or Jerin may be able to give us some insight.
[L.H.] In the past we had conflict with DPAA drivers, but recently we fixed it.
So no need for that anymore.
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > +# disable Arm drivers for all builds disabled_drivers +=
> > +['net/avp', 'net/fm10k']
>
> Why disabling avp and fm10k? Did they do something wrong to be banned?
>
>
>
This config is not only in the old Makefiles, but also in the current meson build system. I believe Jerin and Allain are the original authors, so they may be able to answer.
<snip>
> > 15/01/2021 14:26, Juraj Linkeš:
> > > A few options that disabled drivers in the old makefiles were
> > > improperly ported to the meson build system. Fix this by adding a to
> > > the list of
> >
> > "by adding a" what?
>
> This is a typo, the "a" should not be there. Would that be ok wording?
>
> >
> > > disabled drivers, similarly how the command line option works and
> > > remove unneeded driver options ported from the old makefile system,
> > > since they don't work in the current Meson build system.
> > > Add support for removing drivers for cross builds so that we can
> > > disable them in cross files.
> >
> > Why disabling them?
> > If a driver is not supported it should disable itseld in its meson file.
> >
>
> This is helpful when building for an SoC where we don't want to build to build
> a driver, but the build machine actually supports the driver. I believe in this
> case the meson build system would find the dependencies and designate
> the driver to be build, but we don't want to build the driver for that SoC.
>
> There may be other reasons as well - Honnappa or others from the Arm
> community may shed more light on this.
IMO, the assumption should be everything compiles on all the platforms. Hence, the disables should be applied to the platforms where the drivers do not compile.
>
> > [...]
> > > --- a/config/arm/arm64_armada_linux_gcc
> > > +++ b/config/arm/arm64_armada_linux_gcc
> > > @@ -18,3 +18,4 @@ implementer_id = '0x56'
> > > part_number = '0xd08'
> > > max_lcores = 16
> > > max_numa_nodes = 1
> > > +disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
> >
> > It's removing NXP drivers on Marvell SoC. Fine.
> > And what about other useless drivers?
> >
>
> I only removed what was in the old Makefiles, so I don't really know. Liron or
> Jerin may be able to give us some insight.
>
> > > --- a/config/arm/meson.build
> > > +++ b/config/arm/meson.build
> > > +# disable Arm drivers for all builds disabled_drivers +=
> > > +['net/avp', 'net/fm10k']
> >
> > Why disabling avp and fm10k? Did they do something wrong to be banned?
> >
> >
> >
>
> This config is not only in the old Makefiles, but also in the current meson
> build system. I believe Jerin and Allain are the original authors, so they may
> be able to answer.
> > > > disabled drivers, similarly how the command line option works and
> > > > remove unneeded driver options ported from the old makefile
> > > > system, since they don't work in the current Meson build system.
> > > > Add support for removing drivers for cross builds so that we can
> > > > disable them in cross files.
> > >
> > > Why disabling them?
> > > If a driver is not supported it should disable itseld in its meson file.
> > >
> >
> > This is helpful when building for an SoC where we don't want to build
> > to build a driver, but the build machine actually supports the driver.
> > I believe in this case the meson build system would find the
> > dependencies and designate the driver to be build, but we don't want to build
> the driver for that SoC.
> >
> > There may be other reasons as well - Honnappa or others from the Arm
> > community may shed more light on this.
> IMO, the assumption should be everything compiles on all the platforms. Hence,
> the disables should be applied to the platforms where the drivers do not
> compile.
>
Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
22/01/2021 09:39, Juraj Linkeš:
> > > > > disabled drivers, similarly how the command line option works and
> > > > > remove unneeded driver options ported from the old makefile
> > > > > system, since they don't work in the current Meson build system.
> > > > > Add support for removing drivers for cross builds so that we can
> > > > > disable them in cross files.
> > > >
> > > > Why disabling them?
> > > > If a driver is not supported it should disable itseld in its meson file.
> > > >
> > >
> > > This is helpful when building for an SoC where we don't want to build
> > > to build a driver, but the build machine actually supports the driver.
> > > I believe in this case the meson build system would find the
> > > dependencies and designate the driver to be build, but we don't want to build
> > the driver for that SoC.
> > >
> > > There may be other reasons as well - Honnappa or others from the Arm
> > > community may shed more light on this.
> > IMO, the assumption should be everything compiles on all the platforms. Hence,
> > the disables should be applied to the platforms where the drivers do not
> > compile.
If a driver does not compile, it can disable itself.
No need for a configuration.
> Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
I think this patch should not disable drivers but just add the infra to do it.
On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 22/01/2021 09:39, Juraj Linkeš:
> > > > > > disabled drivers, similarly how the command line option works and
> > > > > > remove unneeded driver options ported from the old makefile
> > > > > > system, since they don't work in the current Meson build system.
> > > > > > Add support for removing drivers for cross builds so that we can
> > > > > > disable them in cross files.
> > > > >
> > > > > Why disabling them?
> > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > >
> > > >
> > > > This is helpful when building for an SoC where we don't want to build
> > > > to build a driver, but the build machine actually supports the driver.
> > > > I believe in this case the meson build system would find the
> > > > dependencies and designate the driver to be build, but we don't want to build
> > > the driver for that SoC.
> > > >
> > > > There may be other reasons as well - Honnappa or others from the Arm
> > > > community may shed more light on this.
> > > IMO, the assumption should be everything compiles on all the platforms. Hence,
> > > the disables should be applied to the platforms where the drivers do not
> > > compile.
>
> If a driver does not compile, it can disable itself.
> No need for a configuration.
>
> > Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
>
> I think this patch should not disable drivers but just add the infra to do it.
IMO, If the SOC has "fixed" set of dpdk devices, probably better to
have positive logic to enable only those in config file.
I think, that will be portable and useful.
IMO, We can have infrastructure code enable only specific drivers and
config owners can later enable the required set.
>
>
22/01/2021 10:07, Jerin Jacob:
> On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > disabled drivers, similarly how the command line option works and
> > > > > > > remove unneeded driver options ported from the old makefile
> > > > > > > system, since they don't work in the current Meson build system.
> > > > > > > Add support for removing drivers for cross builds so that we can
> > > > > > > disable them in cross files.
> > > > > >
> > > > > > Why disabling them?
> > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > >
> > > > >
> > > > > This is helpful when building for an SoC where we don't want to build
> > > > > to build a driver, but the build machine actually supports the driver.
> > > > > I believe in this case the meson build system would find the
> > > > > dependencies and designate the driver to be build, but we don't want to build
> > > > the driver for that SoC.
> > > > >
> > > > > There may be other reasons as well - Honnappa or others from the Arm
> > > > > community may shed more light on this.
> > > > IMO, the assumption should be everything compiles on all the platforms. Hence,
> > > > the disables should be applied to the platforms where the drivers do not
> > > > compile.
> >
> > If a driver does not compile, it can disable itself.
> > No need for a configuration.
> >
> > > Would it be okay to leave the disabled as they're in this commit and leave the updates to the plaform owners? Thomas, what do you think?
> >
> > I think this patch should not disable drivers but just add the infra to do it.
>
> IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> have positive logic to enable only those in config file.
> I think, that will be portable and useful.
> IMO, We can have infrastructure code enable only specific drivers and
> config owners can later enable the required set.
Yes you're right, enabling makes more sense than disabling for SoCs.
<snip>
>
> 22/01/2021 10:07, Jerin Jacob:
> > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> > > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > > disabled drivers, similarly how the command line option
> > > > > > > > works and remove unneeded driver options ported from the
> > > > > > > > old makefile system, since they don't work in the current Meson
> build system.
> > > > > > > > Add support for removing drivers for cross builds so that
> > > > > > > > we can disable them in cross files.
> > > > > > >
> > > > > > > Why disabling them?
> > > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > > >
> > > > > >
> > > > > > This is helpful when building for an SoC where we don't want
> > > > > > to build to build a driver, but the build machine actually supports
> the driver.
> > > > > > I believe in this case the meson build system would find the
> > > > > > dependencies and designate the driver to be build, but we
> > > > > > don't want to build
> > > > > the driver for that SoC.
> > > > > >
> > > > > > There may be other reasons as well - Honnappa or others from
> > > > > > the Arm community may shed more light on this.
> > > > > IMO, the assumption should be everything compiles on all the
> > > > > platforms. Hence, the disables should be applied to the
> > > > > platforms where the drivers do not compile.
> > >
> > > If a driver does not compile, it can disable itself.
> > > No need for a configuration.
> > >
> > > > Would it be okay to leave the disabled as they're in this commit and
> leave the updates to the plaform owners? Thomas, what do you think?
> > >
> > > I think this patch should not disable drivers but just add the infra to do it.
> >
> > IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> > have positive logic to enable only those in config file.
> > I think, that will be portable and useful.
> > IMO, We can have infrastructure code enable only specific drivers and
> > config owners can later enable the required set.
>
> Yes you're right, enabling makes more sense than disabling for SoCs.
Every SoC also supports PCIe interfaces. This means, one could use them with a PCIe based NIC (we do use these interfaces internally at Arm, I am not sure from a deployment perspective).
If we use the enable logic, the list will be huge?
>
25/01/2021 15:58, Honnappa Nagarahalli:
> > 22/01/2021 10:07, Jerin Jacob:
> > > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net>
> > wrote:
> > > > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > > > disabled drivers, similarly how the command line option
> > > > > > > > > works and remove unneeded driver options ported from the
> > > > > > > > > old makefile system, since they don't work in the current Meson
> > build system.
> > > > > > > > > Add support for removing drivers for cross builds so that
> > > > > > > > > we can disable them in cross files.
> > > > > > > >
> > > > > > > > Why disabling them?
> > > > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > > > >
> > > > > > >
> > > > > > > This is helpful when building for an SoC where we don't want
> > > > > > > to build to build a driver, but the build machine actually supports
> > the driver.
> > > > > > > I believe in this case the meson build system would find the
> > > > > > > dependencies and designate the driver to be build, but we
> > > > > > > don't want to build
> > > > > > the driver for that SoC.
> > > > > > >
> > > > > > > There may be other reasons as well - Honnappa or others from
> > > > > > > the Arm community may shed more light on this.
> > > > > > IMO, the assumption should be everything compiles on all the
> > > > > > platforms. Hence, the disables should be applied to the
> > > > > > platforms where the drivers do not compile.
> > > >
> > > > If a driver does not compile, it can disable itself.
> > > > No need for a configuration.
> > > >
> > > > > Would it be okay to leave the disabled as they're in this commit and
> > leave the updates to the plaform owners? Thomas, what do you think?
> > > >
> > > > I think this patch should not disable drivers but just add the infra to do it.
> > >
> > > IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> > > have positive logic to enable only those in config file.
> > > I think, that will be portable and useful.
> > > IMO, We can have infrastructure code enable only specific drivers and
> > > config owners can later enable the required set.
> >
> > Yes you're right, enabling makes more sense than disabling for SoCs.
> Every SoC also supports PCIe interfaces. This means, one could use them with a PCIe based NIC (we do use these interfaces internally at Arm, I am not sure from a deployment perspective).
>
> If we use the enable logic, the list will be huge?
That's also right.
The last to talk will be right :)
On Mon, Jan 25, 2021 at 8:28 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
>
> >
> > 22/01/2021 10:07, Jerin Jacob:
> > > On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas@monjalon.net>
> > wrote:
> > > > 22/01/2021 09:39, Juraj Linkeš:
> > > > > > > > > disabled drivers, similarly how the command line option
> > > > > > > > > works and remove unneeded driver options ported from the
> > > > > > > > > old makefile system, since they don't work in the current Meson
> > build system.
> > > > > > > > > Add support for removing drivers for cross builds so that
> > > > > > > > > we can disable them in cross files.
> > > > > > > >
> > > > > > > > Why disabling them?
> > > > > > > > If a driver is not supported it should disable itseld in its meson file.
> > > > > > > >
> > > > > > >
> > > > > > > This is helpful when building for an SoC where we don't want
> > > > > > > to build to build a driver, but the build machine actually supports
> > the driver.
> > > > > > > I believe in this case the meson build system would find the
> > > > > > > dependencies and designate the driver to be build, but we
> > > > > > > don't want to build
> > > > > > the driver for that SoC.
> > > > > > >
> > > > > > > There may be other reasons as well - Honnappa or others from
> > > > > > > the Arm community may shed more light on this.
> > > > > > IMO, the assumption should be everything compiles on all the
> > > > > > platforms. Hence, the disables should be applied to the
> > > > > > platforms where the drivers do not compile.
> > > >
> > > > If a driver does not compile, it can disable itself.
> > > > No need for a configuration.
> > > >
> > > > > Would it be okay to leave the disabled as they're in this commit and
> > leave the updates to the plaform owners? Thomas, what do you think?
> > > >
> > > > I think this patch should not disable drivers but just add the infra to do it.
> > >
> > > IMO, If the SOC has "fixed" set of dpdk devices, probably better to
> > > have positive logic to enable only those in config file.
> > > I think, that will be portable and useful.
> > > IMO, We can have infrastructure code enable only specific drivers and
> > > config owners can later enable the required set.
> >
> > Yes you're right, enabling makes more sense than disabling for SoCs.
> Every SoC also supports PCIe interfaces. This means, one could use them with a PCIe based NIC (we do use these interfaces internally at Arm, I am not sure from a deployment perspective).
Not every SoC.
>
> If we use the enable logic, the list will be huge?
Yes. I think both support will be useful. IMO, Selecting a small
subset can be achieved via, have a flag in config file to disable all
the drivers and add the selective one as needed.
>
> >
>
@@ -18,3 +18,4 @@ implementer_id = '0x56'
part_number = '0xd08'
max_lcores = 16
max_numa_nodes = 1
+disabled_drivers = ['bus/dpaa', 'bus/fslmc', 'common/dpaax']
@@ -2,6 +2,9 @@
# Copyright(c) 2017 Intel Corporation.
# Copyright(c) 2017 Cavium, Inc
+# disable Arm drivers for all builds
+disabled_drivers += ['net/avp', 'net/fm10k']
+
# common flags to all aarch64 builds, with lowest priority
flags_common = [
# Accelerate rte_memcpy. Be sure to run unit test (memcpy_perf_autotest)
@@ -16,9 +19,6 @@ flags_common = [
# ['RTE_ARM64_MEMCPY_ALIGN_MASK', 0xF],
# ['RTE_ARM64_MEMCPY_STRICT_ALIGN', false],
- ['RTE_NET_FM10K', false],
- ['RTE_NET_AVP', false],
-
['RTE_SCHED_VECTOR', false],
['RTE_ARM_USE_WFE', false],
['RTE_ARCH_ARM64', true],
@@ -130,7 +130,6 @@ implementer_cavium = {
['RTE_MACHINE', '"octeontx2"'],
['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_USE_C11_MEM_MODEL', true],
- ['RTE_EAL_IGB_UIO', false],
['RTE_MAX_LCORE', 36],
['RTE_MAX_NUMA_NODES', 1]
]
@@ -143,3 +143,7 @@ There are other options you may specify in a cross file to tailor the build::
Supported extra configuration
max_numa_nodes = n # will set RTE_MAX_NUMA_NODES
max_lcores = n # will set RTE_MAX_LCORE
+
+ disabled_drivers = ['bus/dpaa', 'crypto'] # add disabled drivers
+ # valid values are directories (optionally with their subdirs)
+ # in the drivers directory
@@ -18,9 +18,13 @@ subdirs = [
'baseband', # depends on common and bus.
]
-disabled_drivers = run_command(list_dir_globs, get_option('disable_drivers'),
+disabled_drivers += run_command(list_dir_globs, get_option('disable_drivers'),
).stdout().split()
+if meson.is_cross_build()
+ disabled_drivers += meson.get_cross_property('disabled_drivers', [])
+endif
+
default_cflags = machine_args
default_cflags += ['-DALLOW_EXPERIMENTAL_API']
default_cflags += ['-DALLOW_INTERNAL_API']
@@ -21,6 +21,7 @@ dpdk_drivers = []
dpdk_extra_ldflags = []
dpdk_libs_disabled = []
dpdk_drvs_disabled = []
+disabled_drivers = []
abi_version_file = files('ABI_VERSION')
if host_machine.cpu_family().startswith('x86')