From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "Andreas Färber" <afaerber@suse.de>,
"Anthony Liguori" <anthony@codemonkey.ws>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-next v2 01/22] object: Add OBJECT_GET_PARENT_CLASS() macro
Date: Wed, 07 Aug 2013 15:38:59 +1000 [thread overview]
Message-ID: <5201DD73.1080001@ozlabs.ru> (raw)
In-Reply-To: <CAEgOgz7i8CxZAdyh6xD7dWZ06OBhggsMkFD2DCrc5TpzZwWzPA@mail.gmail.com>
On 08/07/2013 02:20 PM, Peter Crosthwaite wrote:
> Hi,
>
> On Wed, Aug 7, 2013 at 1:36 PM, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>> On 08/06/2013 06:33 PM, Andreas Färber wrote:
>>> Am 06.08.2013 07:54, schrieb Alexey Kardashevskiy:
>>>> On 08/01/2013 12:17 PM, Andreas Färber wrote:
>>>>> The object argument is currently unused and may be used to optimize the
>>>>> class lookup when needed.
>>>>>
>>>>> Inspired-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>> ---
>>>>> include/qom/object.h | 10 ++++++++++
>>>>> 1 file changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/include/qom/object.h b/include/qom/object.h
>>>>> index 23fc048..a8e71dc 100644
>>>>> --- a/include/qom/object.h
>>>>> +++ b/include/qom/object.h
>>>>> @@ -511,6 +511,16 @@ struct TypeInfo
>>>>> OBJECT_CLASS_CHECK(class, object_get_class(OBJECT(obj)), name)
>>>>>
>>>>> /**
>>>>> + * OBJECT_GET_PARENT_CLASS:
>>>>> + * @obj: The object to obtain the parent class for.
>>>>> + * @name: The QOM typename of @obj.
>>>>> + *
>>>>> + * Returns the parent class for a given object of a specific class.
>>>>> + */
>>>>> +#define OBJECT_GET_PARENT_CLASS(obj, name) \
>>>>> + object_class_get_parent(object_class_by_name(name))
>>>>> +
>>>>> +/**
>>>>> * InterfaceInfo:
>>>>> * @type: The name of the interface.
>>>>> *
>>>>>
>>>>
>>>> Has anyone ever tried to use this macro?
>>>
>>> Since you're asking me, obviously later in this virtio series it's used
>>> and in the IndustryPack series as well.
>>>
>>> I'm not aware of anyone else having used it yet - I'm still waiting for
>>> review feedback from Peter Cr. and/or Anthony (or you!) before I put it
>>> on qom-next.
>>
>>
>> Still do not understand what "obj" is doing here.
>
> The object is currently where cast cache optimizations are
> implemented. So having a handle to it is useful if ever these
> get-parent operations end up in fast paths and we need to do one of
> Anthony's caching tricks.
>
>> This what I would suggest:
>>
>> #define OBJECT_GET_PARENT_CLASS(obj, name) \
>> object_class_get_parent(OBJECT_GET_CLASS(ObjectClass, (obj), (name)))
>>
>
> You have changed the semantic from what Andreas has implemented. This
> will always return the parent of the concrete class, whereas to solve
> the save-override-call problem you need to get the parent of abstract
> level that is overriding the function (not always the concrete class).
>
>> @name here is just to make sure we are at the right level of the class
>> hierarchy.
>>
>
> Its @name that is actually important. Its more than just assertive,
> variation of @name for the same object will and should return
> different results (aside from just checking). The demonstrative case
> for this requirement is TYPE_ARM_CPU, which has a realize fn that
> needs to call the parent version as implemented by TYPE_CPU. ARM CPUs
> however have a whole bunch of concrete classes inheriting from
> TYPE_ARM_CPU. So using your macro, TYPE_ARM_CPU's realize fn will only
> be able to get a handle to the parent of the concrete class (i.e.
> TYPE_ARM_CPU)
This is what I would really (really) expect in this situation.
> and not the parent of TYPE_ARM_CPU (i.e. TYPE_CPU) as
> intended.
Oh. Then it is not get_parent() at all, this is get_grand_parent.
realize() of TYPE_ARM_CPU_CORTEXTA9 (example) calls its parent
(TYPE_ARM_CPU) realize() and that realize() calls its parent (TYPE_CPU)
realize.
It some level (for example, TYPE_ARM_CPU) does not want to implement
realize(), then pointer to realize() from the upper class should be copied
into TYPE_ARM_CPU's type info struct. class_init() callbacks are called for
every class in the chain, so if some class_init() won't write to realize()
pointer, it should be what the parent initialized it to, no?
What do I miss here?
> Regards,
> Peter
>
>> And use it like this:
>>
>> static void xics_kvm_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
>> {
>> XICSStateClass *xsc = XICS_COMMON_CLASS(
>> OBJECT_GET_PARENT_CLASS(OBJECT(icp), TYPE_KVM_XICS));
>> ...
>>
>> Here both source and destination classes are checked, everyone must be happy :)
>>
>>
>> --
>> Alexey
>>
--
Alexey
next prev parent reply other threads:[~2013-08-07 5:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 2:17 [Qemu-devel] [PATCH for-next v2 00/22] QOM realize for virtio Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 01/22] object: Add OBJECT_GET_PARENT_CLASS() macro Andreas Färber
2013-08-06 5:54 ` Alexey Kardashevskiy
2013-08-06 8:33 ` Andreas Färber
2013-08-07 3:36 ` Alexey Kardashevskiy
2013-08-07 4:20 ` Peter Crosthwaite
2013-08-07 5:38 ` Alexey Kardashevskiy [this message]
2013-08-07 5:45 ` Andreas Färber
2013-08-07 5:53 ` Alexey Kardashevskiy
2013-08-07 6:10 ` Peter Crosthwaite
2013-08-07 6:38 ` Alexey Kardashevskiy
2013-08-07 6:28 ` Andreas Färber
2013-08-07 5:58 ` Andreas Färber
2013-08-07 1:50 ` Peter Crosthwaite
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 02/22] virtio-console: Use exitfn for virtserialport, too Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 03/22] virtio-9p-device: Avoid freeing uninitialized memory Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 04/22] virtio-blk-dataplane: Improve error reporting Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 05/22] virtio: Allow NULL VirtioDeviceClass::init hook Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 06/22] virtio-9p: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 07/22] virtio-9p: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 08/22] virtio-blk: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 09/22] virtio-blk: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 10/22] virtio-serial: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 11/22] virtio-serial: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 12/22] virtio-net: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 13/22] virtio-net: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 14/22] virtio-balloon: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 15/22] virtio-balloon: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 16/22] virtio-rng: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 17/22] virtio-rng: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 18/22] virtio-scsi: QOM realize preparations Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 19/22] virtio-scsi: Convert to QOM realize Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 20/22] virtio: Convert VirtioDevice " Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH for-next v2 21/22] virtio: Unrealize parent Andreas Färber
2013-08-01 2:17 ` [Qemu-devel] [PATCH RFC for-next v2 22/22] virtio-scsi: Convert virtio_scsi_common_[un]realize to QOM realize Andreas Färber
2013-08-01 2:22 ` [Qemu-devel] [PATCH for-next v2 00/22] QOM realize for virtio Andreas Färber
2013-08-14 16:28 ` Anthony Liguori
2013-08-14 16:49 ` Andreas Färber
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=5201DD73.1080001@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--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).