On Thu, Apr 30, 2015 at 06:51:43PM -0700, Peter Crosthwaite wrote:
> On Thu, Apr 30, 2015 at 12:19 PM, Eduardo Habkost <ehabk...@redhat.com> wrote:
> > This will provide a predictable path for the CPU objects, and a more
> > powerful alternative for the query-cpus QMP command, as now every QOM
> > property on CPU objects can be easily queried.
> >
> > Signed-off-by: Eduardo Habkost <ehabk...@redhat.com>
> > ---
> > Note that this doesn't replace any future topology enumeration
> > mechanisms we may choose to implement. It just replaces the existing
> > topology-unaware VCPU enumeration mechanism that is query-cpus.
> >
> > Reference to previous discussion:
> >
> > Date: Thu, 23 Apr 2015 10:17:36 -0300
> > From: Eduardo Habkost <ehabk...@redhat.com>
> > Subject: Re: [Qemu-devel] cpu modelling and hotplug (was: [PATCH RFC 0/4]
> > target-i386: PC socket/core/thread modeling, part 1)
> > Message-ID: <20150423131736.ga17...@thinpad.lan.raisama.net>
> > ---
> > exec.c | 16 ++++++++++++++++
> > include/qom/cpu.h | 3 +++
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/exec.c b/exec.c
> > index ae37b98..8bdfa65 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -519,6 +519,20 @@ void tcg_cpu_address_space_init(CPUState *cpu,
> > AddressSpace *as)
> > }
> > #endif
> >
> > +static void cpu_add_qom_link(CPUState *cpu)
> > +{
> > +#if !defined(CONFIG_USER_ONLY)
> > + Object *cobj = OBJECT(cpu);
> > + Object *cpu_container = container_get(OBJECT(current_machine),
> > "/cpus");
> > + char *path = g_strdup_printf("%d", cpu->cpu_index);
> > +
>
> This pathing is inconsistent with other arrayification efforts where
> we use ../foo[N].
> Do we need the container, can we just use /cpu[0], /cpu[1]?
Having a container looked simpler and cleaner than using cpu[0], cpu[1],
but I don't have a strong preference either way.
>
> > + cpu->self = cobj;
>
> Paolo's . property ideal is probably a winner, but see this discussion:
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg03557.html
>
> for how to create RYO links with open coded setters and getters.
> You could use the object itself as an opaque data and a trivial getter,
> no setter and then you can get rid of the self pointer.
True. But I will try to implement that in a generic way instead of
duplicating what's already implemented by object_get_link_property() and
object_resolve_link_property().
--
Eduardo
