[dpdk-dev] [PATCH v15 09/12] build: disable drivers in Arm builds

[Thomas Monjalon]

22/01/2021 10:07, Jerin Jacob:
> On Fri, Jan 22, 2021 at 2:28 PM Thomas Monjalon <thomas at 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.