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. We should continually introduce dependancies on newer & newer versions, as that means we'll never have any opportunity to remove them and reduce the cost on QEMU. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|