On 22/11/16 16:01, Vincent Guittot wrote:
On 22 November 2016 at 15:34, Juri Lelli juri.lelli@arm.com wrote:
On 22/11/16 14:02, Juri Lelli wrote:
[...]
Since I think that both approaches might be useful to implement, why don't we add a "mode" : [absolute|relative] to timers and than we check the mode when executing the event to decide if we want to use current clock for t_next or keep t_first as reference?
Yes being able to select between relative and absolute can make sense
Something like the following (on top of previous patch) maybe? --->8--- src/rt-app.c | 2 ++ src/rt-app_parse_config.c | 6 ++++++ src/rt-app_types.h | 1 + 3 files changed, 9 insertions(+)
diff --git a/src/rt-app.c b/src/rt-app.c index 36013758f718..e28d4f9e8ddc 100644 --- a/src/rt-app.c +++ b/src/rt-app.c @@ -338,6 +338,8 @@ static int run_event(event_data_t *event, int dry_run, t_wu = timespec_sub(&t_now, &rdata->res.timer.t_next); ldata->wu_latency = timespec_to_usec(&t_wu); } else {
if (rdata->res.timer.relative)
clock_gettime(CLOCK_MONOTONIC, &rdata->res.timer.t_next); ldata->wu_latency = 0UL; } }
diff --git a/src/rt-app_parse_config.c b/src/rt-app_parse_config.c index b0f302e2ba25..fbc4612b2257 100644 --- a/src/rt-app_parse_config.c +++ b/src/rt-app_parse_config.c @@ -181,6 +181,7 @@ static int init_timer_resource(rtapp_resource_t *data, const rtapp_options_t *op { log_info(PIN3 "Init: %s timer", data->name); data->res.timer.init = 0;
data->res.timer.relative = 1;
}
static int init_cond_resource(rtapp_resource_t *data, const rtapp_options_t *opts) @@ -489,6 +490,11 @@ parse_thread_event_data(char *name, struct json_object *obj, rdata = &(opts->resources[data->res]); ddata = &(opts->resources[data->dep]);
tmp = get_string_value_from(obj, "mode", TRUE, "relative");
Ok so the timer event will look like absolute mode: "timer1" : { "ref" : "timerA", "period" : 20000, "mode" : "absolute" }
relative mode: "timer1" : { "ref" : "timerA", "period" : 20000, "mode" : "relative" } or "timer1" : { "ref" : "timerA", "period" : 20000 } for keeping current behavior
Looks ok to me
Yep. Will add the patch in v3.