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, 08 Mar 2011 21:01:17 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
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

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

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