On Fri, Nov 25, 2016 at 11:51:26AM -0800, Linus Torvalds wrote: > We do have filesystem code that is just disgusting. As an example: > fs/afs/ tends to have these crazy "_enter()/_exit()" macros in every > single function. If you want that, use the function tracer. That seems > to be just debugging code that has been left around for others to > stumble over. I do *not* believe that we should encourage that kind of > "machine gun spray" use of tracepoints. There is a reason why people want to be able to do that, and that's because kprobes doesn't give you access to the arguments and return codes to the functions. Maybe there could be a way to do this more easily using DWARF information and EBPF magic, perhaps? It won't help for inlined functions, of course, but most of the functions where people want to do this aren't generally functions which are going to be inlined, but rather things like write_begin, writepages, which are called via a struct ops table and so will never be inlined to begin with. And it *is* handy to be able to do this when you don't know ahead of time that you might need to debug a production system that is malfunctioning for some reason. This is the "S" in RAS (Reliability, Availability, Serviceability). This is why it's nice if there were a way to be clear that it is intended for debugging purposes only --- and maybe kprobes with EBPF and DWARF would be the answer. After all, we need *some* way of saying this can never be considered stable --- what would we do if some userspace program like powertop started depending on a function name via ktrace and that function disappeared --- would the userspace application really be intended to demand that we revert the recatoring, because eliminating a function name that they were depending on via ktrace point broke them? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
