Re: module("kernel") / inline("function")

[Roland McGrath <roland at redhat dot com>]

> I believe it's an elfutils behavior that we just inherited.  

Indeed it is.  The meaning of "module" in the libdwfl interfaces is each
thing with an ELF file.  For the linux kernel incarnation, I chose to call
the module for the main kernel image "kernel" for obvious clarity in the
output of other tools (any eu-* thing you can give -k/-K).  I assumed noone
will ever name a module "kernel", though it's not technically prohibited.
In the parallel case of a user executable with DSOs, the libdwfl module for
main executable is named "".  

What terminology systemtap should use is another story, and I agree with
the sentiment that "module" does not naturally define a set of which
"kernel" is a member.  Tapset writers presumably start with the perspective
of what the kernel source looks like.  There you have modules for
subsystems, but you don't really think too hard about whether they are
technically modules or are compiled in.

Perhaps what tapset writers want is: subsystem("name").  Here "name" is a
kernel module name as seen in lsmod.  The set does not include "kernel".
The other difference from current module("name") is that "name" might not
be a module.  If it appears in the list of possible modules for the
particular kernel build, then subsystem("name").foo -> module.foo; if not,
then subsystem("name").foo -> kernel.foo.  The list of all possible modules
is available in the offline compilation style that we are working on
converting to, though not readily available to systemtap now.  So
implementing this now would not be able to distinguish "you haven't loaded
that module" from "no such module exists".


Thanks,
Roland