mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <srostedt@redhat.com>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>, Jiri Olsa <jolsa@redhat.com>,
	Arun Sharma <asharma@fb.com>, Namhyung Kim <namhyung.kim@lge.com>
Subject: Re: [PATCH 02/15] tools/events: Add files to create libtraceevent.a
Date: Wed, 11 Apr 2012 11:38:10 -0400	[thread overview]
Message-ID: <1334158690.23924.252.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20120411152059.GE16257@infradead.org>

On Wed, 2012-04-11 at 12:20 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 06, 2012 at 12:47:53AM +0200, Frederic Weisbecker escreveu:
> > From: Steven Rostedt <srostedt@redhat.com>
> > +struct cmdline {
> > +	char *comm;
> > +	int pid;
> > +};
> 
> In perf we have 'struct thread' for that and some more stuff, they are
> kept in an rb_tree located in a 'struct machine', 'machine's exist to
> support KVM.
> 
> At some point would be good to avoid this, but then it would make this
> code need parts of perf, that would have to then be moved to
> tools/libsymbol/ or some other more suitable name.

Agreed, this can be broken out too. Lets see if we can get the code in
first, and then start fixing it. As said, this would be the smoothest
transition of getting trace-cmd libary into perf. As it has been tested
quit intensively. Note, perf already has an older version built in. And
does most of this nastiness already.
 
> 
> > +static int cmdline_cmp(const void *a, const void *b)
> > +{
> > +	const struct cmdline *ca = a;
> > +	const struct cmdline *cb = b;
> > +
> > +	if (ca->pid < cb->pid)
> > +		return -1;
> > +	if (ca->pid > cb->pid)
> > +		return 1;
> > +
> > +	return 0;
> > +}
> > +
> > +struct cmdline_list {
> > +	struct cmdline_list	*next;
> > +	char			*comm;
> > +	int			pid;
> > +};
> > +
> > +static int cmdline_init(struct pevent *pevent)
> > +{
> > +	struct cmdline_list *cmdlist = pevent->cmdlist;
> > +	struct cmdline_list *item;
> > +	struct cmdline *cmdlines;
> > +	int i;
> > +
> > +	cmdlines = malloc_or_die(sizeof(*cmdlines) * pevent->cmdline_count);
> 
> My biggest pet peeve, looks like this is New Hampshire code, all these
> "do foo or die" strikes a nerve in me :-(
> 
> Die calls in library code should just... die.

I also agree :-) We can keep this for now, and then nuke it in the next
patch. But to do so, would require an audit of this code. I could do the
work in trace-cmd, and then we could port it. Or we can port this as is,
and then update it.

The one thing I really wish C had, was the try/catch of C++. That would
solve the error code issue. But for now we need to do it with goto's and
such.

> 
> Only tools can die, libraries just can't, IMHO.
> 
> > +struct func_map {
> > +	unsigned long long		addr;
> > +	char				*func;
> > +	char				*mod;
> > +};
> > +
> > +struct func_list {
> > +	struct func_list	*next;
> > +	unsigned long long	addr;
> > +	char			*func;
> > +	char			*mod;
> > +};
> 
> For this we have tools/perf/utils/symbol.c, that supports userland as
> well as java JIT maps, etc. The perf.data file doesn't have to carry a
> copy of kallsyms, etc, build-id support is there to make sure we don't
> misresolve symbols using the right DSO found in a cache or in -debuginfo
> packages, etc.

This could be cleaned up too. Currently perf uses this code for the sw
events (aka tracepoints) of the kernel. The func_map and friends are
already used in perf.

> 
> > +int pevent_register_function(struct pevent *pevent, char *func,
> > +			     unsigned long long addr, char *mod)
> > +{
> > +	struct func_list *item;
> > +
> > +	item = malloc_or_die(sizeof(*item));
> > +
> > +	item->next = pevent->funclist;
> > +	item->func = strdup(func);
> > +	if (mod)
> > +		item->mod = strdup(mod);
> > +	else
> > +		item->mod = NULL;
> 
> strdup can fail, and no, we shouldn't die if that happens :-)

Again, this all needs to be audited. But this isn't much different than
what perf already does with the tools/perf/util/trace-event-parse.c

Thus, getting the code out can be the first step. Cleaning it up into a
nice library the second.

-- Steve




  reply	other threads:[~2012-04-11 15:38 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05 22:47 [RFC][PATCH 00/15] tools: Unify perf and trace-cmd trace event format parsing v2 Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 01/15] perf: Separate out trace-cmd parse-events from perf files Frederic Weisbecker
2012-04-06 11:36   ` Borislav Petkov
2012-04-06 15:23     ` Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 02/15] tools/events: Add files to create libtraceevent.a Frederic Weisbecker
2012-04-06  0:08   ` David Ahern
2012-04-06  0:18     ` Steven Rostedt
2012-04-06  0:24       ` David Ahern
2012-04-06 11:40   ` Borislav Petkov
2012-04-06 13:21   ` Borislav Petkov
2012-04-06 22:15     ` Steven Rostedt
2012-04-07  9:08       ` Borislav Petkov
2012-04-11 15:20   ` Arnaldo Carvalho de Melo
2012-04-11 15:38     ` Steven Rostedt [this message]
2012-04-11 17:47       ` Frederic Weisbecker
2012-04-11 17:54       ` Arnaldo Carvalho de Melo
2012-04-05 22:47 ` [PATCH 03/15] perf: Build libtraceevent.a Frederic Weisbecker
2012-04-06 11:45   ` Borislav Petkov
2012-04-06 15:26     ` Frederic Weisbecker
2012-04-06 15:51       ` Borislav Petkov
2012-04-09 17:10         ` Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 04/15] events: Update tools/lib/traceevent to work with perf Frederic Weisbecker
2012-04-06 11:48   ` Borislav Petkov
2012-04-09 17:11     ` Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 05/15] perf: Have perf use the new libtraceevent.a library Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 06/15] perf/events: Add flag to produce nsec output Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 07/15] perf/events: Add flag/symbol format_flags Frederic Weisbecker
2012-04-05 22:47 ` [PATCH 08/15] perf/events: Correct size given to memset Frederic Weisbecker
2012-04-06 11:24   ` Borislav Petkov
2012-04-06 12:00     ` Borislav Petkov
2012-04-06 12:27       ` Steven Rostedt
2012-04-05 22:48 ` [PATCH 09/15] parse-events: Handle invalid opcode parsing gracefully Frederic Weisbecker
2012-04-05 22:48 ` [PATCH 10/15] parse-events: Handle opcode parsing error Frederic Weisbecker
2012-04-05 22:48 ` [PATCH 11/15] parse-events: Let pevent_free() take a NULL pointer Frederic Weisbecker
2012-04-05 22:48 ` [PATCH 12/15] parse-events: Support '+' opcode in print format Frederic Weisbecker
2012-04-05 22:48 ` [PATCH 13/15] parse-events: Allow '*' and '/' operations in TP_printk Frederic Weisbecker
2012-04-05 22:48 ` [PATCH 14/15] parse-event: Fix memset pointer size bug in handle Frederic Weisbecker
2012-04-05 22:48 ` [PATCH 15/15] parse-events: Rename struct record to struct pevent_record Frederic Weisbecker
2012-04-06  3:07 ` [RFC][PATCH 00/15] tools: Unify perf and trace-cmd trace event format parsing v2 David Sharp
2012-04-06 15:11   ` Frederic Weisbecker
2012-04-09 10:13 ` Namhyung Kim
2012-04-23 14:47 ` Our failure on tracing tools unification (Was: Re: [RFC][PATCH 00/15] tools: Unify perf and trace-cmd trace event format parsing v2) Frederic Weisbecker
2012-04-23 15:08   ` Peter Zijlstra
2012-04-23 15:31     ` Steven Rostedt
2012-04-23 16:07       ` Borislav Petkov
2012-04-24  9:10     ` Thomas Gleixner
2012-04-25  8:05     ` Ingo Molnar
2012-04-25 12:39       ` Frederic Weisbecker
2012-04-25 14:19       ` Our failure on tracing tools unification Frank Ch. Eigler
2012-04-25 16:37         ` Arnaldo Carvalho de Melo
2012-04-25 12:26 [PATCH 00/15] tools: Unify perf and trace-cmd trace event format parsing v3 Frederic Weisbecker
2012-04-25 12:26 ` [PATCH 02/15] tools/events: Add files to create libtraceevent.a Frederic Weisbecker

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=1334158690.23924.252.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=acme@infradead.org \
    --cc=asharma@fb.com \
    --cc=bp@alien8.de \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung.kim@lge.com \
    --cc=peterz@infradead.org \
    --cc=srostedt@redhat.com \
    --cc=tglx@linutronix.de \
    /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

all inboxes | Powered by JetHome®