(2013/11/06 15:07), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu...@hitachi.com> wrote: > >>>> [...] I hope to build the list when the kernel build time if >>>> possible... Would you have any idea to classify some annotated(but no >>>> side-effect) functions? >>> >>> The macro magic I can think of would need to change the syntax of the >>> function definition - for example that is how the SYSCALL_DEFINE*() >>> macros work. >> >> Would you mean something like the below macro? :) >> >> NOKPROBE_SYMBOL(int, func_ptr_is_kernel_text)(void *ptr) > > I think this is rather ugly and harder to maintain. The whole _point_ of > such annotations is to make them 'easy on the eyes', to make it easy to > skip a 'noinline', 'noprobe' or 'notrace' tag. > > Using something like NOKPROBE_SYMBOL() makes the whole construct ugly and > attention seeking.
Hmm, by the way how about Steven's idea? A macro like EXPORT_SYMBOL? At least for kprobes_blacklist, which is defined/maintained in kprobes.c for some symbols(*), that is useful for updating it because we can put it near the function definition. * These symbols can not moves to other section because it already in a different section. Of course, still this is not a big problem since there are a few symbols in the kprobe_blacklist. > So until compilers get smarter (or there's some compiler trick I haven't > noticed) lets stay with the separate section - it's not the end of the > world, the (effective) 'noinline' aspect of noprobes changes code > generation anyway. I see. :) So, would you pull this series ? Or I need any update? Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
