linux-kernel - Re: [PATCH] tracing: fix comments of event_trigger_separate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJncD7Q8gV6T2i5EnZzRDdH968da0WZSKk3hZWC=sHu=8onGug@mail.gmail.com>
Date:   Thu, 26 May 2022 09:01:30 +0800
From:   sunliming <kelulanainsley@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     mingo@...hat.com, linux-kernel@...r.kernel.org,
        sunliming@...inos.cn, Tom Zanussi <zanussi@...nel.org>
Subject: Re: [PATCH] tracing: fix comments of event_trigger_separate_filter()

Steven Rostedt <rostedt@...dmis.org> 于2022年5月25日周三 23:51写道：
>
> On Mon, 23 May 2022 15:51:23 +0800
> slm <kelulanainsley@...il.com> wrote:
>
> > The parameter name in comments of event_trigger_separate_filter()
> > is inconsistent with actual parameter name, fix it.
> >
> > Signed-off-by: slm <sunliming@...inos.cn>
>
> Signed off by must have your full name. I doubt "slm" is your full name.
>
> > ---
> >  kernel/trace/trace_events_trigger.c | 23 ++++++++++++-----------
> >  1 file changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> > index 21592bed2e89..c364dc729339 100644
> > --- a/kernel/trace/trace_events_trigger.c
> > +++ b/kernel/trace/trace_events_trigger.c
> > @@ -738,27 +738,28 @@ bool event_trigger_empty_param(const char *param)
> >
> >  /**
> >   * event_trigger_separate_filter - separate an event trigger from a filter
> > - * @param: The param string containing trigger and possibly filter
> > - * @trigger: outparam, will be filled with a pointer to the trigger
> > + * @param_and_filter: The param_and_filter string containing trigger
> > + * and possibly filter
>
> The parameter description should be contained to a single line. No need to
> say "The param_and_filter".
>
>
> > + * @param: outparam, will be filled with a pointer to the trigger
> >   * @filter: outparam, will be filled with a pointer to the filter
> >   * @param_required: Specifies whether or not the param string is required
> >   *
> >   * Given a param string of the form '[trigger] [if filter]', this
> >   * function separates the filter from the trigger and returns the
> > - * trigger in *trigger and the filter in *filter.  Either the *trigger
> > + * trigger in *param and the filter in *filter.  Either the *param
>
> If you are updating this, then it should be:
>
>     trigger in @param and the filter in @filter.
>
> As they are referencing parameters which need the "@" notation.
>
> >   * or the *filter may be set to NULL by this function - if not set to
>
> And that includes the above as well.
>
> >   * NULL, they will contain strings corresponding to the trigger and
> >   * filter.
> >   *
> >   * There are two cases that need to be handled with respect to the
> > - * passed-in param: either the param is required, or it is not
> > - * required.  If @param_required is set, and there's no param, it will
> > - * return -EINVAL.  If @param_required is not set and there's a param
> > - * that starts with a number, that corresponds to the case of a
> > - * trigger with :n (n = number of times the trigger should fire) and
> > - * the parsing continues normally; otherwise the function just returns
> > - * and assumes param just contains a filter and there's nothing else
> > - * to do.
> > + * passed-in param_and_filter: either the param is required, or
>
> As "param" did not have a "@" in front of it, that means it did not
> represent the parameter.
>
> > + * it is not required.  If @param_required is set, and there's no
> > + * param, it will return -EINVAL.  If @param_required is not set
> > + * and there's a param_and_filter that starts with a number, that
> > + * corresponds to the case of a trigger with :n (n = number of times
> > + * the trigger should fire) and the parsing continues normally;
> > + * otherwise the function just returns and assumes param_and_filter
> > + * just contains a filter and there's nothing else to do.
>
> And there's still more space to use, as the biggest line is only 70
> characters and we allow 80.
>
> -- Steve
>
> >   *
> >   * Return: 0 on success, errno otherwise
> >   */
>
I got it. Thanks for your review.