Re: runtime requests

[Roland McGrath <roland at redhat dot com>]

> - packaging it all into a single file, so it can be easily transcribed
>   into the output file, just like the bison parser template

Is this really a benefit?  The complete task of building of the module
needs to be done by the probe management tool.  Even if this is a simple
script, it's not really harder to do it in a more normal way.  i.e., the
translator per se doesn't care if it emits <big blob> or <#include
"runtime-decls.h">, and the thing that runs the translator and then the C
compiler and linker can do it just as easily with a directory full of
runtime code or a single file.  I have two motivations for resisting the
idea of throwing it all into a single C file early on.  First is for our
development--it's just easier if you can run the translator and then hack
and debug its output and the runtime code in its real source form directly,
not deal with some copy.  Another element of that same concern is just ease
of writing the runtime code, i.e. using "static foobar" in file scope two
different runtime source files without thinking about the collision.  The
second motivation is to leave the door open for later compiling the runtime
separately.  I have suspicions about the speed of probe source->.ko process
and moreover its users' expectations and complaints (not to say real
needs); an easy part of improving that will be caching the .o's of the
compiled runtime code against the given kernel, and running the C compiler
every time for the C generated by the translator.