[PATCH 00/55] Hyper-V: code cleanup & prep for future changes

Daniel P. Berrangé berrange at redhat.com
Fri Jan 22 16:08:46 UTC 2021


On Fri, Jan 22, 2021 at 11:05:22AM -0500, Laine Stump wrote:
> (Thought I sent this 7 hours ago before I went to sleep, but when I sat down
> this morning I saw it was still sitting there as a draft :-/)
> 
> On 1/21/21 1:50 PM, Matt Coleman wrote:
> > This series of patches simplifies the code in several ways and makes a
> > few changes required by the next round of patches that I'll submit.
> > 
> > Simplifications:
> > 
> > * add a macro to cut down on repetitive SettingData code
> > * enable GLib auto-cleanup for hypervObject and several OpenWSMAN types
> > 
> > Changes:
> > 
> > * store the version in hypervPrivate, which will be used to handle
> >    breaking changes in the Hyper-V API: despite 2012R2 and 2016+ all
> >    using Hyper-V's "V2" API, backwards-incompatible changes were made in
> >    2016
> > * add inheritance to the WMI generator to simplify handling of the
> >    backwards-incompatible changes introduced in Hyper-V 2016
> 
> 
> I've gone through all of these, and just have two questions that affect
> multiple patches each (I've replied to the associated patches):
> 
> 
> 1) There are several cleanup functions in external libraries that in the
> past were only called after checking that the pointer was != NULL. g_autoptr
> cleanups need to handle being called with NULL as a NOP, and I'm concerned
> that these functions may not behave properly in that case. Can you either
> verify that it's safe to call them with NULL, or provide a wrapper function
> that checks for NULL and use that as the cleanup?

The G_DEFINE_AUTOPTR_*  macros alrady define wrappers that include
a NULL check I believe.


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




More information about the libvir-list mailing list