-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Record multiple traces in a single execution #1900
Labels
Comments
In principle, I'm ok with the change as long as it doesn't change the normal behavior (without multiple sessions). But I think you need to check the feasibility of implementation and how to minimize the change sets. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I would like to propose a new feature, and discuss design guidelines.
Currently, a uftrace run creates a unique recording session for trace data. It has an ID and a directory on disc containing data and metadata.
I want to be able to record multiple separated traces. The user will be able to trigger multiple recording sessions within a single uftrace execution. This will create multiple data directories, containing independent traces.
Use case
When tracing daemons, it may not be possible to restart the process to get multiple traces at different times. The user can toggle tracing by using the
--trace=on|off
option or related triggers. But the trace data cannot be read 'on-the-fly', while uftrace is still recording. The--session=start|end
option creates traces that are available for external use even if the target is still being traced.Design
I propose the following modifications and additions:
UFTRACE_MSG_SESSION
messages toUFTRACE_MSG_SESSION_START
UFTRACE_MSG_SESSION_END
message--session=strart|stop
option (also support in client)In the following example, the user starts uftrace normally. Then halts the recording session using the client, keeping uftrace and the traced target alive. The trace data is finalized in
uftrace.data.1
and the user can create a new trace inuftrace.data.2
.Feedback
What do you think of this approach? If you think this can be added to uftrace, do you agree with the design principles?
The text was updated successfully, but these errors were encountered: