From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46557 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVXL6-0007VA-JA for qemu-devel@nongnu.org; Sun, 04 Jul 2010 18:07:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVXL5-00062S-4Y for qemu-devel@nongnu.org; Sun, 04 Jul 2010 18:07:04 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:56035) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVXL4-00061p-Qy for qemu-devel@nongnu.org; Sun, 04 Jul 2010 18:07:03 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups Date: Sun, 4 Jul 2010 23:06:57 +0100 References: <20100629211802.16137.10587.malonedeb@soybean.canonical.com> <4C2EECE8.8030305@web.de> In-Reply-To: <4C2EECE8.8030305@web.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007042306.57852.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , Jan Kiszka , Gleb Natapov > 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. In practice returning a value from qemu_set_irq may be a reasonable way of communicating this state. However this should be done is such a a way that redundant calls to qemu_set_irq return the same value. See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01592.html Paul