[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: Andreas Färber
Subject: Re: [Qemu-ppc] [PATCH v5 3/6] vl: allow customizing the class of /machine
Date: Fri, 28 Feb 2014 16:57:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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,
>>>>>>>> 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
>>> 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.

>>  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.

> Ok. Understood. Wait and rebase and repost and repeat. Ok ;) Thanks.

A problem here and elsewhere in your series is that it's a mix of
changes to generic code and ppc code, with the cover letter indicating
it's a ppc series. ppc series I usually leave for Alex to review, and
Alex is on travels for a few more weeks to come.

So for those of your patches that I'm aware of - -cpu, FWPathProvider
and this /machine most likely I will pick up the generic parts for the
QOM devices tree after having tested some more corner cases, to get them
into 2.0.

For ppc-next I know that Alex is strictly running a virt-test testsuite
and whenever something in his queue is broken somewhere, the whole queue
gets delayed until the fault is found and fixed or dropped.


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

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