From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Naohiro Aota <naohiro.aota@hgst.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Wang Nan <wangnan0@huawei.com>,
Hemant Kumar <hemant@linux.vnet.ibm.com>
Subject: Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting
Date: Thu, 18 Aug 2016 11:14:42 -0300 [thread overview]
Message-ID: <20160818141442.GT20972@kernel.org> (raw)
In-Reply-To: <147151064700.12957.1184322470361742842.stgit@devbox>
Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:
> Hi Arnaldo and Steven,
>
> Here is an RFC series of hexadecimal type casting and
> changing default type casting of perf and ftrace.
>
> I've introduced x8,x16,x32,x64 according to previous
> discussion on LKML.
> https://lkml.org/lkml/2016/8/10/339
>
> This series includes not only adding hexadecimal types
> (x8,x16,x32,x64), but also checking it is supported by
> running kernel and keeping the backward compativility.
>
> [1/6] Add hexadecimal type casting, but does not touch
> existing types like 'u8'.
> [2/6] Show the supported types on README of ftrace so
> that user application (e.g. perf) can check that.
> [3/6] Add a type availability check to perf-probe.
> [4/6] Add hexadecimal prefix support to perf-probe if
> it is supported by the kernel.
> [5/6] Change the perf-probe default type casting for
> unsigned type to hexadecimal (for backward compatibility)
> [6/6] Change ftrace's 'uNN' to show value in decimal
> and use 'xNN' by default (for backward compatibility)
>
> This way, we can also add "octal" type, pointer type,
> and "character" type etc. and perf can check whether
> the kernel supports it or not. :)
But this requires a kernel update... If we do it all in the tooling
side, no kernel changes are required _and_ newer tools will work with
older kernels, as this is just a formatting issue, the value is there
and from its format one can infer its value, it is not even necessary to
look at its "type".
I understand this is necessary for ftrace, because the pretty printer is
in the kernel, but I don't see why we would prevent tooling from doing
this pretty printing work and make it support any kernel.
I.e. no need at all for checking if the kernel supports anything, just
pretty print it.
- Arnaldo
next prev parent reply other threads:[~2016-08-18 14:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 8:57 [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Masami Hiramatsu
2016-08-18 8:57 ` [PATCH 1/6] ftrace: kprobe: uprobe: Add x8/x16/x32/x64 for hexadecimal types Masami Hiramatsu
2016-08-18 15:38 ` Steven Rostedt
2016-08-24 9:25 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2016-08-18 8:58 ` [PATCH 2/6] ftrace: probe: Add README entries for k/uprobe-events Masami Hiramatsu
2016-08-18 15:40 ` Steven Rostedt
2016-08-24 9:25 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2016-08-18 8:58 ` [PATCH 3/6] perf probe: Add supported type casting of running kernel Masami Hiramatsu
2016-08-23 19:45 ` Arnaldo Carvalho de Melo
2016-08-24 9:26 ` [tip:perf/core] perf probe: Add supported for type casting by the " tip-bot for Masami Hiramatsu
2016-08-18 8:58 ` [PATCH 4/6] perf probe: Support hexadecimal casting Masami Hiramatsu
2016-08-24 9:26 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2016-08-18 8:59 ` [PATCH 5/6] perf-probe: Use hexadecimal type by default if possible Masami Hiramatsu
2016-08-24 9:27 ` [tip:perf/core] perf probe: " tip-bot for Masami Hiramatsu
2016-08-18 8:59 ` [PATCH 6/6] ftrace: kprobe: uprobe: Show u8/u16/u32/u64 types in decimal Masami Hiramatsu
2016-08-18 15:41 ` Steven Rostedt
2016-08-24 9:27 ` [tip:perf/core] " tip-bot for Masami Hiramatsu
2016-08-18 14:14 ` Arnaldo Carvalho de Melo [this message]
2016-08-18 16:01 ` [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Masami Hiramatsu
2016-08-18 16:13 ` Arnaldo Carvalho de Melo
2016-08-20 3:40 ` Masami Hiramatsu
2016-08-18 16:03 ` Steven Rostedt
2016-08-18 16:08 ` Arnaldo Carvalho de Melo
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=20160818141442.GT20972@kernel.org \
--to=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=hemant@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=naohiro.aota@hgst.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=wangnan0@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox