public inbox for linux-trace-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Nam Cao <namcao@linutronix.de>,
	linux-trace-kernel@vger.kernel.org,
	 linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Weissschuh <thomas.weissschuh@linutronix.de>,
	Tomas Glozar <tglozar@redhat.com>, John Kacur <jkacur@redhat.com>,
	Wen Yang <wen.yang@linux.dev>
Subject: Re: [RFC PATCH 07/12] verification/rvgen: Add golden and spec folders for tests
Date: Mon, 04 May 2026 10:26:21 +0200	[thread overview]
Message-ID: <ffb994110f4ec8165aa5a3e7cd83a57beeb609f9.camel@redhat.com> (raw)
In-Reply-To: <878q9z1up7.fsf@yellow.woof>

On Mon, 2026-05-04 at 09:48 +0200, Nam Cao wrote:
> I am working on converting rvgen to use Lark, a parsing library:
> https://github.com/lark-parser/lark
> 
> This test case breaks the current version of the new script, because
> state_c has no label while the script expects one - the script read the
> state's name from the label.

Right, good point, I forgot to add that.. Thanks for checking!

> We should define if the label or the node's name is our state's
> name. For example, if we have:
> 
>     "state_c" [label = "state_d"];
> 
> Will the state's name be state_c or state_d? Or should that be a parsing
> error?
> 
> I propose using the label if one is provided, otherwise using the node's
> name. So
> 
>     "state_c" [label = "state_d"];
> 
> means the state's name is "state_d". But without that statement, the
> state's name is "state_c".
> 
> What do you think?

Mmh, the only valid usecase I can think for DAs is to tweak the dot
representation, e.g.:

 "state_c" [label = "State C"];

in this case the user might want to have a better display on the graph while
still keeping a valid state name.

Also keep in mind that in HA we could do something like

 "state_c" [label = "state_c\nclk < 10"];

Here it's probably simpler to just parse the node name rather than the label.

Do you have any other reason to prefer "state_d" in your example?

Either way we are opening for confusion (like in your example), so if you
believe throwing an error makes the grammar simpler, we could also go down that
path.

In any case, I would make the label definition mandatory. So my current sample
model is wrong.

> (just FYI, my work-in-progress:
> https://github.com/covanam/linux/commits/rv-lark/)

Thanks for sharing, I'll have a look!

Gabriele


  reply	other threads:[~2026-05-04  8:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 15:11 [RFC PATCH 00/12] rv: Add selftests to tools and KUnit tests Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 01/12] tools/rv: Fix substring match bug in monitor name search Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 02/12] tools/rv: Fix substring match when listing container monitors Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 03/12] tools/rv: Fix exit status when monitor execution fails Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 04/12] tools/rv: Fix cleanup after failed trace setup Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 05/12] tools/rv: Add selftests Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 06/12] verification/rvgen: Fix options shared among commands Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 07/12] verification/rvgen: Add golden and spec folders for tests Gabriele Monaco
2026-05-04  7:48   ` Nam Cao
2026-05-04  8:26     ` Gabriele Monaco [this message]
2026-05-04  8:44       ` Nam Cao
2026-05-04  8:49         ` Gabriele Monaco
2026-05-04  9:07           ` Nam Cao
2026-04-27 15:11 ` [RFC PATCH 08/12] verification/rvgen: Add selftests Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 09/12] rv: Add KUnit stub to rv_react() and rv_*_task_monitor_slot() Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 10/12] rv: Add KUnit tests for some DA/HA monitors Gabriele Monaco
2026-05-04  8:39   ` Nam Cao
2026-05-04 11:42     ` Gabriele Monaco
2026-05-04 13:33       ` Nam Cao
2026-05-04 14:02         ` Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 11/12] rv: Add KUnit stubs for current and smp_processor_id() Gabriele Monaco
2026-04-27 15:11 ` [RFC PATCH 12/12] rv: Add KUnit tests for some LTL monitors Gabriele Monaco
2026-04-28 15:09 ` [RFC PATCH 00/12] rv: Add selftests to tools and KUnit tests Wen Yang
2026-04-28 15:27   ` 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=ffb994110f4ec8165aa5a3e7cd83a57beeb609f9.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=namcao@linutronix.de \
    --cc=rostedt@goodmis.org \
    --cc=tglozar@redhat.com \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=wen.yang@linux.dev \
    /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