From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbrBZ-0001XD-Js for qemu-devel@nongnu.org; Tue, 05 Jun 2012 06:40:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbrBR-0006RI-Uu for qemu-devel@nongnu.org; Tue, 05 Jun 2012 06:40:25 -0400 Received: from david.siemens.de ([192.35.17.14]:22527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbrBR-0006Qy-Kg for qemu-devel@nongnu.org; Tue, 05 Jun 2012 06:40:17 -0400 Message-ID: <4FCDE209.3070608@siemens.com> Date: Tue, 05 Jun 2012 12:40:09 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1338858018-17189-1-git-send-email-mdroth@linux.vnet.ibm.com> <1338858018-17189-10-git-send-email-mdroth@linux.vnet.ibm.com> <4FCDDE98.50604@redhat.com> In-Reply-To: <4FCDDE98.50604@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/17] rtc: add qc annotations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, owasserm@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, Michael Roth , yamahata@valinux.co.jp, pbonzini@redhat.com, akong@redhat.com, afaerber@suse.de On 2012-06-05 12:25, Avi Kivity wrote: > On 06/05/2012 04:00 AM, Michael Roth wrote: >> Add our annotations according to QIDL documentation. >> >> +qc_declaration typedef struct RTCState { >> + ISADevice _immutable dev; >> + MemoryRegion _immutable io; >> uint8_t cmos_data[128]; >> uint8_t cmos_index; >> struct tm current_tm; >> int32_t base_year; >> - qemu_irq irq; >> - qemu_irq sqw_irq; >> - int it_shift; >> + qemu_irq _immutable irq; >> + qemu_irq _immutable sqw_irq; > > How is qemu_irq immutable? We're raising and lowering it many times a > second. It's _derived, perhaps, but not immutable. No, IRQState in its current form is immutable, doesn't contain any volatile state. > >> + int32_t _immutable it_shift; >> /* periodic timer */ >> QEMUTimer *periodic_timer; >> int64_t next_periodic_time; >> /* second update */ >> int64_t next_second_time; >> - uint16_t irq_reinject_on_ack_count; >> + uint16_t _derived irq_reinject_on_ack_count; > > It's not derived from anything. It's _host, maybe. I think it is _broken. > >> uint32_t irq_coalesced; >> uint32_t period; >> - QEMUTimer *coalesced_timer; >> + QEMUTimer _broken *coalesced_timer; >> QEMUTimer *second_timer; >> QEMUTimer *second_timer2; >> - Notifier clock_reset_notifier; >> - LostTickPolicy lost_tick_policy; >> - Notifier suspend_notifier; >> + Notifier _broken clock_reset_notifier; > > Why broken? > >> + LostTickPolicy _immutable lost_tick_policy; > > _host; nothign prevents us from changing it dynamically in theory. _host makes no sense to me. Either it is _immutable or _broken - or is properly saved/restored. What should be the semantic of _host? > >> + Notifier _broken suspend_notifier; > > Why broken? > >> } RTCState; >> >> #endif /* !MC146818RTC_STATE_H */ > > Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux