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 <gmon...@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
