[Top][All Lists]

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

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

From: Lin Ma
Subject: Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl
Date: Wed, 25 Mar 2015 23:47:46 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

在 2015年03月23日 21:30, Igor Mammedov 写道:
On Mon, 23 Mar 2015 14:13:07 +0100
Andreas Färber <address@hidden> wrote:


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.

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;


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.


reply via email to

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