From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43752)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <marcel.a@redhat.com>) id 1WJ2Vz-0005Fq-6t
	for qemu-devel@nongnu.org; Thu, 27 Feb 2014 10:04:53 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <marcel.a@redhat.com>) id 1WJ2Vt-0006wO-8U
	for qemu-devel@nongnu.org; Thu, 27 Feb 2014 10:04:47 -0500
Message-ID: <1393513484.31381.36.camel@localhost.localdomain>
From: Marcel Apfelbaum <marcel.a@redhat.com>
Date: Thu, 27 Feb 2014 17:04:44 +0200
In-Reply-To: <530F52C5.3080209@redhat.com>
References: <1392904246-15575-1-git-send-email-aik@ozlabs.ru>
	<1392904246-15575-4-git-send-email-aik@ozlabs.ru>
	<530609F9.1060105@redhat.com> <530F14C2.2050808@suse.de>
	<530F1670.2070701@redhat.com>
	<1393511950.31381.34.camel@localhost.localdomain>
	<530F52C5.3080209@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of
	/machine
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Alexander Graf <agraf@suse.de>, Andreas =?ISO-8859-1?Q?F=E4rber?= <afaerber@suse.de>

On Thu, 2014-02-27 at 15:59 +0100, Paolo Bonzini wrote:
> Il 27/02/2014 15:39, Marcel Apfelbaum ha scritto:
> >> >
> >> > Each of them highlights one of the two aspects that, in my opinion, make
> >> > QOM interesting (respectively, unification of interfaces and the
> >> > containment tree).
> > I was planning to tackle the replacement of the machine from a container
> > to an actual object too, however this patch conflicts with my
> > series because I already have a QOM Machine object created *always*
> > and this patch adds another object *sometimes*.
> >
> > Is this patch's functionality in use yet? Any idea how to merge those ideas?
> 
> pseries simply wants to make /machine implement the FWPathProvider 
> interface.  As long as you have a way for boards to specify a TypeInfo 
> for /machine, this patch will not get in the way.
Thanks Paolo! I'll be aware not to brake this functionality.
Marcel

> 
> Paolo