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

[Mike Mason <mmlnx at us dot ibm dot com>]

Stone, Joshua I wrote:
> On Monday, July 31, 2006 1:25 PM, Frank Ch. Eigler wrote:
> > joshua.i.stone wrote:
> >
> > > [...]  I believe the current parser treats the kernel as a module
> > > named "kernel".  [...]
> > I believe it's an elfutils behavior that we just inherited.  I am
> > ambivalent about whether this is a good idea.
>
> I don't have a strong opinion on this either.  One nice thing in
> treating it this way is that module("*") effectively means "anywhere in
> the kernel address space".  It might be better if it used a name that
> couldn't be an actual module name -- perhaps "$kernel" or "$vmlinux" or
> something.  But it doesn't seem useful to me to have a way to specify
> all-modules-but-not-the-kernel, especially when a module on one system
> might be compiled-in on another system.

Being a newcomer to systemtap, I'm not aware of all the reasoning behind 
the way it currently works.  I can say, though, that from a usability 
standpoint, having module("*") mean "anywhere in the kernel address 
space" makes no sense to me, regardless of whether it's useful. It does 
not produce the expected result. Most users won't realize this is the 
behavior unless they take the time to look at the resulting C code.

> A bit of a side note, I think we should discourage tapsets using
> module("*") unless they really mean it.  The offender that comes to mind
> is the scsi tapset.  I understand that this was done to cover whether
> CONFIG_SCSI=y or m, but the "optional" syntax would suit this better.
> Instead it could be 'kernel.function("scsi...")?,
> module("scsi_mod").function("scsi...")?'.  This is more verbose, but by
> being more explicit we avoid having to read debuginfo for ALL modules.

I agree. I think any tapset or script should explicitly ask for what it 
wants as opposed to relying on a side effect of module("*"). Brevity can 
be taken too far.

Just my .02

Mike Mason