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

[Nam Cao <namcao@linutronix.de>]

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:
> > On Thu, Aug 14, 2025 at 05:08:00PM +0200, Gabriele Monaco wrote:
> > > 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