[libvirt] [PATCH 8/8] interface: Introduce virInterfaceObjNew
John Ferlan
jferlan at redhat.com
Sat May 20 11:26:32 UTC 2017
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 at 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
More information about the libvir-list
mailing list