[PATCH -next 1/2] ring-buffer: Really make it generic.

[PATCH -next 1/2] ring-buffer: Really make it generic.

[Paul Mundt]

In hunting down the cause for the hwlat_detector ring buffer spew in
my failed -next builds it became obvious that folks are now treating
ring_buffer as something that is generic independent of tracing and thus,
suitable for public driver consumption.

Given that there are only a few minor areas in ring_buffer that have any
reliance on CONFIG_TRACING or CONFIG_FUNCTION_TRACER, provide stubs for
those and make it generally available.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jon Masters <jcm@jonmasters.org>

---

 kernel/Makefile            |    1 +
 kernel/trace/ring_buffer.c |   11 +++++++++++
 kernel/trace/trace.h       |    7 +++++++
 3 files changed, 19 insertions(+)

diff --git a/kernel/Makefile b/kernel/Makefile
index 0a32cb2..0630e29 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
 obj-$(CONFIG_FUNCTION_TRACER) += trace/
 obj-$(CONFIG_TRACING) += trace/
 obj-$(CONFIG_X86_DS) += trace/
+obj-$(CONFIG_RING_BUFFER) += trace/
 obj-$(CONFIG_SMP) += sched_cpupri.o
 obj-$(CONFIG_SLOW_WORK) += slow-work.o
 obj-$(CONFIG_PERF_COUNTERS) += perf_counter.o
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 04dac26..bf27bb7 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1563,6 +1563,8 @@ rb_reserve_next_event(struct ring_buffer_per_cpu *cpu_buffer,
 	return NULL;
 }
 
+#ifdef CONFIG_TRACING
+
 #define TRACE_RECURSIVE_DEPTH 16
 
 static int trace_recursive_lock(void)
@@ -1593,6 +1595,13 @@ static void trace_recursive_unlock(void)
 	current->trace_recursion--;
 }
 
+#else
+
+#define trace_recursive_lock()		(0)
+#define trace_recursive_unlock()	do { } while (0)
+
+#endif
+
 static DEFINE_PER_CPU(int, rb_need_resched);
 
 /**
@@ -3104,6 +3113,7 @@ int ring_buffer_read_page(struct ring_buffer *buffer,
 }
 EXPORT_SYMBOL_GPL(ring_buffer_read_page);
 
+#ifdef CONFIG_TRACING
 static ssize_t
 rb_simple_read(struct file *filp, char __user *ubuf,
 	       size_t cnt, loff_t *ppos)
@@ -3171,6 +3181,7 @@ static __init int rb_init_debugfs(void)
 }
 
 fs_initcall(rb_init_debugfs);
+#endif
 
 #ifdef CONFIG_HOTPLUG_CPU
 static int rb_cpu_notify(struct notifier_block *self,
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 6e735d4..3548ae5 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -597,6 +597,7 @@ print_graph_function(struct trace_iterator *iter)
 
 extern struct pid *ftrace_pid_trace;
 
+#ifdef CONFIG_FUNCTION_TRACER
 static inline int ftrace_trace_task(struct task_struct *task)
 {
 	if (!ftrace_pid_trace)
@@ -604,6 +605,12 @@ static inline int ftrace_trace_task(struct task_struct *task)
 
 	return test_tsk_trace_trace(task);
 }
+#else
+static inline int ftrace_trace_task(struct task_struct *task)
+{
+	return 1;
+}
+#endif
 
 /*
  * trace_iterator_flags is an enumeration that defines bit

[PATCH -next 2/2] hwlat_detector: select RING_BUFFER.

[Paul Mundt]

The hwlat_detector broke quite a few of the sh module builds:

ERROR: "ring_buffer_write" [drivers/misc/hwlat_detector.ko] undefined!
ERROR: "ring_buffer_reset" [drivers/misc/hwlat_detector.ko] undefined!
ERROR: "__ring_buffer_alloc" [drivers/misc/hwlat_detector.ko] undefined!
ERROR: "ring_buffer_event_data" [drivers/misc/hwlat_detector.ko] undefined!
ERROR: "ring_buffer_consume" [drivers/misc/hwlat_detector.ko] undefined!
ERROR: "ring_buffer_free" [drivers/misc/hwlat_detector.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

This fixes it up by selecting RING_BUFFER outright.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Cc: Jon Masters <jcm@jonmasters.org>

---

 drivers/misc/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4448a83..f51ba7b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -79,6 +79,7 @@ config IBM_ASM
 config HWLAT_DETECTOR
 	tristate "Testing module to detect hardware-induced latencies"
 	depends on DEBUG_FS
+	select RING_BUFFER
 	default m
 	---help---
 	  A simple hardware latency detector. Use this module to detect

Re: [PATCH -next 1/2] ring-buffer: Really make it generic.

[Jon Masters]

On Thu, 2009-06-25 at 14:30 +0900, Paul Mundt wrote:
> In hunting down the cause for the hwlat_detector ring buffer spew in
> my failed -next builds it became obvious that folks are now treating
> ring_buffer as something that is generic independent of tracing and thus,
> suitable for public driver consumption.
> 
> Given that there are only a few minor areas in ring_buffer that have any
> reliance on CONFIG_TRACING or CONFIG_FUNCTION_TRACER, provide stubs for
> those and make it generally available.

Thanks for this. I had discussed it with Steven previously and I can't
imagine why he wouldn't be in favor of wider use - I suggested that it's
about time ring_buffer moved out of trace/ and got it's own place (it's
getting to be a big boy now, full of youthful aspiration) but we'll have
to wait for him to get back from his trip and let us know what he wants.

Jon.

Re: [PATCH -next 1/2] ring-buffer: Really make it generic.

[Paul Mundt]

On Thu, Jun 25, 2009 at 03:09:04AM -0400, Jon Masters wrote:
> On Thu, 2009-06-25 at 14:30 +0900, Paul Mundt wrote:
> > In hunting down the cause for the hwlat_detector ring buffer spew in
> > my failed -next builds it became obvious that folks are now treating
> > ring_buffer as something that is generic independent of tracing and thus,
> > suitable for public driver consumption.
> > 
> > Given that there are only a few minor areas in ring_buffer that have any
> > reliance on CONFIG_TRACING or CONFIG_FUNCTION_TRACER, provide stubs for
> > those and make it generally available.
> 
> Thanks for this. I had discussed it with Steven previously and I can't
> imagine why he wouldn't be in favor of wider use - I suggested that it's
> about time ring_buffer moved out of trace/ and got it's own place (it's
> getting to be a big boy now, full of youthful aspiration) but we'll have
> to wait for him to get back from his trip and let us know what he wants.
> 
Ok, then as a stop-gap solution it should at least depend on RING_BUFFER
so that it doesn't blow up the other builds ;-)

Re: [PATCH -next 1/2] ring-buffer: Really make it generic.

[Ingo Molnar]

* Jon Masters <jonathan@jonmasters.org> wrote:

> On Thu, 2009-06-25 at 14:30 +0900, Paul Mundt wrote:
> > In hunting down the cause for the hwlat_detector ring buffer spew in
> > my failed -next builds it became obvious that folks are now treating
> > ring_buffer as something that is generic independent of tracing and thus,
> > suitable for public driver consumption.
> > 
> > Given that there are only a few minor areas in ring_buffer that 
> > have any reliance on CONFIG_TRACING or CONFIG_FUNCTION_TRACER, 
> > provide stubs for those and make it generally available.
> 
> Thanks for this. I had discussed it with Steven previously and I 
> can't imagine why he wouldn't be in favor of wider use - I 
> suggested that it's about time ring_buffer moved out of trace/ and 
> got it's own place (it's getting to be a big boy now, full of 
> youthful aspiration) but we'll have to wait for him to get back 
> from his trip and let us know what he wants.

The patch makes sense - i've queued it up in tip:tracing/urgent - 
the sooner we have it upstream the better.

	Ingo