This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

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.

> Similarly, with respect to function("foo") vs. inline("foo"), a
> bunch of accidents are producing the current effects.  Do you have
> an opinion about how they *should* work?

Are you referring to discussions of "merging" the function/inline
syntax?  This is harder, because inlines aren't localized.  If an inline
function is part of a kernel API, then you really have to do module("*")
to probe all instances.  And I don't think this broad searching is
something we should automatically do.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]