Thread (60 messages) 60 messages, 5 authors, 2025-09-04

Re: [RFC PATCH 08/17] rv: Add Hybrid Automata monitor type

From: Gabriele Monaco <gmonaco@redhat.com>
Date: 2025-08-25 08:32:35
Also in: lkml


On Mon, 2025-08-25 at 10:13 +0200, Nam Cao wrote:
On Mon, Aug 25, 2025 at 09:48:23AM +0200, Gabriele Monaco wrote:
quoted
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?
That's right, but if no HA monitor is compiled in, struct ha_monitor is
empty, so  union rv_task_monitor is as large as DA/LTL.
#ifdef CONFIG_RV_HA_MONITOR

struct ha_monitor {
	struct da_monitor da_mon;
	u64 env_store[MAX_HA_ENV_LEN];
	struct hrtimer timer;
};

#else

struct ha_monitor { };

#endif /* CONFIG_RV_HA_MONITOR */
That's why I wanted also LTL to be optionally empty, technically we
could do the same for DA but since it's the smallest it's rather
pointless.

Thanks,
Gabriele
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help