Re: [RFC PATCH v3 0/5] tracing: common error_log for ftrace

[Masami Hiramatsu <mhiramat@kernel.org>]

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

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?

Thank you,



-- 
Masami Hiramatsu <mhiramat@kernel.org>