Let's make sysprof-cli send a READY=1 sd-notify message when it's
finished its setup logic. This allows starting sysprof as a systemd
service and delaying startup of other services until sysprof has
finished its setup logic. This ensures we don't miss any profiling
data when running sysprof-cli in a systemd service as part of the
bootup process.
We skip this step for now when we're running a child process so that
we don't accidentally interfere with a child process that receives
an sd-notify socket and is supposed to send notifications on it instead
of sysprof-cli.
This ensures that the id won't be screwed by the 32 → 24 bit conversion
that happens implicitly when using SysprofCaptureCounter & family of
structs.
These structs are tightly packed and declare the id field as a 24-bit
unsigned, which doesn't necessarily match the counting that is done
via SysprofCollector.
This is by no means a definitive solution, but this gets things in a
more usable state until a better solution is implemented.
GNOME Shell uses the "new-window" action to open new main windows for an
application. Implementing it allows the application launcher to detect that
action, and provide a "New Window" menu entry for the user.
This allows visualizing currently applied filters, and remove individual
and all filters applied.
Currently the only filter that can show up is the mark filter, but in
the future new filters may be applied.
It's a GtkFilter implementation that takes a marks catalog, and filters
frames based on whether the timestamps of the frames hit any mark in
the catalog.
Internally this uses an augmented RB tree based on sys/tree.h. The
augment is a timestamp interval. This tree is used to store the mark
intervals and perform the hit test.
This can probably be optimized / improved by building the tree on
demand but as is, this code seems to be able to handle dozens of
thousands of marks without any visible choke.
This tells the SysprofProfiler that it should avoid using sysprofd unless
for some reason that instrument simply cannot work without it. Currently
that is at least the RAPL and user-space stack decoding instruments
but there may be others.
If this property is set to TRUE (the default) it queries sysprofd and
policy-kit for appropriate privileges. That generally means that the
instruments will use sysprofd to get access to things like /proc files,
perf event streams, and what not.
If set to FALSE, then this tells the instruments that they should try to
do that work locally instead of querying the sysprofd instance via D-Bus.
If we were provided a D-Bus connection to use for sysprofd then use that.
Otherwise, try to fallback to doing the work in process without the help
of sysprofd.
If we are setup without a D-Bus connection to use to talk to sysprofd then
try to perform the syscall() directly for perf_event_open.
Generally that means you need to be root.
This is used to tell the instruments what GDBusConnection they should use
to query sysprofd. Lack of a connection means they should try to do things
in process without querying sysprofd.
This helper allows us to get the file locally or via sysprofd when the
GDBusConnection is provided.
Be careful about use as your local /proc may be different than the
"system" /proc where sysprofd lives.
In map_head_and_body_twice(), the second mmap call fails:
mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xf64a2000
mmap2(0xf64b3000, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0x1000) = -1 EINVAL (Invalid argument)
Due to cache issues, all shared mapping of a page must be equivalently
mapped. This requires page mappings to be at the same virtual address
modulo 4 MB. Due to a kernel limitation, all mappings to a file must
be equivalent.
The test can be fixed by rounding the buffer_size used in the mapped
ring buffer to 4 MB on hppa. This makes the two mmap mappings equivalent.
Bug-Debian: https://bugs.debian.org/1021853
