addresses a few things:
- Windows has a concept of both a network "interface" and an "adapter"
- These are almost always a one-to-one relationship, though there can be
esoteric instances where they are not.
- I believe the gopsutil NetIOCounters function should only return on a
per-interface level, since this is the behavior on linux/darwin.
Previously, the plugin was basically ignoring the actual interfaces
returned from net.Interfaces(). Instead, it was looping over the net
adapters for each interface, somewhat uselessly.
FWIW, the code for getAdapterList() doesn't exist in the Go standard lib
anymore.
closes#245
Currently gopsutils fails to indentify the POWER processors family,
returning an almost empty Info() structure.
This patch improves the POWER identification without changing what is
available for x86.
The value for `ClockTicks` is defined as `100` by the Linux kernel for
all currently supported architectures in Go. Therefore, there is no need
to define this constant for each architecture separately.
This fixes#260.
Signed-off-by: Thomas Hipp <thomashipp@gmail.com>
* on virtualized host, this may happen.
* but we may have a value from parsing `/proc/cpuinfo`
* in this case, we do not return the error if we fail to extra
a value from `cpufreq/cpuinfo_max_freq`
* resolve#249
* in `cpu_windows.go`, `Mhz` is the value of `MaxClockSpeed`
* on Linux platform, the `Mhz` value is extracted from `/proc/cpuinfo`
which reflects the current clock speed; treat this as the fallback
value instead
* read from `cpufreq/cpuinfo_max_freq` under sysfs to get the
maximum clock speed for `Mhz`, just like for Windows platform
* also fix the path to `cpu.CoreID` value; the filename is `core_id`
* for Darwin, it is a minor tweak for readability: the value
returned is in Hz, so using a variable named 'hz' makes more
sense than 'mhz'
* for Linux, the unit is in kHz so we need to divide the value
from `cpuinfo_max_freq` by 10^3 to get MHz (see
cpu-freq/user-guide.txt of the kernel documentation)
This enables using gopsutil in a codebase that gets built on other OSes
than the ones supported. Instead of a build failure as before, due to
the build tags, gopsutil will now throw an "not implemented" runtime
error.
Fixes#234.
This is mostly intended for Linux, where we are returning the OS version
in the PlatformVersion field, which seems reasonable. Often it is still
useful to know which Linux kernel is running.
For FreeBSD and Darwin the kernel version matches the platform version,
since they previously used the kernel version for the platform version.
For Windows the kernel version is empty, since there is no clear way
to determine it.
