[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v11 01/12] qmp: delete qemu opts when delete an

From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH v11 01/12] qmp: delete qemu opts when delete an object
Date: Fri, 25 Sep 2015 14:40:08 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 09/24/2015 04:35 PM, Yang Hongyang wrote:
> On 09/24/2015 03:43 PM, Markus Armbruster wrote:
>> This has finally reached the front of my review queue.  I apologize for
>> the loooong delay.
>> Copying Paolo for another pair of eyeballs (he wrote this code).
> [...]
>>> +
>>> +    opts = qemu_opts_find(qemu_find_opts_err("object", NULL), id);
>>> +    qemu_opts_del(opts);
>> qemu_find_opts_err("object", &error_abort) please, because when it
>> fails, we want to die right away, not when the null pointer it returns
>> gets dereferenced.
> Thanks for the review.
> Jason, do you want me to propose a fix on top of this series or simply
> drop
> this for now because this patch is an independent bug fix and won't
> affect the
> other filter patch series.

Will drop this patch from my tree.


>> Same sloppiness in netdev_del_completion() and qmp_netdev_del(), not
>> your patch's fault.
>> Elsewhere, we store the QemuOpts in the object just so we can delete it:
>> DeviceState, DriveInfo.  Paolo, what do you think?
> I don't get it. Currently, only objects created at the beginning through
> QEMU command line will be stored in the QemuOpts, objects that created
> with object_add won't stored in QemuOpts. Do you mean for DeviceState,
> DriveInfo they store there QemuOpts explicity so that they can delete it?
> Why don't we just delete it from objects directly instead?
>>>   }
>>>   MemoryDeviceInfoList *qmp_query_memory_devices(Error **errp)
>> .

reply via email to

[Prev in Thread] Current Thread [Next in Thread]