From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51533 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVfOH-0006lj-C4 for qemu-devel@nongnu.org; Mon, 05 Jul 2010 02:42:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVfOG-00083w-35 for qemu-devel@nongnu.org; Mon, 05 Jul 2010 02:42:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53623) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVfOF-00083K-Sg for qemu-devel@nongnu.org; Mon, 05 Jul 2010 02:42:52 -0400 Date: Mon, 5 Jul 2010 09:42:39 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups Message-ID: <20100705064239.GI4689@redhat.com> References: <20100629211802.16137.10587.malonedeb@soybean.canonical.com> <4C2EECE8.8030305@web.de> <201007042306.57852.paul@codesourcery.com> <4C317E2A.7090101@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C317E2A.7090101@web.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , Paul Brook , qemu-devel@nongnu.org On Mon, Jul 05, 2010 at 08:39:38AM +0200, Jan Kiszka wrote: > Paul Brook wrote: > >> Blue Swirl wrote: > >>> On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka wrote: > >>>> Paul Brook wrote: > >>>>>> I really see no tangible objection to Jan's patches. They don't > >>>>>> impact any other code. They don't inhibit flexibility in the > >>>>>> infrastructure. You might consider it to be a "hack" but so what. > >>>>>> QEMU is filled with hacks. It would be useless without them because > >>>>>> there would be very little code. > >>>>> I object strongly to anything that makes qemu_irq a message passing > >>>>> API. if you want message passing then you should not be using > >>>>> qemu_irq. > >>>> Blueswirl objected to the straightforward return-value approach I first > >>>> posted. You seems to be more open towards this, right? Still looks like > >>>> I cannot make you both happy at the same time. So what to do? > >>> I have withdrawn my objection. We can do message passing with some > >>> different API later, for simple coalescing needs the return value > >>> approach is enough. > >> Great! I'll respin my patches ASAP. > > > > Note that I still have some concerns over the semantics of that API. > > I believe this should be fundamentally state based, not event based. > > For the caller of qemu_set_irq, it will be like that. > Unfortunately just having qemu_set_irq() return value is not enough to fix timedrift problem for all Windows. For some of them you need to know _which_ CPU accepted IRQ. -- Gleb.