From: "Andreas Färber" <afaerber@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
Lin Ma <lma@suse.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Bruce Rogers <brogers@suse.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl
Date: Mon, 23 Mar 2015 14:13:07 +0100 [thread overview]
Message-ID: <55101163.6050201@suse.de> (raw)
In-Reply-To: <551001E3.3010304@redhat.com>
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.
> 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
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2015-03-23 13:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 10:10 [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl Lin Ma
2015-03-23 10:10 ` [Qemu-devel] [PATCH 2/2] memory-backend: Add can_be_deleted impl for ram-backend and file-backend Lin Ma
2015-03-23 10:36 ` [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl Peter Crosthwaite
2015-03-23 12:06 ` Paolo Bonzini
2015-03-23 13:13 ` Andreas Färber [this message]
2015-03-23 13:30 ` Igor Mammedov
2015-03-25 15:47 ` Lin Ma
2015-03-26 10:05 ` Igor Mammedov
2015-03-26 10:07 ` Andreas Färber
2015-03-26 10:29 ` Igor Mammedov
2015-03-26 13:37 ` Paolo Bonzini
2015-03-26 14:18 ` Igor Mammedov
2015-03-23 15:47 ` Lin Ma
2015-03-23 12:52 ` Andreas Färber
2015-03-23 15:25 ` Lin Ma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55101163.6050201@suse.de \
--to=afaerber@suse.de \
--cc=brogers@suse.com \
--cc=imammedo@redhat.com \
--cc=lma@suse.com \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).