The dot2c.py script generates all states in a single line. This breaks the
100 column limit when the state machines are non-trivial.
Recent changes allow it to print states over multiple lines if the
resulting line would have been too long.

Adapt existing monitors with line length over the limit.

Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
 kernel/trace/rv/monitors/sco/sco.h     | 12 ++++++++++--
 kernel/trace/rv/monitors/snep/snep.h   | 14 ++++++++++++--
 kernel/trace/rv/monitors/snroc/snroc.h | 12 ++++++++++--
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/rv/monitors/sco/sco.h b/kernel/trace/rv/monitors/sco/sco.h
index 7a4c1f2d5ca1c..83ca9a03331af 100644
--- a/kernel/trace/rv/monitors/sco/sco.h
+++ b/kernel/trace/rv/monitors/sco/sco.h
@@ -39,8 +39,16 @@ static const struct automaton_sco automaton_sco = {
 		"schedule_exit"
 	},
 	.function = {
-		{     thread_context_sco, scheduling_context_sco,          INVALID_STATE },
-		{          INVALID_STATE,          INVALID_STATE,     thread_context_sco },
+		{
+			thread_context_sco,
+			scheduling_context_sco,
+			INVALID_STATE
+		},
+		{
+			INVALID_STATE,
+			INVALID_STATE,
+			thread_context_sco
+		},
 	},
 	.initial_state = thread_context_sco,
 	.final_states = { 1, 0 },
diff --git a/kernel/trace/rv/monitors/snep/snep.h b/kernel/trace/rv/monitors/snep/snep.h
index 6d16b9ad931e1..4cd9abb77b7b2 100644
--- a/kernel/trace/rv/monitors/snep/snep.h
+++ b/kernel/trace/rv/monitors/snep/snep.h
@@ -41,8 +41,18 @@ static const struct automaton_snep automaton_snep = {
 		"schedule_exit"
 	},
 	.function = {
-		{ non_scheduling_context_snep, non_scheduling_context_snep, scheduling_contex_snep,               INVALID_STATE },
-		{               INVALID_STATE,               INVALID_STATE,          INVALID_STATE, non_scheduling_context_snep },
+		{
+			non_scheduling_context_snep,
+			non_scheduling_context_snep,
+			scheduling_contex_snep,
+			INVALID_STATE
+		},
+		{
+			INVALID_STATE,
+			INVALID_STATE,
+			INVALID_STATE,
+			non_scheduling_context_snep
+		},
 	},
 	.initial_state = non_scheduling_context_snep,
 	.final_states = { 1, 0 },
diff --git a/kernel/trace/rv/monitors/snroc/snroc.h b/kernel/trace/rv/monitors/snroc/snroc.h
index c3650a2b1b107..be46f7b9ebb87 100644
--- a/kernel/trace/rv/monitors/snroc/snroc.h
+++ b/kernel/trace/rv/monitors/snroc/snroc.h
@@ -39,8 +39,16 @@ static const struct automaton_snroc automaton_snroc = {
 		"sched_switch_out"
 	},
 	.function = {
-		{      INVALID_STATE,  own_context_snroc,       INVALID_STATE },
-		{  own_context_snroc,      INVALID_STATE, other_context_snroc },
+		{
+			INVALID_STATE,
+			own_context_snroc,
+			INVALID_STATE
+		},
+		{
+			own_context_snroc,
+			INVALID_STATE,
+			other_context_snroc
+		},
 	},
 	.initial_state = other_context_snroc,
 	.final_states = { 1, 0 },
-- 
2.50.1

On Tue, Jul 15, 2025 at 09:14:27AM +0200, Gabriele Monaco wrote:
> The dot2c.py script generates all states in a single line. This breaks the
> 100 column limit when the state machines are non-trivial.
> Recent changes allow it to print states over multiple lines if the
> resulting line would have been too long.
> 
> Adapt existing monitors with line length over the limit.
> 
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> ---
>  kernel/trace/rv/monitors/sco/sco.h     | 12 ++++++++++--
>  kernel/trace/rv/monitors/snep/snep.h   | 14 ++++++++++++--
>  kernel/trace/rv/monitors/snroc/snroc.h | 12 ++++++++++--
>  3 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/trace/rv/monitors/sco/sco.h b/kernel/trace/rv/monitors/sco/sco.h
> index 7a4c1f2d5ca1c..83ca9a03331af 100644
> --- a/kernel/trace/rv/monitors/sco/sco.h
> +++ b/kernel/trace/rv/monitors/sco/sco.h
> @@ -39,8 +39,16 @@ static const struct automaton_sco automaton_sco = {
>  		"schedule_exit"
>  	},
>  	.function = {
> -		{     thread_context_sco, scheduling_context_sco,          INVALID_STATE },
> -		{          INVALID_STATE,          INVALID_STATE,     thread_context_sco },
> +		{
> +			thread_context_sco,
> +			scheduling_context_sco,
> +			INVALID_STATE
> +		},
> +		{
> +			INVALID_STATE,
> +			INVALID_STATE,
> +			thread_context_sco
> +		},

I'm confused, these lines were not over 100 columns. Same for snroc.

From my understanding of the previous patch, the script does not break
lines which are not over the limit. Did I miss something?

Nam

On Tue, 2025-07-15 at 17:08 +0200, Nam Cao wrote:
> On Tue, Jul 15, 2025 at 09:14:27AM +0200, Gabriele Monaco wrote:
> > The dot2c.py script generates all states in a single line. This
> > breaks the
> > 100 column limit when the state machines are non-trivial.
> > Recent changes allow it to print states over multiple lines if the
> > resulting line would have been too long.
> > 
> > Adapt existing monitors with line length over the limit.
> > 
> > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> > ---
> >  kernel/trace/rv/monitors/sco/sco.h     | 12 ++++++++++--
> >  kernel/trace/rv/monitors/snep/snep.h   | 14 ++++++++++++--
> >  kernel/trace/rv/monitors/snroc/snroc.h | 12 ++++++++++--
> >  3 files changed, 32 insertions(+), 6 deletions(-)
> > 
> > diff --git a/kernel/trace/rv/monitors/sco/sco.h
> > b/kernel/trace/rv/monitors/sco/sco.h
> > index 7a4c1f2d5ca1c..83ca9a03331af 100644
> > --- a/kernel/trace/rv/monitors/sco/sco.h
> > +++ b/kernel/trace/rv/monitors/sco/sco.h
> > @@ -39,8 +39,16 @@ static const struct automaton_sco automaton_sco
> > = {
> >  		"schedule_exit"
> >  	},
> >  	.function = {
> > -		{     thread_context_sco,
> > scheduling_context_sco,          INVALID_STATE },
> > -		{          INVALID_STATE,         
> > INVALID_STATE,     thread_context_sco },
> > +		{
> > +			thread_context_sco,
> > +			scheduling_context_sco,
> > +			INVALID_STATE
> > +		},
> > +		{
> > +			INVALID_STATE,
> > +			INVALID_STATE,
> > +			thread_context_sco
> > +		},
> 
> I'm confused, these lines were not over 100 columns. Same for snroc.
> 
> From my understanding of the previous patch, the script does not
> break
> lines which are not over the limit. Did I miss something?

Right, I didn't make it obvious in the commit description since I
thought it wasn't too important.
Those are the monitors whose lines are going to be longer than 100
columns later in the series.

Changing it there saves a bit of complication in the next patches,
where I only add lines for new events instead of splitting the line
/and/ adding the events.

Do you think I should mention this in the commit description?

Thanks,
Gabriele

On Tue, Jul 15, 2025 at 05:24:11PM +0200, Gabriele Monaco wrote:
> Right, I didn't make it obvious in the commit description since I
> thought it wasn't too important.
> Those are the monitors whose lines are going to be longer than 100
> columns later in the series.
> 
> Changing it there saves a bit of complication in the next patches,
> where I only add lines for new events instead of splitting the line
> /and/ adding the events.

Ah, that makes sense. I thought the script went wild.

> Do you think I should mention this in the commit description?

A maintainer once told me that the rule is "one thing per patch", not "half
a thing per patch".

This does make the diff easier to read in the later patch, but I think it
is not worth it. For this case, I can easily review the later patches by
regenerate the files.

So I suggest dropping these.

Best regards,
Nam

On Wed, 2025-07-16 at 10:13 +0200, Nam Cao wrote:
> On Tue, Jul 15, 2025 at 05:24:11PM +0200, Gabriele Monaco wrote:
> > Right, I didn't make it obvious in the commit description since I
> > thought it wasn't too important.
> > Those are the monitors whose lines are going to be longer than 100
> > columns later in the series.
> > 
> > Changing it there saves a bit of complication in the next patches,
> > where I only add lines for new events instead of splitting the line
> > /and/ adding the events.
> 
> Ah, that makes sense. I thought the script went wild.
> 
> > Do you think I should mention this in the commit description?
> 
> A maintainer once told me that the rule is "one thing per patch", not
> "half
> a thing per patch".
> 

Sounds like someone familiar, good point :)

> This does make the diff easier to read in the later patch, but I
> think it
> is not worth it. For this case, I can easily review the later patches
> by
> regenerate the files.
> 
> So I suggest dropping these.

Alright then, I'm usually finding the diffs in emails confusing so I
prefer to have as much help as possible. But here it shouldn't be a big
deal indeed.

Thanks,
Gabriele