From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCHv3 4/4] acpi: automatically generated ssdt proc Date: Mon, 17 Oct 2011 20:16:20 +0200 Message-ID: <20111017181620.GA9899@redhat.com> References: <2dcf16cf5ba62dfb998bda6c623ad3333cda173b.1317734661.git.mst@redhat.com> <20111005025233.GA12015@morn.localdomain> <20111005103525.GA5587@redhat.com> <20111006021526.GA23719@morn.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: seabios@seabios.org, kvm@vger.kernel.org To: "Kevin O'Connor" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57058 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751198Ab1JQSPb (ORCPT ); Mon, 17 Oct 2011 14:15:31 -0400 Content-Disposition: inline In-Reply-To: <20111006021526.GA23719@morn.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Oct 05, 2011 at 10:15:26PM -0400, Kevin O'Connor wrote: > Sure: > > - The DSDT is big and has several cross-functional users. Patching up > the DSDT for hotplug when the DSDT also has unrelated stuff (eg, > mouse) seems ugly. > > - The PCI hotplug stuff is generating a whole bunch of devices and the > dynamic code is effectively disabling the unwanted ones. It seems > nicer to dynamically generate the desired entries instead of bulk > generating and dynamically blanking. > > - The CPU hotplug has similar requirements, but is implemented > differently - it generates the CPU objects dynamically. It's not > desirable to bulk generate the CPU objects and "blank" them > dynamically, because 255 CPU objects would noticeably increase > SeaBIOS' static size. > > - Some time back there were patches floating around to pass the DSDT > into SeaBIOS via fw_cfg interface. Those patches never made it in > (I forget why), but the basic functionality seemed sound. Patching > the DSDT in SeaBIOS would seem to eliminate that possibility. > > None of these would be road-blocks. However, they make me want to > consider other approaches. So if we had the hotplug stuff in a separate ssdt, and patched that in the same way my patches do, this seems to address 3 comments otu of 4 (all except the second one). We'll want to do something else for a bridge, but for now this seems a sane compromise? -- MST