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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
