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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/01/2010 10:45 AM, Paul Brook wrote:
>> Since it solves existing problem and is rejected without any rational
>> explanation and without proposing alternative solution (in form of code)
>> it should be committed.
>>      
> No. This is not sufficient justification for applying a patch. We should not
> be accepting patches just because they exist.
>
> If a feature[1] is important enough that we need to implement it, then it
> should also warrant getting a good solution.

I think it's important to try to be constructive.  It's easy to say that 
something is bad but it's far more productive to take the time to offer 
a better alternative.

>   Otherwise we're going to end up
> in exactly the same situation next time someone starts using a nwew
> timesource.
>
> Paul
>
> [1] Time-drift hacks are a new *feature*, not a bugfix. At best they're hiding
> more fundamental flaws, e.g. kvm being incapable of emulating realtime
> behavior.
>    

I think a fundamental problem in this discussion is that you're 
asserting that the true problem is "broken guests".  I contend that 
there is no such thing as broken guests.  Guests behave the way they do 
and to the extent that most hardware accommodates that behavior, our 
goal in QEMU should be to also accommodate that behavior.

Sometimes that means breaking nice abstractions but that's the cost of 
functionality.

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.

Taking these patches really does no harm.  I really think you ought to 
reconsider your position.

Regards,

Anthony Liguori