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: [Ksummit-2008-discuss] DTrace


On Sat, Jul 05, 2008 at 11:44:09AM +0200, Peter Zijlstra wrote:
> On Tue, 2008-07-01 at 19:13 -0400, Theodore Tso wrote:
> 
> .. snip Ted talking about how using Systemtap is a pain ..
> 
> Well said. Until the point where using Systemtap is less work than
> recompile and boot I'm not remotely interested in even looking at it.

To be fair, Systemtap has gotten a lot better.  About a week ago or so
the latest version in its git tree actually passes the "download,
configure, make" test on Ubuntu Hardy.  Apparently previous to that
you needed to know about the magic --enable-staticdw configure option,
but its build system has been made much smarter now, which is good.

Kernel compiles with symbols *do* take longer, since DWARF is just
such a bloated method of storing debugging information, and so the
files get much, much bigger.  However, if you are worried about your
root partition filling up due to bloaded modules taking up a huge
amount of space, you can do this: "make INSTALL_MOD_STRIP=1 modules_install;
make INSTALL_MOD_PATH=/usr/lib/debug modules_install".

I have this partially automated with some patches to make-kpkg, on my
Ubuntu system.  (Available on request).  The real issue is that there
is a bunch of basic usability issues that aren't well documented, or
better yet, automated.  As a result, people hit these things, get
frustrated, and then go back to printk.  They're not going to file
bugs in some bugzilla; they're not going to switch their distribution
to Fedora; they're just going to move on to something more productive.

The really wierd thing is that this might make sense if Systemtap were
primarily targetted at system administrators, and not kernel
developers.  If this were so, making a bunch of installation issues
distro-specific, and only worrying about distro-supplied kernels and
not about kernel developer workflow might make sense.  But given that
a common excuse I've heard for the paucity of tapsets is "well, we
need the kernel developer's expertise", and the fact that Systemtap
has various UI decisions that really seem to make it much more
optimized for developers (there are various things that in Dtrace can
be done with a single command line, but which in Systemtap requires a
much longer scripts, which is bad for system administrators who find
it much easier to use DTrace as a result), this just seems to be a
very puzzling gap.

> Also, it would be really great if you could write probes in regular C,
> some pseudo C language just messes up my mind.

You can.  Just surround the code with %{ and %} symbols.  In fact, you
have to do this a lot in tapsets.

							- Ted


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