Messages in this thread |  | | | Date | Sat, 21 Mar 2009 17:48:52 -0400 | | From | "Frank Ch. Eigler" <> | | Subject | Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2 |
| |
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
|  |