Hi,
On Fri, May 30, 2008 at 01:14:34AM -0400, Andrei Barbu wrote:
> SystemTap itself doesn't get to sit in the Linux kernel. Linux exposes
> an in-kernel API called kprobes. That allows you to do something like
> (conceptually, not real code) set_entry_probe("some_function", myfun),
> that will call myfun when some_function executes and give myfun its
> arguments; after myfun it restores the old function; including the
> stack. What SystemTap does is take code, in their internal language
> (or C if one wishes), compiles it and wraps it in module loading code.
> So what you get is a module that implements the probe that you want.
> SystemTap often will just load this for you and the module
> automatically calls kprobes to hook into the appropriate bits of the
> kernel. So if we wanted to just support SystemTap without any changes
> we'd definitely need module loading support.
I see.
> > It may still be the preferable solution though, if the other option
> > of running it is user space involves much more effort and/or risk...
>
> I think adding a module loading API just for this is overkill and GNU
> Mach probably ought not to have one. By risky, do you mean, will the
> project be completed if we choose the 3rd option?
Yes. Or more precisely: As it seems to be a more experimental path,
could there be considerable danger that unexpected problems show up,
making it impossible to finish it in time?...
> I don't foresee this to be an issue, there's actually not all that
> much extra work that must be done. Adding module support would be far
> more work.
OK, I take your word for it :-)
> Without modules what would be needed is a port exposed for privileged
> enough userland processes so that they can request a probe in the
> kernel and receive information for when the probe fired. Then the
> wrapper code for systemtap would be changed to create processes that
> use this port instead of kernel modules that set kprobes directly.
Doesn't sound too hard indeed -- at least on paper ;-)
-antrik-
