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

[Jag Raman]

On Aug 7, 2022, at 6:39 AM, John Levon <levon@movementarian.org> wrote:

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.

Hi,

I think we need to move forward on this item as the libvfio0user test hang

is affecting some folks.

Looks like libvfio-user wouldn’t ship via distros anytime soon.

I’m wondering if we could consider alternatives to the distro approach?

Would a standalone package be OK until libvfio-user ships as
a distro? I could help with this - I’m familiar with building RPMs.

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.

This of course doesn’t address usability issue that John pointed out above.

--

Jag

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