Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Paul Brook]

> Blue Swirl wrote:
> > On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <address@hidden> 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