Re: [PATCH 1/3] tracing: add __print_flags for events

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

Hi Steven,

> From: Steven Rostedt <srostedt@redhat.com>
> 
> Developers have been asking for the ability in the ftrace event tracer
> to display names of bits in a flags variable.
> 
> Instead of printing out c2, it would be easier to read FOO|BAR|GOO,
> assuming that FOO is bit 1, BAR is bit 6 and GOO is bit 7.
> 
> Some examples where this would be useful are the state flags in a context
> switch, kmalloc flags, and even permision flags in accessing files.
> 
> I included Frederic Weisbecker's idea of using a mask instead of bits,
> thus we can output GFP_KERNEL instead of GPF_WAIT|GFP_IO|GFP_FS.
> 
> I also included Li Zefan's idea of allowing the caller of __print_flags
> to add their own delimiter (or no delimiter) where we can get for
> file permissions rwx instead of r|w|x.
> 
> [ Impact: better displaying of flags in trace output ]

very good feature :)

I'd like to discuss a bit offtopic. struct page->flags have
some overlapped meaning.

example, Wu proposed kpageflags enhancement about two week ago.
his patch have following hunk.

+	/*
+	 * pseudo flags for the well known (anonymous) memory mapped pages
+	 *
+	 * Note that page->_mapcount is overloaded in SLOB/SLUB/SLQB, so the
+	 * simple test in page_mapped() is not enough.
+	 */
+	if (!PageSlab(page) && page_mapped(page))
+		u |= 1 << KPF_MMAP;


How do we handle such complex condition?