When summary & task area memory scaling was introduced
in release 3.3.6, the memory field widths were widened
slightly so unscaled KiB values could be provided more
consistently and scaled values (beyond MiB) could show
3 decimal places of precision. However, some users may
prefer the former widths/precisions for memory fields.
This commit will provide a build time configure option
to return top to those former defaults as a compliment
to a new %CPU & %MEM field precision configure option.
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707648
commit 21e550bc08
Signed-off-by: Jim Warner <james.warner@comcast.net>
When summary & task area memory scaling was introduced
in release 3.3.6, the percentage columns were expanded
to provide 3 decimal places of precision. In hindsight
that may have been overkill, making those columns more
of a distraction than useful, with just too much info.
This patch will revert those columns to the former one
decimal place. And as was true, that decimal point may
be sacrificed depending on the number of cpus present.
And, in case anyone might prefer additional precision,
a build option can provide it (--enable-wide-percent).
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707648http://www.freelists.org/post/procps/What-happened-to-my-top,1
commit 21e550bc08
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier commit purporting to allow top to be built
in the absence of that dynamic linking library stopped
just a little short of the truth. So this will fix it.
Reference(s):
commit 5686877cd4
Signed-off-by: Jim Warner <james.warner@comcast.net>
Been a while since we ran a re-scan over the autotools files. This
change modernises the configure file. Not a great deal of changes
required to bring us up to date, autoscan doesn't understand our
optional things, which is fine.
Oh that poor ol' build system. With this patch it will
have gone through three separate incarnations in terms
of NUMA/Node support. Those 3 iterations consisted of:
1. A 'porridge too hot' where the top numa support was
enabled if it was built in the presence of libnuma and
the numa.h header. But if the numa library wasn't part
of core packages, that would have broken poor old top.
2. A 'porridge too cold' where numa support was off by
default and must have been explicitly enabled when the
./configure script was run. This could have meant that
distros might not distribute a numa-aware procps, even
though their numa library would have been distributed.
3. And this 'porridge' where the top numa support will
become a 'plug-in' feature activated when the presence
of libnuma.so can be verified at runtime. We'll do our
own loading and symbol resolution (with some help from
dlopen in libdl). Thus maintainers' responsibility for
enabling numa support and then satisfying that library
dependency is now an entirely optional --disable-numa.
As Goldilocks might say about our current configure.ac
"Ummm, I think this porridge tastes just about right".
Reference(s):
. 1) too-hot
commit 87ac6383bb
. 2) too-cold
commit 53fd7dd1ed
. original idea from: Dr. Fink <werner@suse.de>
http://www.freelists.org/post/procps/top-NUMA-node-CPU-utilization-support,18
Signed-off-by: Jim Warner <james.warner@comcast.net>
Library systemd-login offers possibility to display
the name of the VM or container which process belongs to.
This patch adds output option "sd_machine" which will
show machine name or "-" when the name can not be determined.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
Library systemd-login offers possibility to display
name of a systemd unit file for specific pid. Note that
not all processes are part of a system unit/service
(e.g. user processes, or kernel threads).
This patch adds output option "sd_unit" which will
show name of systemd unit or "-", when process does not
belong to any unit.
To maintain compatibility with non-systemd systems,
procps must be configured with --with-systemd option
to enable this option.
This patch provides the build system support for those
top extensions dealing with the NUMA summary displays.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch provides the build system support for those
top extensions dealing with the NUMA summary displays.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Lance Shelton <LShelton@fusionio.com>
For portability, check for error.h during configure and define
HAVE_ERROR_H accordingly.
If this header is not available, emulate the functionality of error()
from glibc with an inline wrapper in include/c.h.
For portability, check for stdio_ext.h during configure and define
HAVE_STDIO_EXT_H accordingly.
If the current system does not provide this header, use a fallback for
__fpending(). This definition will not work on all systems as it relies
on internal data structures of libc. A more portable solution should be
preferred, for example by using gnulib.
For portabiliy, check for program_invocation_name during configure and
define HAVE_PROGRAM_INVOCATION_NAME accordingly. Use of this symbol is
now enclosed with the appropriate #ifdef block.
The symbol program_invocation_name is only used for error message
handling using error(), so it's safe to omit this if it is not
available.
Fixes the following error in configure stage.
configure: error: cannot run test program while cross compiling
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Both skill and snice are are mentioned in manual page to be 'obsolete
and unportable'. This commit discourages distributors to keep these
commands part of default system.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The newer tools/ subdirectory shares a common prefix
with the previously existing top/ subdirectory and
thereby hinders shell command completion.
There was already a minor conflict between testsuite/
and top/. This patch renames the tools/ subdirecory
to avoid an even greater conflict.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Newer ncurses install pkg-config files, so search those first. If they
aren't found, fall back to existing detection logic.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The third arg is for "the user has specified some flag", not "the user
has disabled things", so use $withval.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The first check for ncurses is for the non-wide variant, so drop the "w".
The wide version gets checked later on based on watch8bit.
Signed-off-by: Samuli Suominen <ssuominen@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Even as conservative project as coreutils has switched to xz distributions so
neither should we have any reason to use gz and waste space & bandwidth.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The library used to be called libprocps but it was renamed to make sure
there was only one. However the formatting of the library SONAME has
changed so there cannot be any confusion.
libprocps makes it clear that its a library from this project and not a
set of functions directly on the filesystem.
The patch also removes fixed size of input, which can be problematic.
I do not know how long the string `yes' might be in all of the worlds
languages.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The utility library is for functions which are shared in commands,
but that does not belong to libproc-ng. The first function is a
wrapper for strtol that performs error checking, and exists if such
happen.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
. 1 program uses curses (top)
. 2 programs use ncurses (slabtop, watch)
. all 3 include non-wide <curses.h> or <ncurses.h>
. those 3 do not currently need wide support
. but anticipating nls, we link against libncursesw
This patch ensures an environment consistent with current
and future ncurses needs.
Slackware seems to have this patch, while it is not in use(?) Well,
the upstream procps-ng allows one to disable warnings if that is
wanted. After all having this sort of 'feature' does not cost much,
while lacking it might annoy someone.
A patch from Slackware.
Reference: http://www.ftp.be/packages/slackware/slackware_source/a/procps/procps.nowarning.diff.gz
Backported-by: Sami Kerola <kerolasa@iki.fi>
Conflicts:
proc/ksym.c
Previously the version of libproc always tracked the version of procps.
This doesn't work when other non-procps programs link to the library as
they are always playing catch up.
This change makes the library version independent of the procps version.
It will only be incremented when needed.
procps works well on Linux, on other arches there are some strange
differences due to their emulation of procfs which is not 100%
Disabling checks for non-linux until that can be sorted out.
configure.ac now set to 3.3.1
vmstat -p has not worked for a long time, this applies Debian patch
vmstat_part_format, the details:
Author: Daniel Novotny
Description: The contents of /proc/diskstats have changed since 2.6.25
Changed PATH_MAX to 32 because its missing on hurd
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=485243
Bug-Debian: http://bugs.debian.org/588677
Last-Update: 2010-11-17
. 3 pgms require non-wide <curses.h> or <ncurses.h>
This patch represents the tests for a minimal environment
consistent with current ncurses needs.
It should allow a successful configure and build
. 1 program uses curses (top)
. 2 programs use ncurses (slabtop, watch)
. all 3 include non-wide <curses.h> or <ncurses.h>
. those 3 do not currently need wide support
. but anticipating nls, we link against libncursesw
This patch ensures an environment consistent with current
and future ncurses needs.
