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

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(a)linux.vnet.ibm.com&gt; wrote: > > On Mon, Mar 19, 2018 at 04:06 PM +0100, "Daniel P. Berrangé" <berrange(a)redhat.com&gt; 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 :|