[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201207181914.370d4016@gandalf.local.home>
Date: Mon, 7 Dec 2020 18:19:14 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jonathan Corbet <corbet@....net>
Cc: Tom Zanussi <zanussi@...nel.org>,
Artem Bityutskiy <dedekind1@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] docs: trace: fix event state structure name
On Fri, 06 Nov 2020 14:47:46 -0600
Tom Zanussi <zanussi@...nel.org> wrote:
> Hi Artem,
>
> On Wed, 2020-11-04 at 14:21 +0200, Artem Bityutskiy wrote:
> > From: Artem Bityutskiy <artem.bityutskiy@...ux.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@...ux.intel.com>
>
> Thanks for fixing this!
>
> Reviewed-by: Tom Zanussi <zanussi@...nel.org>
>
Jon,
Can you take this patch?
Acked-by: Steven Rostedt (VMware) <rostedt@...dmis.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);
> >
Powered by blists - more mailing lists