Re: [Ksummit-discuss] [topic proposal] tracepoints and ABI stability warranties

[Masami Hiramatsu <mhiramat@kernel.org>]

On Wed, 07 Sep 2016 12:10:49 -0400
Rik van Riel <riel@redhat.com> wrote:

> On Wed, 2016-09-07 at 09:30 -0600, Shuah Khan wrote:
> > On Tue, Sep 6, 2016 at 11:30 PM, Andy Lutomirski <luto@kernel.org>
> > wrote:
> > > 
> > > I wouldn't mind a policy that tracepoints are simply never
> > > stable.  Maybe we
> > > should even deliberately change them periodically to drive the
> > > point home.
> > > 
> > > The kernel should be able to have a debug API that is genuinely for
> > > *debugging* and doesn't freeze the underlying implementation.
> > Agreed. Tracepoints and events provide a powerful tool in debug
> > certain class
> > of problems (races and performance problems) where traditional debug
> > methods
> > such as CONFIG_DEBUG_FOO aren't effective. Trace information includes
> > important
> > status information on thread status which is helpful in debugging.
> 
> From an enterprise distro (and user) point of view,
> it is important to be able to debug a kernel that
> is running on a production system (and developed
> some problem after a month of running), without
> having to reboot into a special "debug kernel".
> 
> Being able to just fire up a tracer debugging
> script that can identify intermittent problems
> is an invaluable tool in making the kernel better
> for our users.

I had made a systemtap flight-recorder mode for same reason, which
records events in background and user can dump it if something
happens. I know that ftrace also has a trace buffer dump feature
when kernel gets panic. (and crash can dump ftrace buffer from
kernel crashdump)

> Hamstringing our ability to make the kernel better,
> in order to keep the debugging ABI stable, is
> shooting ourselves (and our users) in the foot.

Agreed, even if we are able to stabilize tracepoints, the code context
around the tracepoints should be changed, not only code evolution,
but also fixing bugs.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>