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

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

[Jagannathan Raman]

Hi,

This patch updates the libvfio-user submodule to the latest.

Passed 'make check' & GitLab CI.

Thank you!
--
Jag

Jagannathan Raman (1):
  vfio-user: update submodule to latest

 subprojects/libvfio-user | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.20.1

[PATCH 1/1] vfio-user: update submodule to latest

[Jagannathan Raman]

Update libvfio-user submodule to the latest

Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
---
 subprojects/libvfio-user | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/subprojects/libvfio-user b/subprojects/libvfio-user
index 0b28d20557..1305f161b7 160000
--- a/subprojects/libvfio-user
+++ b/subprojects/libvfio-user
@@ -1 +1 @@
-Subproject commit 0b28d205572c80b568a1003db2c8f37ca333e4d7
+Subproject commit 1305f161b7e0dd2c2a420c17efcb0bd49b94dad4
-- 
2.20.1

Re: [PATCH 1/1] vfio-user: update submodule to latest

[Daniel P. Berrangé]

On Mon, Aug 01, 2022 at 09:24:04PM -0400, Jagannathan Raman wrote:
> Update libvfio-user submodule to the latest
> 
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> ---
>  subprojects/libvfio-user | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/subprojects/libvfio-user b/subprojects/libvfio-user
> index 0b28d20557..1305f161b7 160000
> --- a/subprojects/libvfio-user
> +++ b/subprojects/libvfio-user
> @@ -1 +1 @@
> -Subproject commit 0b28d205572c80b568a1003db2c8f37ca333e4d7
> +Subproject commit 1305f161b7e0dd2c2a420c17efcb0bd49b94dad4

Only 3 changes in the submodule with this:

1305f161b7e0dd2c2a420c17efcb0bd49b94dad4 disable client-server test by default (#700)
36beb63be45ad1412562a98d9373a4c0bd91ab3d support for shadow ioeventfd (#698)
1c274027bb4f9d68eee846036e8d50dcde2fd7e9 improve README.md (#696)

That fixes the testing bug we see, the other change affects an API that
QEMU doesn't use. Overall looks safe for applying during soft freeze.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

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 :|

Re: [PATCH 1/1] vfio-user: update submodule to latest

[Stefan Hajnoczi]

On Tue, 2 Aug 2022 at 05:44, Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Mon, Aug 01, 2022 at 09:24:04PM -0400, Jagannathan Raman wrote:
> > Update libvfio-user submodule to the latest
> >
> > Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> > ---
> >  subprojects/libvfio-user | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/subprojects/libvfio-user b/subprojects/libvfio-user
> > index 0b28d20557..1305f161b7 160000
> > --- a/subprojects/libvfio-user
> > +++ b/subprojects/libvfio-user
> > @@ -1 +1 @@
> > -Subproject commit 0b28d205572c80b568a1003db2c8f37ca333e4d7
> > +Subproject commit 1305f161b7e0dd2c2a420c17efcb0bd49b94dad4
>
> Only 3 changes in the submodule with this:
>
> 1305f161b7e0dd2c2a420c17efcb0bd49b94dad4 disable client-server test by default (#700)
> 36beb63be45ad1412562a98d9373a4c0bd91ab3d support for shadow ioeventfd (#698)
> 1c274027bb4f9d68eee846036e8d50dcde2fd7e9 improve README.md (#696)
>
> That fixes the testing bug we see, the other change affects an API that
> QEMU doesn't use. Overall looks safe for applying during soft freeze.
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

CCing Richard so this can be merged.

Stefan

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

[Zhang, Chen]

> -----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?

Thanks
Chen

> 
> Passed 'make check' & GitLab CI.
> 
> Thank you!
> --
> Jag
> 
> Jagannathan Raman (1):
>   vfio-user: update submodule to latest
> 
>  subprojects/libvfio-user | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --
> 2.20.1
> 

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

[Thomas Huth]

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.

  Thomas

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

[Daniel P. Berrangé]

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 :|

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

[Michael S. Tsirkin]

On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:
> 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.

It's weird that the parent lumps libvfio-user which is
a submodule with libvduse and libvhost-user which are not.
I don't know whether moving libvfio-user to avoid confusion
is justified.

-- 
MST

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

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

[Jag Raman]

[-- Attachment #1: Type: text/plain, Size: 3546 bytes --]



On Aug 7, 2022, at 6:39 AM, John Levon <levon@movementarian.org<mailto: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


[-- Attachment #2: Type: text/html, Size: 6060 bytes --]

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

[Thomas Huth]

On 07/08/2022 12.39, John Levon wrote:
> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:
[...]
>> 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?

Some reasoning can be found here:

 
https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/

> I can only think of the flaky test issue (for which I'm
> sorry).

Speaking of that test issue, yes, it would be good to get this patch 
included now as soon as the 7.1 release has been done. Who's going to send a 
pull request for this?

  Thomas

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

[Jag Raman]

> On Aug 29, 2022, at 8:40 AM, Thomas Huth <thuth@redhat.com> wrote:
> 
> On 07/08/2022 12.39, John Levon wrote:
>> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:
> [...]
>>> 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?
> 
> Some reasoning can be found here:
> 
> https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/
> 
>> I can only think of the flaky test issue (for which I'm
>> sorry).
> 
> Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this?

Now that QEMU 7.1 has released, could we please pull this patch in - just so no one else has a bad experience when testing?

--
Jag

> 
> Thomas
> 

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

[Thomas Huth]

On 29/09/2022 03.52, Jag Raman wrote:
> 
> 
>> On Aug 29, 2022, at 8:40 AM, Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 07/08/2022 12.39, John Levon wrote:
>>> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:
>> [...]
>>>> 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?
>>
>> Some reasoning can be found here:
>>
>> https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/
>>
>>> I can only think of the flaky test issue (for which I'm
>>> sorry).
>>
>> Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this?
> 
> Now that QEMU 7.1 has released, could we please pull this patch in - just so no one else has a bad experience when testing?

You are listed as maintainer for subprojects/libvfio-user in the MAINTAINERS 
file, so I guess you should just go ahead and send a pull request for this?

  Thomas

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

[Jag Raman]

> On Sep 29, 2022, at 2:27 AM, Thomas Huth <thuth@redhat.com> wrote:
> 
> On 29/09/2022 03.52, Jag Raman wrote:
>>> On Aug 29, 2022, at 8:40 AM, Thomas Huth <thuth@redhat.com> wrote:
>>> 
>>> On 07/08/2022 12.39, John Levon wrote:
>>>> On Fri, Aug 05, 2022 at 09:24:56AM +0100, Daniel P. Berrangé wrote:
>>> [...]
>>>>> 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?
>>> 
>>> Some reasoning can be found here:
>>> 
>>> https://lore.kernel.org/qemu-devel/d7a7b28f-a665-2567-0fb6-e31e7ecbb5c8@redhat.com/
>>> 
>>>> I can only think of the flaky test issue (for which I'm
>>>> sorry).
>>> 
>>> Speaking of that test issue, yes, it would be good to get this patch included now as soon as the 7.1 release has been done. Who's going to send a pull request for this?
>> Now that QEMU 7.1 has released, could we please pull this patch in - just so no one else has a bad experience when testing?
> 
> You are listed as maintainer for subprojects/libvfio-user in the MAINTAINERS file, so I guess you should just go ahead and send a pull request for this?

OK, will do.

Thank you!
--
Jag

> 
> Thomas
> 

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

[Michael S. Tsirkin]

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 they are submodules are they?

> ... 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?

Why not?  Fundamentally I don't see why would libvhost-user be less
important to users than e.g. qemu-img or qemu-bridge-helper. There's no
rule saying we can only ship a single binary.

> If someone wants to use this, they can
> compile the libraries on their own or help their favorite distribution to
> ship them as packages.
> 
>  Thomas

I can speak for libvhost-user at least, the main reason is simple - QEMU
uses it - to be more precise, QEMU tests use it ATM, but there are also
ideas to implement the device side of virtio inside a VM and that will
use it more directly.  Same developers are working on both qemu and
libvhost-user parts.  So I don't think there is much interest in first
splitting it out then jumping through hoops to get it back.

But there are more reasons - for example, if an application
links against libvhost-user, then it's a good idea
to update libvhost-user and qemu together - they have
been tested together and are known to work well.

I suspect the same applies to other probjects in this area
but I'm not sure.

-- 
MST

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

[Thomas Huth]

On 05/08/2022 10.55, Michael S. Tsirkin wrote:
> 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 they are submodules are they?

Drat, my bad! It's only libvfio-user that is a submodule. Never mind the 
other two.

>> ... 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?
> 
> Why not?  Fundamentally I don't see why would libvhost-user be less
> important to users than e.g. qemu-img or qemu-bridge-helper. There's no
> rule saying we can only ship a single binary.

If libvhost-user does not have another home, then it's fine to have it here, 
I guess, but libvfio-user should rather be packaged as a proper library by 
the distros instead if it has a different upstream home.

  Thomas