Message-ID: <1273973388.26328.118.camel@gandalf.stny.rr.com>
Date:	Sat, 15 May 2010 21:29:48 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Pekka Paalanen <pq@....fi>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Larry Finger <Larry.Finger@...inger.net>
Subject: Re: [PATCH 3/4] tracing: Allow mmio tracer to display
 trace_printk() and other events

On Sat, 2010-05-15 at 10:46 +0300, Pekka Paalanen wrote:
> Sorry, I'm not at my email every day. Real life...

heh, no problem. I'm in no hurry here.

> 
> On Thu, 13 May 2010 11:11:23 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > On Thu, 2010-05-13 at 15:29 +0300, Pekka Paalanen wrote:
> > > On Thu, 13 May 2010 08:15:09 -0400
> > 
> > > > It only displays other events if the user enabled those
> > > > events.
> > > > 
> > > > But that said, I don't want to break existing userspace
> > > > tools. I can add a mmiotrace option "mmiotrace_all_events",
> > > > if the user wants to see all events within the mmiotracer
> > > > then they can just enable that option, otherwise, the
> > > > mmiotracer will act like it currently does.
> > > > 
> > > > How does that sound?
> > > 
> > > That would be fine. Is it not redundant with what you said in
> > > your first sentence?
> > > 
> > 
> > Right now with this patch as is. When you enable the mmiotracer it
> > clears the ring buffer. But if someone previously enabled an
> > event (like sched_switch for example) then that event will appear
> > in the output of the tracer.
> > 
> > The user will need to disable that event and restart the
> > mmiotracer so the output will not break the userspace tools. Is
> > this OK?
> 
> I think it is ok. No non-mmiotrace events are enabled automatically,
> right? Except perhaps trace_printk()?

Yep, trace events do not show up in a trace unless a user enabled them
themselves. trace_printk() is only for developers modifying their kernel
and needs works the opposite: You need to disable it from writing.

But trace_printk() only exists in the kernel if a developer added it and
recompiled their kernel. End users will never see it.

> 
> If a user enables other events while mmiotracing, I would
> assume he knows what he is doing. End users doing dumps per
> request never even know about other kinds of tracing than
> mmiotrace.
> 
> > If not, then my suggestion is to have an mmiotracer option that
> > keeps it from printing out any event except for the ones it knows
> > about.
> > 
> > The reason I added this patch in the first place was because Larry
> > Finger was using the mmiotrace with trace_printk() and the
> > current code does not print out the trace_printk() when
> > mmiotracer is active.
> 
> If this is *only* about trace_printk(), why not make a handler
> for it to emit MARK lines? Actually, I somehow assumed that
> would have been the case, but apparently the event type is
> different. I do not recall these things too well anymore.

Well, I can imagine that another user may want events too. But still,
I'm thinking the original patch to write everything should work. You
would only see events if you specifically enable them.

> 
> 
> Thanks for keeping me in the loop.
> 

No problem, it is your code we are dealing with.

-- Steve


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

Powered by blists - more mailing lists