Re: [PATCH 2/2][RFC] Kernel changes for HPET legacy mode (v7)

[Avi Kivity <avi@redhat.com>]

On 06/22/2009 12:14 PM, Jan Kiszka wrote:
>>> Hmm, stead of introducing a new pair of singe-purpose IOCTLs, why not
>>> add KVM_GET/SET_PIT2 which exchanges an extended kvm_pit_state2. And
>>> that struct should also include some flags field and enough padding to
>>> be potentially extended yet again in the future. In that case I see no
>>> problem having also a mode read-back interface.
>>>
>>>        
>> We'd only add kernel hpet if we were forced to (I imagine the same
>> applications/kernels that forced the PIT into the kernel will do the
>> same for HPET).
>>
>>      
>
> Answer and citation does not yet correlate for me.
>    

Misquote.  I meant to reply to your 'Is it planned to add in-kernel hpet 
support?' question.  Must be early in the morning in some timezone.

> Could you comment more explicitly if your are fine with Beth's proposed
> interface, rather prefer something like my suggestion or even want
> something totally different?
>    

GET/SET PIT2 looks like the best choice to me, at least until I find 
whoever designed the HPET/PIT interdependency and make him take it back.

-- 
error compiling committee.c: too many arguments to function