Re: runtime control.c

[Roland McGrath <roland at redhat dot com>]

> For one thing, the translator/driver will have to compile multiple
> kernel modules, not just the probe itself.  If relayfs fails to make
> it into the base kernel rpm, the total would be three.  One is better.

If there are runtime support modules that are always the same, you can just
compile them separately and provide them in a separate rpm (making a new
rpm for each kernel build).  There are other rpms like the GFS stuff that
are done this way.  It's a releng hassle to spin the new rpm for every
kernel build, but that's the most thorough way to avoid systemtap compiling
too much stock code at translation time.  Or you might instead just cache
locally compiled modules on the machine so that only the first run of the
systemtap translator for the target kernel build compiles the stock code.
If you are concerned with GCC time spent at systemtap's translation time,
then the thing to do is avoid as much as possible compiling unchanging
stock code during translation, by whichever approach (precompiled or cached).

Myself, I'd wait til we have a working system and can measure the time
profile of realistic translation runs, before trying to hone ways to
optimize it.  Rearranging runtime code into and out of separate modules is
not hard, nor very disruptive at source level, to do later.


Thanks,
Roland