htop/linux/Platform.h

143 lines
3.6 KiB
C
Raw Normal View History

#ifndef HEADER_Platform
#define HEADER_Platform
/*
htop - linux/Platform.h
(C) 2014 Hisham H. Muhammad
Released under the GNU GPLv2+, see the COPYING file
in the source distribution for its full text.
*/
2021-08-24 15:27:43 +00:00
#include "config.h"
#include <limits.h>
#include <stdbool.h>
2021-04-29 15:12:43 +00:00
#include <stddef.h>
#include <stdint.h>
#include <sys/time.h>
#include <sys/types.h>
#include "Action.h"
#include "BatteryMeter.h"
#include "DiskIOMeter.h"
#include "Hashtable.h"
2021-08-24 15:27:43 +00:00
#include "Macros.h"
#include "Meter.h"
#include "NetworkIOMeter.h"
#include "Process.h"
#include "ProcessLocksScreen.h"
2021-08-24 15:27:43 +00:00
#include "RichString.h"
#include "SignalsPanel.h"
#include "CommandLine.h"
#include "generic/gettime.h"
#include "generic/hostname.h"
#include "generic/uname.h"
/* GNU/Hurd does not have PATH_MAX in limits.h */
#ifndef PATH_MAX
#define PATH_MAX 4096
#endif
2021-12-16 14:40:50 +00:00
extern const ScreenDefaults Platform_defaultScreens[];
extern const unsigned int Platform_numberOfDefaultScreens;
extern const SignalItem Platform_signals[];
extern const unsigned int Platform_numberOfSignals;
extern const MeterClass *const Platform_meterTypes[];
bool Platform_init(void);
void Platform_done(void);
extern bool Running_containerized;
void Platform_setBindings(Htop_Action *keys);
int Platform_getUptime(void);
float Platform_getTemp(void);
float Platform_getFreq(void);
void Platform_getLoadAverage(double *one, double *five, double *fifteen);
int Platform_getMaxPid(void);
double Platform_setCPUValues(Meter *this, unsigned int cpu);
void Platform_setMemoryValues(Meter *this);
void Platform_setSwapValues(Meter *this);
void Platform_setZramValues(Meter *this);
2020-09-22 11:54:15 +00:00
void Platform_setZfsArcValues(Meter *this);
void Platform_setZfsCompressedArcValues(Meter *this);
char *Platform_getProcessEnv(pid_t pid);
char *Platform_getInodeFilename(pid_t pid, ino_t inode);
FileLocks_ProcessData *Platform_getProcessLocks(pid_t pid);
void Platform_getPressureStall(const char *file, bool some, double *ten, double *sixty, double *threehundred);
2020-08-20 03:59:41 +00:00
bool Platform_getDiskIO(DiskIOData *data);
bool Platform_getNetworkIO(NetworkIOData *data);
2020-10-08 14:34:54 +00:00
void Platform_getBattery(double *percent, ACPresence *isOnAC);
static inline void Platform_getHostname(char *buffer, size_t size)
{
Generic_hostname(buffer, size);
}
static inline void Platform_getRelease(char **string)
{
*string = Generic_uname();
}
#ifdef HAVE_LIBCAP
#define PLATFORM_LONG_OPTIONS \
{"drop-capabilities", optional_argument, 0, 160},
#else
#define PLATFORM_LONG_OPTIONS
#endif
void Platform_longOptionsUsage(const char *name);
CommandLineStatus Platform_getLongOption(int opt, int argc, char **argv);
static inline void Platform_gettime_realtime(struct timeval *tv, uint64_t *msec)
{
2021-07-14 17:15:09 +00:00
Generic_gettime_realtime(tv, msec);
}
static inline void Platform_gettime_monotonic(uint64_t *msec)
{
2021-07-14 17:15:09 +00:00
Generic_gettime_monotonic(msec);
}
static inline Hashtable *Platform_dynamicMeters(void) { return NULL; }
Add a new DynamicMeter class for runtime Meter extension 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.
2021-06-23 07:44:56 +00:00
static inline void Platform_dynamicMetersDone(ATTR_UNUSED Hashtable *table) {}
static inline void Platform_dynamicMeterInit(ATTR_UNUSED Meter *meter) {}
Add a new DynamicMeter class for runtime Meter extension 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.
2021-06-23 07:44:56 +00:00
static inline void Platform_dynamicMeterUpdateValues(ATTR_UNUSED Meter *meter) {}
Add a new DynamicMeter class for runtime Meter extension 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.
2021-06-23 07:44:56 +00:00
static inline void Platform_dynamicMeterDisplay(ATTR_UNUSED const Meter *meter, ATTR_UNUSED RichString *out) {}
Add a new DynamicMeter class for runtime Meter extension 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.
2021-06-23 07:44:56 +00:00
static inline Hashtable *Platform_dynamicColumns(void) { return NULL; }
static inline void Platform_dynamicColumnsDone(ATTR_UNUSED Hashtable *table) {}
static inline const char *Platform_dynamicColumnInit(ATTR_UNUSED unsigned int key) { return NULL; }
static inline bool Platform_dynamicColumnWriteField(ATTR_UNUSED const Process *proc, ATTR_UNUSED RichString *str, ATTR_UNUSED unsigned int key) { return false; }
#endif