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: nits to please a kernel hacker


On Tue, Sep 30, 2008 at 10:09:33AM -0400, Frank Ch. Eigler wrote:
> 
> That's a good point; actual error messages should not be filtered by
> the verbosity logic.  Rather, verbosity values should produce more
> informative text about what preceded the error.
> 

I really think the verbosity approach is not the right one; in the
long run, if the goal is for non-source-code-reading-sysadmins to use
this tool, systemtap really needs to consider using some kind of error
message translation scheme so that the wierd error messages that get
ommitted (currently with a sufficiently high verbosity level) because
the optimizer has made the DWARF information useless, gets translated
into something which a non-tools, non-systemtap expert can actually
understand.  Getting rid of the verbosity level for error messages is
just the first step; it still would be a good idea to trap common
error messages such to english, such as ("attempt to set tracepoint
where the C compilers' sptimizer has optimized out the code", or
"attempt to compile the systemtap runtime failed; probably a failed
systemtap installation?").

> (By the way, many of Roland's frustrations could've been avoided
> had he done it the README way and ran a "make install".)

Maybe it would be better if the README had some explicit words ---
"don't even bother trying to run it out of the build tree; systemtap
has to be run in an installed configuration"?

Yes, some people might be annoyed about needing to install it in
/usr/local.  (Although if you provide and document a "make uninstall",
that can satisfy a lot of the complaints).  But it seems pretty clear
that it is ***so*** annoying to run systemtap out of the build tree
that it might not be worth it.  Sure, you can provide shell scripts
that set all of the magic environment scripts, and that might not be a
bad thing to do.  But the problem is that it makes Systemtap see very
clunky.   

Another approach might be to add logic which tries to detect if stap
was run in the build tree, and then automatically sets all of the
defaults to find the runtime, et. al, out of the build tree.  The
question is whether the additional complexity is worth it.

Regards,

						- Ted


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