This allows setting the net.hadess.PowerProfiles during the execution of
the Sysprof run. This is handy if you want to test in a specific mode (such
as performance) but not leave your system in that state.
This is like sample but has an "enter/exit" flag with it. This can be
useful when you want to provide tracing instead of sampling. We use a
different frame type so that we can denote that this isn't traditional
sampling, and the flag can be used to find the next exit for the current
enter for calculating durations.
The entire stack trace is provided to make things easier on tools
which may want to deal with indirect functions that were not instrumented
but can be unwound. That may allow for tooling to give the user some
insight that it's not *just* this function entering, but some functions
before it were entered too.
This also adds a SysprofTracer instrument which will preload a
libsysprof-tracer-6.so into the process providing the
__cyg_profile_func_enter() and __cyg_profile_func_leave() hooks.
This allows instruments to record a diagnostic and have it land as an
object in a GListModel of diagnostics available to the API consumer.
Such items may be used by recording UI to display issues with the recording
to the user.
This is a SysprofInstrument that will eventually contain the contents of
the sysprof-battery-source.c to get battery charge/rate/etc. Note that
this is different from energy usage which will come from RAPL.
This starts porting the old perf code from libsysprof into
libsysprof-profile. It does not bring over tracepoints yet, because we
need to think about how we want to support that. I may opt to do that as
a separate instrument even if that takes an additional perf fd.
This is a bit different than how we did things previously, but the same
mechanics are involved. Instead of multiple CPU registered together, we'll
just use one-stream-per-cpu.
Partly because I intend to drop support for profiling a single process as
that doesn't really get used much nor does it seem to yield very good
results from perf.
The goal here is to do the whole thing on a fiber rather than how we were
doing it before. This just gets the counter registration going, but we
need to follow up with the parsing/lseek/etc code.
This doesn't start reading from the input stream, but does get things into
place until we actually start processing the recording. When we get a
record vfunc, we will do the input processing.
Also, I no longer wish to try to maintain support for no-polkit. If there
is truly a system where that is something we want to support, we can bring
back the shims as a compile time alternative.
Being able to manage asynchronous operations with libdex will drastically
simplify how we implement the profiler and instruments. We may eventually
do the same with libsysprof-analyze to parallelize some operations.
The goal here is to have a fairly small exposed API surface for profiling
similar to libsysprof-analyze where implementation details are hidden.
SysprofProfiler - Where you setup your recording
SysprofInstrument - What you add to a profiler to extract data
SysprofRecording - Represents an active recording w/ instruments
