[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class

From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH RFC v4 44/44] qom: Introduce CPU class
Date: Tue, 13 Mar 2012 13:53:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2

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 least. Maybe DeviceState. Anthony? Paolo?
> I believe long term we want CPUs to become a DeviceState.  For now, I
> think Andreas's prototype is fine.

I have prepared $(qom-obj-twice-y) to allow for:

    .parent = TYPE_DEVICE, // or TYPE_SYS_BUS_DEVICE
    .parent = TYPE_OBJECT,

So far it was not needed. :)

>  Methods should not take a superclass
> argument in general.

So to clarify, this is pro CPUState?

>> This series is taking much too long to move forward (the QOM "steam"
>> seems to be gone?) and I'm worried that introducing much more basic 
>> infrastructure will make review and applying even slower, cf. 
>> object_class_foreach_ordered()/_get_list().
> Agreed, this series looks more or less good (and mostly mechanical
> anyway).


>  Is it an RFC or what? :)  I wonder if reviewers are put off by
> the subject.

The implied RFC is, are we okay with reusing "CPUState" this way? Or
does someone - last call! - have a better identifier name?

Getting this series merged either means coordinating the PULL with a
maintainer so that no merge conflicts arise in-flight, or having the
maintainer re-run the commit-creating script himself.


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]