The commit msg summary says it all (well, not really).
The previous statically allocated results chain served
the top program perfectly in all its lib memory needs.
But, someone needs to try out the brand new interface.
Besides, there were a few other changes which I wanted
to make. And among them were the following miscellany:
. some names were changed, like 'context' became 'ctx'
. an unnecessary redundant library call was eliminated
. the placement of a few globals was made more logical
( thanks Craig for following the capitalization rule )
Signed-off-by: Jim Warner <james.warner@comcast.net>
This is actually a systemcall getpagesize(2) or it is defined
in configure using a variety of methods, including a default
hard coded value as a last resort.
There is no need to have this in libprocps
Now that the dust is settling following an initial API
library effort, it is apparent my naming standards may
not have always been observed. This was a minor crime,
since those standards are unwritten (& not apparent?).
Basically, top has always capitalized the first letter
of global variables in an effort to distinguish global
definitions from local variables later in the program.
So this patch alters the new API variables to conform,
while also explicitly using 'context' for key structs.
Lastly, top now employs the new '#include <proc/name>'
conventions for the new/converted module header files.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The new library meminfo & vmstat modules use structure
names for their context which exactly mirror the names
of the very /proc/ files whose particulars they yield.
The one exception to this rule was the readstat module
whose struct was named statinfo yet the file was stat.
This commit simply renames that structure (only) so as
to hopefully establish such a naming convention as our
standard going forward. And, it's makes good symmetry.
[ this module's name itself is just perfect as it is ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier attempt at protecting these functions from
already freed memory worked just fine until the memory
was, in fact, reused by the OS. At that point, the ref
count would most likely fail an existing a test for 0.
So this commit will take control of the 'info' pointer
and force it to NULL when a reference count reaches 0.
Plus, since it makes little sense returning an address
that a caller already has, henceforth we will return a
reference count out of the 'ref' and 'unref functions.
Reference(s):
commit 74beff80ff
Signed-off-by: Jim Warner <james.warner@comcast.net>
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.
This patch handles signal related functions in two ways:
For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.
For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.
To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
This commit is mostly about eliminating code, now that
a library is responsible for the cpu tics maintenance.
The top program will continue to provide numa support,
without involving the library in any of those details.
[ not to mention all the 'dl' and 'stderr' numa crap ]
With this transfer of the cpu tics duty to our library
the provision associated with the CPU_ZEROTICS #define
could not initially be migrated. The commit referenced
below suggests it may have lost its importance. In any
case such logic may yet be incorporated in the future.
But for now, that #define has been completely removed.
Reference(s):
commit ee3ed4b45e
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit represents the pioneering attempt at using
the concept of 'chained' library requests in an effort
to reduce function call overhead. It required exposing
no more implementation details than were already shown
through the individual calls, yet is satisfied in one.
It is just such an approach that will prove invaluable
when it comes time to access individual /proc/##/data.
Programs could 'chain' only those 'results' structures
representing their current view independent of all the
fields any such programs might be prepared to display.
Thus the standard 'read', which wouldn't apply to task
level data very well (or efficiently), can now become
a 'read_chain' whereby the former PROC_FILL flags need
can be satisfied & yield the minimum open/close calls.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Removed the printf_uptime, binaries can do printf easily enough.
sprint_uptime split into two as there wasn't a lot of common
code
sprint_uptime(): old style uptime line
sprint_uptime_short(): short new style "uptime -p"
Hertz_hack needed this, no sane system uses the code (I think)
so just assume 100 like we do in FreeBSD.
With the commit referenced below, the linux version is
no longer available via an external variable. So we'll
eliminate the extra superficial function call employed
at program end as part of a debugging (only) o/p spew.
[ the user will soon be returned to the command line ]
[ & he/she can run their own 'uname -r' if in doubt! ]
Reference(s):
commit 56d9d5e7e7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Added function procps_linux_version() which used to be an
exported integer instead. Also changed the method of obtaining
the linux version (more correctly the os release) to use a specific
procfs entry. This works for both Linux and FreeBSD.
This patch will bring three of our man pages into line
with the recent refactor of the libprocps wchan logic.
[ and also eliminates more damn eol whitespace which ]
[ snuck in our repo with the commit referenced below ]
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
commit cf4788c28d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch was made necessary by those library changes
in support of recently revised/simplified wchan logic.
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
Signed-off-by: Jim Warner <james.warner@comcast.net>
It doesn't make any sense to have the binary version strings
embedded into the library. The version strings are defined
already either in the Makefile or in include/c.h
[ in addition to the primary 'lxc' business, i found ]
[ numerous apostrophes used instead of that back-tic ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This will be required for subdir-objects, otherwise automake will have
problems with more than one Makefile.am having rules to build the same
files.
Tested that it builds and both `make check` and `make distcheck` work.
Tested `make install` and compared the tree with the one installed
before this commit, both installed the binaries to the same locations.
The binaries are also in the same location in the build tree (for
instance, ps/pscommand is still there.)
Checked the binaries for the correct libraries linked into them. Binary
sizes matched before and after this change.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This is required for out-of-tree build to work, since many source files
include e.g. proc/*.h which is not under the include/ directory.
Tested that `make distcheck` starts working after this patch.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This commit just tweaks top in the following respects:
. for alphabetic integrity, change 'INSP_hdr...' names
. eliminate the -Wsometimes-uninitialized warning that
was found under OSX Yosemite (llvm 6.0/clang-600.0.56)
. update program 'comments' reflecting copyright dates
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent commit eliminated the potential for a storage
violation with forest view mode. It occurred when some
program (erroneously?) created a lengthy forking loop.
However, the associated commit message was misleading.
The message implied that an unexpected order following
a sort on start_time was the cause of storage overruns
and a 'char' used to track nesting level only distorts
the display when it goes negative. Actually, the truth
is really just the opposite. Any start_time sort quirk
causes no harm while that 'char' can yield corruption.
Should some child end up sorted ahead of its parent by
way of an extremely unlikely shared start_time the end
result is such a child will be displayed unnested just
like init or kthreadd along with all its own children.
However, if nesting levels exceeded 255 (and became 0)
a massive array overrun could be triggered when such a
task and *all* its children were added to an array for
the second time. Exactly how much storage was violated
depended on the number of children that zeroed process
had spawned (hinted at via either SIGSEGV or SIGABRT).
The earlier commit limited nested levels to 100 so the
root cause of the storage violation was already fixed.
The potential for distorted nesting levels due to sort
on start_time would seem to remain. But it's extremely
unlikely that 2 tasks would share the same start_time.
Even so, a new #define has been introduced which makes
top impervious to the order of tasks such that a qsort
is no longer necessary (providing an init/systemd task
exists & was harvested as the first task by readproc).
It can be utilized if distorted nesting ever becomes a
real issue. But since there is a 5-10% performance hit
with that, we'll continue using start_time as default.
References(s):
commit ce70017eb1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will eliminate a very nasty bug associated
with top's forest view mode. It addresses a potential
SIGSEGV/SIGABRT that was only encountered when another
program (erroneously?) creates a lengthy forking loop.
If the growing list of nested children is sufficiently
fast such that proc_t start_time is duplicated between
children then the sort upon which top relies might not
produce the expected order. That, in turn, could cause
the forest_adds function to initially miss some child.
But that missed child would be caught by forest_create
and eventually would cause our array boundary overrun.
Such overrun occurs when some child of that originally
*missed* child is found and a duplicate add attempted.
In correcting this bug we'll also use this opportunity
to prohibit a borrowed proc_t padding byte (char) from
going negative. If the nesting level exceeded 127, the
effect was an "unnesting" with the snprintf width then
viewed as flag+width also yielding left justification.
Henceforth, we'll limit nesting to 100 with subsequent
children shown as " + ", not the usual " `- " prefix.
References(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1153642http://www.freelists.org/post/procps/Bug-in-the-forrest-view,6
Signed-off-by: Jim Warner <james.warner@comcast.net>
When startup defaults were changed users with existing
rcfiles would likely find their previous configuration
was not being honored in all respects. The disparities
involved Graphs modes and Summary/Task memory scaling.
This patch simply restores what was always intended as
the proper behavior for previously saved config files.
References(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762928https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762947
. new startup defaults
commit 8ef6cd91fc
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will cure a potential aberration associated
with a terminal's size (SIGWINCH) and top's new graphs
modes. The symptoms were a dangling tilde (~) plus the
potential loss of a graph's right-most visual content.
The condition was only apparent when a %Cpu approached
100% usage. Also the apparent loss of content affected
the 'block' graph only. With 'bar' graphs, that affect
became the loss of proper right-most bar graph colors.
The cause was determined to be a combination of: 1) an
unnecessary snprintf precision specification; and 2) a
rounding quirk for any graphs which displayed distinct
types of information (as for user/syst, used/unavail).
These could then combine to produce an extra bar/block
which, in turn, resulted in the truncation of a pseudo
termcap attribute used by the show_special() function.
What was originally interpreted as an intractable race
condition turns out to be just a self inflicted wound.
Reference(s):
http://www.freelists.org/post/procps/top-Possible-bug-in-the-graphs,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Let's not report zero for kb_main_available when older
kernels don't have MemAvailable. Instead, if we simply
duplicate the 'free' amount we can avoid all ancillary
problems, such as those involving top's graphing mode.
Reference(s):
http://www.freelists.org/post/procps/kb-main-available-etc,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will trade a former pessimistic calculation
of free physical memory for a more optimistic one that
uses the newly added kb_main_available library export.
But in case one might wish to return to the old former
method, there's a new #define that was made available.
[ the new calculation will affect graphing mode only ]
Reference(s):
http://www.freelists.org/post/procps/systemd-support-to-library,9
Signed-off-by: Jim Warner <james.warner@comcast.net>
Might as well use the newly exposed sysinfo.h variable
'page_bytes' rather than our own. Plus, in the process
we can avoid incurring yet one more function call hit.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Gosh, just because most of us might run with some swap
file allocated, not every system might. I only wish my
testing methodology was as sophisticated as Jaromir's.
Reference(s):
http://www.freelists.org/post/procps/latest-top-enhancements,7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Wow, even the linux/Documentation/filesystems/proc.txt
document doesn't provide us with that level of detail.
Thank you, Jaromir, for your additional clarification!
Reference(s):
commit 411d218793
Signed-off-by: Jim Warner <james.warner@comcast.net>
This should be the last of this kind of crap. I'll get
to work on some means to no longer burden a translator
with lengths requirements. Ideally each word should be
allowed to stand alone and the minimum/maximum lengths
handled programmatically when our ol' top is executed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For over a decade top has used a startup configuration
mimicking the original redhat top. This decision dates
back to when the forked Sourceforge version was trying
to win over users in battles with that ancient kludge.
Will anybody deny that those defaults are coyote ugly?
Well, it is time that top presented a more modern look
at startup, providing that no saved rcfile exists. But
just in case some distro prefers that old, comfortable
look, there's the '--disable-modern-top' build option.
[ Pssst. With the widened memory fields it turns out ]
[ the 'Mem' default window had become almost useless ]
[ on an 80x24 terminal since %CPU & COMMAND were out ]
[ of view. So some other defaults were tweaked a bit ]
[ whether or not --disable-modern-top was specified. ]
Reference(s)
http://www.freelists.org/post/procps/tops-graph-mode-saga-continues,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
When startup argument parsing was recently enhanced to
account for LC_NUMERIC settings, some user input logic
dealing with numbers fails to exploit that capability.
This patch extends such enhancements to a running top.
Reference(s):
commit f7b84f45c7http://www.freelists.org/post/procps/topwatch-floating-point-input,2
Signed-off-by: Jim Warner <james.warner@comcast.net>
When those new cpu/memory graphs modes were introduced
they had global impact. In other words, the modes that
were chosen for a 'current' window affect Summary Area
appearance for every other window as well, even though
each window sets unique View_STATES/View_MEMORY flags.
I do not know how widespread the use of top's separate
window provisions is, but I do know that documentation
promises every window (field group) provides "a unique
separately configurable summary area". And even though
that promise does not include memory scaling (separate
'E' command) the graph modes are integral to 't' & 'm'
and those were already observed on a per window basis.
So this patch just takes the cpu and memory graph mode
values out of global scope in the configuration file &
gives each window its own unique pair of graph values.
Reference(s):
commit 1d171ec741
Signed-off-by: Jim Warner <james.warner@comcast.net>
Boy I hate locale stuff. For code I thought was pretty
robust, Jaromir sure proved that it wasn't. Anyway, me
thinks this commit closes some gaps and will cause top
to behave appropriately under various locale settings.
It does *not* permit top to respond to the ',' and '.'
floating point separator without regard to the locale.
It does, however, enforce proper LC_NUMERIC responses.
Let's look on this commit as an interim solution until
Jaromir can create that proposed 'fp_decode' function.
Who knows, he might even borrow some of our mkfloat().
[ An aside: the coreutils sleep and timeout programs ]
[ claim to permit floating point arguments. However, ]
[ neither one will accept the comma separator should ]
[ the locale be a country that in fact uses a comma. ]
[ In other words, with this commit we are way ahead! ]
Reference(s):
http://www.freelists.org/post/procps/topwatch-floating-point-inputhttp://www.freelists.org/post/procps/topwatch-floating-point-input,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
