linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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,
> 

  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).