[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1305023588.2971.6.camel@frodo>
Date: Tue, 10 May 2011 06:33:08 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: David Sharp <dhsharp@...gle.com>,
Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
Michael Rubin <mrubin@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Christoph Hellwig <hch@...radead.org>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: Fix powerTOP regression with 2.6.39-rc5
On Tue, 2011-05-10 at 10:47 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > [...] Thus a library is a perfect solution. [...]
>
> Btw., just to make things clear, if we indeed have a library to parse things
> and if all apps use that then the ABI moves to another (library) level.
>
> The requirement from my maintenance POV is very, very simple: apps should not
> break on new kernels. If this is achieved by making apps smarter then that's a
> valid solution.
>
Great! Because this is what I want. I would also want a way to designate
events as stable. I'll add a TRACE_EVENT_STABLE() that can only have the
events that maintainers agree to maintain. And give the apps an ability
to only see these. Have the other events need either a separate library,
or perhaps just separate calls from within the same library, so the XFS
developers can feel safe that their tracepoints will not be depended on.
And perhaps have two tracepoints for sched_switch such that Peter
Zijlsta is happy that he's not bound by an tracepoint that keeps him
from getting rid of FIFO ;)
I'm happy to write a libperf.so and I can discuss with Arnaldo, Arjan
and yourself what is the best way of doing this.
Thanks,
-- Steve
--
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