[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141014140223.GC3198@kernel.org>
Date: Tue, 14 Oct 2014 11:02:23 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Jiri Olsa <jolsa@...hat.com>
Cc: Jean Pihet <jean.pihet@...aro.org>, Borislav Petkov <bp@...en8.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Fu Wei <fu.wei@...aro.org>, Robert Richter <rric@...nel.org>,
David Ahern <dsahern@...il.com>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 1/1] rasd: Use perf_evlist__open() instead of open coded
Em Tue, Oct 14, 2014 at 03:56:31PM +0200, Jiri Olsa escreveu:
> On Mon, Oct 13, 2014 at 09:29:57AM +0200, Jean Pihet wrote:
> > On 10 October 2014 22:44, Borislav Petkov <bp@...en8.de> wrote:
> > > On Fri, Oct 10, 2014 at 05:41:58PM -0300, Arnaldo Carvalho de Melo wrote:
> > >> That way we just make public the bare minimum that already proved to be
> > >> useful outside tools/perf/ and over time we move stuff from
> > >> tools/perf/util/evsel.c (and from other tools in or out perf's repo)
> > >> into the lib.
> > That is great!
> > About rasd usage, there are some details at
> > https://wiki.linaro.org/LEG/Engineering/Kernel/perfAndRAS#rasd_implementation.
> sorry for late reply.. I was on vacation last week..
> I read the rasd sources and realized we could poke this
> from another angle.. AFAIU the work the rasd does is following:
> - reads config file and opens configured tracepoints
> - reads samples comming from those tracepoints and displays/writes
> this data to the console/file
> - is there more?
> If I'm not missing anything, this is quite usefull/common usage
> pattern which would deserve new perf command.
> I can see the analogy with ftrace debugfs interface
> - choose/enable tracepoints
> - cat .../tracing/trace-pipe
> and there could be '-d' for the command to act as daemon.
Right, this is to be integrated into 'trace', i.e. to be able to ask for
more events, some with callchains, some without, etc.
We may even have something really bare bones that does what rasd.c does
right now, to show how one can write a tool using the exported
interfaces in tools/lib/api/, but I think that what rasd is _right now_,
is just an attempt to use the libraries using as few as possible apis,
right? I.e. more "meat" will be added there, no?
Anyway, its beeing an interesting exercise and will result in a lot of
untanglement, which is good in any case.
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists