From: Ingo Molnar <mingo@elte.hu>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Christoph Hellwig <hch@lst.de>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Li Zefan <lizf@cn.fujitsu.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Johannes Berg <johannes.berg@intel.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Tom Zanussi <tzanussi@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andi Kleen <andi@firstfloor.org>,
Masami Hiramatsu <mhiramat@redhat.com>,
Lin Ming <ming.m.lin@intel.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
Robert Richter <robert.richter@amd.com>
Subject: Re: [RFD] Future tracing/instrumentation directions
Date: Thu, 20 May 2010 13:42:18 +0200 [thread overview]
Message-ID: <20100520114218.GA15531@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1005201256420.3368@localhost.localdomain>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 20 May 2010, Frederic Weisbecker wrote:
> > On Thu, May 20, 2010 at 11:31:31AM +0200, Ingo Molnar wrote:
> > > - [ While it's still a long way off, if this trend continues
> > > we eventually might even be able to get rid of the
> > > /debug/tracing/ temporary debug API and get rid of
> > > the ugly in-kernel pretty-printing bits. This is
> > > good: it may make Andrew very happy for a change ;-)
> > >
> > > The main detail here to be careful of is that lots of
> > > people are fond of the simplicity of the
> > > /debug/tracing/ debug UI, so when we replace it we
> > > want to do it by keeping that simple workflow (or
> > > best by making it even simpler). I have a few ideas
> > > how to do this.
> >
> > How? We can emulate the /debug/tracing result with something
> > like perf trace, still that won't replace the immediate
> > availability of the result of any trace, which makes it
> > valuable for any simplest workflows.
>
> I'm a bit torn about this. I really like the availability of the ascii
> interface, but if we can come up with a very basic trace binary tool
> which can be built for deep embedded w/o requiring the world and some
> more libs to be available, then I might give up my resistance. Ideally
> it should be done so it can be easily integrated into busybox.
>
> I don't care whether I do
>
> echo 1 >/debug/..../XXX/enable
> cat /debug/tracing/trace
>
> or
>
> perfmini trace enable XXX
> perfmini trace dump
My suggestion for that flow is even shorter:
trace --enable XXX
trace
Plus:
trace --list
trace --enable
trace --disable
> as long as the tool is built in a way that it does not
> need updates when we add trace points or other
> functionality to the kernel.
Yeah, most definitely. The sysfs event_source class will
ensure that whatever (new) events are available propagate
through the tool and are available to it.
Thanks,
Ingo
next prev parent reply other threads:[~2010-05-20 11:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 17:51 [RFC] Unified Ring Buffer (Next Generation) Steven Rostedt
2010-05-19 18:10 ` Andi Kleen
2010-05-19 18:44 ` Steven Rostedt
2010-05-19 19:25 ` Andi Kleen
2010-05-19 19:38 ` Steven Rostedt
2010-05-19 18:47 ` Mathieu Desnoyers
2010-05-20 6:41 ` Andi Kleen
2010-05-20 13:48 ` Mathieu Desnoyers
2010-05-19 19:05 ` Mathieu Desnoyers
2010-05-20 9:31 ` [RFD] Future tracing/instrumentation directions Ingo Molnar
2010-05-20 10:07 ` Frederic Weisbecker
2010-05-20 11:07 ` Thomas Gleixner
2010-05-20 11:42 ` Ingo Molnar [this message]
2010-05-20 11:48 ` Ingo Molnar
2010-05-20 12:15 ` Frederic Weisbecker
2010-05-20 12:19 ` Theodore Tso
2010-05-20 11:36 ` Ingo Molnar
2010-05-20 13:06 ` Frederic Weisbecker
2010-05-20 14:38 ` Steven Rostedt
2010-05-20 15:04 ` Steven Rostedt
2010-05-20 20:12 ` Steven Rostedt
2010-05-21 17:49 ` Ingo Molnar
2010-05-24 20:13 ` Steven Rostedt
2010-05-21 9:24 ` Li Zefan
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=20100520114218.GA15531@elte.hu \
--to=mingo@elte.hu \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=efault@gmx.de \
--cc=fweisbec@gmail.com \
--cc=gorcunov@gmail.com \
--cc=hch@lst.de \
--cc=johannes.berg@intel.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@redhat.com \
--cc=ming.m.lin@intel.com \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tzanussi@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 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.