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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
