linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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]

Message-ID: <20060915123856.GA32076@elte.hu>
Date:	Fri, 15 Sep 2006 14:38:56 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Martin J. Bligh" <mbligh@...igh.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>, fche@...hat.com
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108


* Martin J. Bligh <mbligh@...igh.org> wrote:

> >i.e. we should have macros to prepare local information, with macro 
> >arities of 2, 3, 4 and 5:
> >
> >    _(name, data1);
> >   __(name, data1, data2);
> >  ___(name, data1, data2, data3);
> > ____(name, data1, data2, data3, data4);
> 
> Personally I think that's way more visually offensive that something 
> that looks like a function call, but still ;-) We do it as a caps 
> macro
> 
> KTRACE(foo, bar)
> 
> internally, which I suppose makes it not look like a function call. 
> But at the end of the day, it's all just a matter of visual taste, 
> what's actually in there is way more important.

i disagree with the naming, for the reasons stated before: if we add any 
static info to the kernel, it's a "easier data extraction" thing (for 
the purposes of speeding up dynamic tracing), not a tracepoint. That way 
there's no dispute whether what i remove is a tracepoint (on which 
static tracers might rely in a hard way), or just a speedup for 
SystemTap. So a better name would be what SystemTap has implemented 
today:

  STAP_MARK_NN(kernel_context_switch, prev, next);

or what makes this even more explicit:

  DEBUG_DATA(kernel_context_switch, prev, next);

(but i'm flexible about the naming - as long as it doesnt say 'trace' 
and as long as there are no guarantees at all that those points remain, 
when a better method of accessing the same data for dynamic tracers is 
implemented.)

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