[PATCH] docs: trace: fix event state structure name

[PATCH] docs: trace: fix event state structure name

[Artem Bityutskiy]

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

The documentation refers to a non-existent 'struct synth_trace_state'
structure. The correct name is 'struct synth_event_trace_state'.

In other words, this patch is a mechanical substitution:
s/synth_trace_state/synth_event_trace_state/g

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
---
 Documentation/trace/events.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index f792b1959a33..bdba7b0e19ef 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -787,13 +787,13 @@ To trace a synthetic using the piecewise method described above, the
 synth_event_trace_start() function is used to 'open' the synthetic
 event trace::
 
-       struct synth_trace_state trace_state;
+       struct synth_event_trace_state trace_state;
 
        ret = synth_event_trace_start(schedtest_event_file, &trace_state);
 
 It's passed the trace_event_file representing the synthetic event
 using the same methods as described above, along with a pointer to a
-struct synth_trace_state object, which will be zeroed before use and
+struct synth_event_trace_state object, which will be zeroed before use and
 used to maintain state between this and following calls.
 
 Once the event has been opened, which means space for it has been
@@ -805,7 +805,7 @@ lookup per field.
 
 To assign the values one after the other without lookups,
 synth_event_add_next_val() should be used.  Each call is passed the
-same synth_trace_state object used in the synth_event_trace_start(),
+same synth_event_trace_state object used in the synth_event_trace_start(),
 along with the value to set the next field in the event.  After each
 field is set, the 'cursor' points to the next field, which will be set
 by the subsequent call, continuing until all the fields have been set
@@ -834,7 +834,7 @@ this method would be (without error-handling code)::
        ret = synth_event_add_next_val(395, &trace_state);
 
 To assign the values in any order, synth_event_add_val() should be
-used.  Each call is passed the same synth_trace_state object used in
+used.  Each call is passed the same synth_event_trace_state object used in
 the synth_event_trace_start(), along with the field name of the field
 to set and the value to set it to.  The same sequence of calls as in
 the above examples using this method would be (without error-handling
@@ -856,7 +856,7 @@ can be used but not both at the same time.
 
 Finally, the event won't be actually traced until it's 'closed',
 which is done using synth_event_trace_end(), which takes only the
-struct synth_trace_state object used in the previous calls::
+struct synth_event_trace_state object used in the previous calls::
 
        ret = synth_event_trace_end(&trace_state);
 
-- 
2.26.2

Re: [PATCH] docs: trace: fix event state structure name

[Steven Rostedt]

On Wed,  4 Nov 2020 14:21:13 +0200
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> 
> The documentation refers to a non-existent 'struct synth_trace_state'
> structure. The correct name is 'struct synth_event_trace_state'.
> 
> In other words, this patch is a mechanical substitution:
> s/synth_trace_state/synth_event_trace_state/g
> 

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> ---
>  Documentation/trace/events.rst | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
> index f792b1959a33..bdba7b0e19ef 100644
> --- a/Documentation/trace/events.rst
> +++ b/Documentation/trace/events.rst
> @@ -787,13 +787,13 @@ To trace a synthetic using the piecewise method described above, the
>  synth_event_trace_start() function is used to 'open' the synthetic
>  event trace::
>  
> -       struct synth_trace_state trace_state;
> +       struct synth_event_trace_state trace_state;
>  
>         ret = synth_event_trace_start(schedtest_event_file, &trace_state);
>  
>  It's passed the trace_event_file representing the synthetic event
>  using the same methods as described above, along with a pointer to a
> -struct synth_trace_state object, which will be zeroed before use and
> +struct synth_event_trace_state object, which will be zeroed before use and
>  used to maintain state between this and following calls.
>  
>  Once the event has been opened, which means space for it has been
> @@ -805,7 +805,7 @@ lookup per field.
>  
>  To assign the values one after the other without lookups,
>  synth_event_add_next_val() should be used.  Each call is passed the
> -same synth_trace_state object used in the synth_event_trace_start(),
> +same synth_event_trace_state object used in the synth_event_trace_start(),
>  along with the value to set the next field in the event.  After each
>  field is set, the 'cursor' points to the next field, which will be set
>  by the subsequent call, continuing until all the fields have been set
> @@ -834,7 +834,7 @@ this method would be (without error-handling code)::
>         ret = synth_event_add_next_val(395, &trace_state);
>  
>  To assign the values in any order, synth_event_add_val() should be
> -used.  Each call is passed the same synth_trace_state object used in
> +used.  Each call is passed the same synth_event_trace_state object used in
>  the synth_event_trace_start(), along with the field name of the field
>  to set and the value to set it to.  The same sequence of calls as in
>  the above examples using this method would be (without error-handling
> @@ -856,7 +856,7 @@ can be used but not both at the same time.
>  
>  Finally, the event won't be actually traced until it's 'closed',
>  which is done using synth_event_trace_end(), which takes only the
> -struct synth_trace_state object used in the previous calls::
> +struct synth_event_trace_state object used in the previous calls::
>  
>         ret = synth_event_trace_end(&trace_state);
>  

Re: [PATCH] docs: trace: fix event state structure name

[Tom Zanussi]

Hi Artem,

On Wed, 2020-11-04 at 14:21 +0200, Artem Bityutskiy wrote:
> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> 
> The documentation refers to a non-existent 'struct synth_trace_state'
> structure. The correct name is 'struct synth_event_trace_state'.
> 
> In other words, this patch is a mechanical substitution:
> s/synth_trace_state/synth_event_trace_state/g
> 
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

Thanks for fixing this!

Reviewed-by: Tom Zanussi <zanussi@kernel.org>


> ---
>  Documentation/trace/events.rst | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/trace/events.rst
> b/Documentation/trace/events.rst
> index f792b1959a33..bdba7b0e19ef 100644
> --- a/Documentation/trace/events.rst
> +++ b/Documentation/trace/events.rst
> @@ -787,13 +787,13 @@ To trace a synthetic using the piecewise method
> described above, the
>  synth_event_trace_start() function is used to 'open' the synthetic
>  event trace::
>  
> -       struct synth_trace_state trace_state;
> +       struct synth_event_trace_state trace_state;
>  
>         ret = synth_event_trace_start(schedtest_event_file,
> &trace_state);
>  
>  It's passed the trace_event_file representing the synthetic event
>  using the same methods as described above, along with a pointer to a
> -struct synth_trace_state object, which will be zeroed before use and
> +struct synth_event_trace_state object, which will be zeroed before
> use and
>  used to maintain state between this and following calls.
>  
>  Once the event has been opened, which means space for it has been
> @@ -805,7 +805,7 @@ lookup per field.
>  
>  To assign the values one after the other without lookups,
>  synth_event_add_next_val() should be used.  Each call is passed the
> -same synth_trace_state object used in the synth_event_trace_start(),
> +same synth_event_trace_state object used in the
> synth_event_trace_start(),
>  along with the value to set the next field in the event.  After each
>  field is set, the 'cursor' points to the next field, which will be
> set
>  by the subsequent call, continuing until all the fields have been
> set
> @@ -834,7 +834,7 @@ this method would be (without error-handling
> code)::
>         ret = synth_event_add_next_val(395, &trace_state);
>  
>  To assign the values in any order, synth_event_add_val() should be
> -used.  Each call is passed the same synth_trace_state object used in
> +used.  Each call is passed the same synth_event_trace_state object
> used in
>  the synth_event_trace_start(), along with the field name of the
> field
>  to set and the value to set it to.  The same sequence of calls as in
>  the above examples using this method would be (without error-
> handling
> @@ -856,7 +856,7 @@ can be used but not both at the same time.
>  
>  Finally, the event won't be actually traced until it's 'closed',
>  which is done using synth_event_trace_end(), which takes only the
> -struct synth_trace_state object used in the previous calls::
> +struct synth_event_trace_state object used in the previous calls::
>  
>         ret = synth_event_trace_end(&trace_state);
>  

Re: [PATCH] docs: trace: fix event state structure name

[Steven Rostedt]

On Fri, 06 Nov 2020 14:47:46 -0600
Tom Zanussi <zanussi@kernel.org> wrote:

> Hi Artem,
> 
> On Wed, 2020-11-04 at 14:21 +0200, Artem Bityutskiy wrote:
> > From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> > 
> > The documentation refers to a non-existent 'struct synth_trace_state'
> > structure. The correct name is 'struct synth_event_trace_state'.
> > 
> > In other words, this patch is a mechanical substitution:
> > s/synth_trace_state/synth_event_trace_state/g
> > 
> > Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>  
> 
> Thanks for fixing this!
> 
> Reviewed-by: Tom Zanussi <zanussi@kernel.org>
> 

Jon,

Can you take this patch?

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

> 
> > ---
> >  Documentation/trace/events.rst | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/trace/events.rst
> > b/Documentation/trace/events.rst
> > index f792b1959a33..bdba7b0e19ef 100644
> > --- a/Documentation/trace/events.rst
> > +++ b/Documentation/trace/events.rst
> > @@ -787,13 +787,13 @@ To trace a synthetic using the piecewise method
> > described above, the
> >  synth_event_trace_start() function is used to 'open' the synthetic
> >  event trace::
> >  
> > -       struct synth_trace_state trace_state;
> > +       struct synth_event_trace_state trace_state;
> >  
> >         ret = synth_event_trace_start(schedtest_event_file,
> > &trace_state);
> >  
> >  It's passed the trace_event_file representing the synthetic event
> >  using the same methods as described above, along with a pointer to a
> > -struct synth_trace_state object, which will be zeroed before use and
> > +struct synth_event_trace_state object, which will be zeroed before
> > use and
> >  used to maintain state between this and following calls.
> >  
> >  Once the event has been opened, which means space for it has been
> > @@ -805,7 +805,7 @@ lookup per field.
> >  
> >  To assign the values one after the other without lookups,
> >  synth_event_add_next_val() should be used.  Each call is passed the
> > -same synth_trace_state object used in the synth_event_trace_start(),
> > +same synth_event_trace_state object used in the
> > synth_event_trace_start(),
> >  along with the value to set the next field in the event.  After each
> >  field is set, the 'cursor' points to the next field, which will be
> > set
> >  by the subsequent call, continuing until all the fields have been
> > set
> > @@ -834,7 +834,7 @@ this method would be (without error-handling
> > code)::
> >         ret = synth_event_add_next_val(395, &trace_state);
> >  
> >  To assign the values in any order, synth_event_add_val() should be
> > -used.  Each call is passed the same synth_trace_state object used in
> > +used.  Each call is passed the same synth_event_trace_state object
> > used in
> >  the synth_event_trace_start(), along with the field name of the
> > field
> >  to set and the value to set it to.  The same sequence of calls as in
> >  the above examples using this method would be (without error-
> > handling
> > @@ -856,7 +856,7 @@ can be used but not both at the same time.
> >  
> >  Finally, the event won't be actually traced until it's 'closed',
> >  which is done using synth_event_trace_end(), which takes only the
> > -struct synth_trace_state object used in the previous calls::
> > +struct synth_event_trace_state object used in the previous calls::
> >  
> >         ret = synth_event_trace_end(&trace_state);
> >    

Re: [PATCH] docs: trace: fix event state structure name

[Jonathan Corbet]

On Mon, 7 Dec 2020 18:19:14 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 06 Nov 2020 14:47:46 -0600
> Tom Zanussi <zanussi@kernel.org> wrote:
> 
> > Hi Artem,
> > 
> > On Wed, 2020-11-04 at 14:21 +0200, Artem Bityutskiy wrote:  
> > > From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> > > 
> > > The documentation refers to a non-existent 'struct synth_trace_state'
> > > structure. The correct name is 'struct synth_event_trace_state'.
> > > 
> > > In other words, this patch is a mechanical substitution:
> > > s/synth_trace_state/synth_event_trace_state/g
> > > 
> > > Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>    
> > 
> > Thanks for fixing this!
> > 
> > Reviewed-by: Tom Zanussi <zanussi@kernel.org>
> >   
> 
> Jon,
> 
> Can you take this patch?
> 
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

This wasn't sent to me, of course, so I was about to go digging into the
archive...until I realized I could just feed this email to b4 and
everything just happens by magic.  How did we ever get by before b4?

Anyway...applied :)

Thanks,

jon