Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > [...] SystemTAP, for instance, does it out of tree by keeping a > separate list of address where kprobes must be installed. It does > the job on a distribution kernel maintainer perspective (Redhat), > since they freeze to a particular kernel version and update this > list every time it breaks, but will always be a source of > frustration for vanilla kernel users and kernel developers.
This misstates the details. What systemtap has out-of-tree is a list of kernel function names (and parameter names), not addresses. This list does change somewhat with kernel versions, but we generally keep up. We do test with vanilla kernels, and several non-RH distributors test with their kernels. It is a problem, but it is manageable. > I think the best way to follow the code flow is to add markup in the > code itself: it would follow the kernel HEAD and let each subsystem > maintainer identify the key instrumentation sites of their > subsystem. Of course - when and where the dormant overheads are acceptable, and where the maintainers are willing to commit to a long-term interface (marker name/arguments). Systemtap can connect to markers as well as to kprobes and other event sources: mix & match based on what's available in your particular kernel and what data/computation you want. > About extending on ptrace, I am sorry to say that this solution has > the same downsides as kprobes: it is too slow for high performance > applications, especially if turned on system-wide. [...] Roland McGrath's ptrace-replacement (utrace) should help with this. - FChE - 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/
