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

[Alexey Kardashevskiy]

On 03/01/2014 02:57 AM, Andreas Färber wrote:
> 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.


I still do not entirely understand.

In this series, 1/6 is not really platform dependent but it is still for
Alex to review?

4/6 is about hw/net/spapr_llan.c which is not in hw/ppc/ so it does not
have to be Alex, no?

5/6 is about hw/ppc/spapr_vio.c which is in hw/ppc/ but it is rather QOM
than PPC - still, Alex?

If anyone RB'd or Ack'ed any of those, would it help? Would it help if I
split my patchsets into two (ppc and independent) and post them separately?


Or it always Alex and since I screwed up in the beginning (I know I did,
and I probably keep screwing, sorry for that), I am in very low priority
queue forever?



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



-- 
Alexey