On 01/05/2015 13:59, Eduardo Habkost wrote:
>> I have a patch to add "." and ".." properties. You can use them to add
>> an alias to an object.
>
> What's the difference between a link and an alias to an object?
A (read-only) link adds a reference to the target, an alias doesn't.
Paolo
On Mon, May 04, 2015 at 05:53:59PM +0200, Paolo Bonzini wrote:
>
>
> On 04/05/2015 16:05, Eduardo Habkost wrote:
> > On Mon, May 04, 2015 at 03:19:32PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 04/05/2015 15:16, Igor Mammedov wrote:
> > Can we use the APIC id then? Perhaps wrapped with a
On 04/05/2015 16:05, Eduardo Habkost wrote:
> On Mon, May 04, 2015 at 03:19:32PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 04/05/2015 15:16, Igor Mammedov wrote:
> Can we use the APIC id then? Perhaps wrapped with a CPUState-level
> method get_stable_processor_id()?
>>> We have CPUClass->g
On Mon, May 04, 2015 at 03:19:32PM +0200, Paolo Bonzini wrote:
>
>
> On 04/05/2015 15:16, Igor Mammedov wrote:
> >> > Can we use the APIC id then? Perhaps wrapped with a CPUState-level
> >> > method get_stable_processor_id()?
> > We have CPUClass->get_arch_id() which results in APIC id for
> > t
On Mon, May 04, 2015 at 03:16:16PM +0200, Igor Mammedov wrote:
> On Mon, 04 May 2015 11:59:52 +0200
> Paolo Bonzini wrote:
>
> >
> >
> > On 04/05/2015 11:47, Igor Mammedov wrote:
> > > On Thu, 30 Apr 2015 16:19:07 -0300
> > > Eduardo Habkost wrote:
> > >
> > > > This will provide a predictabl
On 04/05/2015 15:16, Igor Mammedov wrote:
>> > Can we use the APIC id then? Perhaps wrapped with a CPUState-level
>> > method get_stable_processor_id()?
> We have CPUClass->get_arch_id() which results in APIC id for
> target-i386.
> But I'd rather see an arbitrary DEVICE->id as index/name, that
On Mon, 04 May 2015 11:59:52 +0200
Paolo Bonzini wrote:
>
>
> On 04/05/2015 11:47, Igor Mammedov wrote:
> > On Thu, 30 Apr 2015 16:19:07 -0300
> > Eduardo Habkost wrote:
> >
> > > This will provide a predictable path for the CPU objects, and a
> > > more powerful alternative for the query-cpu
On 04/05/2015 11:47, Igor Mammedov wrote:
> On Thu, 30 Apr 2015 16:19:07 -0300
> Eduardo Habkost 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
On Thu, 30 Apr 2015 16:19:07 -0300
Eduardo Habkost 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.
provided the way cpu_index is generated, path w
On Thu, Apr 30, 2015 at 06:51:43PM -0700, Peter Crosthwaite wrote:
> On Thu, Apr 30, 2015 at 12:19 PM, Eduardo Habkost 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 objec
On Thu, Apr 30, 2015 at 10:21:55PM +0200, Andreas Färber wrote:
> First I did not participate in that discussion, second nack to that
> self pointer. Please hold off on this until I'm back. Andreas
I suggested it 3 times before. The message mentioned in the patch has
pointers to the other 2 discus
On Thu, Apr 30, 2015 at 11:47:09PM +0200, Paolo Bonzini wrote:
>
>
> On 30/04/2015 22:21, Andreas Färber wrote:
> >>+cpu->self = cobj;
> >>+object_property_add_link(cpu_container, path, TYPE_CPU, &cpu->self,
> >>NULL,
> >>+ OBJ_PROP_LINK_UNREF_ON_RELEASE, &err
On Thu, Apr 30, 2015 at 2:47 PM, Paolo Bonzini wrote:
>
>
> On 30/04/2015 22:21, Andreas Färber wrote:
>>>+cpu->self = cobj;
>>>+object_property_add_link(cpu_container, path, TYPE_CPU, &cpu->self,
>>>NULL,
>>>+ OBJ_PROP_LINK_UNREF_ON_RELEASE, &error_abort);
>
>
On Thu, Apr 30, 2015 at 12:19 PM, Eduardo Habkost 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
> ---
> Note
On 30/04/2015 22:21, Andreas Färber wrote:
>>+cpu->self = cobj;
>>+object_property_add_link(cpu_container, path, TYPE_CPU, &cpu->self, NULL,
>>+ OBJ_PROP_LINK_UNREF_ON_RELEASE, &error_abort);
Doesn't this leak the CPU object?
I have a patch to add "." and "..
First I did not participate in that discussion, second nack to that self
pointer. Please hold off on this until I'm back. Andreas
Eduardo Habkost schrieb:
>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
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
---
Note that this doesn't replace any future topology enumeration
mechanisms we
17 matches
Mail list logo
