[libvirt] [PATCH v4 0/3] Multiple cleanups within interfaceobj and interface driver

v3: https://www.redhat.com/archives/libvir-list/2017-May/msg01161.html NB: The first 7 patches from v3 were pushed since they were ACK'd. Difference in v4: Patch 1 was essentially ACK'd, but I chose to hold onto it to show the context Patch 2 is the new patch/context - move the @def processing into ObjNew Patch 3 is mostly unchanged; however, I realized during processing of the other code that with the model chosen in virInterfaceObjListAssignDef to return an object that has had both the @lock and @ref incremented so that callers can use the EndAPI to effectively Unlock and Unref that means when calling virInterfaceObjListRemove all that's done is a single Unlock/Unref leaving the object with still 1 reference (and undeleted). That means the caller (testInterfaceUndefine) must make that Unref call of the object. This is no different than how Domain's work, although it's a bit more obtuse there because callers of domain add will make that "second" reference to the object and my goal in this is to be a bit more obvious... The easier way to think about this is for objects only in one list, when leaving the Add/Assign API's, there are 2 Refs and 1 Lock on the object. For objects in 2 lists, there are 3 Refs and 1 Lock. Each caller always calls EndAPI dropping a Ref and the Lock. When it's time to Remove the object, a Find is done - which increments a Ref and Lock and then the Remove API called. The Remove API will effectively Unref for the object in a list (once or twice) and return the Unlocked object w/ 1 Ref. John Ferlan (3): interface: Introduce virInterfaceObjNew interface: Consume @def in virInterfaceObjNew interface: Convert virInterfaceObj to use virObjectLockable po/POTFILES.in | 1 - src/conf/virinterfaceobj.c | 108 +++++++++++++++++++++++++++------------------ src/conf/virinterfaceobj.h | 9 ++-- src/libvirt_private.syms | 3 +- src/test/test_driver.c | 16 +++---- 5 files changed, 77 insertions(+), 60 deletions(-) -- 2.9.4