On Thu, Aug 03, 2023 at 10:40:47AM -0600, Philip Prindeville wrote: > > > > On Aug 2, 2023, at 4:47 PM, Stephen Hemminger <step...@networkplumber.org> > > wrote: > > > > On Wed, 2 Aug 2023 15:49:54 -0600 > > Philip Prindeville <philipp_s...@redfish-solutions.com> wrote: > > > >> Hi, > >> > >> I'm trying to come up with some Kconfig logic for OpenWRT packaging to > >> help users select the right build options for their hardware. > >> > >> Most OpenWRT developers typically cross-compile, so we obviously can't > >> rely on detection on the build host as that's rarely the same as the > >> target machine. > >> > >> Looking in the DPDK repo, I don't see any description of the available > >> architectures, drivers, etc. and what I had seen previously was (if I > >> remember) only for x86_64 hardware, and even that I can't seem to locate > >> again. > >> > >> Would it make sense to put some of these definitions into the repo itself, > >> so that when new drivers are added, that stands out (at least in the > >> commit logs) and we can capture the permutations of what driver goes with > >> which SoC on what architecture, etc? > >> > >> Thanks, > >> > >> -Philip > >> > > > > DPDK now uses meson which by default builds everything available on the > > build architecture. > > There is intentionally no way to disable drivers, you can disable some > > libraries though. > > > > The issue I'm trying to resolve is that if you're building for SoC Xyzzy that > includes an on-chip NIC, then that driver should *only* ever be selectable > when building for that SoC. > > There's no point if generating (or packaging) combinations of platform + > driver that aren't viable. > Actually, for development purposes there is good reason. By having e.g. NIC drivers for ARM SoCs be built when doing an x86 build, it allows us to catch changes that break that driver. It also allows one to do a generic build where the one build could be used across multiple platforms.
/Bruce
