lkml.org 
[lkml]   [2019]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v3 0/5] tracing: common error_log for ftrace
From
Date
Hi Masami,

On Wed, 2019-03-13 at 22:03 +0900, Masami Hiramatsu wrote:
> On Tue, 12 Mar 2019 11:49:11 -0500
> Tom Zanussi <zanussi@kernel.org> wrote:
>
> > 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/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> > > rrrr
> > > 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/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> > > rrrr
> > > 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.
>
> It is OK, that is same as dmesg. If user needs to keep watching it,
> it should be dumped to disk by a daemon.
>
> >
> > 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?
>
> What about timestamp, similar to dmesg?
>

Yeah, I think that makes more sense - unlike the counter, there's no
sense that you may be missing some prior messages.

Thanks,

Tom

> Thank you,
>
>
>

\
 
 \ /
  Last update: 2019-03-13 15:10    [W:0.047 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site