On Mon, Aug 25, 2025 at 09:48:23AM +0200, Gabriele Monaco wrote:

On Thu, 2025-08-21 at 14:18 +0200, Nam Cao wrote:

quoted

On Thu, Aug 14, 2025 at 05:08:00PM +0200, Gabriele Monaco wrote:

quoted

Deterministic automata define which events are allowed in every
state,
but cannot define more sophisticated constraint taking into account
the
system's environment (e.g. time or other states not producing
events).

Add the Hybrid Automata monitor type as an extension of
Deterministic
automata where each state transition is validating a constraint on
a finite number of environment variables.
Hybrid automata can be used to implement timed automata, where the
environment variables are clocks.

Also implement the necessary functionality to handle clock
constraints (ns or jiffy granularity) on state and events.

Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>

So you have figured out how to deal with the time problem. Cool!

I'm curious, instead of a new monitor type, would the entire thing be
simpler if these new features are added as extension to DA monitor
instead?

The existing "pure DA" monitors would just not use the constraint and
timer stuffs and would behave same as before.

Just an idea, I'm not sure how it would look like. But I think we
might reduce some line count.

Mmh, that might save some lines, especially the *_hooks() macros.
The few functions that are now duplicated would end up together with a
condition, though.

I'm however not too fond of forcing any DA user to allocate space for a
timer. Imagine a custom kernel for an embedded device trying to squeeze
some RV monitors in tasks and ending up requiring 64 bytes per monitor
instead of 8.

I'm not sure if I follow. We put "union rv_task_monitor" in task_struct, so
we always require 64 bytes, regardless of the monitor type?

If this doesn't look confusing to you, I'd prefer them separate at
least there.

The current implementation is fine. It is just an thought that I think may
be worth considering. But I trust you know best what to do here.

Nam