Proposed task.stp additions

[Frank Ch. Eigler]

"Stone, Joshua I" <joshua.i.stone@intel.com> writes:

> [...]  Correct, and yes that [nonblocking/atomic probing] limitation
> is painful.  There's been some brainstorming about delayed handlers
> that could block, but I don't know if anyone has prototyped this
> yet.

Another example that operates with similar constraints is oprofile and
handles it with its tasty chocolate chip dcookies.  

I was not thinking delayed *probe* handlers, by the way, but just
delayed tasks like little kernel threads.  These would fill in
information later into some sort of slot left from a query that
couldn't be answered right away.  (This slot could be in the form of
an key/value tuple in an associative array.)

> [...] For a probe like scheduler.cpu_on, you have both $next and
> $prev, and both will stick around for the duration of the probe.
> But you're right -- in general, you can't rely on a task pointer
> staying valid throughout the probe.

Indeed.  Such general mapping functions should probably not be exposed
outside the tapset.  Instead, the place where such data is known to be
valid could make an effort to extract snapshots of all data likely to
be useful - similarly to how the syscalls tapset saves parameters.

- FChE