[Top][All Lists]

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

Re: [Qemu-devel] [RFC] QEMU Object Model status/merge plan

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] QEMU Object Model status/merge plan
Date: Tue, 13 Dec 2011 07:43:26 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/13/2011 05:35 AM, Stefan Hajnoczi wrote:
On Mon, Dec 12, 2011 at 7:36 PM, Anthony Liguori<address@hidden>  wrote:
I choose the serial device to showcase what we'll eventually be able to do.
  The three relevant files are:




I'm not sure I understand how init functions are called for derived

There are three types of init functions:


This lives in (TypeInit) and is called when a class is first created for a type. It is only ever called once. Within this function, you should override any methods in your base classes and set default implementations for any methods you implement.


This is the constructor for a type. It is called when an object is created and chained such that the base class constructors are called first to initialize the object.


This is the qdev initialize function. It is called sometime after properties are set and before the guest starts running for the first time. Long term, I plan to change this to "DeviceState::realize" and remove explicit calls to qdev_init() in favor of a propagated realize signal.

But for now, I'm trying to avoid churn in the tree.

On one hand mm-serial.c calls its superclass init function,
on the other hand isa-bus.c:isa_qdev_init() calls an init function
that its child class must provide.  One is calling its parent, the
other is calling its child.  Is there a consistent way of doing this
and what did I miss :)?

Yes, this is all DeviceState::init. This is what is called when you invoke qdev_init(). Right now, you have to do it explicitly and in the case of composition, since the device is creating another device, it must be the one that calls qdev_init() for that device.

In the case of inheritance, we're just calling the superclass's init function because DeviceState::init is just a normal method so we have to explicitly chain it if we want that behavior.


Anthony Liguori


reply via email to

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