From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpqGq-0003l7-4u for qemu-devel@nongnu.org; Wed, 07 Nov 2007 14:09:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpqGo-0003iY-Jd for qemu-devel@nongnu.org; Wed, 07 Nov 2007 14:08:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpqGo-0003iM-ED for qemu-devel@nongnu.org; Wed, 07 Nov 2007 14:08:58 -0500 Received: from sp604001mt.neufgp.fr ([84.96.92.60] helo=Smtp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IpqGn-0003Wz-LU for qemu-devel@nongnu.org; Wed, 07 Nov 2007 14:08:57 -0500 Received: from [84.102.211.92] by sp604001mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0JR500JJUH4DJS10@sp604001mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Wed, 07 Nov 2007 20:07:29 +0100 (CET) Date: Wed, 07 Nov 2007 20:07:02 +0100 From: Fabrice Bellard Subject: Re: [Qemu-devel] qemu qemu-doc.texi vl.c vl.h hw/mc146818rtc.c In-reply-to: <4732079F.8000104@mail.berlios.de> Message-id: <47320CD6.5050009@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 7BIT References: <4732079F.8000104@mail.berlios.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Stefan Weil wrote: > Hi, > > the change from mc146818rtc.c might be needed for other timer > implementations, > too (because not all systems emulated by QEMU use mc146818rtc.c). > > A list of candidates is here (fgrep gmtime, fgrep gettime): > hw/m48t59.c: gmtime_r (&t, tm); > hw/omap.c: s->convert = rtc_utc ? gmtime_r : localtime_r; > hw/pl031.c: tm = gmtime(&ti); > hw/pxa2xx.c: tm = gmtime(&ti); > hw/etraxfs_timer.c: gettimeofday(&now, NULL); > > hw/omap.c needs additional changes for Windows, because gmtime_r > is missing there. > > Maybe all those locations should use a central function (to be written). Right. There should be at least a function which returns the "current time" with the rtc_utc flag handling. Fabrice.