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: Accessing probe info synchronously

Lasse Bigum <> 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

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