Commit Graph

113 Commits

Author SHA1 Message Date
Jim Warner
c69104b2b8 library: added important new functionality, <pids> api
This commit introduces some new capabilities available
in libproc-2 under the <PIDS> interface. Along the way
errors impacting some item values have been corrected.

The following summarizes the major changes being made.

1. The PIDS_TIME_START item was represented as seconds
since system boot but really held tics since boot. And
some programs properly divided it by Hertz to actually
yield seconds while others acted as if it already was.

So, now we have a new PIDS_TICS_BEGAN field and all of
the 'TIME' fields properly reflect seconds. With those
'TIME' fields, the type was changed to 'float/real' so
one could convert it back to tics without loss of some
centiseconds reflected in the Hertz guy (usually 100).

2. The boot_seconds was established in procps_pids_new
meaning it was fixed/unchanging. As a result, one item
(PIDS_TIME_ELAPSED) was rendered useless. So now, each
of the three retrieval functions establishes a current
boot_seconds well before the set functions are called.

3. Added a PIDS_UTILIZATION item that will provide the
CPU usage over the life of a process, as a percentage.

4. Added PIDS_TIME_ALL_C for symmetry with the similar
item called PIDS_TICS_ALL_C (which reflects raw tics).

5. That 'derived from' notation has been added to some
additional header items to reflect their true origins.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 21:27:02 +11:00
Jim Warner
afdd4690fc misc: amend the man page & source file copyright dates
This just updates the copyright dates in the documents
where I was already represented. Others are unchanged.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-01-07 19:19:15 +11:00
Jim Warner
aeb35b18da library: change 'PIDS_PROCESSOR' into a signed integer
This change is really being made on behalf of the ps &
top programs. Besides, over 2 billion CPUs are plenty!

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-12-16 20:50:07 +11:00
Jim Warner
eafd8e3112 library: refine support for multiple concurrent access
Our new library's now well protected against potential
problems which arise when a multi-threaded application
opens more than one context within the same API at the
same time. However, with a single-threaded application
designed along those same lines, some problems remain.

So, to avoid potential corruption of some data (which
was classified as local 'static __thread') from those
single-threaded designs, we'll move several variables
to the info structure itself and remove the '__thread'
qualifier. Now they're protected against both designs.

[ we'll not be protected against some multi-threaded ]
[ application that shares a single context yet calls ]
[ that interface from separate threads. this is just ]
[ bad application design & no different than sharing ]
[ other modifiable global data between such threads! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-14 16:23:07 +11:00
Jim Warner
23cfb71366 library: ensure thread safety for all static variables
Even though we we had to abandon the master branch top
multi-thread effort and even though the newlib version
of a multi-threaded top provides no real benefit, that
whole exercise was not wasted. Rather, it has revealed
some deficiencies in our library which this addresses.

If two or more threads in the same address space tried
to access the same api simultaneously, there is a good
chance some function-local static variables will yield
some of those renowned unpredictable results. So, this
patch protects them with the '__thread' storage class.

Reference(s):
https://www.freelists.org/post/procps/a-few-more-patches,7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-10-02 12:55:31 +10:00
Jim Warner
af34cc964a library: repair <pids> api boo-boo in the 'select' i/f
The patch referenced below corrected some flaws in the
procps_pids_select implementation. But, there remained
one flaw which this commit will now hopefully address.

Rather than assume callers wished to select only tasks
and not threads meant a command like 'top -H -p 10329'
works differently under newlib than release 3.3.17. It
fails to honor the '-H' (threads) switch under newlib.

So, to fix that oops, we'll allow that select function
to get threads or tasks depending on its 'which' parm.

Reference(s):
. Oct 2015, some flaws corrected
commit bc616b3615

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-09 22:03:23 +10:00
Jim Warner
631e5d91f3 library: add provision for displaying autogroup values
In the link referenced below there's an explanation of
the linux autogroup feature which has been around ever
since linux-2.6.38. With that explanation there's also
surprising (maybe shocking) revelations about the nice
and renice commands if CONFIG_SCHED_AUTOGROUP was set.

When autogroups are active, such programs are rendered
mostly useless because the nice value will only affect
scheduling priority relative to other processes in the
same autogroup. In order to accomplish what we thought
of as renice, that nice value in /proc/<pid>/autogroup
must be changed. Altering any single member of a group
will also affect every other member of that autogroup.

So, this commit will set the stage for users of newlib
to display autogroup identifiers plus their associated
nice values (now that their importance is understood).

Reference(s):
https://github.com/nlburgin/reallynice

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-09 22:00:23 +10:00
Jim Warner
3e94210fe4 library: add new derived smaps_rollup item, <pids> api
That recent addition of USS to the ps program prompted
this change.  Rather than have it (and soon top) add 2
separate items to yield the desired value, we will let
our new library perform the arithmetic when necessary.

Outside of a little extra storage, there is no runtime
costs for such an extension. There is, however, a real
benefit to having such code in the library. Now should
callers choose to sort on this new field, results will
be guaranteed to be what was expected (i.e. accurate).

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-06-17 16:42:58 +10:00
Jim Warner
bf0b3b6522 library: rename/reposition two enumerators, <pids> api
The two special hugetlbfs items were misnamed. The TBL
reference (table) should be TLB (transaction lookaside
buffer). Besides, I never liked their position anyway!

[ and one macro argument tweak is being snuck in too ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-05-02 20:08:38 +10:00
Jim Warner
12543b6c76 library: add support for smaps_rollup file, <pids> api
A couple of people have suggested that smaps_rollup be
added to the ps program and/or top program. This patch
is intended to set the stage for just such extensions.

There are currently 20 displayable items in the rollup
file. And newlib sometimes uses sscanf when populating
the target, sometimes hsearch and one customized gperf
approach. None of these fit well with the smaps items.

Thus, an approach using a simple table lookup was used
and, by disabling 1 code line, it could be made immune
from changes to the items order (unlike a sscanf call)
and doesn't carry the greater cost of a hsearch/gperf.

Note: The next patch will allow top to display some of
these new fields. Then, it'll be possible to determine
the colossal costs of accessing the smaps_rollup file.

Here is a small preview of just what you will discover
when using the command 'time top/top -d0 -n1000' while
configured with just two fields: PID + 1 memory field.

------------------------------------ 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):
. ps: expose shared/private memory separately
https://gitlab.com/procps-ng/procps/-/issues/201
. top/ps: add support for PSS reporting
https://gitlab.com/procps-ng/procps/-/issues/112

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-29 21:42:44 +10:00
Jim Warner
b921776dad library: some miscellaneous tweaks before smaps_rollup
This commit is strictly cosmetic. It was an attempt to
normalize/standardize/alphabetize those #define/#undef
statements. Some missing #undef's were added plus some
comments regarding sources corrected/standardized too.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-29 21:42:44 +10:00
Craig Small
a7afe06e6f library: adding IO accounting
This is a modification of MR !122 by @renit1609 to fit the new
library.

Problem statement:
The procps library has no PROC_FILLIO flag to
fetch the proc field "/proc/[pid]/io" data
process-wise.
IO Accounting is not included as part of procps.

Requirement:
We have a requirement to fetch process wise
IO utilization which can be used for monitoring.

When looking through the procps library, I see
that IO Accounting (/proc/[pid]/io) is not being
included as part of procps. There is no such
flag like PROC_FILLIO being included in readproc.h .

Solution:
While looking at the implementation done for
other proc fields, I used the spare bits in app code.
I renamed PROC_SPARE_1 as PROC_FILLIO, the spare bit from
PROC_SPARE_* and used it for fetching /proc/[pid]/io
data as part of the procps library similar to other
fields. I moved the PROC_SPARE_* bits each by 1 bit
to retain the spare bits. Meanwhile added the IO fields
in proc_t structure.

References:
 procps-ng/procps!122
 procps-ng/procps#184
2021-04-24 22:38:48 +10:00
Jim Warner
c082779769 library: fix an insidious bug affecting TICS_ALL_DELTA
This simple two line code change fixes an intermittent
bug whereby %CPU for parent(s) with collapsed children
could be vastly understated from those displayed under
the current 3.3.17 publicly available top & libprocps.

If one started several top instances in the background
using very a small delay interval (zero?), then if the
shell under which they were running was collapsed, you
would see similar %CPU results for both the libraries.

However, when running a demanding 'make' like a kernel
compile (especially if backed by fast processors and a
SSD), then newlib would generally show only 1/3 to 1/2
of the collapsed %CPU values that appeared for 3.3.17.

Of course, now that the bug has been swatted with this
commit the disparities between those results is easily
explained. Since newly created tasks never contributed
tics during the interval where they were created, only
with many short lived tasks would differences surface.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-24 11:11:03 +10:00
Jim Warner
0f691226ec library: lower addr resolution cost for TICS_ALL_DELTA
Rather than run risks of more expensive and repetitive
address resolution, we will establish this local index
for a one time cost and avoid any potential gcc bloat.

[ this commit was made in pursuit of a bug involving ]
[ the distortion of elapsed task tics. but, it turns ]
[ out these changes had nothing to do with that bug. ]
[ however, the patch is being retained as desirable. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-24 11:11:03 +10:00
Jim Warner
9b601307ff library: lessen chance of distortion on TICS_ALL_DELTA
That old library defined this field as 'unsigned int'.
However, here it was known as a 'signed int'. Thus for
consistency we'll now also treat it as 'unsigned int'.

[ this commit was made in pursuit of a bug involving ]
[ the distortion of elapsed task tics. but, it turns ]
[ out these changes had nothing to do with that bug. ]
[ however, the patch is being retained as desirable. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-24 11:11:03 +10:00
Jim Warner
39a8c08161 library: fix a few source/origin notations, <pids> api
After removing brackets from those 'derived' notations
I was surprised to discover that several origin/source
comments were wrong. So this patch fixes those errors.

[ along the way a couple enumerators were renamed to ]
[ better (i hope) reflect what they're representing. ]

[ that, in turn, also required a little rearranging. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-03-11 21:21:23 +11:00
Jim Warner
333a1bb6b8 library: tweak logic for /proc not mounted, <pids> api
Since 'procps_uptime' will access the /proc filesystem
the <pids> 'new' guy should should protect against the
possibility /proc isn't mounted when 'boot_seconds' is
established. A zero is better than the negative value.

[ the only distortion would be to PIDS_TIME_ELAPSED. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-18 18:35:32 +11:00
Jim Warner
fb0e4f3f68 library: update those source files for copyright dates
In addition to copyright date, the initial descriptive
line was changed from a generic statement to one which
reflects the specific portion of the proc/ filesystem.

[ such descriptions alternate between 'declarations' ]
[ (h files) & corresponding 'definitions' (c files). ]

Also, a few missing copyright attributions were added.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-09 16:40:52 +11:00
Jim Warner
3c87c46439 library: tweak 'other' user/group names for efficiency
This commit just ensures that the relatively expensive
ID to name conversions aren't performed unless they're
explicitly requested. It also internalizes those flags
that required the PROC_FILLSTATUS flag to also be set.

[ requiring a caller, in our case pids.c, to provide ]
[ two flags when a single field was the objective is ]
[ wrong & represents a future potential toe-stubber. ]

[ moreover, what's worse is that those two flags are ]
[ seemingly unrelated. but, without both, a SEGV can ]
[ can be expected when a result.str pointer is NULL. ]

[ by contrast, in the master branch those fields are ]
[ arrays which, when set to zeroes, produce an empty ]
[ string. So, there is no abend (but no name either) ]
[ when one of those two required flags were omitted. ]

[ and worth noting, in that branch it's not just one ]
[ caller required to observe a two flag requirement. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-09 16:40:52 +11:00
Craig Small
bc16fa87f0 misc: Update Craig's email 2021-01-21 17:37:48 +11:00
Jim Warner
423297c9db all: make buildable again for new 'misc.h' header file
With the 4 header files removed in the previous patch,
this commit just changes all those obsolete references
to that new consolidated 'misc.h' header file instead.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-21 17:30:25 +11:00
Jim Warner
fd64b91d09 library: extend ITEMTABLE_DEBUG just a tad, <PIDS> api
Under the above #define this commit now also addresses
2 additional possible toe stubbers involving 'select'.

If some readproc.h constants were uncoupled from their
pids.h enumerators a 'make check-lib' will now detect.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-29 08:48:23 +11:00
Jim Warner
07e4c08c62 misc: just a couple cosmetic changes for comments only
Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-29 08:48:23 +11:00
Jim Warner
eb83a1f821 library: a tweak to the UNREF_RPTHASH code, <pids> api
If a hash results report is output (via UNREF_RPTHASH)
a portion is devoted to occupied table entries ordered
by depth. There is a possibility that some depths will
not be found among existing occupied table entries and
to avoid any confusion probably should not be printed.

[ to illustrate the potential for confusion prior to ]
[ this patch, force a very small table size (like 8) ]
[ & then trigger the procps_pids_unref() eoj report. ]

So this patch ensures only 'in use' entries are shown.

[ admittedly, all of the remaining logic in the loop ]
[ could/should be subordinate to this new 'if' test, ]
[ but we will keep the change to a minimum. besides, ]
[ there's no harm subtracting/adding a zero numdepth ]
[ especially since the chance of a zero is very low. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-24 18:27:57 +11:00
Jim Warner
9eb930eebb library: tweak that history hash algorithm, <pids> api
This patch just raises the size of the hash table used
to calculate elapsed task stuff. The net result should
be less need for 'chaining' under pid hash collisions.

[ the hash scheme is intentionally kept as primitive ]
[ and, therefore, as fast as possible. it employs an ]
[ 'and' approach versus a 'mod' operation since both ]
[ yield similar distribution but the former approach ]
[ was 4 fewer cpu instructions in terms of overhead. ]

[ additionally, for hash collisions, 'chaining' uses ]
[ an array index rather than the usual pointer since ]
[ the HST_t guys may move when they are reallocated. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-11 17:53:22 +11:00
Jim Warner
e2b0f8b0af library: tweak the memory allocation logic, <pids> api
This patch separates the memory allocations into those
used initially from those used in later reallocations.
Thus, we can reduce that iterative realloc() overhead.

Additionally, we'll correct a long standing oops where
multiple history_info structures were created at 'new'
time when only one should have been allocated (jeeze).

[ originally the allocation was strangely based upon ]
[ number of 'items' (???) & later a #define constant ]

Reference(s):
. May, 2016 - subsequent bad history_info logic
commit 9ebadc1438
. Aug, 2015 - original faulty history_info code
commit 7e6a371d8a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-11 17:53:22 +11:00
Jim Warner
2c1973d64c library: eliminate one potential source of human error
There's a huge toe-stubber awaiting future maintenance
as reflected in that commit below which deals with the
addition of new enumerators to the Item_table. Namely,
whenever the table is grown, one must remember to also
change that existing 'logical_end' enumerator's value.

Well, not anymore! Since that MAXTABLE macro was added
to the procps-private.h header we can now also exploit
it so a 'logical_end' automatically tracks table size.

This change also renders some code associated with the
ITEMTABLE_DEBUG #define unnecessary. So it's gone too.

Reference(s):
. 08/2016, add new enumerators
commit 09e1886c9e
. 08/2020, added MAXTABLE macro
commit c865b06c30
. 08/2020, introduced ITEMTABLE_DEBUG
commit 92d0297e1e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-26 21:50:20 +10:00
Jim Warner
92d0297e1e library: introduced 'Item_table' validation provisions
The recent work on updating the <meminfo> and <vmstat>
modules with some newly added linux fields reminded me
(again) of a need for some mechanism guaranteeing that
a header file agrees with the source file assumptions.

Sadly, in the past, if a table entry was omitted or if
the table and header are ordered differently, then the
library would silently return the wrong results values
or even potentially experience a SIGSEGV abnormal end.

This patch offers a much needed development assist for
ensuring that Item_table entries are synchronized with
header file enumerators in terms of number plus order.

It's intended solely for our use as libprocps evolves.

Now, by activating ITEMTABLE_DEBUG, either directly or
via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number
and order will be verified. It is envisioned that this
feature will be used at least once prior to a release.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-13 21:08:58 +10:00
Jim Warner
c13ea57495 library: added some justification emphasis, <pids> api
I almost feel like I should apologize for this kind of
patch ( *almost* ). But, since this comment was unique
to the <pids> api and since it was especially designed
to align with the following comment and since the next
comment already carried the alignment emphasis, I will
refrain from issuing any apology and submit it anyway.

[ plus to prove that i am not totally anal-retentive ]
[ and can exercise some restraint there are two more ]
[ places where i COULD have added alignment emphasis ]

[ see lines 804-806 and lines 1360-1361 for my proof ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-29 19:01:50 +10:00
Jim Warner
a9ac3faa44 library: show allowable range in relative enum warning
This patch just trades the 'typestr' for the much more
meaningful 'valid range' when a relative enum has been
deemed invalid under that XTRA_PROCPS_DEBUG provision.

[ and we'll also make one comment a bit more generic ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-20 16:15:14 +10:00
Jim Warner
11df806a7c library: correct one reference typo in that <PIDS> api
This patch will just correct an oops introduced in the
commit shown below. Thank goodness both 'str' & 'strv'
occupy the same storage location in that result union.

Reference(s):
. standardize 'errno' management
commit 06be33b43e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-10-27 22:27:49 +11:00
Jim Warner
40883a0b85 library: minimize the use of 'cleanup_stacks' routines
Some parts of our newlib implementation are the result
of functions which have been propagated from module to
module. In particular, those 'cleanup_stacks' routines
are all similar & likely originated in the <pids> api.

In that interface there was a need to free dynamically
acquired memory before the result structure was reused
to satisfy subsequent 'get', 'select' or 'reap' calls.
This, in turn, led to a concept of 'dirty' stacks with
the need to call one of two 'cleanup_stack' functions.

None of the remaining interfaces deal with such memory
yet they each had their own 'cleanup_stack' functions.
Those functions were responsible for resetting each of
the result unions to zero, excluding any 'noop' items.

The bottom line is that for all interfaces, repetitive
calls would require iterating through the stack(s) two
separate times: once to 'cleanup' another to 'assign'.

With this commit we will reduce iterations to just the
'assign' routine. A reset to zero will be accomplished
in the 'extra' item set routine (which is the only one
actually requiring any reset). All other items will be
reinitialized automatically by a new current set value
or upon reallocation when an items compliment changes.

In the <pids> interface, any freeing of dynamic memory
could have been accomplished by adding that 'freefunc'
check to the 'assign' function. However, that requires
an Item_table test with every item. Instead, we'll now
satisfy such needs as the very first step in those set
functions responsible for dynamically acquired memory.

[ the <pids> api retains 2 'cleanup_stack' functions ]
[ to accommodate stack(s) 'reset' & to serve 'unref' ]

Lastly, all the 'itemize_stack' functions were tweaked
by eliminating an unnecessary initialization of result
unions. That objective was already accomplished by the
calloc() in a 'stacks_alloc' function or the remaining
'cleanup_stack' routine found in the <pids> interface.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-07-04 20:46:18 +10:00
Jim Warner
f87fc7dc83 library: tweak support for get/select/reap, <PIDS> api
When the <pids> api was refactored in the commit shown
below, one objective was enabling the simultaneous use
of 'get' & 'select/reap' functions. Unlike other 'get'
functions, this <pids> 'get' acts as an iterator where
successive calls will return successive tasks/threads.

However, that goal wasn't quite met since a stack used
by 'get' was commingled with the 'select/reap' stacks.
Such commingling supported the 'reset' function, again
a provision which was unique to this <pids> interface.

Unfortunately, some poor assumptions in 'stacks_fetch'
produced a SEGV whenever 'reap/select' followed 'get'.
Thus, this patch addresses those issues and guarantees
such commingled stacks (extents) will be accommodated.

Reference(s):
. standardize portions of interface, <PIDS> api
commit 9ebadc1438

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-16 21:23:06 +10:00
Jim Warner
a9bfb186eb library: correct 'vectorized' string logic, <PIDS> api
The commit referenced below addressed (some) anomalies
surrounding 'strv' pointers. However, there remained a
couple quirks involving a potential NULL return value.

Any NULL values returned from the old library readproc
guys would cause no real harm for newlib. But they did
produce the misleading "[ duplicate ENUM_ID ]" result.

The following all represent potential NULL results and
suggest shortcomings in testing of that earlier patch.

. kernel threads do not have cgroup, cmdline & environ
. even if present environ could require root to access

So, this patch reverts a portion of the earlier commit
and ensures when some vectored string is not available
a traditional dash ('-') is the 'strv' returned value.

[ and we'll also correct one typo in the header file ]

Reference(s):
. eliminated a final potential NULL, <PIDS> api
commit 09503dc597

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-16 21:23:06 +10:00
Jim Warner
6671a3a8b7 library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.

However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting

Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.

These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).

___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.

So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.

Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.

That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.

___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').

_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.

When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.

________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.

_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.

More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.

Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).

Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.

______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).

Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46
. 01/2019, <stat> origins tweaked
commit 201e816b26

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-26 19:55:30 +11:00
Jim Warner
d9f88246f6 library: insert 'PIDS_ID_TID' for symmetry, <PIDS> api
This change is being made in anticipation of adding the
source origin of each item to the <pids.h> header file.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-03 08:06:48 +11:00
Jim Warner
ad4269f118 library: expanded to provide for the 'executable path'
This patch is the first of three implementing a newlib
branch version of that Jan Rybar master merge request.

With this series we'll ultimately extend 'EXE' support
to both ps and top (plus, everyone else who wants it).

Reference(s):
. master branch merge request
https://gitlab.com/procps-ng/procps/merge_requests/66

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-26 21:25:18 +10:00
Jim Warner
97d078a9af library: clean up some miscellaneous compiler warnings
Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-09 21:35:20 +10:00
Qualys Security Advisory
1052091107 0076-proc/readproc.c: Harden vectorize_this_str().
This detects an integer overflow of "strlen + 1", prevents an integer
overflow of "tot + adj + (2 * pSZ)", and avoids calling snprintf with a
string longer than INT_MAX. Truncate rather than fail, since the callers
do not expect a failure of this function.

---------------------------- adapted for newlib branch
. logic is now in pids.c
. former 'vectorize_this_str' is now 'pids_vectorize_this'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-09 21:35:19 +10:00
Jim Warner
f341bd4632 library: expanded to provide for the UID used at login
This patch represents the newlib implementation of Jan
Rybar's merge request referenced below. It essentially
moves that code out of the ps program and into our new
library where it's available via the <pids> interface.

Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/57
https://bugzilla.redhat.com/show_bug.cgi?id=1518986

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-19 20:33:59 +11:00
Jim Warner
7ede9ef79f library: account for idle state ('I') threads in total
With the documentation update in the commit referenced
below, we should also account for such threads as they
will already be represented in the task/thread totals.

[ and do it in a way that might avoid future changes ]

Reference(s):
commit 91df65b9e7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-12 20:58:31 +11:00
Jim Warner
d53ff45b0d library: delete some obsolete parameter checking logic
This commit removes some obsolete parameter validation
code which was needed back when certain functions were
public, called directly by users (1st/2nd generation).

Now that they're static they can be safely eliminated.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:54 +11:00
Jim Warner
06be33b43e library: improve and/or standardize 'errno' management
With older library logic having been modified to avoid
using those potentially deadly alloc.h routines, while
improving 'errno' handling, we're ready to standardize
and enhance newlib's approach to any potential errors.

In so doing, we'll establish the following objectives:

. . . . . . . . . . . . . functions returning an 'int'
. an error will be indicated by a negative number that
is always the inverse of some well known errno.h value

. . . . . . . . . . . functions returning an 'address'
. any error will be indicated by a NULL return pointer
with the actual reason found in the formal errno value

And, when errno is manipulated directly we will strive
to do so whenever possible within those routines which
have been declared with PROCPS_EXPORT. In other words,
in the user callable functions defined in source last.

[ But, that won't always be possible. In particular, ]
[ all the 'read_failed' functions will sometimes set ]
[ 'errno' so that they can serve callers returning a ]
[ NULL or an int without duplicating a lot of logic. ]

[ Also, that includes one subordinate function which ]
[ was called by 'read_failed' in the <slabinfo> API. ]

------------------------------------------------------
Along the way, several additional miscellaneous issues
were addressed. They're listed here now for posterity.

. the '-1' return value passed outside the library was
eliminated since it would erroneously equate to -EPERM

. the stacks_fetch functions in <diskstats> and <stat>
weren't checked for their possible minus return values

. hash create was not checked in <meminfo> or <vmstat>

. fixed 'new' function faulty parm check in <slabinfo>

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-12-20 21:18:54 +11:00
Jim Warner
28f405689c library: fixed miscellaneous whitespace/comment issues
. ensure whitespace exists between the code & comments
[ changing txt slightly keeps right margin alignment ]

. strive for more consistency with some comment styles
[ don't use C '/*' style where C++ '//' style exists ]

. removed the instance of double space in 1 assignment
[ still striving for consistency in whitespace usage ]

. fixed comment relating to number of 'derived fields'
[ the <meminfo> api recently added one new such enum ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-10-01 22:25:18 +11:00
Jim Warner
89775d5418 library: normalize stacks_extent struct layout, <PIDS>
This patch just rearranges 1 item in the stacks_extent
struct to make it equivalent to all the other modules.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-10-01 22:25:18 +11:00
Jim Warner
3d39e4fd88 library: set stage for NUMA node field display support
In response to that suggestion referenced below, these
changes allow display of task/thread level NUMA nodes.

Currently, only the 'top' program offers any NUMA type
support and it is limited to the Summary Area display.
With this commit both the 'top' and 'ps' programs will
be able to display NUMA nodes associated with threads.

Reference(s):
https://gitlab.com/procps-ng/procps/issues/58

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
6644b1a646 library: eliminate a redundant conditional, <PIDS> api
library: eliminate a single redundant conditional test

Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-22 21:38:10 +10:00
Jim Warner
e70531a945 library: protect against possible 'refcount' underflow
In each module employing a priming read at 'new' time,
should that read fail, a call to 'unref' will be made.

However, there is a hidden dependency that these calls
must never occur before the context 'refcount' was set
due to the way an 'unref' conditional was constructed.

So this commit just ensures that 'unref' will function
as expected, even if called with a 'refcount' of zero.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-07 22:06:59 +11:00
Jim Warner
912075605b library <stat>: remove that PIDS_WCHAN_ADDR enumerator
Removing the Item_table 'stat' oldflags for WCHAN_ADDR
was wrong since that 'stat' field is not a constant 0.
Rather, it could assume these 3 values: -1, 0, and +1.

I have not been able to pin down a '-1' result, but it
probably means some sort of permission error (-EPERM).

The '1' or '0' values were supposed to distinguish the
tasks that were or were not blocked (whether there was
a wchan address). However, in practice there is little
correlation between those values and availability of a
kernel symbol in /proc/$$/wchan (perhaps due to race).

Anyway, the real point is that a 'stat' wchan does not
now intentionally contain an address. Thus, outputting
'ffffff', '-' or '1' in programs like ps is senseless.

So this patch just eliminates PIDS_WCHAN_ADDR from our
item enumerators leaving only the PIDS_WCHAN_NAME guy.
Now the new library can't be blamed for bad addresses!

Reference(s):
. removed Item_table 'oldflags'
commit c4aa6c0ab4
. linux removal of wchan addresses
commit b2f73922d119686323f14fbbe46587f863852328

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-16 08:23:38 +11:00
Jim Warner
71bd5b6485 library <pids>: remove fields obsoleted with linux 2.6
It seems inappropriate to blindly include fields known
to always be zero in our brand new library. Therefore,
this patch removes support for three such enumerators.

[ that stat 'it_real_value' (PIDS_ALARM) field could ]
[ have been made obsolete before a linux 2.6 release ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-10-09 21:31:29 +11:00