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]

[Bug translator/4281] two problems with "stap -m"

------- Additional Comments From hunt at redhat dot com  2007-03-26 18:54 -------
(In reply to comment #3)
> It need not actually bypass the cache.  We could cache the resulting probe.ko
> file and reuse it next time.

Or if it is already cached under another name (stap...) just copy it to the
destination and rename it.  This would be one way to enable running multiple
copies of the same script without disabling the cache.

> > Regardless, you can still disable cache and compile a module, then place a copy
> > of it in the current directory. That is what I think it should do.
> Surely that's only appropriate in -p4 mode, for which we now print the resulting
> module file name on stdout.  We don't normally put files into pwd at all, though
> that is a plausible fallback if neither -k was given nor the cache is available.

> stap -p4 -m close examples/small_demos/close.stp
Warning: using '-m' disables cache support.

> ls -l close*
/bin/ls: close*: No such file or directory

At the very least, we need some kind of warning that you need to use "-k" with
"-m" and look for your module in the temporary directory. But wouldn't it be
better to not require "-k" at all and maybe just put the module in the current
directory.  Wouldn't that make scripting things easier to?  Right now you have
to compile modules and parse the output from stap to get the temporary
directory, then copy the module from there to where you want it, then rm -rf the
temp directory.


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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