From: Andi Kleen <andi@firstfloor.org>
To: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, srikar@linux.vnet.ibm.com,
peterz@infradead.org, oleg@redhat.com,
hegdevasant@linux.vnet.ibm.com, mingo@redhat.com,
anton@redhat.com, systemtap@sourceware.org, namhyung@kernel.org,
masami.hiramatsu.pt@hitachi.com, aravinda@linux.vnet.ibm.com,
penberg@iki.fi
Subject: Re: [PATCH v2 1/3] perf/sdt : Listing of SDT markers by perf
Date: Fri, 18 Jul 2014 10:50:45 -0700 [thread overview]
Message-ID: <87d2d24kui.fsf@tassilo.jf.intel.com> (raw)
In-Reply-To: <20140717055341.19995.97042.stgit@hemant-fedora> (Hemant Kumar's message of "Thu, 17 Jul 2014 11:25:12 +0530")
Hemant Kumar <hemant@linux.vnet.ibm.com> writes:
First I should say supporting these probes is very useful. Thanks for
working on this.
> +
> +#define SDT_CACHE_DIR "/var/cache/perf/"
This requires running perf as root, right?
It would be better to use the $HOME cache dir, like the recent JSON patches.
> +#define SDT_CACHE "perf-sdt.cache"
> +#define SDT_CACHE_TMP "perf-sdt.cache.tmp"
> +
> +#define DELIM ':'
> +
> +struct path_list {
> + char path[PATH_MAX];
> + struct list_head list;
> +} execs;
> +
> +/* Write operation for cache */
> +static void write_cache(FILE *cache, char *buffer)
> +{
> + fprintf(cache, "%s", buffer);
> +}
> +
The function seems redundant.
> +/*
> + * get_sdt_note_info() is the function actually responsible for
> + * flushing the SDT notes info into the "cache" file or to the
> + * stdout if "cache" points to NULL. Also, this function finds out
> + * the build-id of an ELF to be written into "cache".
> + */
> +static void get_sdt_note_info(struct list_head *start, const char *target,
> + FILE *cache)
> +{
> + struct sdt_note *pos;
> + u8 build_id[BUILD_ID_SIZE];
> + char sbuild_id[BUILD_ID_SIZE * 2 + 1];
> + char buffer[2 * PATH_MAX];
> +
> + if (list_empty(start))
> + return;
> +
> + /* Read the build id of the file */
> + if (filename__read_build_id(target, &build_id,
> + sizeof(build_id)) < 0) {
> + pr_debug("Couldn't read build-id in %s\n", target);
pr_info ?
> +
> +/*
> + * Finds out the libraries present in a system as shown by the command
> + * "ldconfig --print-cache". Uses "=>" and '/' to find out the start of a
> + * dso path.
> + */
This seems like a hack. How would that handle chroot, containers etc. ?
> +static inline void append_path(char *path, struct list_head *list)
> +{
> + char *res_path = NULL;
> + struct path_list *tmp = NULL;
> +
> + res_path = (char *)malloc(sizeof(char) * PATH_MAX);
> +
> + if (!res_path)
> + return;
> +
> + memset(res_path, '\0', PATH_MAX);
> +
> + if (realpath(path, res_path) && !is_present_in_list(list, res_path)) {
O^2 algorithm ?
> +/*
> + * Obtain the list of paths from the PATH env variable
> + */
Same as above. This probably needs to be more configurable to handle
more ways to find binaries.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
next prev parent reply other threads:[~2014-07-18 17:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 5:53 [PATCH v2 0/3] perf/sdt : Support for SDT markers Hemant Kumar
2014-07-17 5:55 ` [PATCH v2 1/3] perf/sdt : Listing of SDT markers by perf Hemant Kumar
2014-07-18 17:50 ` Andi Kleen [this message]
2014-07-20 3:17 ` Masami Hiramatsu
2014-07-21 2:38 ` Namhyung Kim
2014-07-21 9:40 ` Hemant Kumar
2014-07-22 11:53 ` Hemant Kumar
2014-07-21 3:01 ` Namhyung Kim
2014-07-22 11:33 ` Hemant Kumar
2014-07-17 5:56 ` [PATCH v2 2/3] perf/sdt: Listing SDT markers for a single file Hemant Kumar
2014-07-17 5:56 ` [PATCH v2 3/3] perf/sdt: Documentation Hemant Kumar
2014-07-18 11:23 ` [PATCH v2 0/3] perf/sdt : Support for SDT markers Masami Hiramatsu
2014-07-19 17:32 ` Hemant Kumar
2014-07-20 3:16 ` Masami Hiramatsu
2014-07-21 2:29 ` Namhyung Kim
2014-07-21 12:24 ` Hemant Kumar
2014-07-22 5:30 ` Masami Hiramatsu
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=87d2d24kui.fsf@tassilo.jf.intel.com \
--to=andi@firstfloor.org \
--cc=anton@redhat.com \
--cc=aravinda@linux.vnet.ibm.com \
--cc=hegdevasant@linux.vnet.ibm.com \
--cc=hemant@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=penberg@iki.fi \
--cc=peterz@infradead.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=systemtap@sourceware.org \
/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