[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] netmap: support git-submodule build otption
From: |
Markus Armbruster |
Subject: |
Re: [PATCH] netmap: support git-submodule build otption |
Date: |
Mon, 07 Oct 2019 14:35:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
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?