All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
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, 8 Mar 2011 19:29:21 -0500	[thread overview]
Message-ID: <20110309002921.GA744@Krystal> (raw)
In-Reply-To: <1299629657.20306.105.camel@gandalf.stny.rr.com>

* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Tue, 2011-03-08 at 19:07 -0500, Mathieu Desnoyers wrote:
> 
> > So what you are saying here is that modifying /etc/modprobe.d/ is the actual
> > interface you propose presenting to the end-users to control their tracepoints ?
> 
> If you want to have them enabled on boot, sure.

No, I'm not talking about enabling tracepoints on boot here. Let's think about a
basic use-case: a distro packages a tracer, and provides a "default" set of
tracepoints that can be enabled when tracing is needed. Therefore, these
tracepoints are not enabled at boot -- they are rather enabled when tracing
starts. Some of these tracepoints are in dynamically loaded modules. Some of
these modules are automatically loaded by the distro (e.g. when a USB device is
plugged in).

The specific module tracepoints should therefore only be enabled when both of
the following conditions are true:

A - the end-user want to trace
B - the module is loaded

But it looks like hooking on modinfo will only let you unconditionally enable
the module tracepoints during normal system operations (even when tracing is
off), or not at all unless you previously load the module (which does not fit
with the reality of distributions automagically loading modules on demand while
tracing runs).

> 
> > Maybe I am missing something, but this interface seems to lack the layer of
> > finish we might want to put into a user-visible API. I don't really see how
> > distributions can hope to automate any of this for their end-user without making
> > a mess of the /etc/modprobe.d/ they ship with.
> 
> What distros enable tracepoints by default?

Do you mean enable as having a probe connected, or just CONFIG_TRACEPOINTS=y ?

> 
> If you want to enable a tracepoint on module load simply do:
> 
>  modprobe mymod trace_my_tracepoint=1
> 
> Otherwise modify your modprobe.d directory. This is the way users have
> been doing module parameters for years.
> 
> That's pretty simple to me.

Everything is always so much easier when your end-user target is yourself.
What are users for anyway ? :-P

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2011-03-09  0:29 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 [this message]
2011-03-09  0:52           ` Steven Rostedt
2011-03-09  1:17             ` Mathieu Desnoyers
2011-03-09  2:01               ` Steven Rostedt
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=20110309002921.GA744@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --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 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.