> Blue Swirl wrote: > > On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka <jan.kis...@web.de> 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
