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@xxxxxxxxxx>
>>> ---
>>> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
