linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Yuanhan Liu <yuanhan.liu@linux.intel.com>,
	chris <chris@chris-wilson.co.uk>
Subject: Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters
Date: Tue, 08 Mar 2011 21:01:17 -0500	[thread overview]
Message-ID: <1299636077.20306.132.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20110309011716.GB3664@Krystal>

On Tue, 2011-03-08 at 20:17 -0500, Mathieu Desnoyers wrote:

> I'm afraid I cannot say, at this point, which distro I am refering to, because
> that would be a little forward of me to push news before official feature
> announcements.

Well, I guess I'm safe at saying it aint Red Hat ;)

> 
> And about the "default" tracepoints, let's mainly think about tracepoints that
> would be specified from a trace control application. E.g. the user wants a type
> of tracing that collects all information required to solve a category of
> problem, and they get enabled automatically.

Well, since tracepoints can change (come and go), this tool had better
be very flexible.


> Well, thinking a little more about it, I won't be using this way of enabling
> tracepoints in my tracer, so please feel free to make it as simple as you like.
> I'm just providing feedback on what the ftrace/perf end user experience will
> look like and, sadly, it does not look good at all by the look of this proposal.

Sadly it matters what the point of this change was for. 1) this does not
affect the way perf enables/disable tracepoints. I'm sure it could
easily add a syscall interface that would keep a nice wall from the
user. 2) it was to enable tracing in ftrace as soon as a module is
loaded. Ideally from a modprobe, not boot time tracing. Although, I
probably could add something to for that too. But that would come later.


> I meant that distros can contain packages that are interested in a specific set
> of tracepoints (views/analysis are tracepoint data consumers), so they can
> specify a set of tracepoints to enable when tracing is activated.

Yep, and this patch is not aimed at that. I am interesting in things
that analyze specific data. But this patch was not something to address
that. And it could easily exist with other means that do.

> > 
> > But that's a good question. As I wrote this because I'm purging my inbox
> > and came across Yuanhan Liu's patch set. I'm curios to what Yuanhan's
> > motivation for this change was.
> 
> Yep.

Yep, I'm looking forward to a response. For myself, I like this patch
because there has been times I needed to enable a tracepoint as soon as
the module was loaded and not a long time afterward (which is what
happens when you do modprobe and echo by hand).

> 
> Hopefully my feedback can be of some use.

For who?

-- Steve



  reply	other threads:[~2011-03-09  2:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-08 22:18 [PATCH][RFC] tracing: Enable tracepoints via module parameters Steven Rostedt
2011-03-08 22:42 ` Steven Rostedt
2011-03-08 23:22 ` Mathieu Desnoyers
2011-03-08 23:32   ` Steven Rostedt
2011-03-09  0:07     ` Mathieu Desnoyers
2011-03-09  0:14       ` Steven Rostedt
2011-03-09  0:29         ` Mathieu Desnoyers
2011-03-09  0:52           ` Steven Rostedt
2011-03-09  1:17             ` Mathieu Desnoyers
2011-03-09  2:01               ` Steven Rostedt [this message]
2011-03-09  2:30                 ` Mathieu Desnoyers
2011-03-09  2:01             ` Yuanhan Liu
2011-03-09  2:12               ` Steven Rostedt
2011-03-09  2:19                 ` Yuanhan Liu
2011-03-10 23:33 ` Rusty Russell
2013-08-13 15:14   ` Steven Rostedt
2013-08-13 22:34     ` Mathieu Desnoyers
2013-08-13 23:09       ` Steven Rostedt
2013-08-15  2:02     ` Rusty Russell
2013-08-15  3:32       ` Steven Rostedt
2021-04-19 21:54         ` Williams, Dan J
2021-04-19 22:11           ` Steven Rostedt
2021-04-20  1:25             ` Dan Williams
2021-04-20 12:55               ` Steven Rostedt
2021-04-20 13:29                 ` Mathieu Desnoyers
2021-04-20 14:55                   ` Steven Rostedt
2021-04-20 15:15                     ` Mathieu Desnoyers
2021-04-20 15:34                       ` Steven Rostedt
2021-04-20 19:54                 ` Dan Williams
2021-04-20 20:32                   ` Steven Rostedt
2021-04-21  6:27                     ` Dan Williams
2021-04-21  7:30                     ` Rasmus Villemoes
2021-04-21 14:20                       ` Steven Rostedt
2021-04-21 14:50                         ` Rasmus Villemoes
2021-04-21 15:00                           ` Steven Rostedt

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=1299636077.20306.132.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=yuanhan.liu@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).