From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v4 00/15] uq/master: Introduce basic irqchip support Date: Thu, 15 Dec 2011 13:54:03 +0200 Message-ID: <4EE9DFDB.4050304@redhat.com> References: <20111212163725.GA32142@amt.cnet> <4EE63123.101@siemens.com> <4EE9CD09.3000901@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Lai Jiangshan , "kvm@vger.kernel.org" , "Michael S. Tsirkin" , Marcelo Tosatti , qemu-devel , Blue Swirl To: Jan Kiszka Return-path: In-Reply-To: <4EE9CD09.3000901@siemens.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 12/15/2011 12:33 PM, Jan Kiszka wrote: > >> > >> Any thoughts on the qemu-kvm merge plan? Sounds painful. > > > > Pain will be where the existing qemu-kvm extensions collide with these > > refactored upstream devices (backend/frontend split specifically). > > That's where we have to merge very carefully. Haven't tried this yet, > > will give it a spin tomorrow or so. > > Done yesterday, still seems to work fine. The result can be found at > > git://git.kiszka.org/qemu-kvm.git kvm-irqchip-merge > > The integration of the upstream irqchip patches was, as expected, not > that hard. But the merge of my earlier refactorings, the > backend/frontend split-up caused some efforts. > > I'm not sure what to do with that branch. We could either try to merge > it before pulling in an upstream version that includes the new irqchips. > But that won't work without manual conflict resolution as well. Or the > branch can serve as a reference for re-doing a merge later on. If we merge this before upstream, will the two sides end up equivalent? Sounds like it'll be pretty easy to resolve the conflicts if so. -- error compiling committee.c: too many arguments to function