On Mon, 30 Mar 2015 12:38:15 +0900 Masami Hiramatsu <masami.hiramatsu...@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. 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. > > > > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/