Re: Unsafe mode for probes

[Arkady <arkady dot miasnikov at gmail dot com>]

Hi,

I can not use printing, monitoring counter and other goodies -
these are too slow for the task. My code handles between 0.2M
to 1M events/s. I must not introduce more than 8% overhead.
I hit the target (~10% overhead) when I write the probe
completely in C. I see how $context is handled. Given a stable
API I could do it in the hand crafted code.
The name "raw" is great.

Arkady

On Sat, Aug 11, 2018 at 6:37 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
>> "a proper context structure allocation for temporary values" is
>> one of the things I would like to wrap into a stable API, and
>> do not enforce it.
>
> But a context is not an optional safety check sort of thing.  It is
> the place where all the runtime per-probe-execution data is, including
> error flags, temporaries, self-monitoring counters, printing buffers,
> all kinds of stuff.  We can probably make it smaller for probe
> handlers that are trivially simple.  But code just won't compile/run
> with no context.
>
>> "Unsafe" means that the stack safety is up to the author.
>> For example, if I hook only entry points of the system calls I
>> want the freedom to inject custom C code.
>
> Maybe "raw" would be a better name then: a probe handler that
> is bound to use self-contained embedded-C only (thus can't print,
> deal with stap globals, etc.).  Even providing $context vars
> would be tricky.
>
> - FChE