This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- Cc: Martin Bligh <mbligh at google dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, prasanna at in dot ibm dot com, Andrew Morton <akpm at osdl dot org>, Ingo Molnar <mingo at elte dot hu>, 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>, 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>, ltt-dev at shafik dot org, systemtap at sources dot redhat dot com, Alan Cox <alan at lxorguk dot ukuu dot org dot uk>, Jeremy Fitzhardinge <jeremy at goop dot org>, Karim Yaghmour <karim at opersys dot com>, Pavel Machek <pavel at suse dot cz>, Joe Perches <joe at perches dot com>, "Randy.Dunlap" <rdunlap at xenotime dot net>, "Jose R. Santos" <jrs at us dot ibm dot com>
- Date: 26 Sep 2006 12:39:38 -0400
- Subject: Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
- References: <20060925151028.GA14695@Krystal> <20060925160115.GE25296@redhat.com> <20060925232828.GA29343@Krystal>
Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> [...]
> > I believe [printf formatting directives] are not
> > quite general enough either e.g. to describe a raw binary blob.
>
> If you want to dump a raw binary blob, what about :
> MARK(mysubsys_myevent, "char %p %u", blobptr, blobsize); where %p is
> a pointer to an array of char and %u the length ?
That involves new conventions beyond printf. Why not "%p %p %u %u"
for two blobs ... or why implicitly dereference the given pointers. A
probe handler unaware of a specific marker's semantics would not know
whether or not this is implied.
> My idea is to use the string to identify what is referred by a
> pointer, so it can be casted into this type with some kind of
> coherency between the marker and the probe.
I understand what you're using them for. To me, they just don't look
like a good fit.
> > I realize they serve a useful purpose in abbreviating what otherwise
> > one might have to do (like that multiplicity of STAP_MARK_* type/arity
> > permutations). [...]
>
> I think that duplicating the number of marker macros could easily make
> them unflexible and ugly. [...]
Inflexible and ugly in what way? Remember, the macro definitions can
be automatically generated. At the macro call site, there needs to be
little difference.
> [...] Good point, I will setup a va_args in the probe. When
> correctly used, however, there is no need to use the format string :
> we can directly get the variables from the var arg list if we know
> in advance what the string will be.
Do I understand you correctly that the probe handlers would be given
va_list values, and would have to call va_arg to yank out individual
actual arguments? So again type safety is a matter of explicit coding
(equivalent to correctly casting each type)?
- FChE