From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a5d:6089:0:0:0:0:0 with SMTP id w9csp1922846wrt; Wed, 21 Nov 2018 06:15:57 -0800 (PST) X-Google-Smtp-Source: AFSGD/XfuFQQMTuiraxkalL8Wozk9CURqERrA3lsMuSY0VturBbz72vOpcuN92BZm6+EbzKgJExQ X-Received: by 2002:a25:be12:: with SMTP id h18-v6mr6190526ybk.80.1542809757571; Wed, 21 Nov 2018 06:15:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542809757; cv=none; d=google.com; s=arc-20160816; b=0MZbtTTZTx5RUvQjvxBt4MOo2LJNF1aaxxidINUTHY8BhNKiOOuISDxXuCUM5RYsY6 B13Ws2CGiegKDcJwmVbBU2IuAxbv/wkIF4T2d9/NWwiS6zEgplsRElb7u7pAzYFmPSTL XstXkKaj/o2QTaav4qe55GRCM3ALPwb0sLgBgsuOGa1wGZyckCNSE65LxPAx+Q+Sr90G Br1yUTMTCDp9vAFVguC6nhPNaxJKL112ZCMFvrP/p+Xlib9C5ED2SgeUJ/Fz0sj5Oqoh 9jaH4hrlY5FxacCXD3fIpwhTm6fp0VyJKIyCjSkxqASUQgDeRrQQAZZbgZ0eJ5Fy8BLb gknQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject :content-transfer-encoding:mime-version:references:in-reply-to :message-id:to:from:date; bh=dDPruojQKkAqLnvjAphCKZP6a7fNV3+pI/6fp8f4Fuw=; b=bs2j5wjiumP8szjw3Easb1B7LFCyyMs/H1udTT6Ptd0gnUxS+byVEQMdGxuBC8qAEK 0H8j6yoBayfBWBe1F9E12MArSUE4HVOrYHJBW7GaYdTy3fsmzSJx+JGqGzlgi9AEPwdp 7KWFZH5XvmGO3Mzo7O8GPvMX45ZHqzQ3BMLbmx+s36UmPgN+xVq04wrvRyoOd4YvhaFy 2YdcHlxg59MAnhgkmsPJpUszoBIDPvjiMd4z0FRbVurmBB7Uqfcvq+LoG9DZZAmIgSEh I8TPqXKT2DhAmWSGfKm6+qHMw9VZxtDCmEXSRyLtVijHSoE/RsqbFPi341MSrOFopeFB iUCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [2001:4830:134:3::11]) by mx.google.com with ESMTPS id l78si10239122ywe.174.2018.11.21.06.15.57 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 21 Nov 2018 06:15:57 -0800 (PST) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) client-ip=2001:4830:134:3::11; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 2001:4830:134:3::11 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from localhost ([::1]:39411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPTIL-0000lG-2P for alex.bennee@linaro.org; Wed, 21 Nov 2018 09:15:57 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPTIF-0000lB-06 for qemu-arm@nongnu.org; Wed, 21 Nov 2018 09:15:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPTIB-0001s6-TO for qemu-arm@nongnu.org; Wed, 21 Nov 2018 09:15:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53342) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gPTIB-0001rZ-Lz; Wed, 21 Nov 2018 09:15:47 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9FED7C068BE1; Wed, 21 Nov 2018 14:15:46 +0000 (UTC) Received: from localhost (unknown [10.43.2.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8FF4B605AF; Wed, 21 Nov 2018 14:15:33 +0000 (UTC) Date: Wed, 21 Nov 2018 15:15:26 +0100 From: Igor Mammedov To: "Michael S. Tsirkin" Message-ID: <20181121151526.5785b43f@redhat.com> In-Reply-To: <20181121072954-mutt-send-email-mst@kernel.org> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181116172919.43f3e27d@redhat.com> <20181119163110.2f357f40@redhat.com> <20181121072954-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 21 Nov 2018 14:15:46 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Samuel Ortiz , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , Richard Henderson , Eduardo Habkost Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: KJzoya/FQMMu On Wed, 21 Nov 2018 07:35:47 -0500 "Michael S. Tsirkin" wrote: > On Mon, Nov 19, 2018 at 04:31:10PM +0100, Igor Mammedov wrote: > > On Fri, 16 Nov 2018 17:37:54 +0100 > > Paolo Bonzini wrote: > > > > > On 16/11/18 17:29, Igor Mammedov wrote: > > > > General suggestions for this series: > > > > 1. Preferably don't do multiple changes within a patch > > > > neither post huge patches (unless it's pure code movement). > > > > (it's easy to squash patches later it necessary) > > > > 2. Start small, pick a table generalize it and send as > > > > one small patchset. Tables are often independent > > > > and it's much easier on both author/reviewer to agree upon > > > > changes and rewrite it if necessary. > > > > > > How would that be done? This series is on the bigger side, agreed, but > > > most of it is really just code movement. It's a starting point, having > > > a generic ACPI library is way beyond what this is trying to do. > > I've tried to give suggestions how to restructure series > > on per patch basis. In my opinion it quite possible to split > > series in several smaller ones and it should really help with > > making series cleaner and easier/faster to review/amend/merge > > vs what we have in v5. > > (it's more frustrating to rework large series vs smaller one) > > > > If something isn't clear, it's easy to reach out to me here > > or directly (email/irc/github) for clarification/feed back. > > I assume the #1 goal is to add reduced HW support. So another > option to speed up merging is to just go ahead and duplicate a > bunch of code e.g. in pc_virt.c acpi/reduced.c or in any other > file. > This way it might be easier to see what's common code and what isn't. > And I think offline Igor said he might prefer that way. Right Igor? You mean probably 'x86 reduced hw' support. That's was what I've already suggested for PCI AML code during patch review. Just don't call it generic when it's not and place code in hw/i386/ directory beside acpi-build.c. It might apply to some other tables (i.e. complex cases). On per patch review I gave suggestions how to amend series to make it acceptable without doing complex refactoring and pointed out places we probably shouldn't refactor now and just duplicate as it's too complex or not clear how to generalize it yet. Problem with duplication is that a random contributor is not around to clean code up after a feature is merged and we end up with a bunch of messy code. A word to the contributors, Don't do refactoring in silence, keep discussing approaches here, suggest alternatives. That way it's easier to reach a compromise and merge it with less iterations. And if you do split it in smaller parts, the process should go even faster. I'll sent a small RSDP refactoring series for reference. > > > Paolo > > > > > > > 3. when you think about refactoring acpi into a generic API > > > > think about it as routines that go into a separate library > > > > (pure acpi spec code) and qemu/acpi glue routines and > > > > divide them correspondingly. > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition Date: Wed, 21 Nov 2018 15:15:26 +0100 Message-ID: <20181121151526.5785b43f@redhat.com> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181116172919.43f3e27d@redhat.com> <20181119163110.2f357f40@redhat.com> <20181121072954-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1gPTIC-0007tF-Ot for xen-devel@lists.xenproject.org; Wed, 21 Nov 2018 14:15:48 +0000 In-Reply-To: <20181121072954-mutt-send-email-mst@kernel.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: "Michael S. Tsirkin" Cc: Peter Maydell , Stefano Stabellini , Samuel Ortiz , qemu-devel@nongnu.org, Shannon Zhao , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , Richard Henderson , Eduardo Habkost List-Id: xen-devel@lists.xenproject.org T24gV2VkLCAyMSBOb3YgMjAxOCAwNzozNTo0NyAtMDUwMAoiTWljaGFlbCBTLiBUc2lya2luIiA8 bXN0QHJlZGhhdC5jb20+IHdyb3RlOgoKPiBPbiBNb24sIE5vdiAxOSwgMjAxOCBhdCAwNDozMTox MFBNICswMTAwLCBJZ29yIE1hbW1lZG92IHdyb3RlOgo+ID4gT24gRnJpLCAxNiBOb3YgMjAxOCAx NzozNzo1NCArMDEwMAo+ID4gUGFvbG8gQm9uemluaSA8cGJvbnppbmlAcmVkaGF0LmNvbT4gd3Jv dGU6Cj4gPiAgIAo+ID4gPiBPbiAxNi8xMS8xOCAxNzoyOSwgSWdvciBNYW1tZWRvdiB3cm90ZTog IAo+ID4gPiA+IEdlbmVyYWwgc3VnZ2VzdGlvbnMgZm9yIHRoaXMgc2VyaWVzOgo+ID4gPiA+ICAg MS4gUHJlZmVyYWJseSBkb24ndCBkbyBtdWx0aXBsZSBjaGFuZ2VzIHdpdGhpbiBhIHBhdGNoCj4g PiA+ID4gICAgICBuZWl0aGVyIHBvc3QgaHVnZSBwYXRjaGVzICh1bmxlc3MgaXQncyBwdXJlIGNv ZGUgbW92ZW1lbnQpLgo+ID4gPiA+ICAgICAgKGl0J3MgZWFzeSB0byBzcXVhc2ggcGF0Y2hlcyBs YXRlciBpdCBuZWNlc3NhcnkpCj4gPiA+ID4gICAyLiBTdGFydCBzbWFsbCwgcGljayBhIHRhYmxl IGdlbmVyYWxpemUgaXQgYW5kIHNlbmQgYXMKPiA+ID4gPiAgICAgIG9uZSBzbWFsbCBwYXRjaHNl dC4gVGFibGVzIGFyZSBvZnRlbiBpbmRlcGVuZGVudAo+ID4gPiA+ICAgICAgYW5kIGl0J3MgbXVj aCBlYXNpZXIgb24gYm90aCBhdXRob3IvcmV2aWV3ZXIgdG8gYWdyZWUgdXBvbgo+ID4gPiA+ICAg ICAgY2hhbmdlcyBhbmQgcmV3cml0ZSBpdCBpZiBuZWNlc3NhcnkuICAgIAo+ID4gPiAKPiA+ID4g SG93IHdvdWxkIHRoYXQgYmUgZG9uZT8gIFRoaXMgc2VyaWVzIGlzIG9uIHRoZSBiaWdnZXIgc2lk ZSwgYWdyZWVkLCBidXQKPiA+ID4gbW9zdCBvZiBpdCBpcyByZWFsbHkganVzdCBjb2RlIG1vdmVt ZW50LiAgSXQncyBhIHN0YXJ0aW5nIHBvaW50LCBoYXZpbmcKPiA+ID4gYSBnZW5lcmljIEFDUEkg bGlicmFyeSBpcyB3YXkgYmV5b25kIHdoYXQgdGhpcyBpcyB0cnlpbmcgdG8gZG8uICAKPiA+IEkn dmUgdHJpZWQgdG8gZ2l2ZSBzdWdnZXN0aW9ucyBob3cgdG8gcmVzdHJ1Y3R1cmUgc2VyaWVzCj4g PiBvbiBwZXIgcGF0Y2ggYmFzaXMuIEluIG15IG9waW5pb24gaXQgcXVpdGUgcG9zc2libGUgdG8g c3BsaXQKPiA+IHNlcmllcyBpbiBzZXZlcmFsIHNtYWxsZXIgb25lcyBhbmQgaXQgc2hvdWxkIHJl YWxseSBoZWxwIHdpdGgKPiA+IG1ha2luZyBzZXJpZXMgY2xlYW5lciBhbmQgZWFzaWVyL2Zhc3Rl ciB0byByZXZpZXcvYW1lbmQvbWVyZ2UKPiA+IHZzIHdoYXQgd2UgaGF2ZSBpbiB2NS4KPiA+IChp dCdzIG1vcmUgZnJ1c3RyYXRpbmcgdG8gcmV3b3JrIGxhcmdlIHNlcmllcyB2cyBzbWFsbGVyIG9u ZSkKPiA+IAo+ID4gSWYgc29tZXRoaW5nIGlzbid0IGNsZWFyLCBpdCdzIGVhc3kgdG8gcmVhY2gg b3V0IHRvIG1lIGhlcmUKPiA+IG9yIGRpcmVjdGx5IChlbWFpbC9pcmMvZ2l0aHViKSBmb3IgY2xh cmlmaWNhdGlvbi9mZWVkIGJhY2suICAKPiAKPiBJIGFzc3VtZSB0aGUgIzEgZ29hbCBpcyB0byBh ZGQgcmVkdWNlZCBIVyBzdXBwb3J0LiAgU28gYW5vdGhlcgo+IG9wdGlvbiB0byBzcGVlZCB1cCBt ZXJnaW5nIGlzIHRvIGp1c3QgZ28gYWhlYWQgYW5kIGR1cGxpY2F0ZSBhCj4gYnVuY2ggb2YgY29k ZSBlLmcuIGluIHBjX3ZpcnQuYyBhY3BpL3JlZHVjZWQuYyBvciBpbiBhbnkgb3RoZXIKPiBmaWxl Lgo+IFRoaXMgd2F5IGl0IG1pZ2h0IGJlIGVhc2llciB0byBzZWUgd2hhdCdzIGNvbW1vbiBjb2Rl IGFuZCB3aGF0IGlzbid0Lgo+IEFuZCBJIHRoaW5rIG9mZmxpbmUgSWdvciBzYWlkIGhlIG1pZ2h0 IHByZWZlciB0aGF0IHdheS4gUmlnaHQgSWdvcj8KWW91IG1lYW4gcHJvYmFibHkgJ3g4NiByZWR1 Y2VkIGh3JyBzdXBwb3J0LiBUaGF0J3Mgd2FzIHdoYXQgSSd2ZQphbHJlYWR5IHN1Z2dlc3RlZCBm b3IgUENJIEFNTCBjb2RlIGR1cmluZyBwYXRjaCByZXZpZXcuIEp1c3QgZG9uJ3QKY2FsbCBpdCBn ZW5lcmljIHdoZW4gaXQncyBub3QgYW5kIHBsYWNlIGNvZGUgaW4gaHcvaTM4Ni8gZGlyZWN0b3J5 IGJlc2lkZQphY3BpLWJ1aWxkLmMuIEl0IG1pZ2h0IGFwcGx5IHRvIHNvbWUgb3RoZXIgdGFibGVz IChpLmUuIGNvbXBsZXggY2FzZXMpLgoKT24gcGVyIHBhdGNoIHJldmlldyBJIGdhdmUgc3VnZ2Vz dGlvbnMgaG93IHRvIGFtZW5kIHNlcmllcyB0byBtYWtlCml0IGFjY2VwdGFibGUgd2l0aG91dCBk b2luZyBjb21wbGV4IHJlZmFjdG9yaW5nIGFuZCBwb2ludGVkIG91dApwbGFjZXMgd2UgcHJvYmFi bHkgc2hvdWxkbid0IHJlZmFjdG9yIG5vdyBhbmQganVzdCBkdXBsaWNhdGUgYXMKaXQncyB0b28g Y29tcGxleCBvciBub3QgY2xlYXIgaG93IHRvIGdlbmVyYWxpemUgaXQgeWV0LgoKUHJvYmxlbSB3 aXRoIGR1cGxpY2F0aW9uIGlzIHRoYXQgYSByYW5kb20gY29udHJpYnV0b3IgaXMgbm90CmFyb3Vu ZCB0byBjbGVhbiBjb2RlIHVwIGFmdGVyIGEgZmVhdHVyZSBpcyBtZXJnZWQgYW5kIHdlIGVuZCB1 cAp3aXRoIGEgYnVuY2ggb2YgbWVzc3kgY29kZS4KCkEgd29yZCB0byB0aGUgY29udHJpYnV0b3Jz LApEb24ndCBkbyByZWZhY3RvcmluZyBpbiBzaWxlbmNlLCBrZWVwIGRpc2N1c3NpbmcgYXBwcm9h Y2hlcyBoZXJlLApzdWdnZXN0IGFsdGVybmF0aXZlcy4gVGhhdCB3YXkgaXQncyBlYXNpZXIgdG8g cmVhY2ggYSBjb21wcm9taXNlCmFuZCBtZXJnZSBpdCB3aXRoIGxlc3MgaXRlcmF0aW9ucy4gQW5k IGlmIHlvdSBkbyBzcGxpdCBpdCBpbiBzbWFsbGVyCnBhcnRzLCB0aGUgcHJvY2VzcyBzaG91bGQg Z28gZXZlbiBmYXN0ZXIuCgpJJ2xsIHNlbnQgYSBzbWFsbCBSU0RQIHJlZmFjdG9yaW5nIHNlcmll cyBmb3IgcmVmZXJlbmNlLgoKPiA+ID4gUGFvbG8KPiA+ID4gICAKPiA+ID4gPiAgIDMuIHdoZW4g eW91IHRoaW5rIGFib3V0IHJlZmFjdG9yaW5nIGFjcGkgaW50byBhIGdlbmVyaWMgQVBJCj4gPiA+ ID4gICAgICB0aGluayBhYm91dCBpdCBhcyByb3V0aW5lcyB0aGF0IGdvIGludG8gYSBzZXBhcmF0 ZSBsaWJyYXJ5Cj4gPiA+ID4gICAgICAocHVyZSBhY3BpIHNwZWMgY29kZSkgYW5kIHFlbXUvYWNw aSBnbHVlIHJvdXRpbmVzIGFuZAo+ID4gPiA+ICAgICAgIGRpdmlkZSB0aGVtIGNvcnJlc3BvbmRp bmdseS4gICAgCj4gPiA+ICAgCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJv amVjdC5vcmcKaHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hl bi1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPTIG-0000ld-RD for qemu-devel@nongnu.org; Wed, 21 Nov 2018 09:15:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPTIG-0001uW-1r for qemu-devel@nongnu.org; Wed, 21 Nov 2018 09:15:52 -0500 Date: Wed, 21 Nov 2018 15:15:26 +0100 From: Igor Mammedov Message-ID: <20181121151526.5785b43f@redhat.com> In-Reply-To: <20181121072954-mutt-send-email-mst@kernel.org> References: <20181105014047.26447-1-sameo@linux.intel.com> <20181116172919.43f3e27d@redhat.com> <20181119163110.2f357f40@redhat.com> <20181121072954-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/24] ACPI reorganization for hardware-reduced API addition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , Samuel Ortiz , qemu-devel@nongnu.org, Peter Maydell , Stefano Stabellini , Eduardo Habkost , Shannon Zhao , qemu-arm@nongnu.org, Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson On Wed, 21 Nov 2018 07:35:47 -0500 "Michael S. Tsirkin" wrote: > On Mon, Nov 19, 2018 at 04:31:10PM +0100, Igor Mammedov wrote: > > On Fri, 16 Nov 2018 17:37:54 +0100 > > Paolo Bonzini wrote: > > > > > On 16/11/18 17:29, Igor Mammedov wrote: > > > > General suggestions for this series: > > > > 1. Preferably don't do multiple changes within a patch > > > > neither post huge patches (unless it's pure code movement). > > > > (it's easy to squash patches later it necessary) > > > > 2. Start small, pick a table generalize it and send as > > > > one small patchset. Tables are often independent > > > > and it's much easier on both author/reviewer to agree upon > > > > changes and rewrite it if necessary. > > > > > > How would that be done? This series is on the bigger side, agreed, but > > > most of it is really just code movement. It's a starting point, having > > > a generic ACPI library is way beyond what this is trying to do. > > I've tried to give suggestions how to restructure series > > on per patch basis. In my opinion it quite possible to split > > series in several smaller ones and it should really help with > > making series cleaner and easier/faster to review/amend/merge > > vs what we have in v5. > > (it's more frustrating to rework large series vs smaller one) > > > > If something isn't clear, it's easy to reach out to me here > > or directly (email/irc/github) for clarification/feed back. > > I assume the #1 goal is to add reduced HW support. So another > option to speed up merging is to just go ahead and duplicate a > bunch of code e.g. in pc_virt.c acpi/reduced.c or in any other > file. > This way it might be easier to see what's common code and what isn't. > And I think offline Igor said he might prefer that way. Right Igor? You mean probably 'x86 reduced hw' support. That's was what I've already suggested for PCI AML code during patch review. Just don't call it generic when it's not and place code in hw/i386/ directory beside acpi-build.c. It might apply to some other tables (i.e. complex cases). On per patch review I gave suggestions how to amend series to make it acceptable without doing complex refactoring and pointed out places we probably shouldn't refactor now and just duplicate as it's too complex or not clear how to generalize it yet. Problem with duplication is that a random contributor is not around to clean code up after a feature is merged and we end up with a bunch of messy code. A word to the contributors, Don't do refactoring in silence, keep discussing approaches here, suggest alternatives. That way it's easier to reach a compromise and merge it with less iterations. And if you do split it in smaller parts, the process should go even faster. I'll sent a small RSDP refactoring series for reference. > > > Paolo > > > > > > > 3. when you think about refactoring acpi into a generic API > > > > think about it as routines that go into a separate library > > > > (pure acpi spec code) and qemu/acpi glue routines and > > > > divide them correspondingly. > > >