All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Karim Yaghmour <karim@opersys.com>
Cc: Martin Bligh <mbligh@google.com>,
	"Frank Ch. Eigler" <fche@redhat.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>
Subject: Re: [PATCH] Linux Kernel Markers 0.8 for 2.6.17 (with near jump for  i386)
Date: Mon, 25 Sep 2006 01:39:40 -0400	[thread overview]
Message-ID: <20060925053940.GA7014@Krystal> (raw)
In-Reply-To: <451591AC.9030703@opersys.com>

* Karim Yaghmour (karim@opersys.com) wrote:
> diffing against an LTT tree ...
> 

Ok, I will do the diff against a vanilla kernel, good point.

> > --- /dev/null
> > +++ b/include/asm-alpha/marker.h
> ...
> > --- /dev/null
> > +++ b/include/asm-arm/marker.h
> ...
> > --- /dev/null
> > +++ b/include/asm-arm26/marker.h
> ...
> ...
> 
> Not sure about the need for asm-foo/marker.h if the file contains no
> code at all. If there's going to be one marker.h per arch, it might
> as well have a purpose. So instead of:
> 
> > --- /dev/null
> > +++ b/include/asm-i386/marker.h
> ...
> > +#define ARCH_HAS_MARK_NEAR_JUMP
> 
> and
> 
> > --- /dev/null
> > +++ b/include/linux/marker.h
> ...
> > +#ifndef ARCH_HAS_MARK_NEAR_JUMP
> ...
> 
> Why not just have asm-foo/marker.h either implement the optimization
> or point to an asm-generic/marker.h which contains the non-optimized
> code. No #ifndefs needed.
> 
Ok, good idea.

> > --- /dev/null
> > +++ b/kernel/Kconfig.marker
> ...
> > +config MARK_SYMBOL
> ...
> > +config MARK_JUMP_CALL
> ...
> > +config MARK_JUMP
> ...
> 
> My understanding of Ingo's input is that he'd rather not have this
> multiple options. Either the markers are active or they aren't.
> So ...
> MARK_ACTIVE ... speaks for itself, enables both the markers and
> the set/disable infrastructure. Markers are enabled in their
> optimized per-architecture implementation.
> 
> MARK_FORCE_DIRECT_CALL ... forces all markers to be non-optimized
> (good for embedded systems where the image is in rom/flash and
> can therefore not have runtime binary modifications.) Maybe this
> should depend on CONFIG_EMBEDDED.
> 
> 

Ok, now only :

CONFIG_MARKERS
and
CONFIG_MARKERS_FORCE_DIRECT_CALL (only appears is EMBEDDED is enabled)

I have rewritted almost everything else, I will post a patch soon (currently
cleaning up). It now supports inline function, unrolled loops and multiple
definitions of the same marker.

Supporting inline functions has proven more important than I first thought
because of gcc 4.0+ optimisations where it takes a static-only function and
inline it automatically in the body of the caller. It removes the symbols of the
inlined function when it does that.

My new approach is a separate .markers section, everything is there.

Mathieu

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

      reply	other threads:[~2006-09-25  5:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-22 21:42 [PATCH] Linux Kernel Markers 0.8 for 2.6.17 (with near jump for i386) Mathieu Desnoyers
2006-09-23 19:57 ` Karim Yaghmour
2006-09-25  5:39   ` Mathieu Desnoyers [this message]

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=20060925053940.GA7014@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=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=prasanna@in.ibm.com \
    --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.