Subject: Re: [RFC PATCH] dynamic debug - adding ring buffer storage support
From: Steven Rostedt <rostedt@goodmis.org>
Reply-To: rostedt@goodmis.org
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Jiri Olsa <jolsa@redhat.com>,
       Jason Baron <jbaron@redhat.com>, linux-kernel@vger.kernel.org
In-Reply-To: <20091230225011.GJ6322@nowhere>
References: <1261481526-17630-1-git-send-email-jolsa@redhat.com>
	 <20091222153955.GD3308@redhat.com>
	 <20091222161353.GB20225@jolsa.lab.eng.brq.redhat.com>
	 <20091228092402.GD24690@elte.hu>  <20091230225011.GJ6322@nowhere>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: Kihon Technologies Inc.
Date: Wed, 30 Dec 2009 20:44:17 -0500
Message-ID: <1262223857.28171.9.camel@gandalf.stny.rr.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1983
Lines: 58

On Wed, 2009-12-30 at 23:50 +0100, Frederic Weisbecker wrote:

> That said, I sometimes dream about one event per printk.
> 
> Having, say:
> 
> /debug/tracing/events/printk/
>          |
>          ---- kernel/
>          |      |
>          |      ------- time/
>          |      |        |
>          |      |        ---- clocksource.c
>          |      |                 |
>          |      |                 --- clocksource_unstable:218/
>          |      |                 |            |
>          |      |                 |            ---- format
>          |      |                 |            |
>          |      |                 |            ---- filter
>          |      |                 |            |
>          |      |                 |            ---- enable
>          |      |                 --- [...]
>          |      ------- [...]
>          |
>          ---- drivers/
>          |       |
>          |       ---- [...]
>          |
>          ---- [...]
> 
> 
> That would give a total control over every printk, trace_printk, etc...
> 
> Too bad that would bloat the memory.
> Well, that could be wrapped in a single, wildly implemented (understand:
> not using TRACE_EVENT macro) trace event, something able to walk through
> every calls of printk, trace_printk, early_printk, etc... and imitate
> a per printk event granularity.
> 
> But still it needs to be useful...


I think we can do the above without bloating memory. Yes we would not
need the TRACE_EVENT macro for this. The TRACE_EVENT macro is just for
generic tracing, but we could easily come up with something specific for
the printk's that will not bloat the kernel as much.

When I get some time, I may try to play with this idea.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/