[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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




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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]