From: Rik van Riel <riel@redhat.com>
To: Shuah Khan <shuahkhan@gmail.com>, Andy Lutomirski <luto@kernel.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [topic proposal] tracepoints and ABI stability warranties
Date: Wed, 07 Sep 2016 12:10:49 -0400 [thread overview]
Message-ID: <1473264649.10218.56.camel@redhat.com> (raw)
In-Reply-To: <CAKocOOM7XJeW79dtFNx2Agi7cyrQxmMROmQrisdTG8oZMSi_qQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
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.
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.
--
All rights reversed
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-09-07 16:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 18:51 [Ksummit-discuss] [topic proposal] tracepoints and ABI stability warranties Al Viro
2016-09-06 19:22 ` Steven Rostedt
2016-09-06 21:36 ` Alexey Dobriyan
2016-09-06 21:53 ` Steven Rostedt
2016-09-06 22:41 ` Alexey Dobriyan
2016-09-06 23:12 ` Steven Rostedt
2016-09-08 11:43 ` Alexey Dobriyan
2016-09-07 5:10 ` Al Viro
2016-09-07 5:30 ` Andy Lutomirski
2016-09-07 6:41 ` Vlastimil Babka
2016-09-19 12:51 ` Michal Hocko
2016-09-07 13:15 ` Christian Borntraeger
2016-09-07 15:30 ` Shuah Khan
2016-09-07 16:10 ` Rik van Riel [this message]
2016-09-08 3:24 ` Masami Hiramatsu
2016-09-15 19:23 ` Mark Brown
2016-09-06 22:02 ` Alexey Dobriyan
2016-09-06 22:15 ` Steven Rostedt
2016-09-06 21:05 ` Shuah Khan
2016-09-08 3:13 ` Masami Hiramatsu
2016-09-07 23:17 ` Masami Hiramatsu
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=1473264649.10218.56.camel@redhat.com \
--to=riel@redhat.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=luto@kernel.org \
--cc=shuahkhan@gmail.com \
/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.