(restore cc's) On 11/24, Andi Kleen wrote: > > On Tue, Nov 24, 2009 at 09:41:52PM +0100, Oleg Nesterov wrote: > > On 11/24, Andi Kleen wrote: > > > > > > Oleg Nesterov <o...@redhat.com> writes: > > > > > > > From: Roland McGrath <rol...@redhat.com> > > > > > > > > This adds the utrace facility, a new modular interface in the kernel > > > > for implementing user thread tracing and debugging. This fits on top > > > > of the tracehook_* layer, so the new code is well-isolated. > > > > > > Could we just drop the tracehook layer if this finally merged > > > and call the low level functions directly? > > > > Not sure I understand. Tracehooks are trivial inline wrappers on > > top utrace calls, > > Yes that's the problem -- they are unnecessary obfuscation > when you can just call directly.
This is subjective, but personally I disagree. Contrary, imho it is good that tracehook hides the (simple) details. I do not understand why the reader of, say, do_fork() should see the contents of tracehook_report_clone_complete(). This will complicate the understanding. Those people who want to understand/change fork() do not care about utrace/ptrace usually. And please note that it is much, much easier to change this code when it lives in tracehooks.h instead of sched.c/signal.c/etc. > > What is the point? > > Less code obfuscation. > > When it's a utrace call, call it a utrace call, not something else. Why do you think this is obfuscation? Well, we can rename these helpers, s/tracehook_/utrace_/, but I don't see how this can make the code more readable. Oleg.
