From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1NPg-0001lc-SJ for qemu-devel@nongnu.org; Tue, 05 May 2009 12:22:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1NPg-0001lI-CI for qemu-devel@nongnu.org; Tue, 05 May 2009 12:22:36 -0400 Received: from [199.232.76.173] (port=60018 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1NPf-0001l6-Si for qemu-devel@nongnu.org; Tue, 05 May 2009 12:22:35 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:42796) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1NPf-0001D0-8w for qemu-devel@nongnu.org; Tue, 05 May 2009 12:22:35 -0400 Received: by fg-out-1718.google.com with SMTP id l27so977594fgb.8 for ; Tue, 05 May 2009 09:22:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87zldtotvx.fsf@pike.pond.sub.org> References: <87zldtotvx.fsf@pike.pond.sub.org> Date: Tue, 5 May 2009 19:22:33 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH 1/4] Confine use of global rtc_state to PC CMOS functions From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On 5/4/09, Markus Armbruster wrote: > Blue Swirl writes: > > > On 4/30/09, Markus Armbruster wrote: > >> Pass the state as argument to cmos_init() and cmos_init_hd(). > >> cmos_init() still needs to save it in rtc_state for use by > >> cmos_set_s3_resume(). > > > > pc.c could pass acpi an opaque handle (former rtc_state) at init or > > acpi could export a function to set the handle, called by pc.c. Then > > cmos_set_s3_resume could take a state parameter. > > > We'd just move a global variable from pc.c to acpi.c, wouldn't we? > Could you explain why that's a better place? No, acpi would only have an opaque pointer to the variable stored in PIIX4PMState, the "owner" would still be pc.c. > Passing rtc_state to piix4_pm_init() doesn't work well for pcdt.c, > because we'd have to pass it from RTC device to PIIX3 ACPI device > somehow, creating one of those ugly "non-tree" device dependencies, > i.e. one that doesn't follow device tree or interrupt tree edges. Your > other idea (a function to set the handle) allows me to keep the two > devices decoupled, provided I can set the handle even before > piix4_pm_init(). Still one idea: a signal (qemu_irq) could be used to convey the s3 resume condition. That may be another tree. Setting the handle before piix4_pm_init will fail if the handle is going to be stored in PIIX4PMState, but the setup can be reversed: piix4_pm_init can call a function to get the handle.