linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Cc: Sameeruddin shaik <sameeruddin.shaik8@gmail.com>,
	Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH v3] libtracefs: An API to set the filtering of functions
Date: Mon, 22 Mar 2021 09:39:08 -0400	[thread overview]
Message-ID: <20210322093908.41cd89de@gandalf.local.home> (raw)
In-Reply-To: <CAPpZLN5SSxa2ZwnE1G3iuk2uuvm0JaP_N92esJKqL=zSDwCruQ@mail.gmail.com>

On Thu, 18 Mar 2021 19:22:26 +0200
Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:

> Looks good to me.
> Thanks Sameer!
> Acked-by: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>

Thanks Semeer,

I'm applying version 3 of your patch.

As Tzvetomir said:

> I consider this patch as a good foundation for the API, but we should
> work on some optimizations on top of it, in separate patches. What
> else should be added, when this patch is merged:
>  1. A unit test of the API
>  2. Man page of the API

Feel free to send us a unit test of the API, that would be most useful.

You can also work on a man page as well.

>  3. Optimizations: new kernels support writing indexes instead of
> strings into the "set_ftrace_filter" file. This is faster, as there is
> no string comparison in the kernel context. The function index can be
> retrieved from "available_filter_functions" files - the first function
> is with index 0, the next is 1 ... and so forth. So, the possible
> optimization of the API is to check - if the kernel supports indexes,
> use it, or fail back to the legacy logic with strings.

There was a task I had where I needed the above work completed and had to
write it myself. Since it is already completed, there's no reason to have
you work on something that is not needed anymore. The code I wrote only
works for Linux kernels 5.1 and beyond. The code you wrote here is needed
for kernels older than that. Knowing that you were working on this code, I
just tested if the optimization existed, and if not, it would fail. Now I
can make it fall back to your code instead of failing.

As the man pages and the unit tests are still needed, we are looking
forward for your continued contribution to the tracing libraries.

Thanks!

-- Steve

      parent reply	other threads:[~2021-03-22 13:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 16:38 [PATCH v3] libtracefs: An API to set the filtering of functions Sameeruddin shaik
2021-03-18 17:22 ` Tzvetomir Stoyanov
2021-03-21  0:35   ` Sameeruddin Shaik
2021-03-22 13:39   ` Steven Rostedt [this message]

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=20210322093908.41cd89de@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=sameeruddin.shaik8@gmail.com \
    --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).