We currently expect the instrumented library to maintain context hierarchy by themselves using a stack. This is cumbersome to implement and may impose run-time cost when the library is not monitored. Now that we have a kind of "formal" schema of events, we could restore the context hierarchy on the consumer side (i.e., at crau-query). Here is the sketch how it would work:
First, the library is instrumented directly using new_context and *_data probe points. For new_context, the same context are passed as context and parent parameters, which indicates that context hierarchy is managed by the consumer, not the library itself.
On the crau-query side, it loads the schema and populates a mapping between context and the potential parent (e.g., tls::handshake → [], tls::sign → [tls::handshake], pk::sign → [tls::sign, pk::*], etc.). It then initializes a stack to maintain the context hierarchy. When it encounters a new_context called with context == parent, there are 3 possibilities:
- if the stack is empty, push the current context
- if the name of the last element on the stack is a potential parent of the current context, push it
- otherwise, pop the last element from the stack until a potential parent is found or the stack becomes empty, and push the current one
This works because the context ID is distinguishable among processes and threads. This is already ensured by mixing PID/TGID as part of the final context ID generated by crau-agent.
We currently expect the instrumented library to maintain context hierarchy by themselves using a stack. This is cumbersome to implement and may impose run-time cost when the library is not monitored. Now that we have a kind of "formal" schema of events, we could restore the context hierarchy on the consumer side (i.e., at crau-query). Here is the sketch how it would work:
First, the library is instrumented directly using
new_contextand*_dataprobe points. Fornew_context, the same context are passed ascontextandparentparameters, which indicates that context hierarchy is managed by the consumer, not the library itself.On the crau-query side, it loads the schema and populates a mapping between context and the potential parent (e.g.,
tls::handshake→ [],tls::sign→ [tls::handshake],pk::sign→ [tls::sign,pk::*], etc.). It then initializes a stack to maintain the context hierarchy. When it encounters anew_contextcalled withcontext == parent, there are 3 possibilities:This works because the context ID is distinguishable among processes and threads. This is already ensured by mixing PID/TGID as part of the final context ID generated by crau-agent.