qemu-devel
[Top][All Lists]
Advanced

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

Re: Serious doubts about Gitlab CI


From: Thomas Huth
Subject: Re: Serious doubts about Gitlab CI
Date: Tue, 30 Mar 2021 18:10:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0

On 30/03/2021 15.27, Daniel P. Berrangé wrote:
On Tue, Mar 30, 2021 at 03:19:49PM +0200, Paolo Bonzini wrote:
On 30/03/21 15:12, Daniel P. Berrangé wrote:
Now, but that may change already in 6.1 in order to add CFI support.
We can bundle a newer version, but we don't need to require a newer
version. Simply conditional compile for the bits we need. If distro
slirp is too old, then sorry, you can't enable CFI + slirp at the
same time. If the distro really wants that combination we don't have
to own the solution - the distro should update their slirp.

Or to put it another way, QEMU doesn't need to go out of its way to
enable new features on old distros. We merely need to not regress
in the features we previously offered.  We bundled slirp as a submodule
so that old distros didn't loose slirp entirely. We don't need to
offer CFI on those distros.

This is true, on the other hand only having to support one API version has
its benefits.  The complication in the build system is minimal once slirp is
made into a subproject; therefore it is appealing to keep the QEMU code
simple.

I don't think slirp is special in this regard. The benefit you're promoting
here applies to any dependancy we have, but I think the benefit is not big
enough to justify.

The use of submodules has imposed significant pain on QEMU developers over
the years, and as such I think our general goal should be to have zero git
submodules over the long term. Usage of submodules ought to be considered
a short term workaround only, with a clear criteria for removal.
I agree with Daniel. Submodules keep being a pain. For all libs that are mature and widely available enough in the distros now, we should consider to drop the submodules rather sooner than later.

 Thomas




reply via email to

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