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

[Igor Mammedov]

On Wed, 25 Mar 2015 23:47:46 +0800
Lin Ma <address@hidden> wrote:

> 
> 在 2015年03月23日 21:30, Igor Mammedov 写道:
> > On Mon, 23 Mar 2015 14:13:07 +0100
> > Andreas Färber <address@hidden> 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;
>      }

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.

> >
> >>>   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
> >>
> >
> >
>