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