[libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew

John Ferlan jferlan at redhat.com
Sun May 21 15:36:23 UTC 2017

>> Also I didn't want the "overhead" of converting it to a virObject only
>> to convert it later to the newer object. I mean I could now, but I have
>> this goal of making all these driver objects use the same object around
>> the same time. Some convert more easily since they already use virObject
>> - others are a bit more effort.
>> Still even if I convert it to a virObject now, that's not going to be
>> done in "this" patch...
> Fair enough. It's just that whenever I see virSomethinObj I expect it to
> be derived from virObject. Thus I can use virObject APIs.
> And as for the "overhead" - I think that it'll be goot if all the
> objects that you will make use the new "listable" object (or whatever it
> is going to be called) already have common ground => are virObject
> already (or something derived from it). At least that's how I view these
> patches. What do you think? Here's the deal, I'll give you ACK on this
> and you'll send 9/8 to convert this to actual virObject?

I understand your point, but it's not like I invented virInterfaceObjPtr
during this series either...

Guess I didn't see the value in creating the OnceInit/Dispose stuff only
to see it removed when the "listable" object comes along and makes it
unnecessary, but I'll send 2 more patches shortly.



A listable object would have both @active and @def, thus rendering the
local object obsolete because of this code in virClassNew:

    } else if (parent &&
               objectSize <= parent->objectSize) {
                            _("object size %zu of %s is smaller than
parent class %zu"),
                            objectSize, name, parent->objectSize);
        return NULL;

There'd be no elements in virInterfaceObj other than the @parent, so
there's no use for OnceInit and friends.  Yes, I went there during
development ;-)

More information about the libvir-list mailing list