On Mon, 2009-02-23 at 13:32 -0500, Theodore Tso wrote: > On Mon, Feb 23, 2009 at 12:31:31PM -0500, Steven Rostedt wrote: > > > The impression that this is somehow different with tracepoints is > > > mistaken. Tracepoints are *exactly* as "ABI-like" as markers. > > > > I disagree with this point. markers are text strings that will eventually > > appear to userspace. trace points need translation. A trace point can be > > modified at any time and should never mess up user apps. > > > > You may have a hook to a trace point that provides user apps a text based > > output. If the trace point changes, this hook may break. But the tracer > > maintainer of that hook will be responsible for that change, not the > > maintainer of the code the tracepoint existed in. > > So stupid question time --- exactly who is supposed to write and > maintain trnaslation code; the "hook"? What trace points have done is > added an extra layer of indirection, but in order for someone to > actually make *use* of the have the trace point, someone has to > maintain the "hook". That just means we have to make it easier to write/generate this glue, no? If we had function argument debug data (see below) we could generate a generic tracepoint hook. > I'm sorry I've offended Peter with the ext4 trace_mark() hooks, but > it's what I could forsee needing if someone wants reports a wierd sh*t > bug in ext4 and I wanted to be able to be able to extract debugging > information without forcing them to patch and recompile the kernel, > and in the ideal world, without even needing to reboot the kernel. > (If we had usable and reliable debuginfo information, in most cases > I'd be able simply use access to function parameters as replacements > for trace_mark().) We're working on adding arguments to the function/graph tracer, it would fit all your above requirements and doesn't need any source modification to boot. Furthermore, most of it is upstream. > I've had to debug problems in the field on customer machines where > installing a new kernel was a big deal (as in, you get a window to > reboot the machine every 24 hours, and the problem is so complex you > can't replicate it anywhere *but* the production environment). It's > also been the case that more than once I've seen wierd behaviour on my > laptop, and being able to peer inside it to see what is going on > easily and conveniently is a major win. Yeah, I know, the function graph tracer is brilliant that way. It even provides information on the rest of the system and requires no additional patches or big lumps of userspace. > Finally, whether or not the text string is an ABI really depends on > the tools. Given that the string is self describing, it's only an ABI > if the tools are stupid. > This really isn't rocket science.... It isn't, yet how many scripts/programs have you seen that failed at the above? -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
