<snip> > > 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. 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? >
