On Thu, 26 Mar 2015 11:07:27 +0100 Andreas Färber <[email protected]> wrote:
> Am 26.03.2015 um 11:05 schrieb Igor Mammedov: > > On Wed, 25 Mar 2015 23:47:46 +0800 > > Lin Ma <[email protected]> wrote: > >> 在 2015年03月23日 21:30, Igor Mammedov 写道: > >>> On Mon, 23 Mar 2015 14:13:07 +0100 > >>> Andreas Färber <[email protected]> wrote: > >>>> 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; > >> } > > > > all backends currently implement TYPE_USER_CREATABLE interface, > > so I'd rather extend UserCreatableClass with: > > > > bool can_be_deleted(UserCreatable *uc) > > > > callback, which backends could implement if needed. > > As for the implementation, could we simply look at Object::ref field? What value of ref, one would use to decide if deletion is possible? In generic case object can have ref > 1 but still be eligible for deleting via object-del. > > Regards, > Andreas >
