From: Steven Rostedt <rostedt@goodmis.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [topic proposal] tracepoints and ABI stability warranties
Date: Tue, 6 Sep 2016 18:15:32 -0400 [thread overview]
Message-ID: <20160906181532.75bed9db@gandalf.local.home> (raw)
In-Reply-To: <20160906220213.GA16979@p183.telecom.by>
On Wed, 7 Sep 2016 01:02:13 +0300
Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Wed, Sep 07, 2016 at 12:36:44AM +0300, Alexey Dobriyan wrote:
> > P.S.: techically every kernel release almost certainly breaks crash(1)
> > program, program many people on this list should be familiar with.
> > It is unclear why rules should be different for tracepoints.
>
> Concrete example:
>
> TRACE_EVENT(sched_switch,
> TP_STRUCT__entry(
> __array( char, prev_comm, TASK_COMM_LEN )
> __field( pid_t, prev_pid )
> __field( int, prev_prio )
> __field( long, prev_state
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> struct task_struct::state is long but it looks like a historical
> artifact, it can be just int. In this case it is easy to extend value and
> preserve compatibility.
Oh, tracepoints can change, and they do all the time. It's only if that
change breaks existing tools.
The sched_wake_up has a "success" field that tools use to know if the
wake up was successful or not. That's because the old code where the
tracepoint was located was hit even if the task was already awake and
nothing happened. Today the tracepoint is only called when a wake up
actually happens. That is, "success" is always true. But we need to
keep that there, because existing tools depend on it.
-- Steve
next prev parent reply other threads:[~2016-09-06 22:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 18:51 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
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 [this message]
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=20160906181532.75bed9db@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=adobriyan@gmail.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox