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

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> 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,

If CI of QEMU code isn't useful, then I suspect the QEMU code isn't
useful, period.  Giuseppe assures us the netmap QEMU code *is* useful.
It followe we better make sure our CI covers it.

A submodule would make sure, but it looks like it won't fly.  So let's
try another tack:

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

Giuseppe, you mentioned netmap is in FreeBSD, and getting it into Linux
is unlikely, so let's focus on FreeBSD.

We have a FreeBSD section in .patchew.yml, which makes me guess Patchew
CI tests FreeBSD.  Does it test with CONFIG_NETMAP out of the box?  If
not, how do we have to tweak its configuration to get CONFIG_NETMAP
enabled?  Who could help with this?