From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753569AbbCaHhD (ORCPT ); Tue, 31 Mar 2015 03:37:03 -0400 Received: from mail9.hitachi.co.jp ([133.145.228.44]:49814 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753386AbbCaHg6 (ORCPT ); Tue, 31 Mar 2015 03:36:58 -0400 Message-ID: <551A4E93.1030309@hitachi.com> Date: Tue, 31 Mar 2015 16:36:51 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steven Rostedt CC: linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Namhyung Kim , Mathieu Desnoyers Subject: Re: Re: [RFC][PATCH 00/10] tracing: Use TRACE_DEFINE_ENUM() to show enum values References: <20150327213704.857765144@goodmis.org> <5518C527.7020101@hitachi.com> <20150330100743.0fac7066@gandalf.local.home> In-Reply-To: <20150330100743.0fac7066@gandalf.local.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (2015/03/30 23:07), Steven Rostedt wrote: > On Mon, 30 Mar 2015 12:38:15 +0900 > Masami Hiramatsu wrote: > >> (2015/03/28 6:37), Steven Rostedt wrote: >>> As there are many tracepoints that use __print_symbolic() to translate >>> numbers into ASCII strings, and several of these translate enums as >>> well, it causes a problem for user space tools that read the tracepoint >>> format files and have to translate the binary data to their associated >>> strings. >>> >>> For example, with the tlb_flush tracepoint, we have this in the format >>> file: >>> >>> print fmt: "pages:%ld reason:%s (%d)", REC->pages, >>> __print_symbolic(REC->reason, >>> { TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" }, >>> { TLB_REMOTE_SHOOTDOWN, "remote shootdown" }, >>> { TLB_LOCAL_SHOOTDOWN, "local shootdown" }, >>> { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" }), REC->reason >> >> Hmm, would user-space application really need to know the symbol name of enums? >> If not, the event format files would better export the number(value) instead of >> the enum name, like below. >> >> print fmt: "pages:%ld reason:%s (%d)", REC->pages, >> __print_symbolic(REC->reason, >> { 0, "flush on task switch" }, >> { 1, "remote shootdown" }, >> { 2, "local shootdown" }, >> { 3, "local mm shootdown" }), REC->reason >> >> I'm still not sure how we can code it :( (It seems that some trick we need when >> showing the print fmt.) > > > Believe me, I've tried tons of tricks. I even pulled out my "Elder MACRO > Wand", and it too could not execute the enum illuminous valueous (to > show both the enum name and value in the same output). > > The problem is that an enum name is only known by the compiler itself. > The preprocessor does not know what an enum is. And after the compiler > is done, the enum name no longer exists, just its value. Yeah, I see. Handling enums in macro is not possible. > > Thus, I found no way to have print_fmt display the numbers instead of > the names. > > Instead of adding an enum mapping file, I could add a way to look at > all the events in the system that defined a mapping, and do a > "s/ENUM_NAME/ENUM_VALUE/g" do the saved print formats? I'm not sure how > much we want to do that in the kernel though. No, it's not what I expected... What I thought was expanding __print_symbolic() macro in TP_printk with a special hash string(start with #), and when showing it via event/format, replace the hash string with the strings generated by the map of symbols. This will introduce a small overhead to show the format as a side effect. Actually I even have not tried, so it's just an idea yet. Thank you, >>> Now, userspace does not know what the value of TLB_REMOTE_SHOOTDOWN is. >>> To solve this, a new macro is created as a helper to allow tracepoints >>> to export enums they use to userspace. This macro is called, >>> TRACE_DEFINE_ENUM(), such that >>> >>> TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN); >>> >>> Will export the TLB_REMOTE_SHOOTDOWN enum to use space. >>> >>> How that is done is with a new file in the debugfs tracing directory. >>> >>> # cat /sys/kernel/debug/tracing/enum_map >>> TLB_LOCAL_MM_SHOOTDOWN 3 >>> TLB_LOCAL_SHOOTDOWN 2 >>> TLB_REMOTE_SHOOTDOWN 1 >>> TLB_FLUSH_ON_TASK_SWITCH 0 >> >> BTW, if we can show the enum_map, can we also show the "symbolic" map >> instead of using the __print_symbolic() ? :) > > There's nothing mapping the two in the kernel. And worse yet, some > enums are used in operations. Just look at f2fs_submit_read_bio, where > in the __print_symbolic() it has: > > (1ULL << __REQ_NOIDLE) | ... > > the __REQ_NOIDLE is an enum. > > But, if I do just a substitution, then we wont even have to update > userspace tools. They should still work. > > -- Steve > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com