From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCw7x-0004K2-Qx for qemu-devel@nongnu.org; Wed, 08 Jul 2015 16:39:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCw7s-0003r2-Ni for qemu-devel@nongnu.org; Wed, 08 Jul 2015 16:39:33 -0400 Received: from mail-wg0-x235.google.com ([2a00:1450:400c:c00::235]:36848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCw7s-0003qk-F5 for qemu-devel@nongnu.org; Wed, 08 Jul 2015 16:39:28 -0400 Received: by wgxm20 with SMTP id m20so22760135wgx.3 for ; Wed, 08 Jul 2015 13:39:27 -0700 (PDT) Sender: Paolo Bonzini References: <1433812331-18993-1-git-send-email-minyard@acm.org> <1433812331-18993-15-git-send-email-minyard@acm.org> <20150707100829.401476a9@nial.brq.redhat.com> <559D6170.6080804@redhat.com> <20150708212640.12350f9e@igors-macbook-pro.local> From: Paolo Bonzini Message-ID: <559D8A7C.2050703@redhat.com> Date: Wed, 8 Jul 2015 22:39:24 +0200 MIME-Version: 1.0 In-Reply-To: <20150708212640.12350f9e@igors-macbook-pro.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 14/16] acpi: Add a way for devices to add ACPI tables List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Corey Minyard , qemu-devel@nongnu.org, minyard@acm.org On 08/07/2015 21:26, Igor Mammedov wrote: > > This was suggested by Michael, so I think you should read the reviews > > of earlier versions first. > > That is basically the same as hooks in v1 only the other way around > with all drawbacks attached. > > Just dropping this universal way to scatter ACPI code all over QEMU > and calling ipmi_encode_one_acpi() "[15/16] ipmi: Add ACPI table entries" > directly from build_ssdt() would simplify series quite a bit. On the other hand, it would be much harder to make IPMI optional unless you want to add a bunch of ugly stubs. Same for SMBIOS. Especially when you can have the same ACPI and SMBIOS tables in both x86 and ARM virtual machines, it becomes a little more the device business to provide ACPI and SMBIOS information. So overall I'm happy with the way it was done here. I and Michael disagreed on several details, but not enough to fight over it... Paolo > I'd do the same for SMBIOS entries as well, i.e. drop similar > universal way for devices to supply SMBIOS info (it's not their > business) and just call ipmi_encode_one_smbios() to add ipmi specific > entry if device is present. Again simplifying series even more. > > that roughly would save us 300 lines of not really necessary code > and keep things consistent with a way we are managing ssdt now.