From: Tom Zanussi <zanussi@kernel.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: rostedt@goodmis.org, tglx@linutronix.de, namhyung@kernel.org,
bigeasy@linutronix.de, joel@joelfernandes.org,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: Re: [RFC PATCH v3 0/5] tracing: common error_log for ftrace
Date: Tue, 12 Mar 2019 11:49:11 -0500 [thread overview]
Message-ID: <1552409351.4293.22.camel@kernel.org> (raw)
In-Reply-To: <20190312152605.00150aae7b781137005e9ebf@kernel.org>
Hi Masami,
On Tue, 2019-03-12 at 15:26 +0900, Masami Hiramatsu wrote:
> Hi Tom,
>
> On Tue, 5 Mar 2019 23:06:46 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> > On Mon, 4 Mar 2019 17:36:43 -0600
> > > Changes from v2:
> > >
> > > - Added [n] numbering as suggested by Masami
>
> Hmm, this seems a bit different what I suggested.
>
> I'm trying to port probe event's error report on
> your error log, and I found that the number is
> just shifted as below.
>
> When I filled the log with errors.
> =============
> /sys/kernel/debug/tracing # cat error_log
> [1] trace_kprobe: error: Invalid unsigned integer string
> Command: r10aa00:foo/bar vfs
> ^
> ...
>
> [7] trace_kprobe: error: Group name must follow C naming convention
> Command: p:a-b/bar vfs_read
> ^
> [8] trace_kprobe: error: Event name is too long
> Command:
> p:a/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> rrrrrrrrrrr vfs_read
> =============
>
> And do one more error,
>
> =============
> /sys/kernel/debug/tracing # cat error_log
> [1] trace_kprobe: error: Maxactive is too big
> Command: r0xaa00:foo/bar vfs
>
> ....
>
> [7] trace_kprobe: error: Event name is too long
> Command:
> p:a/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> rrrrrrrrrrr vfs_read
> ^
> [8] trace_kprobe: error: Event name must follow C naming convention
> Command: p:a/bar.c vfs_read
> ^
> =============
>
> The number of logs are changed :( This can confuse users.
> I think it is better to keep the number as a unique number for
> each entry as below.
>
Hmm, that makes sense, but I wonder if that will also confuse users,
when the log wraps around and no longer starts at [1] and there's no
way to retrieve the previous errors.
I took your suggestion as a way mainly to clearly delineate each error,
since without the [number] or something similar, they all kind of run
together.
Not sure what advantage numbering itself provides - would some other
non-numbered separator work?
Thanks,
Tom
> =============
> /sys/kernel/debug/tracing # cat error_log
> [2] trace_kprobe: error: Maxactive is too big
> Command: r0xaa00:foo/bar vfs
>
> ....
>
> [8] trace_kprobe: error: Event name is too long
> Command:
> p:a/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> rrrrrrrrrrr vfs_read
> ^
> [9] trace_kprobe: error: Event name must follow C naming convention
> Command: p:a/bar.c vfs_read
> ^
> =============
>
> Thank you,
>
next prev parent reply other threads:[~2019-03-12 16:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-04 23:36 [RFC PATCH v3 0/5] tracing: common error_log for ftrace Tom Zanussi
2019-03-04 23:36 ` [RFC PATCH v3 1/5] tracing: Add tracing error log Tom Zanussi
2019-03-04 23:36 ` [RFC PATCH v3 2/5] tracing: Save the last hist command's associated event name Tom Zanussi
2019-03-04 23:36 ` [RFC PATCH v3 3/5] tracing: Use tracing error_log with hist triggers Tom Zanussi
2019-03-12 15:46 ` Masami Hiramatsu
2019-03-12 16:50 ` Tom Zanussi
2019-03-04 23:36 ` [RFC PATCH v3 4/5] tracing: Use tracing error_log with kprobe events (incomplete) Tom Zanussi
2019-03-04 23:36 ` [RFC PATCH v3 5/5] tracing: Use tracing error_log with trace event filters Tom Zanussi
2019-03-05 14:06 ` [RFC PATCH v3 0/5] tracing: common error_log for ftrace Masami Hiramatsu
2019-03-12 6:26 ` Masami Hiramatsu
2019-03-12 16:49 ` Tom Zanussi [this message]
2019-03-13 13:03 ` Masami Hiramatsu
2019-03-13 14:09 ` Tom Zanussi
2019-03-05 21:58 ` Steven Rostedt
2019-03-05 22:05 ` Tom Zanussi
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=1552409351.4293.22.camel@kernel.org \
--to=zanussi@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).