1. Patchew
  2. Libvirt
  3. [libvirt] [PATCH 00/20] Fix virConnect(Un)RegisterCloseCallback and get rid of global variables
  4. View patch

[libvirt] [PATCH 04/20] test: Implement virConnectSupportsFeature

Marc Hartmayer posted 20 patches 7 years, 2 months ago
[libvirt] [PATCH 04/20] test: Implement virConnectSupportsFeature
Posted by Marc Hartmayer 7 years, 2 months ago 
Implement virConnectSupportsFeature for the test driver as this API is
used by various API functions (the functions usually use the macro
VIR_DRV_SUPPORTS_FEATURE for calling virConnectSupportsFeature).

Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
---
 src/test/test_driver.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 043caa976274..203358c7017f 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -6829,6 +6829,32 @@ testDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
 }
 
 
+static int
+testConnectSupportsFeature(virConnectPtr conn ATTRIBUTE_UNUSED,
+                           int feature)
+{
+    switch ((virDrvFeature) feature) {
+    case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
+        return 1;
+    case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
+    case VIR_DRV_FEATURE_FD_PASSING:
+    case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
+    case VIR_DRV_FEATURE_MIGRATION_DIRECT:
+    case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
+    case VIR_DRV_FEATURE_MIGRATION_P2P:
+    case VIR_DRV_FEATURE_MIGRATION_PARAMS:
+    case VIR_DRV_FEATURE_MIGRATION_V1:
+    case VIR_DRV_FEATURE_MIGRATION_V2:
+    case VIR_DRV_FEATURE_MIGRATION_V3:
+    case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE:
+    case VIR_DRV_FEATURE_REMOTE:
+    case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
+    case VIR_DRV_FEATURE_XML_MIGRATABLE:
+    default:
+        return 0;
+    }
+}
+
 
 static virHypervisorDriver testHypervisorDriver = {
     .name = "Test",
@@ -6837,6 +6863,7 @@ static virHypervisorDriver testHypervisorDriver = {
     .connectGetVersion = testConnectGetVersion, /* 0.1.1 */
     .connectGetHostname = testConnectGetHostname, /* 0.6.3 */
     .connectGetMaxVcpus = testConnectGetMaxVcpus, /* 0.3.2 */
+    .connectSupportsFeature = testConnectSupportsFeature, /* 4.2.0 */
     .nodeGetInfo = testNodeGetInfo, /* 0.1.1 */
     .nodeGetCPUStats = testNodeGetCPUStats, /* 2.3.0 */
     .nodeGetFreeMemory = testNodeGetFreeMemory, /* 2.3.0 */
-- 
2.13.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 04/20] test: Implement virConnectSupportsFeature
Posted by John Ferlan 7 years, 2 months ago 

On 03/08/2018 07:20 AM, Marc Hartmayer wrote:
> Implement virConnectSupportsFeature for the test driver as this API is
> used by various API functions (the functions usually use the macro
> VIR_DRV_SUPPORTS_FEATURE for calling virConnectSupportsFeature).
> 
> Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
> Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
> ---
>  src/test/test_driver.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> index 043caa976274..203358c7017f 100644
> --- a/src/test/test_driver.c
> +++ b/src/test/test_driver.c
> @@ -6829,6 +6829,32 @@ testDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
>  }
>  
>  
> +static int
> +testConnectSupportsFeature(virConnectPtr conn ATTRIBUTE_UNUSED,
> +                           int feature)
> +{
> +    switch ((virDrvFeature) feature) {
> +    case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
> +        return 1;

Not that it makes a difference, but since
src/remote/remote_daemon_dispatch.c returns 1 for
VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK always like
VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK used to before patch 2, then does
returning 1 here really matter?

Perhaps why Nikolay added to remoteDispatchConnectSupportsFeature since
commit id '03722957' was the last to add some new feature bit...

[yes, I'm still a bit mystified about how all this works - so I'm
learning a bit as I go... Still not clear why the same API returns 1 for
VIR_DRV_FEATURE_FD_PASSING always].


So while it seems reasonable, if you return 0, then what happens? Mostly
curious, what's here looks fine to me otherwise.

A weak,

Reviewed-by: John Ferlan <jferlan@redhat.com>

John

> +    case VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK:
> +    case VIR_DRV_FEATURE_FD_PASSING:
> +    case VIR_DRV_FEATURE_MIGRATE_CHANGE_PROTECTION:
> +    case VIR_DRV_FEATURE_MIGRATION_DIRECT:
> +    case VIR_DRV_FEATURE_MIGRATION_OFFLINE:
> +    case VIR_DRV_FEATURE_MIGRATION_P2P:
> +    case VIR_DRV_FEATURE_MIGRATION_PARAMS:
> +    case VIR_DRV_FEATURE_MIGRATION_V1:
> +    case VIR_DRV_FEATURE_MIGRATION_V2:
> +    case VIR_DRV_FEATURE_MIGRATION_V3:
> +    case VIR_DRV_FEATURE_PROGRAM_KEEPALIVE:
> +    case VIR_DRV_FEATURE_REMOTE:
> +    case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
> +    case VIR_DRV_FEATURE_XML_MIGRATABLE:
> +    default:
> +        return 0;
> +    }
> +}
> +
>  
>  static virHypervisorDriver testHypervisorDriver = {
>      .name = "Test",
> @@ -6837,6 +6863,7 @@ static virHypervisorDriver testHypervisorDriver = {
>      .connectGetVersion = testConnectGetVersion, /* 0.1.1 */
>      .connectGetHostname = testConnectGetHostname, /* 0.6.3 */
>      .connectGetMaxVcpus = testConnectGetMaxVcpus, /* 0.3.2 */
> +    .connectSupportsFeature = testConnectSupportsFeature, /* 4.2.0 */
>      .nodeGetInfo = testNodeGetInfo, /* 0.1.1 */
>      .nodeGetCPUStats = testNodeGetCPUStats, /* 2.3.0 */
>      .nodeGetFreeMemory = testNodeGetFreeMemory, /* 2.3.0 */
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 04/20] test: Implement virConnectSupportsFeature
Posted by Daniel P. Berrangé 7 years, 1 month ago 
On Wed, Mar 14, 2018 at 06:35:59PM -0400, John Ferlan wrote:
> 
> 
> On 03/08/2018 07:20 AM, Marc Hartmayer wrote:
> > Implement virConnectSupportsFeature for the test driver as this API is
> > used by various API functions (the functions usually use the macro
> > VIR_DRV_SUPPORTS_FEATURE for calling virConnectSupportsFeature).
> > 
> > Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
> > Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
> > Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
> > ---
> >  src/test/test_driver.c | 27 +++++++++++++++++++++++++++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> > index 043caa976274..203358c7017f 100644
> > --- a/src/test/test_driver.c
> > +++ b/src/test/test_driver.c
> > @@ -6829,6 +6829,32 @@ testDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
> >  }
> >  
> >  
> > +static int
> > +testConnectSupportsFeature(virConnectPtr conn ATTRIBUTE_UNUSED,
> > +                           int feature)
> > +{
> > +    switch ((virDrvFeature) feature) {
> > +    case VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK:
> > +        return 1;
> 
> Not that it makes a difference, but since
> src/remote/remote_daemon_dispatch.c returns 1 for
> VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK always like
> VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK used to before patch 2, then does
> returning 1 here really matter?
> 
> Perhaps why Nikolay added to remoteDispatchConnectSupportsFeature since
> commit id '03722957' was the last to add some new feature bit...
> 
> [yes, I'm still a bit mystified about how all this works - so I'm
> learning a bit as I go... Still not clear why the same API returns 1 for
> VIR_DRV_FEATURE_FD_PASSING always].

The VIR_DRV_FEATURES don't all correspond to driver specific features.
A bunch of the bits correspond to aspects of the remote protocol, so
do not require involvement of driver specific code.  The EVENT_CALLBACK
bit is one such feature - the way we supported events at the RPC level
originally turned out to be flawed, so we introduced a second way to
represent them. The remote driver & libvirtd negotiate which way to
use. The virt drivers have no involvement in this, as the actual libvirt
API implemented is unchanged.


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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Patchew 2.1-devel-8c64711

© 2016 - 2025 Red Hat, Inc.