From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKPjc-0003Up-6i for qemu-devel@nongnu.org; Mon, 03 Mar 2014 05:04:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKPjU-0008Jm-Qi for qemu-devel@nongnu.org; Mon, 03 Mar 2014 05:04:32 -0500 Received: from mail-pb0-f51.google.com ([209.85.160.51]:45378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKPjU-0008JU-Hy for qemu-devel@nongnu.org; Mon, 03 Mar 2014 05:04:24 -0500 Received: by mail-pb0-f51.google.com with SMTP id uo5so2894488pbc.10 for ; Mon, 03 Mar 2014 02:04:23 -0800 (PST) Message-ID: <531453A1.90801@ozlabs.ru> Date: Mon, 03 Mar 2014 21:04:17 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 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> <1393513484.31381.36.camel@localhost.localdomain> <5310A55B.7030602@ozlabs.ru> <5310A5BF.6030003@redhat.com> <5310A670.70304@ozlabs.ru> <5310B1E7.7090600@suse.de> In-Reply-To: <5310B1E7.7090600@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v5 3/6] vl: allow customizing the class of /machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Paolo Bonzini Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Alexander Graf , Marcel Apfelbaum 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