Messages in this thread | | | Date | Tue, 31 Mar 2015 16:36:51 +0900 | From | Masami Hiramatsu <> | Subject | Re: Re: [RFC][PATCH 00/10] tracing: Use TRACE_DEFINE_ENUM() to show enum values |
| |
(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
| |