run_external_process() contained pipe file descriptors leaks (e.g. one
pipe end was never closed). Also the stdout might have been captured
incomplete, since only a single read() was performed on the pipe.
Furthermore should a child process try to write a larger amount of data
onto the pipe then it will become stuck, because the parent process
isn't consuming the data. Thus the timeout would trigger in these cases
although the child process does nothing wrong.
This commit changes the implementation to follow a select() based
approach that continually reads from the pipe, but discards data that
doesn't fit in the provided buffer.
Honor prefix for installing gamemoderun to properly work in cross
environment so it can be installed in e.g. /usr/x86_64-pc-linux-gnu/bin
instead of /usr/bin like it's already done for gamemoded.
The local variable 'bus' was shadowing the global 'bus' variable;
to not confuse the two, rename the local one. Also unref the local
bus, i.e. fix a small memory leak.
MAX_GOVERNOR_LENGTH is defined as PATH_MAX + 1, so when comparing
two variable, each of once size, use the smaller one, i.e. PATH_MAX.
Assert statically that MAX_GOVERNOR_LENGTH is larger then PATH_MAX
so copying a string to a MAX_GOVERNOR_LENGTH sized variable from a
PATH_MAX size variable will not truncate the string.
If there is no null byte among the first n bytes of the source the
resulting string will not be properly null terminated.
Ensure that all strings that are copied via strncpy are properly
terminated copy "sizeof (dest) - 1" bytes and manually terminate
the string in the cases the array was not initialized.
Example compiler warning:
../daemon/gamemode-tests.c: In function ‘run_cpu_governor_tests’:
../daemon/gamemode-tests.c:326:4: warning: ‘strncpy’ specified bound
256 equals destination size [-Wstringop-truncation]
strncpy(defaultgov, currentgov, CONFIG_VALUE_MAX);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The install_mode option was only added in Meson 0.47. In versions prior
to that, it will base the mode on the permissions of the source file,
so set this executable to be compatible with older versions.
See #115.
SCHED_ISO is not supported by upstream kernels, so don't try to use this by
default since for most users it will result in an error log that trying to
set the scheduling policy fails.
Without extra system configuration, we will also not have permission to renice
processes by default, so out of the box doing this will fail as well.
Users that wish to use these features can enable them from the config once
they have configured their system appropriately.
This should hopefully fix issue #113, where the user was in the common situation of having an intel and an nvidia GPU, at card0 and card1 respectively, but the nvidia gpu was [gpu:0] according to the driver
The drm device ID doesn't match up with the pci device as expected, spotted by issue #113
I can't test this myself just yet, will need data from the user in question to verify PCIDevice is the right value
This also fixes the instances in testing where we don't have the nv overclock in use, but we do have the mode set
Solves issues explaining the what the perf_level actually meant, and future proofs for any PR that wants to set individual perf levels
