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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

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

For the caller of qemu_set_irq, it will be like that.

> 
> 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.

I played with ignoring redundant invocations of qemu_set_irq early to
strengthen the state based concept. Unfortunately, the result was a
non-booting x86 system as at least the PIT is not properly deasserting
its IRQ line in periodic mode. Everything is fixable, I'm just reluctant
to overload the planned series with such a measure. I would prefer doing
this in a second step after checking for more such regressions.

> 
> See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01592.html

Will adopt the naming scheme.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]