Hi - On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote: > [...] > To me personally there are two big direct usability issues with > SystemTap: > > 1) It relies on DEBUG_INFO for any reasonable level of utility. > Yes, it will limp along otherwise as well, but most of the > actual novel capabilities depend on debuginfo. Which is an > acceptable constraint for enterprise usage where kernels are > switched every few months and having a debuginfo package is not > a big issue. Not acceptable for upstream kernel development.
In my own limited kernel-building experience, I find the debuginfo data conveniently and instantly available after every "make". Can you elaborate how is it harder for you to incidentally make it than for someone to download it? > It also puts way too trust into the compiler generating 1GB+ of > debuginfo correctly. I want to be able to rely on tools all the > time and thus i want tools to have some really simple and > predictable foundations. Well, the data has to come from *somewhere*. We know several shortcomings (and have staff working on gcc debuginfo improvements), but there is little alternative. If not from the compiler, where are you going to get detailed type/structure layouts? Stack slot to variable mappings? Statement-level PC addresses? Unwind data? > 2) It's not upstream and folks using it seem to insist on not > having it upstream ;-) This 'distance' to upstream seems to have > grown during the past few years - instead of shrinking. [...] Considering our upstream-bound assistance with foundation technologies like markers, tracepoints, kprobes, utrace, and several other bits, this does not seem entirely fair. > If these fundamental problems are addressed then i'd even argue for > the totality of SystemTap to be aimed upstreamed (including the > scripting language, etc.), [...] If consensus on this were plausible, we could seriously discuss it. But I don't buy the package-deal that utrace must not attempt merging on its own merits, just because it makes systemtap (as it is today) useful to more people. - FChE
