Re: [Qemu-devel] KVM call agenda for tuesday 31

[Andreas Färber]

Am 31.01.2012 14:59, schrieb Anthony Liguori:
> On 01/30/2012 05:41 PM, Andreas Färber wrote:
>> Am 30.01.2012 19:55, schrieb Juan Quintela:
>>> Please send in any agenda items you are interested in covering.
>>
>> QOM roadmap update:
>> * Series 3/4 is on the list.
>> ->  Please officially designate a merge date (Friday?).
>> ->  To make review sensible, I ask for a hard device freeze until merged.
>>     I.e., no new devices and no conflicting changes to DeviceInfo.
> 
> I put together a few slides to help this discussion:
> 
> http://www.codemonkey.ws/files/qom-overview.pdf

So basically we barely managed to walk through the slides without
getting into any of the requested agenda points. ;)

Re slide 5 I could use a more detailed explanation.
>From what I understand, ...
...types are registered through device_init() and module_call_init().
...classes are lazily initialized, eventually calling class_init.
...objects are instantiated through object_new[_with_type](), eventually
calling instance_init, by convention named initfn.
Up to here would be step 1.

How does the realize step 2 fit in technically? What types does this
apply to? All? Who calls realize? Where should class authors draw the
line between the two? (DOs and DON'Ts)

Then some conceptual questions:

How is inheritance (virtual methods in C++) supposed to work? (in my
case a reset function overwritten by each subclass) I've seen code in
series 3/4 calling methods the parent class defines in its header,
replacing the parent class' function pointer? Or should derived classes
store their parent's function pointer in a new ObjectClass and invoke
that? (i.e., are such parent functions supposed to be public or static)

When you talk about setting properties, does that refer to using the
property accessor functions moved to Object in series 3/4? Or should
qdev devices that currently expose only arbitrary setup functions
instead move their state to a header file so that it can be written into
by the parent? If so, should such headers reside in hw/ or include/qemu/?

Andreas

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