linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH v4 3/5] trace-cmd: Load libtraceevent plugins from build folder, if exists.
Date: Fri, 4 Oct 2019 11:09:14 -0400	[thread overview]
Message-ID: <20191004110914.011edb67@gandalf.local.home> (raw)
In-Reply-To: <20191004133647.27759-4-tz.stoyanov@gmail.com>

On Fri,  4 Oct 2019 16:36:45 +0300
"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com> wrote:

> When a development version of trace-cmd is built and run on the machine,
> by default it loads only installed plugins, from system directories.
> Thus, the development plugins will not be loaded. To simplify the development
> process, a new logic is added:
>   At plugins load time, check the location of trace-cmd application and look
>   for "plugins" directory around it. If found, load plugins from it. Those
>   plugins will be loaded last, so in case of duplication the "development"
>   plugins win.
> A two new APIs are introduced to libtraceevent, in order to accomplish this
> logic:
>  tep_load_plugins_dir() - loads tep plugins from a specific directory.
>  tep_plugins_append() - Append two plugin lists.

We should probably break this patch up into two. One that adds the new
interface to libtraceevent (making it easier to send to upstream
libtraceevent), and then one that uses it in trace-cmd.

And we should probably update the man pages when adding the tep_*()
patches. That said, I have some comments about this.

> 
> Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>


> diff --git a/lib/trace-cmd/trace-util.c b/lib/trace-cmd/trace-util.c
> index b08e377..5a84fc3 100644
> --- a/lib/trace-cmd/trace-util.c
> +++ b/lib/trace-cmd/trace-util.c
> @@ -884,6 +884,52 @@ void trace_util_free_plugin_files(char **files)
>  	free(files);
>  }
>  
> +static char *get_source_plugins_dir(void)
> +{
> +	char *p, path[PATH_MAX+1];
> +	int ret;
> +
> +	ret = readlink("/proc/self/exe", path, PATH_MAX);
> +	if (ret > PATH_MAX || ret < 0)
> +		return NULL;
> +
> +	dirname(path);
> +	p = strrchr(path, '/');
> +	if (!p)
> +		return NULL;
> +	/* Check if we are in the the source tree */
> +	if (strcmp(p, "/tracecmd") != 0)
> +		return NULL;
> +
> +	strcpy(p, "/lib/traceevent/plugins");
> +	return strdup(path);
> +}
> +
> +struct tep_plugin_list*
> +trace_load_tep_plugins(struct tep_handle *tep)
> +{
> +	struct tep_plugin_list *list_dev;
> +	struct tep_plugin_list *list;
> +	char *path;
> +
> +	if (tracecmd_disable_plugins)
> +		tep_set_flag(tep, TEP_DISABLE_PLUGINS);
> +	if (tracecmd_disable_sys_plugins)
> +		tep_set_flag(tep, TEP_DISABLE_SYS_PLUGINS);
> +
> +	list = tep_load_plugins(tep);
> +
> +	path = get_source_plugins_dir();
> +	if (path) {
> +		list_dev = tep_load_plugins_dir(tep, path);
> +		tep_plugins_append(list_dev, list);
> +		list = list_dev;
> +		free(path);

I think it would be better to be able to add paths to the tep, and then
call "tep_load_plugins()". That is:

	path = get_source_plugins_dir();
	if (path)
		tep_add_plugin_path(tep, path);

	list = tep_load_plugins(tep);

And have the tep_load_plugins() do all the work, and not have a
tep_plugins_append(). That append function is exposing too much of the
implementation of the tep code.

-- Steve

> +	}
> +
> +	return list;
> +}
> +
>  char *tracecmd_get_tracing_file(const char *name)
>  {
>  	static const char *tracing;
>

  reply	other threads:[~2019-10-04 15:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 13:36 [PATCH v4 0/5] Remove redundant trace-cmd plugin handling logic Tzvetomir Stoyanov (VMware)
2019-10-04 13:36 ` [PATCH v4 1/5] trace-cmd: Move libtraceevent plugins in its own directory Tzvetomir Stoyanov (VMware)
2019-10-04 13:36 ` [PATCH v4 2/5] trace-cmd: Rename plugin_python to plugin_python_loader Tzvetomir Stoyanov (VMware)
2019-10-04 13:36 ` [PATCH v4 3/5] trace-cmd: Load libtraceevent plugins from build folder, if exists Tzvetomir Stoyanov (VMware)
2019-10-04 15:09   ` Steven Rostedt [this message]
2019-10-04 13:36 ` [PATCH v4 4/5] trace-cmd: Change plugin install directories Tzvetomir Stoyanov (VMware)
2019-10-04 13:36 ` [PATCH v4 5/5] trace-cmd: Add initial infrastructure for trace-cmd specific plugins Tzvetomir Stoyanov (VMware)
2019-10-04 14:46 ` [PATCH v4 0/5] Remove redundant trace-cmd plugin handling logic Steven Rostedt
2019-10-04 14:48   ` 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=20191004110914.011edb67@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-trace-devel@vger.kernel.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).