On 2011-02-07 15:28, Anthony Liguori wrote: > On 02/07/2011 08:10 AM, Jan Kiszka wrote: >> Again: please not in an ad-hoc fashion but as a generic services usable >> by _all_ periodic timer sources that want to implement compensation. >> This infrastructure should also be designed to once integrate IRQ >> coalescing information as well. >> >> The point why I'm insisting on a broader solution is that both sources >> for lost ticks (iothread and vcpu) end up in the same output: an >> adjustment of the injection frequency of the affected timer device. >> There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the >> SoC timer of some emulated ARM board as well. >> > > Fair enough, how about: > > typedef struct PeriodicTimer PeriodicTimer; > > /** > * @accumulated_ticks: the number of unacknowledged ticks in total > since the creation of the timer > **/ > typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks); I guess you mean PeriodicTimerFunc. Why the accumulated_ticks argument? > > PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque); > > void periodic_timer_mod(PeriodicTimer *timer, int64_t interval, TimeUnit > unit); > > /** > * @policy: the drift catch-up policy > * DRIFT_COMP_FAST, deliver next tick as soon as any > tick is acknowledged if accumulated_ticks > 1 > * DRIFT_COMP_NONE, do not change interval regardless of > accumulated ticks > * DRIFT_COMP_GRADUAL, shorten interval by half until > accumulated_ticks <= 1 > */ > void periodic_timer_set_policy(PeriodicTimer *timer, > DriftCompensationPolicy policy); > > /** > * @ticks: number of ticks to acknowledge that are currently outstanding. > **/ > void periodic_timer_ack(PeriodicTimer *timer, int ticks); > Looks reasonable otherwise. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
