This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Accessing probe info synchronously
Lasse Bigum <zenith@zenith.dk> writes:
> [...]
> > Both the run time limits and array sizes are deliberately configurable
> > quantities. What one doesn't get to hack around is the atomicity
> > requirement for kprobes-based probe handlers.
>
> We know that the limits can be configured, but I think I must have
> missed the atomicity requirement. Could you be so helpful to throw me a
> link?
The issue does not arise during pure script usage (since these are
already prevented from sleeping/blocking), so it is not in ordinary
man pages. The tutorial's "tapset" section inclues some such
guidelines as they apply to embedded-C, and I added a word or two to
the general "undocumented but complex safety constraints" line in the
stap.1 man page.
> [...] We don't want SystemTap to wait for our application, all that
> SystemTap needs to do for us is to send a SIGSTOP to the application
> trying to make a system call, and then notify (in some way) our IDS,
> and then resume operation. [...]
OK, so the send_sig bit is it. OK, we can see about supporting that
more formally.
> As to how we notify the IDS of the system call, the application that
> tried to do it, and what parameters was used for the system call,
> well that is what is missing from our puzzle now I think :) [...]
It sounds like this part can travel along the usual output stream
via ordinary printf's.
- FChE