Total memory would go out of bounds for machines ~ > 3.5gB of
memory due to the limit of what u_int can hold.
Use ``getpagesize()`` and bitshift pagesize so it fits.
See also: https://github.com/thewtex/tmux-mem-cpu-load/issues/29
The color preceding of the space preceding the load is
made to be consistent with the load color instead of the default. This is
consistent with the CPU percentage color and easier to read.
* Added NetBSD support.
* removed per-platform header files: all the supported platforms were using
identical header files for cpu, memory and load (except a few differences).
Since this was unnecessary code duplication I've gathered what was common
among the platforms, removed duplicates and moved what was left to the
common/ dir.
* implemented get_cpu_count() function across all platforms. We are using it
on every platform, yet not on every one this was implemented as a separate
function.
* removed platform detection through preprocessor from main: we don't need this
there anymore, since the headers are common for all platforms. CMake will
handle setting of correct source files for us now.
* Unified used defines for CPU states across all platforms and made linux use
them. Added some platform detection to cpu.h in order to set them correctly
across the platforms.
* moved getsysctl.h to common/ dir, since it's used on Net and Free BSD, and
thus become a common include.
* Unified load_string() across all platforms. Same case as with the header
files. We can use the same getloadavg() based logic for getting load averages
on all platforms. *BSD and OS X code was already the pretty much identical.
Removed duplicated code and made linux adhere to getloadavg() logic.
All the platforms were using identical logic based on getloadavg() function to
get the load avg stats (except linux, which was using sinfo struct, but can use getloadavg() function). I've noticed this while working on NetBSD port.
Also: fixed a typo on freebsd.
Since the headers for cpu, memory and load functions are virtually the same for
all platforms, I've decided to move them into common/ dir and do some
refacotring:
* removed per-platform header files
* implemented get_cpu_count() function across all platforms. We are using it cpu
on every platform, yet not on every one this was implemented as a separate
function.
* removed platform detection through preprocessor from main: we don't need this
there anymore, since the headers are common for all platforms. CMake will
handle setting of correct source files for us now.
* Unified used defines for CPU states across all platforms and made linux use
them. Added some platform detection to cpu.h in order to set them correctly
across the platforms.
* moved getsysctl.h to common/ dir, since it's used on Net and Free BSD, and
thus become a common include.
As suggested to me by "Jasper Lievisse Adriaanse" in an email:
On 2015-02-16 09:02 Jasper Lievisse Adriaanse <jasper@openbsd.org> wrote:
> You can actually use 'long' instead of juggling between 64 and 32 bit return
> types. I've impemented something similiar for libgtop years ago and never had
> any issues when using 'long' for both 64 and 32 platforms. Here's the
> refernce: https://git.gnome.org/browse/libgtop/tree/sysdeps/openbsd/cpu.c#n62
This is a better idea than what I've implemented. Also this should resolve
eventual occurrence of "unable to get cpu stats" problem on 64bit platforms we
do not detect.
- Instead of displaying hardware ram quantity, display ram available to be
allocated by applications. FreeBSD uses some ram for kernel, segment mappings
and other stuff. Those memory pages are not available for allocation by
applications.
- Calculate correctly ram usage. Active + Wired (buffers). Nothing else.
For more info see:
- http://www.cyberciti.biz/files/scripts/freebsd-memory.pl.txt
- conky source code on github
- output of top and vmstat on FreeBSD
- http://www.zabbix.com/forum/showthread.php?t=21826
- https://support.zabbix.com/browse/ZBXNEXT-774
htop on FreeBSD uses linux procfs compatibility layer, and thus it's readings
are a little off.
On 64bit system KERN_CPTIME systctl gets returned as 64bit uint.
On 32bit system it's returned as 32bit uint. This is not documented anywhere
(or maybe I've missed it). I've added preprocessor test for 64bit system.