Re: [Qemu-devel] [PATCH v2] qom: Introduce object_realize_nofail()

[Andreas Färber]

Am 13.04.2012 00:09, schrieb Anthony Liguori:
> On 04/12/2012 05:02 PM, Andreas Färber wrote:
>> Am 12.04.2012 23:24, schrieb Anthony Liguori:
>>> I guess I don't understand what the problem we're trying to solve is.
>>>
>>> Why can't we introduce an Object::realize() and just have it not
>>> automatically call DeviceState::init()?  That way we have a way to
>>> clearly indicate whether a device needs to be refactored.
>>
>> That would be perfect, but means we should drop Paolo's 23/24 v2 and due
>> to legacy compatibility I do need either object_realize_nofail() or an
>> inline version thereof.
> 
> I don't understand which "legacy compatibility" you're referring to. 
> Can you be specific?

hw/sh7750.c is creating all kinds of realize-unaware SysBus devices that
are virtually unmaintained, none of you will have reviewed or updated
them to match some shiny new realize model.

My current work is CPU modelling, not redoing devices I have no clue
about in 14 targets. There's a non-qdev struct with a cpu field that I'm
updating from CPUSH4State to QOM SuperHCPU and, for inspecting and
testing and evaluating general SoC modelling that was calling for a
child<SuperHCPU> property of a QOM object. And unfortunately that object
has a user-specifiable CPU (and an unresponsive maintainer, but this is
intentionially a test run in a part of code where conflicts were
unlikely to occur, as opposed to target-arm, so I don't complain). So
either I need a property that decides on what parameter to pass to
cpu_init() or I need SoC types for each CPU type and in that case the
mentioned convenience issue of how to tweak CPU properties on a SoC
object comes into play. (We surely do not want the user to iterate over
the DAG searching for CPUs and setting properties on each one when -cpu
does that for all cores in an easy and central way, that would be a step
backwards.)

We can surely postpone that part of my sh4 series (leaving out
subclasses and leaving the SoC non-qdev), working on that right now, but
that doesn't solve the fundamental issue of the Paolo-Anthony realize
model that I'm trying to point out with this example, apparently in vein. :(

Andreas

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