This was a lot more trivial than I expected, about a 20 minute

hack.  Most of the time was spent on test boots :)
The first patch removes the packed attribute from the ftrace_page

blob of dynamic ftrace entries, because not only does it cause

unaligned accesses on sparc64 it's also totally useless.
The second patch adds sparc64 ftrace support.
One thing I noticed is that sparc64 uses an mcount implementation

already for a quick-and-dirty stack usage checker.  I tried to

make them live alongside eachother.
Next, I think the mcount symbol export needs some tweaking.  On sparc,

the symbol _mcount is what the compiler references (this seems to be a

sparc sysv4'ism) whereas on x86 it appears that plain "mcount" is

used.  I provide both symbols and we already have a local export of

"_mcount" to take care of this.  I think architectures should deal

with this symbol exporting since it is different on every system.
Signed-off-by: David S. Miller <davem@davemloft.net>

--

No, the same is for PPC (_mcount). I have a port for this ready. I'll

look at your code and compare it with my PPC port.
Ingo, do you think it's time I can hand the PPC stuff over to you? I'll

just have to update it to the lastest linux-ftrace.git.
Thanks,
-- Steve
--

ok. It was so for purely histeric raisons, when we still tried to stuff 
my thinking would be to perhaps also do an ftrace/max-stack plugin that

would just measure the maximum stack footprint - coupled with emitting

the stack trace itself to the trace buffer. This way we could measure

the maximum stack footprint even of very yucky codepaths where we

couldnt do a printk or other ad-hoc things.
While such an ftrace/max-stack plugin would be something very similar to

and would reuse much of trace_functions.c, i think on the UI side it

should be a separate tracer plugin. I.e. we could tell people "activate

ftrace/max-stack" and they'd know what to do, and it would just do the

right thing by default after a:
ok, agreed, fixed this bug on x86 - see the first patch below.
[ also a patch integration detail: i took the liberty to move your

  arch/sparc64/Kconfig's HAVE_FTRACE to the first spot of the SPARC64

  select lines as per the second patch below - your patch had a conflict

  against current mainline (which probably means you already changed

  this file in your Sparc64 tree). By moving that entry to the first

  line your tree and the ftrace tree should auto-merge just fine without

  any conflicts. ]
btw., if you have any ftrace usability observations (or any observations

about it), let us know. ftrace tries to be self-contained (no user-space

tools required) and 'intuitive by default' - i.e. someone looking into

/debug/tracing/ and at the trace output for the first time should find

his way around and should be able to operate most of its functionality

without much effort.
But there lies the minor complication: it is pretty hard for us ftrace

developers to look into /debug/tracing/ "for the first time", so we rely

on others to tell us their first impressions, to improve the code :-)
	Ingo
------------>

Subject: ftrace: fix mcount export bug

From: Ingo Molnar <mingo@elte.hu>

Date: Wed May 14 08:10:31 CEST 2008
David S. Miller noti...
[ message continues ]

When adding new select entries I try to keep them sorted alphabetically.

It will not solve all the merge issues but as the list grows this should

help. At least betterthan adding to the end.
	Sam

--

yep, i do that too in other cases - but the list here is very short.

Btw., i also do sorting for include file names, such as in

kernel/trace/ftrace.c:
 #include <linux/stop_machine.h>

 #include <linux/clocksource.h>

 #include <linux/kallsyms.h>

 #include <linux/seq_file.h>

 #include <linux/debugfs.h>

 #include <linux/kthread.h>

 #include <linux/hardirq.h>

 #include <linux/ftrace.h>

 #include <linux/uaccess.h>

 #include <linux/sysctl.h>

 #include <linux/hash.h>

 #include <linux/ctype.h>

 #include <linux/list.h>
 #include "trace.h"
(i also sort by length to make it visually more appealing. "Reverse

christmas tree" sorting ;-)
[ and yes, linux/uaccess.h is mis-sorted - fixed. ]
	Ingo

--

From: Ingo Molnar <mingo@elte.hu>
I do this for local variable declarations too.

--

Now that ftrace is being ported to other architectures, it has become

apparent that DYNAMIC_FTRACE is dependent on whether or not that

architecture implements dynamic ftrace. FTRACE itself may be ported to

an architecture without porting dynamic ftrace.
This patch adds HAVE_DYNAMIC_FTRACE to allow architectures to port ftrace

without having to also port the dynamic aspect as well.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>

---

 arch/powerpc/Kconfig |    1 +

 arch/sparc64/Kconfig |    1 +

 arch/x86/Kconfig     |    1 +

 kernel/trace/Kconfig |    4 ++++

 4 files changed, 7 insertions(+)
Index: linux-tip.git/arch/powerpc/Kconfig

===================================================================

--- linux-tip.git.orig/arch/powerpc/Kconfig	2008-05-16 20:26:20.000000000 -0700

+++ linux-tip.git/arch/powerpc/Kconfig	2008-05-16 20:27:47.000000000 -0700

@@ -107,6 +107,7 @@ config PPC

 	default y

 	select HAVE_IDE

 	select HAVE_IMMEDIATE

+	select HAVE_DYNAMIC_FTRACE

 	select HAVE_FTRACE

 	select HAVE_KPROBES

 	select HAVE_KRETPROBES

Index: linux-tip.git/arch/sparc64/Kconfig

===================================================================

--- linux-tip.git.orig/arch/sparc64/Kconfig	2008-05-16 20:26:20.000000000 -0700

+++ linux-tip.git/arch/sparc64/Kconfig	2008-05-16 20:27:24.000000000 -0700

@@ -11,6 +11,7 @@ config SPARC

 config SPARC64

 	bool

 	default y

+	select HAVE_DYNAMIC_FTRACE

 	select HAVE_FTRACE

 	select HAVE_IDE

 	select HAVE_LMB

Index: linux-tip.git/arch/x86/Kconfig

===================================================================

--- linux-tip.git.orig/arch/x86/Kconfig	2008-05-16 20:26:20.000000000 -0700

+++ linux-tip.git/arch/x86/Kconfig	2008-05-16 20:27:32.000000000 -0700

@@ -23,6 +23,7 @@ config X86

 	select HAVE_OPROFILE

 	select HAVE_KPROBES

 	select HAVE_KRETPROBES

+	select HAVE_DYNAMIC_FTRACE

 	select HAVE_FTRACE

 	select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)

 	select ...
[ message continues ]

applied, thanks Steven.
	Ingo

--

yeah, same here:
  --------------------------------->

  static void

  ftrace_record_ip(unsigned long ip)

  {

          struct dyn_ftrace *node;

          unsigned long flags;

          unsigned long key;

          int resched;

          int atomic;

          int cpu;

  [...]

  <--------------------------------
for me the primary motivation isnt even merge conflicts in this case

(getting conflicts on this level is rare), but readability and making it

smooth to move the eye off the variable declarations.
IMO good code is obvious even without having to read the types, so the

less visually intrusive the variable declarations section is, the

better.
	Ingo

--