Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl

[Lin Ma <lma@suse.com>]

在 2015年03月23日 21:30, Igor Mammedov 写道:
> On Mon, 23 Mar 2015 14:13:07 +0100
> Andreas Färber <afaerber@suse.de> wrote:
>
>> Hi,
>>
>> For consistency in git-log, please use "qom:" rather than "object:".
>>
>> Am 23.03.2015 um 13:06 schrieb Paolo Bonzini:
>>> On 23/03/2015 11:36, Peter Crosthwaite wrote:
>>>> I don't think TypeInfo is the right place for this. You can however
>>>> define function hooks for Object in ObjectClass. See the unparent
>>>> field of ObjectClass for a precedent.
>> Agree.
>>
>>> In this case, the right place could be UserCreatable.
>> Maybe, not so familiar with that interface myself. Does object_del allow
>> to delete non-UserCreatable objects? Then it wouldn't help much.
> object_del() works only with /objects children, and so far the only way
> that child placed there is via object_add() which requires a new object
> to have TYPE_USER_CREATABLE interface.
> I'd go this way rather than overhaul object_unparent() in this case.
What about these changes?
1. Add a callback function named 'ObjectCanBeDeleted *can_be_deleted' to 
struct ObjectClass in object.h
2. Call the function in qmp_object_del of qmp.c, says:
     ObjectClass *obj_class = object_get_class(obj);
         if (obj_class->can_be_deleted)
             if (!obj_class->can_be_deleted(obj))
                 error out

3. Then implement can_be_deleted callback in backends, says:
     static bool host_memory_backend_can_be_deleted(Object *obj) {......}

     static void host_memory_backend_class_init(ObjectClass *oc, void 
*data) {
         ......
         oc->can_be_deleted = host_memory_backend_can_be_deleted;
     }
>
>>>   Alternatively...
>>>
>>>> But is a better way to do this to add error handling to
>>>> object_unparent API and override object_unparent for your device in
>>>> question to throw the error? Then your change doesn't have to be
>>>> limited to QMP.
>>> ... this is also a good choice.
>> Well, I have doubts about asking someone who's not ultimately familiar
>> with that code to refactor the API. For instance, we wouldn't want QEMU
>> on shutdown or in error cases refusing to unparent some object.
>>
>> Doing it at QMP level (ObjectClass/UserCreatable) seems safer, given
>> that Chun Yan's trivial block option fix ended up respinning a QemuOpts
>> refactoring some twenty times before it got merged.
>>
>> Regards,
>> Andreas
>>
>
>