1. Patchew
  2. Libvirt
  3. [libvirt] [PATCH 0/8] Multiple cleanups within interfaceobj and interface driver
  4. View patch

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

John Ferlan posted 8 patches 8 years, 9 months ago
There is a newer version of this series
[libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew
Posted by John Ferlan 8 years, 9 months ago 
Create/use a helper to perform the object allocation

Signed-off-by: John Ferlan <jferlan@redhat.com>
---
 src/conf/virinterfaceobj.c | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/src/conf/virinterfaceobj.c b/src/conf/virinterfaceobj.c
index 1cc5c92..4463653 100644
--- a/src/conf/virinterfaceobj.c
+++ b/src/conf/virinterfaceobj.c
@@ -46,6 +46,27 @@ struct _virInterfaceObjList {
 
 /* virInterfaceObj manipulation */
 
+static virInterfaceObjPtr
+virInterfaceObjNew(void)
+{
+    virInterfaceObjPtr obj;
+
+    if (VIR_ALLOC(obj) < 0)
+        return NULL;
+
+    if (virMutexInit(&obj->lock) < 0) {
+        virReportError(VIR_ERR_INTERNAL_ERROR,
+                       "%s", _("cannot initialize mutex"));
+        VIR_FREE(obj);
+        return NULL;
+    }
+
+    virInterfaceObjLock(obj);
+
+    return obj;
+}
+
+
 void
 virInterfaceObjLock(virInterfaceObjPtr obj)
 {
@@ -228,18 +249,12 @@ virInterfaceObjListAssignDef(virInterfaceObjListPtr interfaces,
         return obj;
     }
 
-    if (VIR_ALLOC(obj) < 0)
-        return NULL;
-    if (virMutexInit(&obj->lock) < 0) {
-        virReportError(VIR_ERR_INTERNAL_ERROR,
-                       "%s", _("cannot initialize mutex"));
-        VIR_FREE(obj);
+    if (!(obj = virInterfaceObjNew()))
         return NULL;
-    }
-    virInterfaceObjLock(obj);
 
     if (VIR_APPEND_ELEMENT_COPY(interfaces->objs,
                                 interfaces->count, obj) < 0) {
+        virInterfaceObjUnlock(obj);
         virInterfaceObjFree(obj);
         return NULL;
     }
-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew
Posted by Michal Privoznik 8 years, 8 months ago 
On 04/26/2017 12:36 AM, John Ferlan wrote:
> Create/use a helper to perform the object allocation
> 
> Signed-off-by: John Ferlan <jferlan@redhat.com>
> ---
>  src/conf/virinterfaceobj.c | 31 +++++++++++++++++++++++--------
>  1 file changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/src/conf/virinterfaceobj.c b/src/conf/virinterfaceobj.c
> index 1cc5c92..4463653 100644
> --- a/src/conf/virinterfaceobj.c
> +++ b/src/conf/virinterfaceobj.c
> @@ -46,6 +46,27 @@ struct _virInterfaceObjList {
>  
>  /* virInterfaceObj manipulation */
>  
> +static virInterfaceObjPtr
> +virInterfaceObjNew(void)
> +{
> +    virInterfaceObjPtr obj;
> +
> +    if (VIR_ALLOC(obj) < 0)
> +        return NULL;
> +
> +    if (virMutexInit(&obj->lock) < 0) {
> +        virReportError(VIR_ERR_INTERNAL_ERROR,
> +                       "%s", _("cannot initialize mutex"));
> +        VIR_FREE(obj);
> +        return NULL;
> +    }
> +
> +    virInterfaceObjLock(obj);
> +
> +    return obj;
> +}
> +
> +


Any reason why virInterfaceObj can't actually be an virObject?
virInterfaceObjLock() is so 0.9.X release-y.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew
Posted by John Ferlan 8 years, 8 months ago 

On 05/19/2017 11:29 AM, Michal Privoznik wrote:
> On 04/26/2017 12:36 AM, John Ferlan wrote:
>> Create/use a helper to perform the object allocation
>>
>> Signed-off-by: John Ferlan <jferlan@redhat.com>
>> ---
>>  src/conf/virinterfaceobj.c | 31 +++++++++++++++++++++++--------
>>  1 file changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/conf/virinterfaceobj.c b/src/conf/virinterfaceobj.c
>> index 1cc5c92..4463653 100644
>> --- a/src/conf/virinterfaceobj.c
>> +++ b/src/conf/virinterfaceobj.c
>> @@ -46,6 +46,27 @@ struct _virInterfaceObjList {
>>  
>>  /* virInterfaceObj manipulation */
>>  
>> +static virInterfaceObjPtr
>> +virInterfaceObjNew(void)
>> +{
>> +    virInterfaceObjPtr obj;
>> +
>> +    if (VIR_ALLOC(obj) < 0)
>> +        return NULL;
>> +
>> +    if (virMutexInit(&obj->lock) < 0) {
>> +        virReportError(VIR_ERR_INTERNAL_ERROR,
>> +                       "%s", _("cannot initialize mutex"));
>> +        VIR_FREE(obj);
>> +        return NULL;
>> +    }
>> +
>> +    virInterfaceObjLock(obj);
>> +
>> +    return obj;
>> +}
>> +
>> +
> 
> 
> Any reason why virInterfaceObj can't actually be an virObject?
> virInterfaceObjLock() is so 0.9.X release-y.
> 
> Michal
> 

I thought I tried that once - one large leap for mankind, but was asked
to show all the tiny steps it took me to get there ;-)

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

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew
Posted by Michal Privoznik 8 years, 8 months ago 
On 05/20/2017 01:26 PM, John Ferlan wrote:
> 
> 
> On 05/19/2017 11:29 AM, Michal Privoznik wrote:
>> On 04/26/2017 12:36 AM, John Ferlan wrote:
>>> Create/use a helper to perform the object allocation
>>>
>>> Signed-off-by: John Ferlan <jferlan@redhat.com>
>>> ---
>>>  src/conf/virinterfaceobj.c | 31 +++++++++++++++++++++++--------
>>>  1 file changed, 23 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/src/conf/virinterfaceobj.c b/src/conf/virinterfaceobj.c
>>> index 1cc5c92..4463653 100644
>>> --- a/src/conf/virinterfaceobj.c
>>> +++ b/src/conf/virinterfaceobj.c
>>> @@ -46,6 +46,27 @@ struct _virInterfaceObjList {
>>>  
>>>  /* virInterfaceObj manipulation */
>>>  
>>> +static virInterfaceObjPtr
>>> +virInterfaceObjNew(void)
>>> +{
>>> +    virInterfaceObjPtr obj;
>>> +
>>> +    if (VIR_ALLOC(obj) < 0)
>>> +        return NULL;
>>> +
>>> +    if (virMutexInit(&obj->lock) < 0) {
>>> +        virReportError(VIR_ERR_INTERNAL_ERROR,
>>> +                       "%s", _("cannot initialize mutex"));
>>> +        VIR_FREE(obj);
>>> +        return NULL;
>>> +    }
>>> +
>>> +    virInterfaceObjLock(obj);
>>> +
>>> +    return obj;
>>> +}
>>> +
>>> +
>>
>>
>> Any reason why virInterfaceObj can't actually be an virObject?
>> virInterfaceObjLock() is so 0.9.X release-y.
>>
>> Michal
>>
> 
> I thought I tried that once - one large leap for mankind, but was asked
> to show all the tiny steps it took me to get there ;-)

Right.

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

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew
Posted by John Ferlan 8 years, 8 months ago 
>>
>> 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.

John

FWIW:

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) {
        virReportInvalidArg(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 ;-)

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

Patchew 2.1-devel-8c64711

© 2016 - 2026 Red Hat, Inc.