All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Andreas Färber" <afaerber@suse.de>
Cc: quintela@redhat.com,
	Developers qemu-devel <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7
Date: Tue, 07 Feb 2012 12:01:16 -0600	[thread overview]
Message-ID: <4F3166EC.7000002@codemonkey.ws> (raw)
In-Reply-To: <4F312AFC.6020908@suse.de>

On 02/07/2012 07:45 AM, Andreas Färber wrote:
> Am 06.02.2012 20:25, schrieb Juan Quintela:
>> Please send in any agenda items you are interested in covering.
>
> I had some follow-up questions to the last call that remained
> unanswered. We don't really need a call for that though, email is fine.
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
>
> How is the realize step (DeviceState::init) supposed to translate to
> Object-derived classes (e.g., CPU) and where to draw the line between
> initfn and realize.

Realize probably should be folded into Object or some intermediate object.

The idea is that there will be a realized boolean property.  When the level 
changes, it will invoke a realize() or unrealize() method depending on the 
direction.  DeviceState will implement realize() and invoke init().  For 
unrealize(), it will invoke exit().

> For virtual methods Anthony outlined the intended scheme here:
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00622.html
> (Derived classes should save the parent's function pointer in their own
> Class and initialize it from the parent class' function pointer.)
>
> Another topic that can be answered by email is what the time planning
> for the 4th QOM series looks like. Are there things that developers of
> new devices should keep in mind / start doing differently wrt SysBus?

I think I answered this elsewhere.

Regards,

ANthony Liguori

> Andreas
>


WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Developers qemu-devel <qemu-devel@nongnu.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	quintela@redhat.com
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7
Date: Tue, 07 Feb 2012 12:01:16 -0600	[thread overview]
Message-ID: <4F3166EC.7000002@codemonkey.ws> (raw)
In-Reply-To: <4F312AFC.6020908@suse.de>

On 02/07/2012 07:45 AM, Andreas Färber wrote:
> Am 06.02.2012 20:25, schrieb Juan Quintela:
>> Please send in any agenda items you are interested in covering.
>
> I had some follow-up questions to the last call that remained
> unanswered. We don't really need a call for that though, email is fine.
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
>
> How is the realize step (DeviceState::init) supposed to translate to
> Object-derived classes (e.g., CPU) and where to draw the line between
> initfn and realize.

Realize probably should be folded into Object or some intermediate object.

The idea is that there will be a realized boolean property.  When the level 
changes, it will invoke a realize() or unrealize() method depending on the 
direction.  DeviceState will implement realize() and invoke init().  For 
unrealize(), it will invoke exit().

> For virtual methods Anthony outlined the intended scheme here:
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00622.html
> (Derived classes should save the parent's function pointer in their own
> Class and initialize it from the parent class' function pointer.)
>
> Another topic that can be answered by email is what the time planning
> for the 4th QOM series looks like. Are there things that developers of
> new devices should keep in mind / start doing differently wrt SysBus?

I think I answered this elsewhere.

Regards,

ANthony Liguori

> Andreas
>

  parent reply	other threads:[~2012-02-07 18:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-06 19:25 KVM call agenda for Tuesday 7 Juan Quintela
2012-02-06 19:25 ` [Qemu-devel] " Juan Quintela
2012-02-07 13:45 ` Andreas Färber
2012-02-07 13:45   ` Andreas Färber
2012-02-07 13:52   ` Paolo Bonzini
2012-02-07 13:52     ` Paolo Bonzini
2012-02-07 14:56     ` Anthony Liguori
2012-02-07 14:56       ` Anthony Liguori
2012-02-07 15:21       ` Paolo Bonzini
2012-02-07 15:21         ` Paolo Bonzini
2012-02-07 16:24         ` Anthony Liguori
2012-02-07 16:24           ` Anthony Liguori
2012-02-07 16:27           ` Paolo Bonzini
2012-02-07 16:27             ` Paolo Bonzini
2012-02-07 16:33             ` Anthony Liguori
2012-02-07 16:33               ` Anthony Liguori
2012-02-07 16:40               ` Peter Maydell
2012-02-07 16:40                 ` Peter Maydell
2012-02-07 17:04               ` Paolo Bonzini
2012-02-07 17:04                 ` Paolo Bonzini
2012-02-07 16:41         ` Andreas Färber
2012-02-07 16:41           ` Andreas Färber
2012-02-07 16:53           ` Anthony Liguori
2012-02-07 16:53             ` Anthony Liguori
2012-02-07 18:01   ` Anthony Liguori [this message]
2012-02-07 18:01     ` Anthony Liguori
2012-02-07 18:17     ` Andreas Färber
2012-02-07 18:17       ` Andreas Färber
2012-02-07 19:06       ` Anthony Liguori
2012-02-07 14:23 ` Juan Quintela
2012-02-07 14:23   ` [Qemu-devel] " Juan Quintela

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=4F3166EC.7000002@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=afaerber@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.