From: Jason Baron <jbaron@redhat.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/5] ftrace: show ftrace_bprintk()'s formats
Date: Wed, 14 Jan 2009 09:25:46 -0500 [thread overview]
Message-ID: <20090114142546.GA3141@redhat.com> (raw)
In-Reply-To: <496D52D4.70202@cn.fujitsu.com>
On Wed, Jan 14, 2009 at 10:49:56AM +0800, Lai Jiangshan wrote:
> Jason Baron wrote:
> > On Wed, Dec 31, 2008 at 10:56:23AM +0800, Lai Jiangshan wrote:
> >> Impact: let user knows the format
> >>
> >> Create a file on <debugfs-dir>/tracing/ to show ftrace_bprintk()'s formats.
> >>
> >> This formats will help for these condition:
> >> 1) User get binary data from core file.(formats are backup before coredump)
> >> 2) User splice ring_buffer to a file.
> >> User can use formats for parsing the binary data in userspace.
> >>
> >
> > When I 'cat' trace_bprintk_formats on my system the file is empty. This
> > seems to be b/c 'ftrace_bprintk' is not being used in this patchset. It
> > can't be used in patch #5 during marker register b/c the format wouldn't
> > be known at runtime. Thus, as it currently stands this patch, patch 4/5,
> > isn't adding much?
>
> If you don't use ftrace_bprintk(), the file trace_bprintk_formats is empty.
> This file record all formats which ftrace_bprintk() uses.
>
> You can use ftrace_bprintk() everywhere as another printk().
>
> Patch #5 enables binary printk for markers, this is another additional tool
> for tracing markers.
>
> >
> > A thought on how this might be resolved would be to have the core marker
> > code pass us its address so this could be recorded in the trace buffer.
> > Then, also add some debug file that displays the markers and maps marker
> > addresses with format strings.
> >
>
> Patch#5 does it as you said.
>
>
>
hmm...i'm still not clear on this. in patch #5 you have:
+static void marker_bprintk_probe(void *probe_private, void *call_private,
+ const char *fmt, va_list *args)
+{
+ struct marker_bprintk_struct *p = probe_private;
+
+ if (p->fmt_state == MARKER_FMT_LACK) {
+ int flen = strlen(fmt);
+ if (p->fmt - p->name + flen < MARKER_NAME_FMT_LEN) {
+ memcpy(p->fmt, fmt, flen + 1);
+ p->fmt_state = MARKER_FMT_OK;
+ } else
+ p->fmt_state = MARKER_FMT_INVALID;
+ }
+
+ if (p->fmt_state == MARKER_FMT_OK)
+ trace_vbprintk(0, p->name, *args);
+}
+
trace_vbprintk first argument is 'ip'. So I don't see how we are
associating instruction pointers with each 'ftrace' record? Aren't we
just recording each entry with '0' for the 'ip'?
thanks,
-Jason
next prev parent reply other threads:[~2009-01-14 14:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 2:56 [PATCH 4/5] ftrace: show ftrace_bprintk()'s formats Lai Jiangshan
2009-01-13 23:16 ` Jason Baron
2009-01-14 2:49 ` Lai Jiangshan
2009-01-14 14:25 ` Jason Baron [this message]
2009-01-15 10:19 ` Lai Jiangshan
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=20090114142546.GA3141@redhat.com \
--to=jbaron@redhat.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.