Skip to content

Reconstruct context hierarchy from schema #295

Description

@ueno

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions