[v4] Multiple cleanups within interfaceobj and interface driver

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

John Ferlan posted 3 patches 6 years, 10 months ago

Diff against v1 v2 v3
Download series mbox

Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20170603105323.9005-1-jferlan@redhat.com

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(-)

Expand all Fold all

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

Posted by John Ferlan 6 years, 10 months ago

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

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