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....@nongnu.org> On Behalf Of Jagannathan > > > Raman > > > Sent: Tuesday, August 2, 2022 9:24 AM > > > To: qemu-devel@nongnu.org > > > Cc: stefa...@gmail.com; berra...@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.zh...@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 :|