This is the mail archive of the systemtap@sourceware.org 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] |
Hi -I don't have any specific tool in mind but giving this interface satisfies the need for those who wants to write their own programs to trace user space without needing to use systemtap. I am not sure in reality how many people will do that but comments seem to ask for such an interface.
varap wrote:
[...]
A fixed pool of predefined handlers seem like an antithesis ofLike i mentioned in response to Prasanna's user space probes approach mail there will be two types of handlers for user space probes [...]
systemtap. Did you have some user interface in mind for these?
I understand that this is what you're proposing.
SystemTap will use the second approach.
OK, so no user interface required for the first. But of course if
you're building the first approach also, you must have some tool in
mind to at least demonstrate it.
I am fine to keep the issues separate but if this lets us solve the root problem in limited cases we can use it until complete solution is found.
[...] you could use the preexisting handlers and don't need to write
kernel module and possibly don't even need root permission to trace.
[...]
With some cleverness, we can keep separated the issues of these predefined handlers (and the hypothetical non-systemtap tool that might use them) and unprivileged probing.
In the scheme i mentioned the syntax i was thinking is a command line option some thing like below
The scheme i am thinking is you could start a new process [...][...] I am not sure i see the value of process("process name")It would be one way of identifying present or future processes to
syntax if our focus is process specific tracing.
probe. For processes that do not yet exist, what other scheme do you
have in mind?
But you were concerned about the process("name") *syntax*. Sure, implementing any of these various probes may involve forked observer processes. But if you don't have that *syntax*, how else do you want a script to target a particular process (other than by pid)?
No disagreements in use of systemtap language in kernel and doing it in situ. In the userspace however one can pipe the output to the post processing process without needing to write to disk.I am not saying gdb macros are as powerful as systemtap scripts. All i meant is one can use gdb batch scripts to print the variables you need and use all kinds of post processing using your favorite scripting language. As the handlers are run in the userspace i am not seeing much advantage of using systemtap language to do filtering in the userspace vs post processing using your favorite scripting language.I am not sure i see lot of value of this solution compared to a gdbHow would this gdb batch job alternative work? Are you intending to
batch job, but for bit better performance than the heavy weight gdb.
[...]
compare the expressity of systemtap script with gdb macros?
It has the same kind of advantage in user space as it does in kernel space: the option of safely and compactly filtering/analyzing/acting-on data in situ rather than archiving masses of trace data and passively analyzing it after the fact.
- FChE
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |