[libvirt] [PATCH 02/20] remote: Don't hard code the feature VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK as available

[Daniel P. Berrangé]

On Tue, Apr 03, 2018 at 01:46:13PM +0200, Marc Hartmayer wrote:
> On Wed, Mar 21, 2018 at 07:57 AM +0100, Marc Hartmayer <mhartmay at linux.vnet.ibm.com> wrote:
> > On Mon, Mar 19, 2018 at 04:06 PM +0100, "Daniel P. Berrangé" <berrange at redhat.com> wrote:
> >> On Thu, Mar 08, 2018 at 01:20:25PM +0100, Marc Hartmayer wrote:
> >>> Don't assume that the feature VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK is
> >>> available for every driver used for the connection.
> >>
> >> The very definition of the virConnectRegisterCloseCallback() API is that
> >> it will always succeed.   What varies is that some driver connections
> >> may never fail and so the close callback will never be invoked. The actual
> >> registration of the callback will always succeed regardless of which driver
> >> is in use. So it is correct to report the VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK
> >> as always supported regardless of driver.
> >
> > Okay. So how can we deal with the situation in patch 18 if we cannot
> > differentiate between 'callback was “really” registered' and only the
> > call was 'successful'? If it’s not really registered nobody will free
> > the callback data. This was also the cause for the fix: ce35122cfe:
> > "daemon: fixup refcounting in close callback handling".
> >
> > Thanks in advance.
> 
> Polite ping.

If conn->driver->connectRegisterCloseCallback is NULL, then the
virConnectRegisterCloseCallback()  method should immediately
call  freecb(opaque).


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