Jim Warner [Wed, 10 Feb 2016 06:00:00 +0000 (00:00 -0600)]
top: tweaks to vertical scroll management & 'i' toggle
The commit referenced below claims to disable vertical
scrolling when idle tasks weren't being shown. However
it really addresses only a point in time when that 'i'
toggle is keyed. Left untouched were the up/down keys.
So this commit will simply finish the job of disabling
vertical scrolling whenever tasks which have used some
CPU are the only ones which are currently being shown.
Mike Frysinger [Mon, 7 Mar 2016 20:36:59 +0000 (15:36 -0500)]
enable transparent large file support
Historically LFS mattered only to open/read large files. A few programs
here use open/seek, but not generally on files that are large. However,
LFS also applies to stat which procps does in a bunch of places -- some
filesystems have 64bit inodes and attempts to do a 32bit stat will throw
an error.
Craig Small [Thu, 3 Mar 2016 10:24:08 +0000 (21:24 +1100)]
A locale-independent strtod
There is a need in some utilities to have a way of accepting both
types of decimal points "." and ",". The only way seems to be to
rebuild strtod().
This new function will accept "123.456" and "123,456" as 123.456
and considers them the same number. It means we lose thousands
separator, but this is rarely used.
test scripts are added to check the function returns the proper
values. There was simpler predecessor that got stuck on negative
0 or -0.123 which these tests flushed out.
Jim Warner [Sat, 24 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: extend '=' key to include active 'locate' request
It is documented behavior that when certain other keys
are active, sorts column highlighting will temporarily
be disabled. Among those keys is the 'L' (locate/find)
provision. The equals ('=') key can be used to restore
column highlighting by resetting other keys, except 1.
When a locate/find is active, the '=' key will have no
effect on 'x' column highlighting, which still remains
disabled. Further, when 'L' is active an 'x' keystroke
is processed changing the state of column highlighting
but without any visual clue (since it's yet disabled).
So this commit just extends the '=' key to embrace 'L'
processing resets, just like other highlight disabling
keys while avoiding 'x' state changes if approproiate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Fri, 23 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: ATEOJ_RPTHSH prints hash table entries less often
We'll following the newlib <pids> approach to hashing:
. a 'PIDs at max depth:' portion of that UNREF_RPTHASH
enabled #define is now published only when the maximum
depth of hash table entry chains exceed depths of one.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 22 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: do not co-mingle strings/numbers under namespaces
Craig's recent commit under that newlib branch dealing
with namespace support has prompted me to review top's
handling of those fields. Currently, when such a field
is zero, top displays a dash ('-'). This will mean the
justification toggles ('j/J') will behave incorrectly.
This patch simply allows the potential zero to display
or be suppressed with the already existing '0' toggle.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 21 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: miscellaneous accumulated tweaks to code/comments
A patch containing the following miscellaneous tweaks:
. remove a function that handled former library errors
[ that function should have gone bye-bye with 3.3.11 ]
[ when those 'wchan' provisions were much simplified ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sun, 25 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: correct <pids> support of true string vectors
When reference counts were added to some string fields
the 3 true string vector fields were not duplicated as
were those other fields. Instead they were supposed to
disallow a duplicate stack reference beyond the first.
However, the actual implementation gave NULL for every
true vector field whenever such items were duplicated.
More importantly, such true string vector fields never
considered references to the shared proc_t source root
which would have forced the conversion of such vectors
into a single string form via the '_CVT' library flag.
So this commit restores the intended outcome with true
string vectors. There's only 1 valid reference allowed
and duplicates and converted fields will yield a NULL.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Craig Small [Mon, 26 Oct 2015 00:18:52 +0000 (11:18 +1100)]
Closes: #9 ps: Remove Unix98 output limitations
ps previously followed the Unix98 standard when it comes to
user-defined output, sometimes. This meant you could have
user output format with a header that included commas and
equals signs. It was dependent on if ps thought you wanted
sysv or bsd format and THAT was dependent on things in previous
options.
It was very confusing to a user because
ps p $$ -o pid=,comm=
gave you a two-column output but
ps -p $$ -o pid=,comm=
would give you a one column output with the header ",comm="
The -p versus p means (to ps) you want sysv or bsd parsing.
Unix98 standard or not, this is plainly just silly.
The commit removes any of the quirks Unix98 has with user defined
output. If you really wanted a ps header with commas in the output,
today isn't your day.
Craig Small [Sat, 24 Oct 2015 03:29:25 +0000 (14:29 +1100)]
free: use SReclaimable in cached
The previous commit added all of slab into the cache value. The
thing was is cached in this context is something you can get
back and reclaim if under memory pressure.
The problem was slab parameter includes both reclaimable and
unreclaimable values which doesn't make sense in this context.
This commit make cached only use the reclaimable component.
Craig Small [Sat, 24 Oct 2015 03:15:07 +0000 (14:15 +1100)]
free: use SReclaimable in cached
The previous commit added all of slab into the cache value. The
thing was is cached in this context is something you can get
back and reclaim if under memory pressure.
The problem was slab parameter includes both reclaimable and
unreclaimable values which doesn't make sense in this context.
This commit make cached only use the reclaimable component.
Jim Warner [Tue, 13 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: allow duplicated results for <pids> interface
Ok, here is that rather major internal redesign hinted
at in the three previous commits. Its need was quickly
revealed after adapting top then attempting to display
newly added 'CGNAME' fields and an existing 'CGROUPS'.
That very quickly generated a SEGV. And the reason was
just as quickly recognized. Both fields relied on that
proc_t.cgroup member yet whichever result structure is
first in a stack is the one which assumes ownership of
of the vectored sting by resetting its cgroup to NULL.
So this commit introduces reference counting for a few
of the fields in the proc_t. Specifically there are 17
entries in the Item_table dealing with strings/vectors
where ownership is transferred to newlib. Now whenever
such fields are represented more than once in a stack,
the strings will be duplicated instead of transferred.
In this way we can generally remain optimized avoiding
string copies, yet still accommodate them when needed.
There's an exception to this scheme: those true string
vectors (CGROUP_V, CMDLINE_V and ENVIRON_V). When such
fields are duplicated in a stack the result structures
beyond the first will be set to NULL, which the caller
will (should) already be equipped to deal with anyway.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Mon, 12 Oct 2015 05:00:00 +0000 (00:00 -0500)]
ps: exploits <pids> enhancement for control group name
[ 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>
Jim Warner [Mon, 12 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: exploit <pids> enhancement for control group name
[ 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>
Jim Warner [Mon, 12 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: added PROCPS_PIDS_CGNAME for <pids> interface
The ps program was modified to print the control group
names, based on the library provided list of all those
control groups to which a process belongs. But this is
probably something the newlib should be doing for all.
So this commit borrows the ps approach to cg names and
thus will make that available to all future consumers.
[ 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>
Jim Warner [Sun, 11 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: rename the 'procps_pids_stacks_sort' function
The above function was the sole public function in the
<pids> interface to use the word 'stacks' in its name.
All of the others dealt exclusively with their duties,
So this commit normalizes that outlier by renaming it.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sat, 10 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: re-enable <pids) dealloc_stacks, found a need
The above function had been disabled via '#if 0' so as
to prevent a compiler warning. But it really should be
called by that 'procps_pids_read_shut' function rather
than it duplicating/reinventing the same logic itself.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Fri, 9 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: extend '=' key to include active 'locate' request
It is documented behavior that when certain other keys
are active, sorts column highlighting will temporarily
be disabled. Among those keys is the 'L' (locate/find)
provision. The equals ('=') key can be used to restore
column highlighting by resetting other keys, except 1.
When a locate/find is active, the '=' key will have no
effect on 'x' column highlighting, which still remains
disabled. Further, when 'L' is active an 'x' keystroke
is processed changing the state of column highlighting
but without any visual clue (since it's yet disabled).
So this commit just extends the '=' key to embrace 'L'
processing resets, just like other highlight disabling
keys while avoiding 'x' state changes if approproiate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Craig Small [Tue, 1 Sep 2015 11:28:07 +0000 (21:28 +1000)]
watch: Correctly process [m Remove lib dependency
The commit referenced below made the ANSI sequence
[m be interpreted as [0m However this change was put
in the incorrect place and would reference an undefined
pointer, causing a crash. Thanks to Jimmy Theis for the
second heads-up.
watch doesn't need any libprocps functions so it is no
longer linked to them.
Craig Small [Tue, 21 Jul 2015 12:45:02 +0000 (22:45 +1000)]
w: Adjust command width
w would error out if the window size was smaller than 71 or some
other fields through environment grew too big. The code was a little
convoluted as well. The minimum length for command was 3, which is
pretty useless.
This change does the following:
w doesn't care by default the window size
w will adjust the command length up and down, to a minimum of 7
characters.
if the fields don't fit, w will line-wrap each line.
The idea being its better the line-wrap than it is to error out.
pkill: reject -signal number with trailing garbage
This commit prevents pkill from accepting something like `-1garbage` as
a SIGHUP. The previous code was using atoi() which does not check for
trailing garbage and would parse the above as 1.
Handling numeric signals in signal_option() is not really necessary,
since signal_name_to_number() will recognize numeric signals and parse
them properly using strtol() and checking for trailing garbage. It also
checks that the numeric signals are in the proper range. So all we need
to do is remove the buggy numeric signal handling here.
Tested with `pkill -1garbage sleep`, after this patch it will complain
that "1" is not a valid option, which is the expected.
Signed-off-by: Filipe Brandenburger <filbranden@google.com> Ported-by: Jim Warner <james.warner@comcast.net>
From original:
commit 9646f7cba47e078855d1fc5e3be9fb05b1b89629
Jim Warner [Thu, 8 Oct 2015 05:00:00 +0000 (00:00 -0500)]
top: correct a flaw in the support for pids monitoring
Ever since top was adapted to the new <pids> interface
there has been a bug that would cause an abnormal exit
when the '-p' argument contained *no* valid pids. This
was never revealed until now since the QA folks tested
only with valid, existing pids. (bunch of morons, eh?)
And even though the program author is blameless he has
taken it upon himself to clean up after the QA jokers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 8 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: correct a flawed approach for PROCPS_FILL_UID
Gosh, just because nobody uses some newlib provision I
guess, since it is being offered, it ought to actually
be tested at some point. Well, that point just arrived
and guess what? A surprise: some bugs were discovered.
The procps_pids_select function established a for loop
wherein readproc is called until the passed 'maxthese'
limit. Unfortunately this was incorrect for 2 reasons:
1. For PROCPS_FILL_PID results are limited by what the
oldlib finds, having established the pid list at open.
Total found already cannot exceed a passed 'maxthese';
2. With PROCPS_FILL_UID, returned results could exceed
a 'maxthese' thus making the for loop incorrect again.
[ plus yours truly neglected to forward the required ]
[ UIDs total to our old library, another oops biggie ]
In summary: the loop should have been forever, exiting
only when all those identified procs had been located.
So, while addressing those bugs, I've consolidated all
the retrieval code (initialize, iterate, summarize) in
a single helper function which will now serve both the
procps_pids_reap and select functions. And as a result
those guys were reduced to quite trivial housekeeping.
This patch, hopefully, completes the normalization for
reap/select (fill), which began with references shown.
Jim Warner [Wed, 7 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: miscellaneous minor accumulated <pids> tweaks
This patch contains the following minor modifications:
. When assigning to boot_seconds from a double, a cast
to 'unsigned long' was employed that in reality should
have been 'unsigned long long'. But, on second thought
it's probably best if the compiler makes the decision.
. Results for ID_TGID do not require an 'f_status' flg
since both tid and tgid will be available by virtue of
the 'simple_nextpid' function normal operations. Thus,
that flag has been removed from the <pids> Item_table.
. When the pids_stacks structure was eliminated with a
change to the alloc/dealloc functions in the reference
below, several casts became redundant and are removed.
Jim Warner [Sat, 3 Oct 2015 05:00:00 +0000 (00:00 -0500)]
ps: exploit those new <pids> task/threads capabilities
This commit represents the ps transition to the <pids>
'stacks' interface. While an effort to minimize impact
on existing code was made (as with a disguised proc_t)
the changes were still extensive. Along the way, a few
modifications beyond simply conversion were also made.
------------------------------------------------------
Here's a brief overview the design of this conversion:
. The need to satisfy relative enum requirements could
not easily have been made table driven since any entry
in the format_array might require several <pids> items
in support. So I decided to allow every print function
to contribute its own relative enums once the decision
as to exactly what will be printed had been finalized.
. A similar approach was taken for sorting, since it's
possible to have sort keys that will not be displayed.
Here, I relied on the existing print extensions above.
. In summary, just prior to printing ps walks thru two
lists one time (the format_list & sort_list) and calls
each print function. That function does not print, but
sets its required enum if necessary. Later, when those
same functions are called repeatedly for every printed
line, the only overhead will be an if test and branch.
------------------------------------------------------
Below is a summary of major changes beyond conversion:
. Sorts are now the responsibility of the library. And
therefore the total # of sortable fields substantially
increased without effort. Additionally, several quirky
fields remain as sortable, even though they can't ever
be printed(?). Surely that must make sense to someone.
[ while on this subject of sort, please do *not* try ]
[ to sort old ps on 'args'. or better yet, if you do ]
[ try that sort, see if you can determine his order, ]
[ without peeking at the source. that one hurts yet! ]
. All logic dealing with the old openproc flags and ps
struct members known as 'need' have been whacked since
that entire area was solely the new library's concern.
. Remaining malloc/calloc calls to stdlib were changed
to xmalloc/xcalloc from our own include/xalloc.h file.
None of the replaced calls ever checked return values.
[ be aware that 2 minor potential memory leaks exist ]
[ depending on command line arguments. no attempt is ]
[ made to free dynamically acquired format/sort node ]
[ structures upon return; a conscious design choice. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 1 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: privatize two with <pids> select/fill changes
After simplifying that select/fill interface, there is
no longer a need for public 'alloc' & 'dealloc' stacks
functions. There is now only one instance of stacks as
an input parameter found in procps_pids_stacks_sort().
But sorting 'empty' stacks serves no possible purpose.
So this commit retains both functions, since they will
still be needed, but designates them private (static).
Additionally, with their demise we will eliminate that
pids_stacks structure from the header file, internally
using what always was the true 'stacks_extent' struct.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 1 Oct 2015 05:00:00 +0000 (00:00 -0500)]
library: normalize the <pids> fill/selection interface
After wrestling with the conversion of both top and ps
the differences between reap (all) & fill (select) has
become increasingly inconvenient. So this patch simply
normalizes that API making returned results identical.
The former procps_pids_stacks_fill identifier will now
be known as procps_pids_select which serves as logical
counterpart to the existing procps_pids_reap function.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 30 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: add <pids> TIME_ALL/TIME_ELAPSED needed by ps
Shoot, here's yet another bow to ps needs. But it's ok
because it makes a lot of sense. Rather than force all
users into their own calculations do but it once here.
As an aside this need arose during ps testing when the
sorts were using TIME_START or TICS_ALL. That was just
fine for almost every need except 'etime' plus 'time'.
That 'etime' was sorting the opposite of what's wanted
when using TIME_START (of course) while 'time' yielded
some weird ordering because TICS_ALL was too granular.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 30 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: add abbreviated TTY_NUMBER to that <pids> API
While not documented in the man page, ps allows 'tty4'
as a valid output specifier complimenting 'tty8' & its
derivatives. So, in order to eliminate a dev_to_name()
call in the ps program the library will now offer this
abbreviated tty version (consisting of a number only).
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Tue, 29 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: the <pids> API now supports 'extra' enum sort
The 'PROCPS_PIDS_extra' enumerator already enjoys some
special place wherein it's zeroed with each iteration.
This patch simply extends the special handling to also
include support for sorting. It will be treated as the
'ull_int' data type, since that encompasses the entire
scope of that union within all pids_result structures.
[ plus, we've also corrected the actual 'extra' name ]
This change was prompted by the conversion of ps which
needs that enumerator to store the former 'pcpu' data,
so it will be available for sorting (not for display).
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Mon, 28 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: strengthen <pids> sort order parameter checks
The way that the passed sort order was validated would
allow the invalid 0 to fall between the sofa cushions.
So this patch will simply close that former oversight.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sun, 27 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: streamline the approach to tracking relative enum
Two separate entries under the Fieldstab were employed
to manage 'relative' enumerators under that new <pids>
interface. However, just a single entry could actually
serve both needs with a negative 'not selected' value.
So this commit just borrows the approach used with the
ps conversion where -1 is now representing unselected.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sat, 26 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: eliminate an unused error message and its support
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>
Craig Small [Sat, 26 Sep 2015 04:39:37 +0000 (14:39 +1000)]
library: Removed unused methods.
As part of the push to remove the old API, 3 more old calls were
deleted from the library. Now all someone needs to do is fix ps
and we're largely done.
Craig Small [Sat, 26 Sep 2015 04:32:56 +0000 (14:32 +1000)]
skill: use library for process scanning
skill is one of the older and more unloved programs. It was still
scanning readdir /proc. It now will use the procps library like the
rest of the programs.
Craig Small [Fri, 25 Sep 2015 23:13:13 +0000 (09:13 +1000)]
kill: split out from skill/snice
The first part of fixing skill/snice to use the library instead
of directly readdir()ing /proc which is what it does now.
Remove the kill code from the skill/snice code and put common
elements into lib/signals.c Not 100% sure that is the right
destination instead of a new lib file, but ok for now.
kill shares some parsing logic with skill/snice but mainly
around signal specifications. The "do it" code is very different.
Jim Warner [Sun, 13 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: make the pids_sort_order enums more intuitive
The values of PROCPS_SORT_ASCEND & PROCPS_SORT_DESCEND
were a tad unintuitive. This patch will just make them
a more natural +1 for ascending and -1 for descending.
[ plus it still allows that fast path multiplication ]
[ instead of a comparison for signed numbers/strings ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Fri, 11 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: trade 'look_up_our_self' for a new API equivalent
With the advent of the 'fatal_proc_unmounted' function
in the <pids.h> API to ensure the /proc filesystem was
mounted, we will finally get rid of the last remaining
vestiges of the former libprocps <readproc> interface.
[ also play a little catch up and whack some headers ]
[ that are not necessary now, beyond that readproc.h ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 10 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: enable an 'invariant' stack for that pids API
After peeking at possible conversion of the ps program
it appeared that we may ultimately need the concept of
a 'static' pids_stack in suport of look_up_our_self().
In other words, one not impacted by procps_pids_reset.
This patch simply sets the stage for that possibility.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 9 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: abandon long/long long distinction with KLONG
With this patch the distinction between a 'long' KLONG
and a 'long long' KLONG is being abandoned in favor of
a consistent declaration as 'long' only. Plus we would
have also defined it as 'unsigned' except there exists
much code already explicitly specifying the qualifier.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 9 Sep 2015 05:00:00 +0000 (00:00 -0500)]
pmap: adapt to changes in <pids> API regarding address
This commit was prompted by that change from 'addr' to
'ul_int' in the <pids> interface. Along the way, KLONG
was removed as having long ago outlived its usefulness
as performance optimizations for weird configurations.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Wed, 9 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: exchange <pids> 'addr' for that 'ul_int' type
Work on converting ps has revealed the desirability of
trading a void pointer for that ul_int type. There was
much arithmetic employed against such values and casts
would otherwise have been required. Even pmap needed a
cast on occasions when comparing an internal variable.
Besides, there is much to be said for reducing demands
on (and the complexity of) the result structure union.
[ we choose ul_int over ull_int since that former is ]
[ the exact same size and capacity as a void pointer ]
[ regardless of whether compiled as 32-bit or 64-bit ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Mon, 7 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: plug a rather big hole in the display fields dike
Whoa, guess what field got overlooked in that march to
the newlib conversion? It was the TTY guy. However, it
wasn't completely top's fault - that newlib must share
at least some responsibility, for only offering a num.
[ and while we're at it, let's touch up the man page ]
[ to agree with ol' newlib's current implementation. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Mon, 7 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: add PROCPS_PIDS_TTY_NAME to compliment number
OK, ok, this was kind of a huge omission. So please do
not select the TTY field for display in top quite yet,
at least until a next patch has been pushed to GitLab.
And to produce a correct sort order for this new field
the GNU 'strverscmp' routine was a necessary addition.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sun, 6 Sep 2015 05:00:00 +0000 (00:00 -0500)]
w: eliminate inappropriate cmdline padding with spaces
This commit is an outgrowth of the research into a bug
involving the recently added enum 'PROCPS_PIDS_extra'.
The WHAT portion of output is being padded with spaces
since the printf field width format specifier was used
in combination with a precision specifier. This commit
reduces the format string to just that precision part.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Sun, 6 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: ensure any 'flags' is consistently 'unsigned'
This commit is an outgrowth of the research into a bug
that recently surfaced with the 'w' program. And while
that program was just a victim several inconsistencies
were found in the handling of library flags during the
research. This patch just address such irregularities.
Jim Warner [Sun, 6 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: swat (now) obvious bug from PROCPS_PIDS_extra
I can't remember during what sleepy hour that enum was
added to pids.h, but it damn sure fell short of a full
implementation by approximately 1,000,000 miles or so.
Strangely it surfaced on Craig's system seemingly ggdb
related whereas on mine, a segmentation fault was only
seen when that -h (no header) argument was being used.
Oh well, the road to its resolution also offered us an
opportunity to cleanup some other items along the way.
Jim Warner [Fri, 4 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: suppress zero 'days' under the <uptime.h> API
The former whattime logic used to suppress that 'days'
output when the system had been up less than 24 hours.
But since the refactor for newlib, '0 days' was always
output under those conditions. So this commit restores
the former expected behavior of suppressing that item.
[ plus an erroneous calculation of uphours was fixed ]
[ and the clang warnings shown below were also fixed ]
Reference(s):
proc/uptime.c:74:10: warning: unused variable 'buf' [-Wunused-variable]
char buf[256];
^
proc/uptime.c:131:58: warning: data argument not used by format string [-Wformat-extra-args]
pos += sprintf(upbuf + pos, "%d min, ", uphours, upminutes);
~~~~~~~~~~ ^
proc/uptime.c:175:15: warning: expression result unused [-Wunused-value]
comma +1;
~~~~~ ^~
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 3 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: utilize a library result struct for 'forest view'
When top was originally adapted to use that <pids> API,
the forest view support was redesigned since the proc_t
pad_3 byte could no longer be employed to hold a task's
nesting level. The redesign required additional arrays.
Now that the dust is settling on those initial efforts,
that PROCPS_PIDS_noop item was used as a substitute for
the old pad_3 along with a return to the former design.
But, while it proved adequate, the invariant nature for
that item required of top an extra initialization step.
So the library was coaxed into adding one more pid_item
(PROCPS_PIDS_extra) which will, unlike that 'noop' guy,
be reset with each reap. Everybody should be happy now.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 3 Sep 2015 05:00:00 +0000 (00:00 -0500)]
library: extend 'noop' concept to a resettable 'extra'
The presence of that PROCPS_PIDS_noop may yet see some
use in the future with its 'no alter' library promise.
However, when top used that item to reflect the forest
view nesting level, the unchanging nature of that item
became more of an inconvenience than benefit. For each
refresh top was forced to loop through all the stacks,
resetting that PROCPS_PIDS_noop result struct to zero.
So this commit will now offer users a choice between a
new re-initialized item (PROCPS_PIDS_extra) & the noop
invariant. Since the library already resets all those
result structures, top will now utilize it at no cost.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Thu, 3 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: do not co-mingle strings/numbers under namespaces
Craig's recent commit under that newlib branch dealing
with namespace support has prompted me to review top's
handling of those fields. Currently, when such a field
is zero, top displays a dash ('-'). This will mean the
justification toggles ('j/J') will behave incorrectly.
This patch simply allows the potential zero to display
or be suppressed with the already existing '0' toggle.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jim Warner [Tue, 1 Sep 2015 05:00:00 +0000 (00:00 -0500)]
top: still more tidying up after <pids> implementation
A patch containing the following miscellaneous tweaks:
. remove a function that handled former library errors
[ that function should have gone bye-bye with 3.3.11 ]
[ when those 'wchan' provisions were much simplified ]
. make clearer a distinction between 'new' and 'reset'
[ use PROCPS_PIDS_noop when procps_pids_new() called ]
[ since at that point we are only establishing depth ]
Craig Small [Tue, 1 Sep 2015 11:28:07 +0000 (21:28 +1000)]
watch: Correctly process [m Remove lib dependency
The commit referenced below made the ANSI sequence
[m be interpreted as [0m However this change was put
in the incorrect place and would reference an undefined
pointer, causing a crash. Thanks to Jimmy Theis for the
second heads-up.
watch doesn't need any libprocps functions so it is no
longer linked to them.
Jim Warner [Sun, 30 Aug 2015 05:00:00 +0000 (00:00 -0500)]
library: beef up 'enum pids_item' parameter validation
I was surprised to find that ol' gcc silently converts
a single (different) enum into an address where one or
more enums were expected to be dereferenced. Of course
this was just yet another way to generate an old SEGV.
So this commit will strengthen those parameter checks.
[ we will *not* blame Craig for a failure to consult ]
[ the documentation, since it doesn't even exist yet ]
Jim Warner [Sat, 29 Aug 2015 05:00:00 +0000 (00:00 -0500)]
pmap: silence a clang -Wuninitialized variable warning
Reference(s):
pmap.c:618:20: warning: variable 'start' is uninitialized when used here [-Wuninitialized]
maxw1, start,
^~~~~ Signed-off-by: Jim Warner <james.warner@comcast.net>