[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH v5 3/6] vl: allow customizing the class of /machin

From: Paolo Bonzini
Subject: Re: [Qemu-ppc] [PATCH v5 3/6] vl: allow customizing the class of /machine
Date: Fri, 28 Feb 2014 17:35:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Il 28/02/2014 16:57, Andreas Färber ha scritto:
Am 28.02.2014 16:08, schrieb Alexey Kardashevskiy:
On 03/01/2014 02:05 AM, Paolo Bonzini wrote:
Il 28/02/2014 16:03, Alexey Kardashevskiy ha scritto:
On 02/28/2014 02:04 AM, Marcel Apfelbaum wrote:
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,
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

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.

What is the outcome of this discussion for the patches I posted? Do I have
to wait till you finish that machine properties rework and repost or...?

Your patches are fine.

I disputed that in this case and asked for a code change in qdev code
either not creating the container and/or asserting that that code path
is not hit.

You're right. The outcome of the discussion was not that the patches are fine, but rather that they need not be blocked by Marcel's work. I was too terse/vague/wrong---sorry.

 Who gets in first, wins.  The other, rebases. :)

Negative, qemu.git is not a tombola. If there's known issues they need
to be fixed before merging. But yes, when there's two "good" approaches
then it's a matter of merge order, which ideally should involve
communication rather than competition among maintainers. Because the
pull that does not apply then gets bounced by Peter.

Right, hence the smiley. People that submit patches should be aware of conflicting series and tell the maintainers about it.


reply via email to

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