[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/1] Update vfio-user module to the latest
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 0/1] Update vfio-user module to the latest |
Date: |
Fri, 5 Aug 2022 09:24:56 +0100 |
User-agent: |
Mutt/2.2.6 (2022-06-05) |
On Fri, Aug 05, 2022 at 09:21:07AM +0200, Thomas Huth wrote:
> On 02/08/2022 12.00, Zhang, Chen wrote:
> >
> >
> > > -----Original Message-----
> > > From: Qemu-devel <qemu-devel-
> > > bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Jagannathan
> > > Raman
> > > Sent: Tuesday, August 2, 2022 9:24 AM
> > > To: qemu-devel@nongnu.org
> > > Cc: stefanha@gmail.com; berrange@redhat.com
> > > Subject: [PATCH 0/1] Update vfio-user module to the latest
> > >
> > > Hi,
> > >
> > > This patch updates the libvfio-user submodule to the latest.
> >
> > Just a rough idea, why not depends on linux distribution for the
> > libvfio-user.so?
> > It looks no libvfio-user packet in distribution's repo.
> >
> > Hi Thomas/Daniel:
> >
> > 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.
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.
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.
So again my preference is to not add any library as a submodule. Lets
the distros handle dependancies like they always have.
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.
We are where we are with libvfio-user.so, and I don't think that is
something to be used as justification for adding more libraries as
submodules. Rather we should set a timeframe to remove libvfio-user
submodule to put distros on notice.
With 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 :|