All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: vincent.donnefort@arm.com
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH] trace-cmd: Add support for built-in plugins
Date: Mon, 11 Nov 2019 18:02:24 -0500	[thread overview]
Message-ID: <20191111180224.2992867b@gandalf.local.home> (raw)
In-Reply-To: <1573126532-373130-1-git-send-email-vincent.donnefort@arm.com>


Hi Vincent,

On Thu,  7 Nov 2019 11:35:32 +0000
vincent.donnefort@arm.com wrote:

> From: Vincent Donnefort <vincent.donnefort@arm.com>
> 
> When building trace-cmd with the -static option, plugins might not work, if
> the shared version for the Glibc is not available on the system. To still
> give a chance to have plugins, a new built-in mechanism is introduced.
> 
> The built-in build support for a plugin can be easily enabled with the
> declaration:
> 
>  TEP_PLUGIN(plugin_name)
>  {
>          plugin_init()
>  }
> 
>  /* optional */
>  TEP_PLUGIN(plugin_name)
>  {
>          plugin_exit()
>  }
> 
> Enabling as a first step, blk and sched_switch plugins as built-in.

I don't have a problem with the idea of this patch. My concern is that
the code in lib/traceevent will soon be obsoleted by using the
libtraceevent library in the Linux kernel under tools/lib/traceevent.

That means when we transition to the libtraceevent library, this work
will be lost.

Instead, could this be added to tools/lib/traceevent in the Linux
kernel somehow, and instead of building it into the executable, perhaps
make it part of the libtraceevent.a file (the static version of the
libary).

Thoughts?

-- Steve



      reply	other threads:[~2019-11-11 23:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07 11:35 [PATCH] trace-cmd: Add support for built-in plugins vincent.donnefort
2019-11-11 23:02 ` 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=20191111180224.2992867b@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=vincent.donnefort@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.