linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sameeruddin Shaik <sameeruddin.shaik8@gmail.com>
To: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH] libtracefs: An API to set the filtering of functions
Date: Tue, 2 Mar 2021 10:44:14 +0530	[thread overview]
Message-ID: <CAK7tX=Zn-pj2-+6Y_JwCgUraiVCVz7uc28WYP27wJuKURhYsuQ@mail.gmail.com> (raw)
In-Reply-To: <CAPpZLN7XLeOqTqBZZDetyL9Wc32dDNd0Gd8yBcET7Pd3qUYRcw@mail.gmail.com>

> Let's fix the number of parameters to this function:)

>> Not sure what you mean by that.
Actually i meant this ""int tracefs_function_filter(struct
tracefs_instance *instance,
                                    const char * const * filters,
                                    const char * module, bool reset,
                                    const char * const ** errs);""
For every patch, a parameter is increasing in this API.

> let's return the number of bytes written, also we will calculate the
> complete filters length and return it, if there is difference,
> we will loop into the integer array and print the erroneous filters

>>Not sure how that is helpful. How would you use the number of bytes
>>written?

We will return the number of bytes written and we also store the total
length of strings
in filters array, in one pointer variable, we will check the
difference between bytes written
and the total length of the strings, if there is difference we will
print failed filters otherwise
we will not print anything.

>It is very useful to have a way to report back the failed filters.
>Using an array
>of strings will work for this API, but I was thinking somehow to leverage the
>error_log file by the ftrace itself. Currently it does not report any
>error, just
>returns EINVAL. In more complex filters it would be useful to log
>more detailed description of the problem in the error_log file.

This error_log is also a good idea.

If possible let's have a live discussion on this API,so that we can
discuss the corner cases in the design
more efficiently and we can close it ASAP.

Thanks,
sameer shaik.

Thanks,
sameer shaik


On Tue, Mar 2, 2021 at 9:52 AM Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
>
> On Mon, Mar 1, 2021 at 10:40 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Tue,  2 Mar 2021 22:45:10 +0530
> > Sameeruddin shaik <sameeruddin.shaik8@gmail.com> wrote:
> >
> > > This new API will write the function filters into the
> > > set_ftrace_filter file, it will write only string as of now, it can't
> > > handle kernel glob or regular expressions.
> >
> > The limitation of no glob or regular expressions is fine. We can add that
> > in future patches.
> >
> > >
> > > tracefs_function_filter()
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=210643
> > >
> > > Signed-off-by: Sameeruddin shaik <sameeruddin.shaik8@gmail.com>
> > >
> [ ... ]
> >
> > > +                     free(each_str);
> > > +                     continue;
> > > +             }
> > > +             size += write(fd, each_str, write_size);
> >
> > Need to check errors here, and we need a way to report that an error
> > happened for a string. Perhaps the API also needs to have an error message
> > pointer that is passed in? Or a bitmask that lets the user know which
> > filter failed?
> >
> > Tzvetomir, have any ideas on how to report back to the caller which filter
> > failed? Could just send back an array of strings of the filters that failed.
>
> It is very useful to have a way to report back the failed filters.
> Using an array
> of strings will work for this API, but I was thinking somehow to leverage the
> error_log file by the ftrace itself. Currently it does not report any
> error, just
> returns EINVAL. In more complex filters it would be useful to log
> more detailed description of the problem in the error_log file.
>
> [ ... ]
>
>
> --
> Tzvetomir (Ceco) Stoyanov
> VMware Open Source Technology Center

  reply	other threads:[~2021-03-03  0:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 17:15 [PATCH] libtracefs: An API to set the filtering of functions Sameeruddin shaik
2021-03-01 18:17 ` Steven Rostedt
2021-03-02  4:21   ` Tzvetomir Stoyanov
2021-03-02  5:14     ` Sameeruddin Shaik [this message]
2021-03-02 13:15       ` Steven Rostedt
2021-03-03  1:16   ` Sameeruddin Shaik
2021-03-02  1:28     ` Steven Rostedt
2021-03-04  8:59       ` Tzvetomir Stoyanov
2021-03-04  9:43         ` Sameeruddin Shaik
2021-03-06 11:20 Sameeruddin shaik
2021-03-05 12:20 ` Tzvetomir Stoyanov
2021-03-05 14:39   ` Steven Rostedt
2021-03-05 14:54     ` Steven Rostedt
2021-03-06  1:55       ` Sameeruddin Shaik
2021-03-06  3:39         ` Steven Rostedt
2021-03-06  4:29           ` Sameeruddin Shaik
2021-03-06  5:19             ` Steven Rostedt
2021-03-06 15:05         ` Steven Rostedt
2021-03-08 23:53           ` Sameeruddin Shaik
2021-03-10 16:21 Sameeruddin shaik
2021-03-10  5:28 ` Tzvetomir Stoyanov
2021-03-10 16:51 ` Sameeruddin Shaik
2021-03-10  5:28   ` Tzvetomir Stoyanov

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='CAK7tX=Zn-pj2-+6Y_JwCgUraiVCVz7uc28WYP27wJuKURhYsuQ@mail.gmail.com' \
    --to=sameeruddin.shaik8@gmail.com \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tz.stoyanov@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).