<snip>

22/01/2021 10:07, Jerin Jacob:

quoted

On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon [off-list ref]

wrote:

quoted

quoted

22/01/2021 09:39, Juraj Linkeš:

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

quoted

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.

quoted

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.

quoted

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?

quoted

quoted

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?