Re: Re: [RFC][PATCH 00/10] tracing: Use TRACE_DEFINE_ENUM() to show enum values

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(2015/03/30 23:07), Steven Rostedt wrote:
> On Mon, 30 Mar 2015 12:38:15 +0900
> Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> 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