For quite some time now, top has stood out like a sore
thumb regarding the approach to cmdline options & help
text. Only short options were used and that same help
text was displayed for '-h' (help) plus 'v' (version).
[ also, top 'rolled his own' when it came to parsing ]
[ options while avoiding that getopt implementation. ]
Well, with this commit all of that has changed and top
now has added a long form of his options. Additionally
he employs getopt_long() for the bulk of that parsing.
[ however, top will still avoid separate fputs calls ]
[ characteristic of other procps-ng programs when it ]
[ comes to help. rather all such text is one string. ]
Along the way, the following major getopt deficiencies
were addressed, assuming the absence of a new #define:
* an equals sign ('=') is allowed on both option forms
* whitespace is allowed before & after the equals sign
* optional arguments needn't abut their related option
for short form nor is an '=' required with either form
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ordinarily, whenever a new field is added to top, that
RCF_VERSION_ID should be bumped which then prevents an
older version of top from reading the expanded rcfile.
With this change, however, we'll keep the existing 'k'
version since we've yet to release the newlib version.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit shown below introduced two abreast printing
for %Cpu statistics. But, the Memory & Swap lines have
always been printed on separate lines when '4' was on.
With this commit, those lines will now be treated just
like %Cpu stats, either separate lines or two abreast.
Reference(s):
. May 2020, added '4' toggle for 2 abreast
commit 59f5a37a24
Signed-off-by: Jim Warner <james.warner@comcast.net>
Sometimes, it might be useful to isolate a parent task
and its forked children from other system activity. As
an example, a user might want to examine workload in a
specific lxc container. Or maybe there is some need to
question what's happening under the same tmux session.
Since forest view mode tends to be a relatively stable
display, it will sometimes satisfy the above need. But
that mode can't currently guarantee the target process
always remains as the topmost task or even is visible.
So, this patch will enable focusing on any parent task
and keeping it as the topmost process while displaying
it and its forked children only. It then appears as if
there is no other activity in that system by virtue of
the blank lines which follow that final child process.
To implement this new feature, top's redundant 'F' key
has been repurposed. It made little sense devoting two
keys to the Fields Management screen (especially since
the key we've taken required two separate keystrokes).
[ and while we're at it, i also added punctuation to ]
[ the prologue for that renamed 'forest_display' guy ]
[ since all other forest functions used punctuation. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some time ago, IO accounting was added for the library
and exploited by the ps program. This patch just plays
a little catch-up & adds similar functionality to top.
[ and we also finally get around to incrementing the ]
[ rcfile id which should have already been done when ]
[ the smaps fields were added or, at least, with USS ]
Reference(s):
. added IO accounting to ps program
commit 8baf8eeab4
. added IO accounting to library
commit a7afe06e6f
Signed-off-by: Jim Warner <james.warner@comcast.net>
We're just following the ps program's lead introducing
a new 'USS' field to represent the non-swapped portion
of physical memory ('RSS') not shared by another task.
Signed-off-by: Jim Warner <james.warner@comcast.net>
My, how time flies. Here we are finally attending to a
2 year old issue at long last (well, at least top is).
In truth, this change was prompted by that more recent
issue #201 and simply represents my initial picks from
among those available with the new library provisions.
Note: we have to bump that rcfile version whenever new
fields are added. That will mean older top programs no
longer can read this top's rcfile. But that's Ok since
top offers a warning before replacing an older rcfile.
Doubtless, more smaps_rollup fields will be introduced
under top as we get more experience with this feature.
However, any such usage comes with tremendoud costs as
was reported for the previous patch and repeated here:
Here is a small preview of just what you will discover
when using this command line: time top/top -d0 -n1000.
------------------------------------ as a regular user
with only PID + RES (statm)
real 0m2.605s
user 0m1.060s
sys 0m1.377s
with only PID + RSS (smaps)
real 0m26.397s 10x more costly
user 0m1.253s
sys 0m24.915s
----------------- as a root (thus smaps for all tasks)
with only PID + RES (statm)
real 0m2.651s
user 0m1.177s
sys 0m1.286s
with only PID + RSS (smaps)
real 0m33.040s 12x more costly
user 0m1.256s
sys 0m31.533s
Reference(s):
. top/ps: add support for PSS reporting
https://gitlab.com/procps-ng/procps/-/issues/112
. ps: expose shared/private memory separately
https://gitlab.com/procps-ng/procps/-/issues/201
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ actually, this patch goes a little beyond what was ]
[ strictly required. some messages were expanded for ]
[ clarity and should an inactive node be selected by ]
[ the '3' command, a second '2' no longer is needed. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
I'm about to break older top rcfile compatibility when
preserving those two new toggles. And, though this has
happened several times over the years, we never issued
any warnings that such thing was just about to happen.
So, this patch corrects the long standing shortcoming.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When implementing that earlier '4' toggle, in response
to the issue referenced below, I got to thinking about
those environments with massively parallel processors.
Such environments may not benefit from the '4' toggle.
So, I decided to implement a feature that could enable
use of those '1' and/or '4' toggles no matter how many
active processors top may have ultimately encountered.
With the new '!' toggle, adjacent cpus can be combined
to any degree, represented as a single cpu group/line.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172
Signed-off-by: Jim Warner <james.warner@comcast.net>
In the back of my mind, I've always wanted to enable a
two abreast cpu display. Folks with massively parallel
machines must surely have been frustrated with the '1'
toggle when Off (individual cpus in the Summary Area).
So, I'll use that recently raised issue shown below as
a justification for finally implementing this feature.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/172
Signed-off-by: Jim Warner <james.warner@comcast.net>
Several years after the 'e' & 'E' interactive commands
were introduce to affect memory scaling, an 'E' switch
was added. This was after discovering a dropped Redhat
patch which provided a unique 'M' command line switch.
If only for symmetry it makes sense to offer a similar
command switch ('e') for the Task Area memory scaling.
As was true with 'E', top's help text will show 'e' as
if it were a switch without arguments in order to keep
help text displayed without wrap in an 80x24 terminal.
The man page, however, will show all of the arguments.
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/165
. 03/2017, added 'E' command line switch
commit b2bd65407a
. 12/2012, added 'e' interactive command
commit 21e550bc08
. 12/2012, added 'E' interactive command
commit bc46f67f9a
Signed-off-by: Jim Warner <james.warner@comcast.net>
In a translator hint, under a caution, a reference was
made to the "next three items". Unfortunately however,
there was one intervening 'item' to which that caution
did not apply. This commit just relocates that 'item'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Currently, it isn't possible to establish an 'Inspect'
pipe that relies on SIGINT to end. That's because this
signal will also end the parent process (top) as well.
So this patch will temporarily ignore that signal when
processing any 'Inspect' pipe, allowing one like this:
. pipe ^I Trace Calls ^I /usr/bin/strace -r -p %d 2>&1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Using Ctrl-V for the collapse children key now appears
as a mistake. First, it's too close to that Ctrl-C key
which would prematurely terminate top. Second, a lower
case 'v' was unused and perfectly compliments an upper
case 'V' which is used to toggle 'forest view' itself.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ along the way we'll shorten some of the repetitive ]
[ variable width field narratives in top's man page. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is simply preparation for upcoming vertical
scrolling enhancements. With those changes, it will be
impossible to predict what the beginning task position
should be at the time the message is currently issued.
This patch will allow such a message to be shown after
the individual windows' tasks have all been displayed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The issue cited below really dealt with preserving the
'Other filter' criteria in the rcfile. But as an aside
the htop 'F6' feature (collapsed children) was raised.
I took that as an implied challenge and decided to try
implementing a similar feature in top. So, this commit
will now provide a brand new forest view toggle ('^V')
which will be used to collapse/expand forked children.
[ this patch will also lead to additional patches in ]
[ support of more rational vertical scrolling, since ]
[ many more tasks might now be hidden in some window ]
Reference(s):
. where this secondary issue was raised
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
Well, after the rearranging and refactoring, all those
active 'other filter' entries for each window will now
be preserved in the user's configuration file via 'W'.
For raising the issue below, thanks to Marco Ippolito.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/99
Signed-off-by: Jim Warner <james.warner@comcast.net>
We now use the actual terminfo 'max_colors' value with
the 'color mapping' screen, not that hard coded '256'.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/96
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the Qualys security audit, we began to harden our
treatment of the top rcfile. In particular, the values
read were checked so as to prevent some malicious user
from editing it in order to achieve an evil objective.
However when it came to colors I was surprised to find
that at least one user edited the rcfile for 256-color
support. Unfortunately, our new checks prevented this.
So this commit will provide the means to exploit those
extra colors with no need to manually edit the rcfile.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/96
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to exploiting the login user ID provision,
the following miscellaneous changes are also included:
. unnecessary braces have been eliminated from an 'if'
. a comment with case EU_CPU: was corrected to 's_int'
and the associated block of code relocated accordingly
. case EU_CPN: wasn't shared with other enumerators so
reference to 'i' was changed to that actual enumerator
. case EU_SGN: wasn't shared with other enumerators so
reference to 'i' was changed to that actual enumerator
Signed-off-by: Jim Warner <james.warner@comcast.net>
Those references below offer more detail regarding the
default startup changes beginning with version 3.3.10.
It is important to remember that all such changes were
supposed to impact only new users or users who had not
saved the personal config file (via that 'W' command).
However, I introduced a bug wherein the rcfile was not
fully honored. This gave the changes a bad reputation.
That bug was corrected in release 3.3.11 but the issue
of default startup options keeps resurfacing. And it's
clear there's no consensus on what should be included.
Our --disable-modern-top configure option is of little
help since it remains an all-or-nothing approach. What
we need is an answer offering unlimited customization.
So, this commit will provide distribution packagers or
system administrators with a much more flexible way to
set their own preferred startup default configuration.
A new rcfile is being introduced: '/etc/topdefaultrc',
whose format/content is the same as a personal rcfile.
Thus once a 'proper' enterprise configuration has been
established and saved via 'W', it can be copied to the
/etc/ directory. Thereafter, startup in the absence of
a saved rcfile will use that configuration as default.
Now if a distribution packager or system administrator
wishes to expose their users to some of top's advanced
capabilities they can do so gradually. Perhaps setting
up graph mode for summary area task and memory display
while retaining the %CPU sort could be tried. Or maybe
showing colors, but better customized for a particular
terminal emulator. Such possibilities are now endless.
[ in exploiting this new capability, i hope that the ]
[ other windows (alt display mode) aren't overlooked ]
Reference(s):
. Sep, 2014 - Not fully honoring rcfile bug discussed
https://www.freelists.org/post/procps/top-saved-rcfile-bug
. Oct, 2014 - Attempt to defend new startup defaults
https://bugzilla.redhat.com/show_bug.cgi?id=1153049
. Jul, 2015 - Forest vs. %CPU views discussion
https://gitlab.com/procps-ng/procps/issues/6
. Oct, 2017 - Question the use of --disable-modern-top
https://bugzilla.redhat.com/show_bug.cgi?id=1499410
. Oct, 2017 - Forest vs. %CPU views discussion again
https://www.freelists.org/post/procps/Forest-mode-by-default-in-top-seems-a-bit-strange
. Dec, 2017 - Rehash of 3.3.10 startup defaults change
https://gitlab.com/procps-ng/procps/issues/78
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the library having now normalized errno handling,
perhaps it is time at least one program took advantage
of it. So, instead of printing just a message with the
programs's line number, top will now also provide that
associated errno string text, compliments of strerror.
[ with those newlib functions returning NULL, we can ]
[ use errno directly in strerror. for the ones which ]
[ yield an int, all we need do is invert such return ]
[ values before passing it to the strerror function. ]
Reference(s):
Signed-off-by: Jim Warner <james.warner@comcast.net>
After noticing that the 'uk' translation expanded what
was supposed to be a 3 line header into 5 lines, seems
appropriate to offer more guidance on max lines count.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The top man page was changed back on 10/20/15, in that
commit shown below. There, freelists.org was suggested
as the bug reports recipient. But, the program was not
changed from the original Debian bug reports approach.
Reference(s):
commit b1f7b2a509
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that top can properly handle translated multi-byte
strings I've been reviewing translated efforts so far,
and weighing output against related translation hints.
In one case, a translation hint has not kept pace with
the current program state. In addition, that same hint
could be expanded to suggest translation alternatives.
[ frankly I never expected the translators to tackle ]
[ some of those 'special' strings. the task appeared ]
[ just too daunting. but they have done a great job! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the help of our Swedish translator, hopefully the
final buglet has now been vanquished in the multi-byte
translation support. This one was a real nasty bugger.
Although it didn't occur with every terminal emulator,
occasionally random text lines were being chopped off.
As it turns out, those terminals were blameless. There
were two separate places in top's show_special routine
where potential multi-byte sequences were inadequately
addressed. Solution: exploit existing utf-8 functions.
[ it also became apparent that the translation hints ]
[ in the top_nls module were deficient. so a special ]
[ caution was added regarding the final line of txt. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
If built without ./configure --disable-modern-top, the
program displays each cpu individually providing there
is sufficient vertical screen real estate. For massive
SMP environments this will necessitate use of a config
file where the cpu summary toggle ('1') could be saved
via the 'W' command. But, an rcfile may not be viable.
So this commit introduces a '1' command line switch to
emulate exactly the effects of the interactive toggle.
And since it is our first numeric switch some existing
parsing logic had to be changed slightly. Such changes
are, in truth, an improvement. For example, instead of
seeing "inappropriate '2'" with ./top -2 we'll now see
the vastly more appropriate error "unknown option '2'.
References(s):
https://gitlab.com/procps-ng/procps/issues/55
[ this patch has been adapted from the master branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
In their 3.2.7 version of top, Redhat introduced an -M
switch to automatically scale Summary Area memory data
to avoid truncation (and the resulting '+' indicator).
The procps-ng top does not employ suffixes with memory
data nor does it allow for different scaling with each
separate value. Rather, scaling appears at line start.
If built without ./configure --disable-modern-top, the
Summary Area memory will be scaled at GiB which should
lessen chance of truncation. Otherwise KiB was used to
reflect such memory, increasing the truncation chance.
And while 'W' can be used to preserve some appropriate
scaling value, there are arguments against such rcfile
approaches as cited in the issue and bug report below.
So this commit will bump the Summary Area memory scale
factor from KiB to MiB when using --disable-modern-top
as a concession to that Redhat bug report noted below.
And it also introduces a new command line switch which
can force any desired scaling regardless of the rcfile
or which ./configure option might have been specified.
[ for top's help text we'll show 'E' as if it were a ]
[ switch without arguments in order to keep the help ]
[ text displayable without wrap in an 80x24 terminal ]
[ the man page, however, will show all k-e arguments ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/53https://bugzilla.redhat.com/show_bug.cgi?id=1034466
[ this patch has been adapted from the master branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the decision was made to also add that Linux-4.5
support (was only in this newlib branch) to our master
branch, a tweak to newlib's top is necessary. In order
to share the rcfile between them, any fields unique to
a branch must appear last in it's list of enumerators.
And the troublesome field in question above is CGNAME.
It doesn't matter if a unique field is on or off, only
that it, as a higher enum/char, appear after all other
shared fields. Otherwise one risks the 'corrupt' error
message from the top without that field or the display
of the wrong column in the top with that unique field.
[ and strictly speaking, the changes under top_nls.c ]
[ were technically not really necessary. however, we ]
[ choose to maintain strict ordering via enum value. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and all users exposed to those 'out of memory' fields,
it's about time we added them to the top man document.
But before doing so, it's long past time that they are
normalized to at last remedy this kind of foolishness:
. excessive width on that oomem score itself (8 vs. 4)
. some potentially confusing names inherited from suse
Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
Signed-off-by: Jim Warner <james.warner@comcast.net>
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.
p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ but stay tuned! there is a commit coming soon that ]
[ represents a rather major internal redesign, which ]
[ was prompted by the ps and top adaptation testing. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just eliminates an error message no longer
needed under that newlib <pids> interface. Plus, a few
enumerators in the header weren't in alphabetic order.
Signed-off-by: Jim Warner <james.warner@comcast.net>
It was probably always wrong to have a variable length
proc_t structure. This patch takes all remaining oomem
former suse only options and makes them unconditional.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The newlib informal cutoff for kernel support seems to
be around release 2.6. This commit eliminates any such
support for really old 2.4 and 2.5 kernels within top.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adapts top to exploit the new <proc/pids.h>
interface. And it appears to have reduced top's weight
by a considerable margin. Gone were the sort callbacks
and manipulation of those library flags. Gosh, all top
needs to do now is track some enumerators of interest.
[ whoa, wait just a damn minute. it now appears some ]
[ that weight loss was solely the result of a theft. ]
[ jeeze, we turn our back for just a minute & newlib ]
[ up & steals our pids hashing logic for his history ]
[ needs. oh well, i guess life's just not that fair. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since it's possible that euser name is not being shown
or the horizontal position had been scrolled past that
USER column, then part of those headers will be blank.
So it doesn't make sense to try and show the USER that
is associated with a process at all. Thus, this commit
simply removes the 'user' provision from both headers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
