This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]