All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Igor Mammedov <imammedo@redhat.com>, Lin Ma <lma@suse.com>
Cc: pbonzini@redhat.com, peter.crosthwaite@xilinx.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] object: Add can_be_deleted callback to TypeInfo and TypeImpl
Date: Thu, 26 Mar 2015 11:07:27 +0100	[thread overview]
Message-ID: <5513DA5F.6060906@suse.de> (raw)
In-Reply-To: <20150326110529.5f158af3@nial.brq.redhat.com>

Am 26.03.2015 um 11:05 schrieb Igor Mammedov:
> On Wed, 25 Mar 2015 23:47:46 +0800
> Lin Ma <lma@suse.com> wrote:
>> 在 2015年03月23日 21:30, Igor Mammedov 写道:
>>> On Mon, 23 Mar 2015 14:13:07 +0100
>>> Andreas Färber <afaerber@suse.de> 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?

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)

  reply	other threads:[~2015-03-26 10:07 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
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 [this message]
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=5513DA5F.6060906@suse.de \
    --to=afaerber@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.