This commit is based on exploratory work by Sohaib Mohamed.
The end goal is two-fold - to support addition of Meters we
build via configuration files for both the PCP platform and
for scripts ( https://github.com/htop-dev/htop/issues/526 )
Here, we focus on generic code and the PCP support. A new
class DynamicMeter is introduced - it uses the special case
'param' field handling that previously was used only by the
CPUMeter, such that every runtime-configured Meter is given
a unique identifier. Unlike with the CPUMeter this is used
internally only. When reading/writing to htoprc instead of
CPU(N) - where N is an integer param (CPU number) - we use
the string name for each meter. For example, if we have a
configuration for a DynamicMeter for some Redis metrics, we
might read and write "Dynamic(redis)". This identifier is
subsequently matched (back) up to the configuration file so
we're able to re-create arbitrary user configurations.
The PCP platform configuration file format is fairly simple.
We expand configs from several directories, including the
users homedir alongside htoprc (below htop/meters/) and also
/etc/pcp/htop/meters. The format will be described via a
new pcp-htop(5) man page, but its basically ini-style and
each Meter has one or more metric expressions associated, as
well as specifications for labels, color and so on via a dot
separated notation for individual metrics within the Meter.
A few initial sample configuration files are provided below
./pcp/meters that give the general idea. The PCP "derived"
metric specification - see pmRegisterDerived(3) - is used
as the syntax for specifying metrics in PCP DynamicMeters.
When manipulating CPUMeters in the AvailableMeterPanel we
use the bottom 16 bits to hold the CPU number. However,
the bitmask used to extract the CPU number only masks the
lower 8 bits (0xff).
Allow other projects (PCP) to be able to ship an htop binary
which uses the custom name (pcp-htop) in several diagnostics
so that its clear which (if any!) binary failed.
Reading and parsing /proc/<pid>/maps is quite expensive.
Do not check for deleted libraries if the main binary has been deleted;
in this case the deleted binary takes precedence.
Do not check in threads. The check is void for kernel threads and user-
land threads can just inherit the state from the main process structure.
