qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"KVM devel mailing list" <kvm@vger.kernel.org>,
	陳韋任 <chenwj@iis.sinica.edu.tw>,
	quintela@redhat.com, "Stefan Weil" <sw@weilnetz.de>,
	"Developers qemu-devel" <qemu-devel@nongnu.org>,
	"Alex Bradbury" <asb@asbradbury.org>
Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31
Date: Tue, 31 Jan 2012 17:23:24 +0100	[thread overview]
Message-ID: <4F28157C.1000609@suse.de> (raw)
In-Reply-To: <4F27F3DB.2040400@codemonkey.ws>

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

      parent reply	other threads:[~2012-01-31 16:25 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 18:55 [Qemu-devel] KVM call agenda for tuesday 31 Juan Quintela
2012-01-30 23:41 ` Andreas Färber
2012-01-30 23:53   ` Anthony Liguori
2012-01-31  0:37     ` Alexander Graf
2012-01-31 10:49     ` Lluís Vilanova
2012-01-31 13:15     ` Andreas Färber
2012-01-31 14:01       ` Mitsyanko Igor
2012-08-08 16:25         ` Andreas Färber
2012-08-09  7:53           ` Igor Mitsyanko
2012-01-31 14:12       ` Anthony Liguori
2012-01-31 15:04         ` Michael S. Tsirkin
2012-01-31 15:10           ` Michael S. Tsirkin
2012-01-31 15:12         ` Paolo Bonzini
2012-02-09 22:23       ` Peter Maydell
2012-02-09 22:37         ` Anthony Liguori
2012-02-09 22:42           ` Peter Maydell
2012-02-09 23:17           ` Andreas Färber
2012-02-09 23:21             ` Alexander Graf
2012-02-21 15:33         ` Peter Maydell
2012-02-22  8:06           ` Mitsyanko Igor
2012-03-05 13:38           ` Igor Mitsyanko
2012-03-05 14:13             ` Avi Kivity
2012-03-05 14:37               ` Igor Mitsyanko
2012-03-05 15:10                 ` Avi Kivity
2012-03-05 15:15                   ` Anthony Liguori
2012-03-05 15:17                     ` Avi Kivity
2012-03-05 18:53                       ` Blue Swirl
2012-03-05 20:58                         ` malc
2012-03-05 15:20                   ` Peter Maydell
2012-03-05 15:21                     ` Avi Kivity
2012-03-05 15:27                       ` Peter Maydell
2012-03-05 15:43                   ` Andreas Färber
2012-03-05 15:47                     ` Avi Kivity
2012-03-05 15:50                     ` Peter Maydell
2012-03-05 17:27                       ` Avi Kivity
2012-03-12  9:43           ` Igor Mitsyanko
2012-03-14  9:30             ` Igor Mitsyanko
2012-03-14 10:16             ` Avi Kivity
2012-01-31 13:59   ` Anthony Liguori
2012-01-31 14:09     ` Avi Kivity
2012-01-31 14:17       ` Anthony Liguori
2012-01-31 14:44         ` Avi Kivity
2012-01-31 16:23     ` Andreas Färber [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F28157C.1000609@suse.de \
    --to=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=asb@asbradbury.org \
    --cc=chenwj@iis.sinica.edu.tw \
    --cc=kvm@vger.kernel.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=sw@weilnetz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).