This is the mail archive of the
mailing list for the systemtap project.
Re: [PATCH] Linux Kernel Markers
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Paul Mundt <lethal at linux-sh dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Andrew Morton <akpm at osdl dot org>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, "Martin J. Bligh" <mbligh at mbligh dot org>, Ingo Molnar <mingo at elte dot hu>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com
- Date: Wed, 20 Sep 2006 22:20:27 +0900
- Subject: Re: [PATCH] Linux Kernel Markers
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <20060918234502.GA197@Krystal>
Mathieu Desnoyers wrote:
> Following this huge discussion thread, I tried to come with a marker mechanism
> (which is something everyone seems to agree that is a necessity) that would be
> useful to each kind of tracing (dynamic and static) (concerned projects :
> SystemTAP, LKET, LKST, LTTng) and even combinations of those. Religious
> considerations aside, I really think that this kind of generic markup is
> necessary to fill *everybody*'s need. If I forgot about a specific genericity
> aspect, please tell me.
> I take for agreed that both static and dynamic tracing are useful for different
> needs and that a full markup must support both and combinations, letting the
> user or the distribution choose.
Basically, I like this static marker concept.
But I wonder why wouldn't you use the architecture-independent
marker which SystemTap already supports.
If we use NOPs, it highly depends on architecture, and is hard
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory