All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Martin Bligh <mbligh@google.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	prasanna@in.ibm.com, Andrew Morton <akpm@osdl.org>,
	Ingo Molnar <mingo@elte.hu>, Paul Mundt <lethal@linux-sh.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jes Sorensen <jes@sgi.com>, Tom Zanussi <zanussi@us.ibm.com>,
	Richard J Moore <richardj_moore@uk.ibm.com>,
	Michel Dagenais <michel.dagenais@polymtl.ca>,
	Christoph Hellwig <hch@infradead.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	William Cohen <wcohen@redhat.com>,
	ltt-dev@shafik.org, systemtap@sources.redhat.com,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Karim Yaghmour <karim@opersys.com>, Pavel Machek <pavel@suse.cz>,
	Joe Perches <joe@perches.com>,
	"Randy.Dunlap" <rdunlap@xenotime.net>,
	"Jose R. Santos" <jrs@us.ibm.com>
Subject: Re: [PATCH] Linux Kernel Markers 0.11 for 2.6.17
Date: Mon, 25 Sep 2006 19:28:28 -0400	[thread overview]
Message-ID: <20060925232828.GA29343@Krystal> (raw)
In-Reply-To: <20060925160115.GE25296@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

Hi,

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Hi -
> 
> > [...]
> > - It _does not_ change the compiler optimisations.
> 
> Like any similar mechanism, it does force the compiler to change its
> code generation, so one can't claim this too strongly.
> 
Yes, memory dependencies are changed, you are right. I was principally talking
about the inline and unrolled loops optimisations.


> > [...]  Comments are welcome,
> 
> I'm still uneasy about the use of varargs.  The current code now uses
> the formatting string as metadata to be matched (strcmp) between
> producer and consumer.  A general tool that would use them would have
> to start parsing general printf directives.

If you want to generate probes automatically, yes.

> I believe they 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 ?

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 realize they serve a useful purpose in abbreviating what otherwise
> one might have to do (like that multiplicity of STAP_MARK_* type/arity
> permutations).  But maybe there is a better way.
> 

I think that duplicating the number of marker macros could easily make
them unflexible and ugly. This is why I am trying to come with this generic
macro.

> Also, while regparm(0) may provide some comfort on x86, is there good
> reason to believe that the same trick works (and will continue to
> work) on non-x86 platforms to invoke a non-varargs callee with a
> varargs caller?
> 

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.

Mathieu

OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-09-25 23:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-25 15:10 [PATCH] Linux Kernel Markers 0.11 for 2.6.17 Mathieu Desnoyers
2006-09-25 16:01 ` Frank Ch. Eigler
2006-09-25 23:28   ` Mathieu Desnoyers [this message]
2006-09-26 16:39     ` Frank Ch. Eigler
2006-09-27  1:30       ` Mathieu Desnoyers
2006-09-27 16:12         ` Frank Ch. Eigler
2006-09-25 18:16 ` Jeremy Fitzhardinge
2006-09-25 20:10   ` Mathieu Desnoyers
2006-09-25 20:25     ` Jeremy Fitzhardinge
2006-09-25 20:35       ` Mathieu Desnoyers
2006-09-25 20:47         ` Mathieu Desnoyers
2006-09-25 21:22           ` Jeremy Fitzhardinge
2006-09-25 21:32             ` Mathieu Desnoyers
2006-09-25 21:35               ` Jeremy Fitzhardinge
2006-09-25 23:13   ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060925232828.GA29343@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=fche@redhat.com \
    --cc=gregkh@suse.de \
    --cc=hch@infradead.org \
    --cc=jeremy@goop.org \
    --cc=jes@sgi.com \
    --cc=joe@perches.com \
    --cc=jrs@us.ibm.com \
    --cc=karim@opersys.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mbligh@google.com \
    --cc=michel.dagenais@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=pavel@suse.cz \
    --cc=prasanna@in.ibm.com \
    --cc=rdunlap@xenotime.net \
    --cc=richardj_moore@uk.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=tglx@linutronix.de \
    --cc=wcohen@redhat.com \
    --cc=zanussi@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.