On 03/14/2012 03:37 PM, Andreas Färber wrote:
Am 14.03.2012 21:37, schrieb Igor Mitsyanko:
On 13.03.2012 3:13 PM, Andreas Färber wrote:
I never heard anyone wanting to generalize reset so far. I don't think
it belongs into Object at least. Maybe DeviceState. Anthony? Paolo?
We can have a sp
Am 14.03.2012 21:37, schrieb Igor Mitsyanko:
> On 13.03.2012 3:13 PM, Andreas Färber wrote:
>
>> I never heard anyone wanting to generalize reset so far. I don't think
>> it belongs into Object at least. Maybe DeviceState. Anthony? Paolo?
>>
>
> We can have a special object for this, let's call i
On 03/14/2012 02:57 PM, Andreas Färber wrote:
Am 14.03.2012 20:48, schrieb Anthony Liguori:
On 03/14/2012 03:37 PM, Igor Mitsyanko wrote:
On 13.03.2012 3:13 PM, Andreas Färber wrote:
In SysBusDeviceClass etc. we use the specific object type, too.
Obviously my CPU is the first "new" QOM type,
Am 14.03.2012 20:48, schrieb Anthony Liguori:
> On 03/14/2012 03:37 PM, Igor Mitsyanko wrote:
>> On 13.03.2012 3:13 PM, Andreas Färber wrote:
>>
>>> In SysBusDeviceClass etc. we use the specific object type, too.
>>> Obviously my CPU is the first "new" QOM type, so we can go different
>>> ways if w
On 03/14/2012 03:37 PM, Igor Mitsyanko wrote:
On 13.03.2012 3:13 PM, Andreas Färber wrote:
In SysBusDeviceClass etc. we use the specific object type, too.
Obviously my CPU is the first "new" QOM type, so we can go different
ways if we want to. As long as it's a CPU-specific mechanism, using the
On 13.03.2012 3:13 PM, Andreas Färber wrote:
In SysBusDeviceClass etc. we use the specific object type, too.
Obviously my CPU is the first "new" QOM type, so we can go different
ways if we want to. As long as it's a CPU-specific mechanism, using the
specific type avoids some casts.
It will be
On 03/13/2012 07:20 AM, Paolo Bonzini wrote:
Il 13/03/2012 13:13, Andreas Färber ha scritto:
It will be easier to generalize later qdev code and not make special
case when adding cpus.
I never heard anyone wanting to generalize reset so far. I don't think
it belongs into Object at least. Maybe
Il 13/03/2012 13:13, Andreas Färber ha scritto:
> > It will be easier to generalize later qdev code and not make special
> > case when adding cpus.
>
> I never heard anyone wanting to generalize reset so far. I don't think
> it belongs into Object at least. Maybe DeviceState. Anthony? Paolo?
I be
Il 13/03/2012 13:53, Andreas Färber ha scritto:
>> > Methods should not take a superclass
>> > argument in general.
> So to clarify, this is pro CPUState?
Yes.
>>> >> This series is taking much too long to move forward (the QOM "steam"
>>> >> seems to be gone?) and I'm worried that introducing m
Am 13.03.2012 13:20, schrieb Paolo Bonzini:
> Il 13/03/2012 13:13, Andreas Färber ha scritto:
>>> It will be easier to generalize later qdev code and not make special
>>> case when adding cpus.
>>
>> I never heard anyone wanting to generalize reset so far. I don't think
>> it belongs into Object at
Am 12.03.2012 10:38, schrieb Igor Mammedov:
> On 03/10/2012 03:28 AM, Andreas Färber wrote:
>> Reintroduce CPUState as QOM object: It's abstract and derived directly
>> from TYPE_OBJECT for compatibility with the user emulators.
>> The identifier CPUState avoids conflicts between CPU() and the stru
On 03/10/2012 03:28 AM, Andreas Färber wrote:
Reintroduce CPUState as QOM object: It's abstract and derived directly
from TYPE_OBJECT for compatibility with the user emulators.
The identifier CPUState avoids conflicts between CPU() and the struct.
Introduce $(qom-twice-y) to build it separately
Reintroduce CPUState as QOM object: It's abstract and derived directly
from TYPE_OBJECT for compatibility with the user emulators.
The identifier CPUState avoids conflicts between CPU() and the struct.
Introduce $(qom-twice-y) to build it separately for system and for user
emulators.
Prepare a vi
13 matches
Mail list logo
