Re: [PATCH 0/1] Update vfio-user module to the latest

[John Levon]

On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:

> > > For the RFC QEMU user space eBPF support,
> > > https://lore.kernel.org/all/20220617073630.535914-6-chen.zhang@intel.com/T/
> > > Maybe introduce the libubpf.so as a subproject like libvfio-user.so is 
> > > more appropriate?
> > 
> > Fair comment. I never noticed them before, but why do we have those
> > submodules in the subprojects/ folder (libvduse, libvfio-user and
> > libvhost-user)? ... I don't think it's the job of QEMU to ship libraries
> > that a user might want to use for a certain feature, so could we please
> > remove those submodules again? If someone wants to use this, they can
> > compile the libraries on their own or help their favorite distribution to
> > ship them as packages.
> 
> FWIW, I don't really agree with shipping libvfio-user.so as a submodule
> either, but the consensus was that we have to do it because there's no
> stable ABI committed to by libvfio-user maintainers yet.  My counterpoint
> is that as long as QEMU ships libvfio-user as a submodule, there's no
> incentive to create a stable ABI, leaving a chicken & egg scenario.

qemu is not the only consumer of the library, so I'm not sure removing the
submodule from qemu moves the needle in either direction.

We are still discovering our abstractions are not quite right in places, so
we're not yet confident enough to mark the API/ABI as stable (nor do we have any
testing of this in place). It would be all downside at this point.

> IOW personally I'd rather libvfio-user.so was put into the distros right
> now, and have the pain ABI incompatible releases act as motivation for
> the creation of a stable ABI.

We can't control what the distributions choose to do, but speaking for
libvfio-user, we would not support this choice or anything like it. It would
only cause pain for users.

> A second factor is that as long as it is a submodule, there is little
> pressure for the distros to actually package the library, which leaves
> us in a place where someone will always object to removing the submodule
> from QEMU because it doesn't exist in distro X.

No distribution has even *asked* us about this.  Do you have some evidence that
by making this more difficult, somehow we'll start hearing from all the distros?
What's the mechanism by which this will work?

It seems to me that all that will happen by removing it, is make it extremely
annoying for anyone wanting to use it with qemu, as every user will have to
figure out which commit is needed for the qemu commit they're trying to compile.

> If we do add something as a submodule for some reason, I'd like us to
> say upfront that this is for a fixed time period (ie maximum of 3
> releases aka 1 year) only after which we'll remove it no matter what.

I'm not clear on the costs of having the submodule: could you please explain why
it's an issue exactly? I can only think of the flaky test issue (for which I'm
sorry).

regards
john