From: Ingo Molnar <mingo@elte.hu>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Tom Zanussi <tzanussi@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing/events: make struct trace_entry->type to be int type
Date: Wed, 22 Apr 2009 11:40:26 +0200 [thread overview]
Message-ID: <20090422094026.GF18226@elte.hu> (raw)
In-Reply-To: <49EEE104.9050709@cn.fujitsu.com>
* Li Zefan <lizf@cn.fujitsu.com> wrote:
> Frederic Weisbecker wrote:
> > On Wed, Apr 22, 2009 at 04:53:34PM +0800, Li Zefan wrote:
> >> struct trace_entry->type is unsigned char, while trace event's id is
> >> int type, thus for a event with id >= 256, it's entry->type is cast
> >> to (id % 256), and then we can't see the trace output of this event.
> >>
> >> # insmod trace-events-sample.ko
> >> # echo foo_bar > /mnt/tracing/set_event
> >> # cat /debug/tracing/events/trace-events-sample/foo_bar/id
> >> 256
> >> # cat /mnt/tracing/trace_pipe
> >> <...>-3548 [001] 215.091142: Unknown type 0
> >> <...>-3548 [001] 216.089207: Unknown type 0
> >> <...>-3548 [001] 217.087271: Unknown type 0
> >> <...>-3548 [001] 218.085332: Unknown type 0
> >>
> >> [ Impact: fix output for trace events with id >= 256 ]
> >>
> >> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> >
> >
> > Indeed, now with the trace_events, we are approaching this possible
> > overflow and the type is indeed an int:
> >
> > struct trace_event *ftrace_find_event(int type)
> >
> > Curious: does it only happen with the trace-event-sample?
> > I doubt we already reached this threshold of event number.
> > But anyway, it's a good thing.
> >
>
> I guess we haven't reached this limit, at least for mainline. :)
>
> And the biggest id is 48 in my config.
I think we'll hit 256 pretty soon :) Applied, thanks guys!
Btw., has anyone thought about a .config option that turns every
dprintk into a tracepoint, enumerated in /debug/tracing/events/
nicely (grouped by subsystems) and toggle-able?
( They cannot have 'format' and 'filter' files [at least yet] - but
integrating them into the existing tracing facilities makes sense
nevertheless - they are often used as subsystem tracepoints.
Allowing them to be captured via the tracing facilities would make
their usage a lot more flexible. )
Ingo
next prev parent reply other threads:[~2009-04-22 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-22 8:53 [PATCH] tracing/events: make struct trace_entry->type to be int type Li Zefan
2009-04-22 9:10 ` Frederic Weisbecker
2009-04-22 9:19 ` Li Zefan
2009-04-22 9:40 ` Ingo Molnar [this message]
2009-04-22 10:06 ` [tip:tracing/core] " tip-bot for Li Zefan
2009-04-22 13:40 ` Steven Rostedt
2009-04-22 13:52 ` Ingo Molnar
2009-04-22 14:07 ` Steven Rostedt
2009-04-23 0:57 ` Li Zefan
2009-04-22 13:15 ` [PATCH] " Steven Rostedt
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=20090422094026.GF18226@elte.hu \
--to=mingo@elte.hu \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox