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 17:06:03 -0500 [thread overview]
Message-ID: <45DCC24B.4040204@kryptiva.com> (raw)
In-Reply-To: <20070221204535.GA616@Krystal>
----- KRYPTIVA PACKAGED MESSAGE -----
PACKAGING TYPE: SIGNED
Mathieu Desnoyers wrote:
> The problem with your proposal, I guess, is that people will have to add a supplementary parameter to the macro.
>
> It is not uncommon to have two slightly versions of macros/functions in the kernel (preempt_enable()/preempt_enable_no_resched(), or macros starting with underscores). Normally, the underscore states that the macro does not do the proper locking itself (this is not our case). Therefore, I would suggest using a name that suggests against what the macro is protected. For instance, a marker
> pointing to the generic version is only needed to protect against the debug trap handler and should only be used on x86 and x86_64.
I can see your point, to a degree. The difference here is that the
variants you mention are actually macros that do something, they
aren't stubs for code. IOW, you actually know what's happening
underneath a foo() vs. _foo() by its name only. Maybe this applies
the same to markers, I don't know. But maybe we want to make it
easy for those looking at markers that there's a master kill
switch somewhere that all markers go through and through which
they can all be disabled very simply (say by using a "#if 0").
While different names *may* be doing that, a same name *does* that.
But I don't feel too strongly either way, it's really up to those
who maintaining the code to say.
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/LoBwAUpXC6F2jf
nElq3fnZQpGW97Fk/2QRABgAAAAAAABOIEXcvqAADJ5wAAAAAAAAAB4TAAQAAAAAAAAAggP/
RQ/W0H9H9bhrZyC67an//DbWC4D38PgLoeMG6Tjvx7jWTpEh79DeQ/+sbb9aYZvbwYwtaVaJ
VuPEiRnPZX0mqnOFm+GDzE9jB6202lR0Nzczh1WCifbrrXI7CSEjOwI3ve0jcCoGxTEzZRYj
LGxuubV8Hh5HU12zi3Mxgdz031Y=
----- KRYPTIVA SIGNATURE END -----
next prev parent reply other threads:[~2007-02-21 21:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-11 20:03 [PATCH 00/05] Linux Kernel Markers - kernel 2.6.20 Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 01/05] Linux Kernel Markers : Kconfig menus Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 02/05] Linux Kernel Markers, architecture independant code Mathieu Desnoyers
2007-02-15 7:21 ` Andrew Morton
2007-02-15 19:12 ` Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 03/05] Linux Kernel Markers : powerpc optimization Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 04/05] Linux Kernel Markers : i386 optimization Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 05/05] Linux Kernel Markers, non optimized architectures Mathieu Desnoyers
2007-02-15 7:16 ` Andrew Morton
2007-02-15 19:09 ` Mathieu Desnoyers
2007-02-16 20:26 ` Karim Yaghmour
2007-02-16 23:38 ` Mathieu Desnoyers
2007-02-21 20:09 ` Karim Yaghmour
2007-02-21 20:45 ` Mathieu Desnoyers
2007-02-21 22:06 ` Karim Yaghmour [this message]
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:28 ` Frank Ch. Eigler
2007-02-15 22:18 ` Andrew Morton
2007-02-15 22:30 ` Mathieu Desnoyers
2007-02-15 23:14 ` Vara Prasad
2007-02-16 1:32 ` Mathieu Desnoyers
2007-02-16 1:33 ` [PATCH] Linux Kernel Markers Documentation Mathieu Desnoyers
2007-02-16 1:45 ` Randy Dunlap
2007-02-16 3:56 ` Mathieu Desnoyers
2007-02-16 4:05 ` [PATCH] Linux Kernel Markers Documentation - fix 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=45DCC24B.4040204@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 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.