linux-kernel - Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Mar 2011 21:30:57 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
	chris <chris@...is-wilson.co.uk>
Subject: Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Tue, 2011-03-08 at 20:17 -0500, Mathieu Desnoyers wrote:
> 
> > 
> > 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.

The idea is that a tool activates a set of tracepoints, gather trace data, and
then use the metainformation to figure out which of the tracepoints it requested
are there. If some of the tracepoints it needs are not there, it bails out.

> 
> 
> > 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.

As long as this method of enabling TRACE_EVENT probes located in modules before
these are loaded does not become the single and only one, I'm fine with it. It
makes sense for the kernel-developer use-case. Although past experience taught
me to be careful about the "we'll allow better interfaces to come later"
approach.

[...]

> > 
> > Hopefully my feedback can be of some use.
> 
> For who?

For who CC'd me on this thread. ;-)

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/