public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Karim Yaghmour <karim.yaghmour@kryptiva.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>,
		linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
		Ingo Molnar <mingo@redhat.com>,
	systemtap@sources.redhat.com, 	ltt-dev@shafik.org
Subject: Re: [PATCH 05/05] Linux Kernel Markers, non optimized architectures
Date: Wed, 21 Feb 2007 19:53:00 -0000	[thread overview]
Message-ID: <45DCA6E1.7080903@kryptiva.com> (raw)
In-Reply-To: <20070216233825.GB28087@Krystal>

----- KRYPTIVA PACKAGED MESSAGE -----
PACKAGING TYPE: SIGNED

Hello Mathieu,

Mathieu Desnoyers wrote:
 > Yes, that was indeed the first way I implemented it, as a "disable" option. One of the main thing we have to figure out before I modify this is if we want to have the generic version of markers available in a "forced" manner at the marker site with the GEN_MARK macro instead of the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c irq
 > enable/disable tracing functions. The reason why is because they are called just before the trap handler returns and I need it to do XMC on x86 and x86_64. It would therefore cause a recursive trap.
 >
 > I think it makes sense to have this kind of support for hard-to-instrument sites within the marker infrastructure, but the cost is to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites).

I must admit that I'm unsure about the use of different marker macros.
How about bitwise flags that could be coded as part of the marker
at the marker site? Something like "MARKER_TYPE_FORCED". This would
still allow some form of toplevel control at the macro definition.
Otherwise there's some digging to be done on a per-marker
basis ...

Karim
----- KRYPTIVA SIGNED MESSAGE -----
This email claims to have been packaged by Kryptiva.
To process this email and authenticate its origin, get
the free plugin from:
http://www.kryptiva.com/downloads

----- KRYPTIVA SIGNATURE START -----
AvWVqAAAAAIAAAABAAAAAAAATiACAQAAAAC3AQAIAAAAAgAAAAECABTXxT4xHdR4/1uU1hL2
+TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF
ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1
IVdBt6tKzhaPW8MOfncRABgAAAAAAABOIEXcozcACATMAAAAAAAAABkTAAQAAAAAAAAAggQA
mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV
yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85
nVh3hKiNPsw8DYs1NKb+KMON+4g=
----- KRYPTIVA SIGNATURE END -----

  reply	other threads:[~2007-02-21 19:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-11 20:13 [PATCH 00/05] Linux Kernel Markers - kernel 2.6.20 Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 03/05] Linux Kernel Markers : powerpc optimization Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 01/05] Linux Kernel Markers : Kconfig menus Mathieu Desnoyers
2007-02-11 20:08 ` [PATCH 02/05] Linux Kernel Markers, architecture independant code Mathieu Desnoyers
2007-02-15  7:22   ` Andrew Morton
2007-02-15 19:12     ` Mathieu Desnoyers
2007-02-11 20:13 ` [PATCH 04/05] Linux Kernel Markers : i386 optimization Mathieu Desnoyers
2007-02-11 20:44 ` [PATCH 05/05] Linux Kernel Markers, non optimized architectures Mathieu Desnoyers
2007-02-15  7:17   ` Andrew Morton
2007-02-15 19:09     ` Mathieu Desnoyers
2007-02-16 20:10       ` Karim Yaghmour
2007-02-16 23:38         ` Mathieu Desnoyers
2007-02-21 19:53           ` Karim Yaghmour [this message]
2007-02-21 20:51             ` Mathieu Desnoyers
2007-02-21 21:50               ` Karim Yaghmour
2007-02-22  0:18                 ` [PATCH] Linux Kernel Markers - cleanup Mathieu Desnoyers
2007-02-15  7:12 ` [PATCH 00/05] Linux Kernel Markers - kernel 2.6.20 Andrew Morton
2007-02-15 15:29   ` Frank Ch. Eigler
2007-02-15 22:19     ` Andrew Morton
2007-02-15 22:36       ` Mathieu Desnoyers
2007-02-15 23:15       ` Vara Prasad
2007-02-16  1:34   ` [PATCH] Linux Kernel Markers Documentation Mathieu Desnoyers
2007-02-16  1:51     ` Randy Dunlap
2007-02-16  4:01       ` Mathieu Desnoyers
2007-02-16  4:05       ` [PATCH] Linux Kernel Markers Documentation - fix Mathieu Desnoyers
2007-02-16  1:37   ` [PATCH 00/05] Linux Kernel Markers - kernel 2.6.20 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=45DCA6E1.7080903@kryptiva.com \
    --to=karim.yaghmour@kryptiva.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@redhat.com \
    --cc=systemtap@sources.redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).