| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
All uses of meter drawing "mode" numbers now have the type
`MeterModeId`, including the uses in structures and arrays.
`MeterModeId` is defined as `unsigned int`, as (currently) it doesn't
save any code size by defining it to any smaller type.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
|
|
| |
The Meter objects have their own 'h' properties.
Avoid access to the `Meter_modes` array.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Let the respective `MeterClass.updateMode` functions initialize the
meter mode instead. The `updateMode` function is always called after the
`MeterClass.init` function by `Meter_new()`.
This not only simplifies the init functions of meter subclasses, but
avoids the use of the global `Meter_modes` array when it's unnecessary.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of CUSTOM_METERMODE value in meter default mode was a bad
design. There are no meter that really has a "custom" mode to work with
and currently that value serves as a useless placeholder that hides the
real default mode for a meter.
Replace CUSTOM_METERMODE in `defaultMode` of all meters with the real
intended default modes. Currently only CPU meters and MemorySwapMeter
used this, and their real defaults are BAR_METERMODE.
In Meter_setMode(), remove the special treatment of `defaultMode ==
CUSTOM_METERMODE`, Meter_setMode() still calls the `updateMode` function
for custom treatment when it's present for a meter class.
As CUSTOM_METERMODE is obsolete from `defaultMode`, the init functions
of CPU meters and MemorySwapMeter need to be adjusted to avoid
incomplete initialization (Meter.draw function bring NULL).
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following up with some discusson from a few months back,
where it was proposed that ProcessTable is a better name.
This data structure is definitely not a list ... if it
was one-dimensional it'd be a set, but in practice it has
much more in common with a two-dimensional table.
The Process table is a familiar operating system concept
for many people too so it resonates a little in that way
as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard isnan() function is defined to never throw FP exceptions
even when the argument is a "signaling" NaN. This makes isnan() more
expensive than (x != x) expression unless the compiler flag
'-fno-signaling-nans' is given.
Introduce functions isNaN(), isNonnegative(), isPositive(),
sumPositiveValues() and compareRealNumbers(), and replace isnan() in
htop's codebase with the new functions. These functions utilize
isgreater() and isgreaterequal() comparisons, which do not throw FP
exceptions on "quiet" NaNs, which htop uses extensively.
With isnan() removed, there is no need to suppress the warning
'-Wno-c11-extensions' in FreeBSD. Remove the code from 'configure.ac'.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
First stage in sanitizing the process list structure so that htop
can support other types of lists too (cgroups, filesystems, ...),
in the not-too-distant future.
This introduces struct Machine for system-wide information while
keeping process-list information in ProcessList (now much less).
Next step is to propogate this separation into each platform, to
match these core changes.
|
|
|
|
| |
Closes: #1144
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes:
- Wrap function implementations
- Pointer alignment for function signatures
- Pointer alignment for variable declarations
- Whitespace after keywords
- Whitespace after comma
- Whitespace around initializers
- Whitespace around operators
- Code indentation
- Line break for single line statements
- Misleading alignment
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Extending to right neighbors is intended for text meters with an
overlong content, so the whole text is shown if possible.
Multi column meters, like the combined memory and swap meter, position
its text depending on the given total width; keep the position to the
original assigned header slot.
Short term resolution for #796
|
| |
|
| |
|
|
|
|
|
| |
Related to #729 as the text mode displays all zero values for offline
CPUs.
|
|
|
|
|
|
|
|
|
|
|
| |
Currently htop does not support offline CPUs and hot-swapping, e.g. via
echo 0 > /sys/devices/system/cpu/cpu2/online
Split the current single cpuCount variable into activeCPUs and
existingCPUs.
Supersedes: #650
Related: #580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
`RichString_appendnAscii()` avoids a `strlen(3)` call over
` RichString_appendAscii()`.
Use the former where the length is available from a previous checked
`snprintf(3)` call.
Keep `RichString_appendAscii()` when passing a string literal and
rely on compilers to optimize the `strlen(3)` call away.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
The local stack buffer does not need to be cleaned to zeros when
- just initialized, cause the length is set to 0 and the first
character is set to '\0', so all printing functions will safely stop
- no further used, i.e. the variable goes out of scope
|
|\ \
| |/
|/|
| | |
FreeBSD: add support for CPU frequency and temperature
Tested on two physical systems running FreeBSD 12.1
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
| |
The usage percentage is the first text, no need to set a minimum width.
The BarMeter does already add padding.
|
|
|
|
|
|
|
|
| |
RichString_writeFrom takes a top spot during performance analysis due to the
calls to mbstowcs() and iswprint().
Most of the time we know in advance that we are only going to print regular
ASCII characters.
|
|
|
|
| |
Most of the time the parameter is passed to snprintf type functions
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Show the CPU temperature in the CPU meter, like CPU frequency, instead
of using an extra Meter.
|
| |
|
| |
|
| |
|
|
|
|
| |
Information as seen by IWYU 0.12 + clang 9 on Linux
|
| |
|
| |
|
|
|
|
|
|
|
| |
E.g. if the HT/SMT mode changes
Use separate data for sub-meters
Do not reuse drawData for maintainability
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This is a straightforward extension of the existing multi-column CPU meter
code, which now allows for up CPU meters to be displayed in up to 16 columns.
This also adds the meter declarations to all the platform-specific code.
|
|
|
|
|
|
|
|
|
| |
Instead of scanning the meter name to determine the number of columns in a
CPU meter, move the common code behind some wrapper functions, and specify the
number of columns as an explicit parameter when called from the wrappers.
While this does add a bit of code for all the necessary wrapper functions, this
should be less brittle in case of future changes to the CPU meter code.
|
|
|
|
|
|
|
|
|
| |
Use the more portable sysfs node /sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq
to get the CPU frequency.
In case of an error fall back to /proc/cpuinfo .
Also use a fixed width of 4 for the frequency to avoid position jumps
in case the frequency moves in the range 900-1100 MHz.
|
| |
|