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
