From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Oleg Nesterov <oleg@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Masami Hiramatsu <mhiramat@redhat.com>,
Seiji Aguchi <saguchi@redhat.com>,
linux-kernel@vger.kernel.org,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: [GIT PULL] tracing: make signal tracepoints more useful
Date: Tue, 17 Jan 2012 07:03:31 -0500 [thread overview]
Message-ID: <1326801811.7642.188.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20120117100222.GH10397@elte.hu>
On Tue, 2012-01-17 at 11:02 +0100, Ingo Molnar wrote:
> That is not true *AT ALL* in such an unqualified manner. Steve,
> stop being stupid.
>
> The kernel syscall ABI may indeed sometimes expand *INPUT*
> structures (if via some mechanism it's possible to make sure
> that old ABI uses don't cause the kernel to read undefined
> data), but the trace events are *OUTPUT* structures.
The difference between syscalls and tracepoints is that a tracepoint
always reports the size of the structure that was read, where a syscall
does not. So I do consider this similar to reading the /proc/stat file
as the user can see how much was read. The backwards compatibility
should be easy to write. Old tools should not break, because it wont be
reading the new fields, and new tools can determine which tracepoint is
there because it is trivial to see which version of the tracepoint is
there because of the size read.
But as I'm stupid, I'll shut up now.
-- Steve
next prev parent reply other threads:[~2012-01-17 12:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 17:45 [PATCH 0/2] " Oleg Nesterov
2012-01-10 17:45 ` [PATCH 1/2] tracing: let trace_signal_generate() report more info, kill overflow_fail/lose_info Oleg Nesterov
2012-01-10 17:45 ` [PATCH 2/2] tracing: send_sigqueue() needs trace_signal_generate() too Oleg Nesterov
2012-01-10 18:59 ` [PATCH 0/2] tracing: make signal tracepoints more useful Steven Rostedt
2012-01-10 21:09 ` Seiji Aguchi
2012-01-13 18:20 ` [GIT PULL] " Oleg Nesterov
2012-01-15 18:24 ` Oleg Nesterov
2012-01-16 7:45 ` Ingo Molnar
2012-01-16 12:31 ` Steven Rostedt
2012-01-16 12:53 ` Ingo Molnar
2012-01-16 15:10 ` Oleg Nesterov
2012-01-17 18:50 ` Linus Torvalds
2012-01-18 9:39 ` Ingo Molnar
2012-01-16 15:52 ` Steven Rostedt
2012-01-17 10:02 ` Ingo Molnar
2012-01-17 12:03 ` Steven Rostedt [this message]
2012-01-17 12:40 ` Ingo Molnar
2012-01-17 14:04 ` Oleg Nesterov
2012-01-18 11:59 ` Ingo Molnar
2012-01-17 14:37 ` Steven Rostedt
2012-01-17 14:55 ` Oleg Nesterov
2012-01-20 18:01 ` Jason Baron
2012-01-17 19:52 ` Steven Rostedt
2012-01-16 15:03 ` Oleg Nesterov
2012-01-16 15:42 ` Seiji Aguchi
2012-01-16 15:58 ` Steven Rostedt
2012-01-26 10:10 ` Ingo Molnar
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=1326801811.7642.188.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=saguchi@redhat.com \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®