From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1768324AbcHROda (ORCPT ); Thu, 18 Aug 2016 10:33:30 -0400 Received: from mail.kernel.org ([198.145.29.136]:44600 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1950325AbcHROPg (ORCPT ); Thu, 18 Aug 2016 10:15:36 -0400 Date: Thu, 18 Aug 2016 11:14:42 -0300 From: Arnaldo Carvalho de Melo To: Masami Hiramatsu Cc: Steven Rostedt , linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Naohiro Aota , Alexander Shishkin , Wang Nan , Hemant Kumar Subject: Re: [PATCH 0/6] perf/ftrace: Introduce hexadecimal type casting Message-ID: <20160818141442.GT20972@kernel.org> References: <147151064700.12957.1184322470361742842.stgit@devbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147151064700.12957.1184322470361742842.stgit@devbox> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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