[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: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl
Date: Mon, 23 Mar 2015 14:30:51 +0100

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.

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

reply via email to

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