On Mon, 7 Oct 2019 at 11:50, Markus Armbruster <arm...@redhat.com> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: > > Basically new submodules are a pain so we seek to minimize > > the use of them. > > I suggested making it a submodule upthread[*]. Let me try to distill > the conversation into a rationale. Giuseppe, please correct mistakes. > > To make use of QEMU's netmap backend (CONFIG_NETMAP), you have to build > and install netmap software from sources[**]. Which pretty much ensures > developers compile with CONFIG_NETMAP off, and the code rots. > > For other dependencies that aren't readily available on common > development hosts (slirp, capstone), we use submodules to avoid such > rot. If the system provides, we use that, and if it doesn't, we fall > back to the submodule. This has served us well.
I would put this differently. We don't use submodules to avoid code-rot. We use submodules where a dependency is needed for us to provide QEMU features that are sufficiently important that we want to provide them to users even if those users don't have the dependency available to them as a system library. There are lots of features of QEMU that only compile with sufficiently recent versions of dependencies, and we don't try to submodule-ize them because the features aren't really that important for the bulk of our users. For instance, we provided pixman as a submodule for a while because the features that require it (our graphics layer code) are important to almost all users. But we didn't provide spice as a module even when you pretty much needed to be running bleeding-edge redhat to satisfy the version dependency we had, because most users don't care about spice support. Shipping our dependencies as submodules imposes real costs on the project (for instance we then need to track the upstream to see when we should be updating, including checking whether we need to update to fix security issues). Submodules should be the exception, not the rule. > For netmap, falling back to the submodule when the host doesn't provide > tends not to be useful beyond compile-testing. Because of that, we fall > back only when the user explicitly asks for it by passing > --enable-netmap=git to configure. CI should do that. This sounds like netmap is in the same position as most of our dependencies: OK to compile if the system provides the library, but if the system doesn't then almost all users won't care that the feature isn't present. If CI of the QEMU code is useful, get the library supported by and shipped in distros. If you can't get anybody in a distro (Linux or BSD) to care enough to ship the library, this is a really niche feature, and up for consideration for deprecate-and-drop from QEMU, I think. thanks -- PMM
