Messages in this thread | | | Date | Tue, 19 Sep 2006 09:14:19 -0700 | From | Martin Bligh <> | Subject | Re: [PATCH] Linux Kernel Markers |
| |
> It is an interesting idea but there appears to be following hard issues > (some of which you have already listed) i am not able to see how we can > overcome them > > 1) We are going to have a duplicate of the whole function which means > any significant changes in the original function needs to be done on the > copy as well, you think maintainers would like this double work idea.
No, no ... the duplicate function isn't duplicated source code, only object code. Either a config option via the markup macros that we've been discussing, or something I hack up on the fly to debug a problem dynamically. In terms of how the debugging-type source code is kept, it's no different than something like systemtap or LTT (either would work, and a normal diff could be used to keep out of tree stuff), it's just how it hooks in is different to kprobes.
> 2) Inline functions is often the place where we need a fast path to > overcome the current kprobes overhead.
You can still instrument inline functions, you just need to hook all the callers, not the inline itself.
> 3) As you said it is not trivial across all the platforms to do a switch > to the instrumented function from the original during the execution. > This problem is similar to the issue we are dealing with djprobes.
If we just freeze all kernel operations for a split second whilst we do this, does it matter? Or even if we don't ... there's a brief race where some calls are traced, and some are not ... does that even matter? Doesn't seem like most usages would care.
M.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |