linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Nam Cao <namcao@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] rv/ltl: Support per-cpu monitors
Date: Thu, 31 Jul 2025 10:02:19 +0200	[thread overview]
Message-ID: <0fb442dc58bd36345b60f4bb8f6be73db74900ac.camel@redhat.com> (raw)
In-Reply-To: <da946aaf40a8d1a320dc62673013ceceef1c93b3.1753879295.git.namcao@linutronix.de>

On Wed, 2025-07-30 at 14:45 +0200, Nam Cao wrote:
> Add support for per-cpu run-time verification linear temporal logic
> monitors. This is analogous to deterministic automaton per-cpu
> monitors.
> 
> Signed-off-by: Nam Cao <namcao@linutronix.de>
> ---
> 
> diff --git a/kernel/trace/rv/rv_trace.h b/kernel/trace/rv/rv_trace.h
> index 4a6faddac614..f9e5fd044c45 100644
> --- a/kernel/trace/rv/rv_trace.h
> +++ b/kernel/trace/rv/rv_trace.h
> @@ -177,6 +177,53 @@ DECLARE_EVENT_CLASS(error_ltl_monitor_id,
>  #include <monitors/pagefault/pagefault_trace.h>
>  #include <monitors/sleep/sleep_trace.h>
>  // Add new monitors based on CONFIG_LTL_MON_EVENTS_ID here
> +
> +#ifdef CONFIG_LTL_MON_EVENTS_IMPLICIT
> +DECLARE_EVENT_CLASS(event_ltl_monitor,
> +
> +	TP_PROTO(unsigned int cpu, char *states, char *atoms, char
> *next),
> +

You don't really need to follow to the ID/IMPLICIT convention here.

These LTL per-cpu monitors are, in fact, not implicit since they do
have an id (the CPU), implicit makes sense with the current
implementation of da_get_monitor that uses the current CPU (doesn't
have to stay that way, but there was no need to change so far).

If you don't want to get rid of the task's comm in the tracepoint (and
unify both with an integer id, like with DA), I'd suggest you use
different names like CONFIG_LTL_MON_EVENTS_TASK (in fact that doesn't
just have an ID) and CONFIG_LTL_MON_EVENTS_CPU (or even
CONFIG_LTL_MON_EVENTS_ID, for this it actually makes sense).

I'd prefer it as general as possible to ease new monitor types, but to
be real picky the LTLs per-task are not ID and the per-cpu are not
IMPLICIT.

The id field is what the rv userspace tool uses to differentiate
monitor types, by the way.


> +#endif /* CONFIG_LTL_MON_EVENTS_IMPLICIT */
> +
>  #endif /* CONFIG_LTL_MON_EVENTS_ID */

Also, I'm not sure if that was intended, but
CONFIG_LTL_MON_EVENTS_IMPLICIT gets compiled only with
CONFIG_LTL_MON_EVENTS_ID.

Thanks,
Gabriele


  reply	other threads:[~2025-07-31  8:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-30 12:45 [PATCH 0/5] rv: LTL per-cpu monitor type and real-time scheduling monitor Nam Cao
2025-07-30 12:45 ` [PATCH 1/5] rv/ltl: Prepare for other monitor types Nam Cao
2025-07-31  9:04   ` Gabriele Monaco
2025-07-31  9:28     ` Nam Cao
2025-07-31 10:14       ` Gabriele Monaco
2025-07-30 12:45 ` [PATCH 2/5] rv/ltl: Support per-cpu monitors Nam Cao
2025-07-31  8:02   ` Gabriele Monaco [this message]
2025-08-01  6:26     ` Nam Cao
2025-07-30 12:45 ` [PATCH 3/5] verification/rvgen/ltl: Support per-cpu monitor generation Nam Cao
2025-07-30 12:45 ` [PATCH 4/5] sched: Add rt task enqueue/dequeue trace points Nam Cao
2025-07-30 13:53   ` Gabriele Monaco
2025-07-30 15:18     ` Nam Cao
2025-07-30 16:18       ` Gabriele Monaco
2025-07-31  7:35         ` Nam Cao
2025-07-31  8:39           ` Gabriele Monaco
2025-08-01  3:42           ` K Prateek Nayak
2025-08-01  7:29             ` Nam Cao
2025-08-01  9:56               ` K Prateek Nayak
2025-08-01 11:04                 ` Gabriele Monaco
2025-08-04  3:07                   ` K Prateek Nayak
2025-08-04  5:49                     ` Nam Cao
2025-07-30 12:45 ` [PATCH 5/5] rv: Add rts monitor Nam Cao
2025-07-31  7:47   ` Gabriele Monaco
2025-08-01  7:58     ` Nam Cao
2025-08-01  9:14       ` Gabriele Monaco
2025-08-04  6:05         ` Nam Cao
2025-08-05  8:40   ` Gabriele Monaco
2025-08-05 12:22     ` Nam Cao
2025-08-05 15:45       ` Nam Cao
2025-08-06  8:15         ` Gabriele Monaco
2025-08-06  8:46           ` Nam Cao
2025-08-06  9:03             ` Gabriele Monaco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0fb442dc58bd36345b60f4bb8f6be73db74900ac.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=namcao@linutronix.de \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).