qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] netmap: support git-submodule build otption


From: Peter Maydell
Subject: Re: [PATCH] netmap: support git-submodule build otption
Date: Mon, 7 Oct 2019 12:58:38 +0100

On Mon, 7 Oct 2019 at 11:50, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]