After doing some profiling and timings, then comparing
newlib top to the existing 3.3.12 version, I concluded
top should avoid stack results unless actually needed.
Not only will stack depth be kept to minimums, but the
new library can save some otherwise wasted pathlength.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will begin some refinements associated with
gprof. Initially, functions names have been changed to
help in identifying potential bottlenecks. This effort
also included the obscure set, free and sort routines.
Plus the following additional modifications were made:
. the stacks_alloc prologue was generalized plus added
to a couple of modules where it had not yet propagated
. a couple of the '// end ...' comments were corrected
. some functions have been formally tagged as 'inline'
Signed-off-by: Jim Warner <james.warner@comcast.net>
The immediately prior commit demonstrated how our APIs
might be expanded in at some point in the future while
maintaining binary compatibility in previous programs.
However, since we've yet to release the 1st version of
our new library, there's no need to violate alphabetic
ordering just yet. So, this patch restores that order.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the 4.8 kernel, 2 new fields will be added to the
meminfo pseudo file. This commit, soon to be replaced,
is intended as an example of how such changes might be
incorporated plus still maintain binary compatibility.
This actually goes further than is strictly necessary,
by retaining meminfo_item ordering for 'set' functions
and the creation of hash table entries. However, there
is only 1 true requirement, that of Item_table entries
which must always agree exactly with item enumerators.
All of the other changes could be done alphabetically.
Ok, so what happens when an old program encounters the
new expanded meminfo items? Well, if it was thoroughly
tested against an old library, it won't even see those
new fields. On the other hand, if it somehow exceeds a
previous MEMINFO_logical_end, then it will just get an
extra result structure or two, with no real harm done.
[ this patch is being replace by the very next patch ]
[ so that our iniitial newlib release can maintain a ]
[ strict alphabetic ordering in all areas initially! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
These 2 programs accessed newlib stacks directly which
meant incorrect result type specifications couldn't be
detected using our new result type validation feature.
And, while the usage was correct, to put each on a par
with all of our other programs, they now rely on those
newlib offered VAL macros for accessing stack results.
[ the ps and top programs retain direct stack access ]
[ when assignment to some result struct is necessary ]
[ PIDS_extra is used by top to store the forest view ]
[ level, while ps uses it for cooked cpu percentages ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
index() is a legacy function, which is no longer implemented by all C
libraries (example: uClibc). Instead, use the POSIX defined strchr()
function.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
dlopen() functionality is only used when SELinux support is enabled, so
<dlfcn.h> only needs to be included when ENABLE_LIBSELINUX is
defined. This fixes the build in configurations where <dlfcn.h> is not
available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the numa stuff was imported from the top program,
that #include for dlopen() was not made conditional as
it should have been. Well, here it is being corrected.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Rather than return a 0 result for all VAL type errors,
return what would have been without validation active.
This will enable a program like pgrep to still print a
result even though it used some incorrect type member.
With this commit, our VAL macro validations logic will
behave in exactly the same way as the GET validations.
While warning messages may be issued, except for a bad
enumerator, values will always be returned to callers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
One ought not to assume that random memory access will
always succeed or, when it does, that an obviously bad
item enumerator will always be found at that location.
Thus, this patch corrects some really poor assumptions
associated with the 'xtra_procps_debug.h' header file.
[ and it does so in somewhat contorted ways so as to ]
[ avoid several darn gcc -Wnonnull warning messages! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch, top has ensured that base library VAL
macros are never found inside function bodies. Rather,
they are used solely to support global derived macros.
Program functions remain free to further tailor macros
but they'll now always be based on the top derivative.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When users call the native 'get' functions they have a
responsibility to check that the result struct address
was indeed returned. But when using those 'GET' macros
there was no protection for possible NULL dereference.
So this patch will add some protection for a potential
failure of an underlying 'get' function. And should it
occur then those 'GET' macros will just return a zero.
Plus, we'll also mirror that behavior in the debugging
header should the XTRA_PROCPS_DEBUG #define be active.
And, we might as well add a warning when invalid items
are passed to 'GET' macros, just like we do for 'VAL'.
[ lastly, we added the missing opening parens/braces ]
[ to 2 'GET' macros in that xtra-procps-debug.h file ]
[ which went unnoticed until the qa folks caught up. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is a response to errors found in those type
references now that our library allows for validation.
In two cases, former assignments to a result structure
could no longer employ that VAL macro if validation is
active. Thus, direct reference to some stack was used.
For the record, those instances were to be found here:
. ps - uses PIDS_extra to store the cooked pcpu values
. top - uses PIDS_extra to store the forest view level
Signed-off-by: Jim Warner <james.warner@comcast.net>
During development, we now have a means for validating
that a type referenced in application code matches the
actual type set by the library. The new feature can be
activated through either of the following two methods:
1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms)
2) an #include <proc/xtra-procps-debug.h> (single pgm)
[ in the future, one could add a formal configure.ac ]
[ provision. but for now a manual approach is safer. ]
Lastly, for any module which provides a sort function,
the handling for both 'noop' & 'extra' enumerators was
made consistent. Now, 'noop' is not sorted and 'extra'
will be sorted as that module's widest supported type.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the VAL macro now requires a 4th parameter, this
commit simply adds the 'info' context structure to it.
In some cases, that context structure needed to become
global, since it was referenced in multiple functions.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will set the stage for validating the types
referenced in the result union. For now, the parameter
representing that 'info' structure will remain unused.
[ and while we're at it, let us correct a faulty GET ]
[ macro in the diskstats header. that puppy missed a ]
[ parm which ain't so good if that guy is ever used! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is the response to changes in <pids> types.
These additional modifications were also incorporated.
. ps -------------------------------------------------
pr_wname was eliminated as it just duplicated pr_wchan
pr_wchan referenced WCHAN_ADDR in error, vs WCHAN_NAME
pr_nwchan referenced WCHAN_NAME, not proper WCHAN_ADDR
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit attempts to minimize the variety of types
currently used. Plus, the following were also changed:
. the MEM fields were switched to parallel the VM guys
. PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS
. PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT
. made NICE 's_int' so that it then parallels PRIORITY
. change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int'
. removed Item_table 'oldflags' for an obsoleted field
. PIDS_WCHAN_ADDR
. added calculations like TICS_ALL_C for the following
. PIDS_TICS_USER_C
. PIDS_TICS_SYSTEM_C
. these three new 'TICS' fields have been incorporated
. PIDS_TICS_BLKIO - jiffies spent in block i/o
. PIDS_TICS_GUEST - jiffies spent as a guest
. PIDS_TICS_GUEST_C - as above, includes dead children
. that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA
( so it did not hide between TICS_BLKIO & TICS_GUEST )
( and to make clearer what's included: utime + stime )
. eliminated 'sl_int' entirely from that result struct
[ often, the <pids> module changes necessitated that ]
[ readproc header and source files had to change too ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit provides for raising the total displayable
fields from its current 70 to 86. It also bumps the id
in an rcfile representing the version from 'i' to 'j'.
The increase in number of fields will make sharing the
rcfile with an older top, once it's saved, impossible.
These changes are being done via a #define rather than
hard coded so any such sharing will still be possible.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch, all of the modules which offer a reap
function (pids, diskstats, slabinfo and stat too) will
now also provide for sorting whatever had been reaped.
It was easy to overlook a sort function for our <STAT>
guy given the paucity of CPUs on your typical personal
desktop or laptop. However, out in the world one might
find boxes with hundreds of CPUs plus many NUMA nodes.
Hey, who are we to disallow sorts on something another
person might see as useful under the above conditions?
And, there's always something to be said for symmetry.
[ of course, several minor tweaks were also included ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
. a more appropriate error return code was substituted
. a safer form of comparison is utilized in two places
. a STAT_VAL macro replaced by more proper MEMINFO_VAL
. several of the silly 'xerrx' formats had been missed
. a few whitespace changes have also been incorporated
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch we've completed a progression toward a
standard approach to naming conventions which follows:
* Only functions will begin with that 'procps_' prefix
. ........................................... examples
. procps_vmstat_get ()
. procps_diskstats_select ()
- ----------------------------------------------------
* Exposed structures begin with the module/header name
. ........................................... examples
. struct pids_info
. struct stat_reaped
- ----------------------------------------------------
* Item enumerators begin like structs, but capitalized
. ........................................... examples
. VMSTAT_COMPACT_FAIL
. MEMINFO_DELTA_ACTIVE
[ slabinfo varies slightly due to some item variants ]
. SLABINFO_extra
. SLABS_SIZE_ACTIVE
. SLABNODE_OBJS_PER_SLAB
[ could cure with a prefix of SLABINFO, but too long ]
- ----------------------------------------------------
* Other enumerators work exactly like item enumerators
. ........................................... examples
. PIDS_SORT_ASCEND
. STAT_REAP_CPUS_AND_NODES
- ----------------------------------------------------
* Macros and constants begin just like the enumerators
. ........................................... examples
. #define SLABINFO_GET
. #define DISKSTATS_TYPE_DISK
- ----------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch attempts to standardize the naming of those
most important (declared not defined) context structs.
The present practice represents a hodge podge of names
only some of which reflect the source /proc file name.
And 2 of those file names embed a literal 'info' which
is likely the origin of that required parm identifier.
Now we'll append a universal '_info' to such structure
names, while including the names of those /proc pseudo
files where possible. In any case, that context struct
will *always* begin with the actual module/header file
name. And only the following two sound a little weird!
---------> 'meminfo_info' + 'slabinfo_info' <---------
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is a response to changes to the <diskstats>
interface. And the following represents the summary of
significant unrelated alterations that were also made.
+ corrected that 'milli weighted IO' output, which has
been wrong since that original patch referenced below.
as implemented, it duplicated 'milli spent IO' output.
+ restored original commit intent regarding disks with
a partition switch as represented in references below.
+ moved all item enumerators up near the source start.
+ removed all remaining tabs and inconsistent indents.
+ reformatted the silly style applied to 'xerrx' uses.
Reference(s):
. disallowed 'disks' under 'partition' switch
commit 7df7795b92
. original commit with disk/partition rational
commit e445f7e6c5
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will bring this interface up to our 3rd gen
standards. The following summarizes the major changes.
* New delta provisions have been added to most fields.
There are, of course, some fields for which a delta is
inappropriate. They include the identifying items such
as name, type, major and minor. Plus the io_inprogress
field which already acts, in effect, as a delta value.
* To provide delta support, dev_node historical values
have become persistent. By the same token, the library
must provide for future removal of disks/partitions. A
timestamp is used to detect 'stale' data which will be
deleted so as not to satisfy some get, select or reap.
* Such persistent support is provided by a linked list
which, by default, grows from the bottom down so as to
maintain compatibility with the /proc/diskstats order.
Initially, I was tempted to use the GNU tsearch (tree)
provisions until I discovered the overhead of building
that tree plus costs of a subsequent 'twalk'. Besides,
walking such a tree means retrieval order would differ
from an order required/expected by the vmstat program.
* The '/sys/block' directory is no longer scanned with
every refresh cycle. Rather, it's only accessed when a
node is first encountered. Then, that node's 'type' is
persistent for its lifetime like several other fields.
* A sort provision was included, at virtually no cost,
even though such a provision was not currently needed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Where possible, libprocps files convey the name of the
actual source pseudo file under the '/proc' directory.
This brings diskstats into line with such an approach.
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ plus we also play catch up on some earlier changes ]
[ that impacted skill.c, after using --enable-skill! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whoa, I had never considered an alternative to ncurses
until the issue referenced below was raised. Thus, I'm
surprised to find that 'tparm' was the only impediment
to ultimately utilizing this alternate curses library.
And, while we could have substituted that non-standard
'tiparm' with only 2 arguments, we'll utilize the full
parms compliment in the spirit of that original patch.
Frankly, the task of developing an alternative library
to that ncurses implementation really boggles my mind.
Congratulations to rofl0r, whoever that masked man is.
Reference(s):
. issue raised
https://gitlab.com/procps-ng/procps/issues/38
. netbsd-curses home
https://github.com/sabotage-linux/netbsd-curses
Signed-off-by: Jim Warner <james.warner@comcast.net>
A collection of miscellaneous code and comment tweaks.
[ such changes will stop when desk checking ends too ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
So as to avoid that potential (and inappropriate) numa
library spew to stderr, plus some resulting corruption
of top's display, top buffered stderr output until the
program ended. However, under our new library, timings
have changed meaning the corruption could occur again.
So this patch just relocates the stderr redirect to an
earlier startup point ahead of the 1st call to <STAT>.
[ plus we also fiddle just a tad with a few comments ]
Reference(s):
. original libnuma fix
commit 35dc6dcc49
. original redhat discussion
https://bugzilla.redhat.com/show_bug.cgi?id=998678
Signed-off-by: Jim Warner <james.warner@comcast.net>
Emulating the presumed proper behavior of the original
program, when the -p switch is used we will now report
an error if that provided name matches some disk name.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Back in July of last year, when vmstat was modified to
exploit the 2nd gen <slabinfo> alloc & sort provision,
yours truly introduced this bug (in the commit below).
Reference(s):
commit 8d9612f782
Signed-off-by: Jim Warner <james.warner@comcast.net>
That #define QUICK_THREADS was impossible to implement
under the new <pids> interface. Plus it was also found
to distort some thread information (referenced below).
So, it's always been inactive under the newlib branch.
However, it will (with small changes) still serve some
useful purpose in our library. Now, when the redefined
FALSE_THREADS is active, those special strings showing
"[ duplicate ENUM ]" will appear for any child thread.
Note: the real reason for such strings appearing isn't
being exercised, only their mechanics. In actual usage
they are substituted when a user duplicates such items
in a results stack & only the 1st instance can own it.
With this patch, we are simply fooling the <pids> code
into thinking an item was duplicated via a NULL value.
Reference(s):
. from master branch
commit 25a6ecdbfb
Signed-off-by: Jim Warner <james.warner@comcast.net>
If process_ansi encountered an unknown character when processing an ANSI
escape sequence, it would ungetc all the characters read so far, except
for the character just read, and the opening '\033['. ungetting the
middle of the escape sequence does not produce useful results, and also
relies on the unportable assumption that ungetc works on multiple
characters (which glibc does not support). Discard the characters
instead.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
process_ansi stopped processing an ANSI escape sequence if
(c < '0' && c > '9' && c != ';'), which will never happen. Fix the
range check to use || instead.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
process_ansi assumed all numbers in a color control sequence correspond
to colors or attributes, which breaks badly if it encounters a
ISO-8613-3 escape sequence (such as for truecolor RGB). For instance,
the sequence "\x1b[38;2;10;20;30m" sets the foreground color to
rgb(10,20,30), but watch will interpret all five numbers in the sequence
as colors or attributes themselves.
Stop processing the entire escape sequence if watch encounters any
number it doesn't understand, as that number may change the meaning of
the rest of the sequence.
Previously there was a commit to change all noinst_PROGRAMS into
check_PROGRAMS. This was not a good idea.
check_PROGRAMS are built before TESTS are run. However they are
NOT build before the dejagnu tests are run, causing those tests
to fail.
So:
If the program is required for dejagnu, it needs to go into
noinst_PROGRAMS
If the program is required for TESTS or is one of those TESTS,
it needs to go into check_PROGRAMS
For some unknown reason, check_PROGRAMS are not built before check.
They are built before recheck and after check, which isn't very
useful.
This means any tests by dejagnu that need those programs will fail.
On my console I get a build error, the CI merrily reports the error
but considers the build OK; go figure.
The kludge adds check_PROGRAMS to be a dependency to check.
Note, TESTS don't need to be included in this, because they are
properly compliled after the dejagnu tests but before they are
run.
As part of the fix to truncate the command in non-8bit, watch had
the function for output_header changed (much for scope cleanliness
and cohesiveness than anything; so I'm going to blame Meyer)...
Anyhow the 8bit enabled version did not have that update which
meant watch failed to compile. Thanks to @asavah for issue #37
and the patch.
References:
commit 5a40c7970d
