On Fri, 17 Feb 2017 19:56:32 +0100
Igor Mammedov wrote:
> Some callers call CPUClass->parse_features manually to convert
> '-cpu cpufoo,featurestr' string to cpu type and featurestr
> into a set of global properties. And theni do controlled
> cpu creation with setting
On 21 February 2017 at 18:28, Eduardo Habkost wrote:
> Peter, do you think a wrapper for parse_features + object_new()
> would still be necessary to avoid too much code duplication on
> arm boards in 2.9, or can we live without it until we apply
> Igor's series (probaly after
On Tue, Feb 21, 2017 at 05:59:53PM +, Peter Maydell wrote:
> On 21 February 2017 at 16:18, Paolo Bonzini wrote:
> > On 21/02/2017 14:57, Peter Maydell wrote:
> >>> -global is a qdev thing.
> >> ...which reminds me to ask: is there any hope for unifying
> >> our properties
On Fri, Feb 17, 2017 at 07:56:32PM +0100, Igor Mammedov wrote:
>
> Some callers call CPUClass->parse_features manually to convert
> '-cpu cpufoo,featurestr' string to cpu type and featurestr
> into a set of global properties. And theni do controlled
> cpu creation with setting properties and
On Tue, Feb 21, 2017 at 04:48:49PM +0100, Markus Armbruster wrote:
> Peter Maydell writes:
>
> > On 21 February 2017 at 13:56, Markus Armbruster wrote:
> >> -global is a qdev thing.
> >
> > ...which reminds me to ask: is there any hope for unifying
>
On 21 February 2017 at 16:18, Paolo Bonzini wrote:
> On 21/02/2017 14:57, Peter Maydell wrote:
>>> -global is a qdev thing.
>> ...which reminds me to ask: is there any hope for unifying
>> our properties so we don't have both "qdev properties" and
>> "qom properties" or are
On 21/02/2017 14:57, Peter Maydell wrote:
>> -global is a qdev thing.
> ...which reminds me to ask: is there any hope for unifying
> our properties so we don't have both "qdev properties" and
> "qom properties" or are we doomed to two distinct sets of
> APIs forever?
We already have one set of
Peter Maydell writes:
> On 21 February 2017 at 13:56, Markus Armbruster wrote:
>> -global is a qdev thing.
>
> ...which reminds me to ask: is there any hope for unifying
> our properties so we don't have both "qdev properties" and
> "qom properties"
On 21 February 2017 at 13:56, Markus Armbruster wrote:
> -global is a qdev thing.
...which reminds me to ask: is there any hope for unifying
our properties so we don't have both "qdev properties" and
"qom properties" or are we doomed to two distinct sets of
APIs forever?
Peter Maydell writes:
> On 21 February 2017 at 12:44, Igor Mammedov wrote:
>> If we are to ditch legacy approach,
>> It would be cleaner for SoC to have fixed/unconfigurable
>> CPU type and each SoC being modeled as a separate
>> QOM object/type
On Mon, 20 Feb 2017 19:11:00 +
Peter Maydell wrote:
> On 20 February 2017 at 18:55, Igor Mammedov wrote:
> > Peter Maydell wrote:
[...]
>
> > its sole user netduino2 board has cpu_model hardcodded
> > at board
On 21 February 2017 at 12:44, Igor Mammedov wrote:
> If we are to ditch legacy approach,
> It would be cleaner for SoC to have fixed/unconfigurable
> CPU type and each SoC being modeled as a separate
> QOM object/type that would instantiate CPU directly
> with QOM style,
On 20 February 2017 at 18:55, Igor Mammedov wrote:
> Peter Maydell wrote:
>> This API seems a little awkward for the SoC case, where
>> the board model doesn't actually know what the default
>> CPU model or the valid CPU models are, because it just
On Fri, 17 Feb 2017 19:05:20 +
Peter Maydell wrote:
> On 17 February 2017 at 18:56, Igor Mammedov wrote:
> > Some callers call CPUClass->parse_features manually to convert
> > '-cpu cpufoo,featurestr' string to cpu type and featurestr
> > into
On 17 February 2017 at 18:56, Igor Mammedov wrote:
> Some callers call CPUClass->parse_features manually to convert
> '-cpu cpufoo,featurestr' string to cpu type and featurestr
> into a set of global properties. And theni do controlled
> cpu creation with setting properties
Some callers call CPUClass->parse_features manually to convert
'-cpu cpufoo,featurestr' string to cpu type and featurestr
into a set of global properties. And theni do controlled
cpu creation with setting properties and completing it with realize.
That's a lot of code duplication as they are
16 matches
Mail list logo