All of lore.kernel.org
 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 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.