qemu-ppc
[Top][All Lists]
Advanced

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

Regards,
Andreas

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