> I don't get this: Why implement module loading just for this? Can't
> SystemTap be just statically linked in gnumach? Or are the actual test
> functions compiled and loaded as modules in SystemTap?...
>
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.
> In the latter case, I agree that it would be a bit ugly. 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? 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. 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.
Andrei
