Commit Graph

544 Commits

Author SHA1 Message Date
Jim Warner
ecd64f4445 library: normalize/standardize an i/f, <DISKSTATS> api
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>
2016-07-26 20:46:08 +10:00
Jim Warner
8e5d5e44e9 library: rename 'diskstat' source as 'diskstats' files
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>
2016-07-26 07:59:52 +10:00
Jim Warner
338166df57 misc: just eliminate several 'unused' warning messages
[ 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>
2016-07-26 07:59:48 +10:00
Jim Warner
220236a9af library: some minor miscellaeous improvements, 3rd gen
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>
2016-07-17 08:49:48 +10:00
Jim Warner
c546d9dd44 library: recycle the QUICK_THREADS #define, <PIDS> api
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>
2016-07-17 08:49:48 +10:00
Jim Warner
9bea1b2def library: the overlooked twerks (oops, tweaks), 3rd gen
Yes, all of these changes are strictly cosmetic. It is
likely symptomatic of some deep-seated character flaw.

[ or, it might be because of a certain pride in this ]
[ new library and the desire to make it even better! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-09 12:48:28 +10:00
Jim Warner
a6115bfff4 library: some tweaks to 2 file read functions, 3rd gen
Ever since their introduction, plus continuing through
several evolutions, both the meminfo and vmstat 'read'
functions employed a 'do while' loop for /proc access.

However, that loop construct was wrong since identical
tests were already done (twice!) within each loop body
itself, then accompanied by its own 'break' statement.

So, we will now transform them both into forever loops
which will help us to emphasize such break statements.

[ plus, let's return an error should nothing be read ]

[ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ]

Reference(s):
. original meminfo introduction
commit a20e88e4e7
. original vmstat introduction
commit a410e236ab

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-06 21:36:37 +10:00
Simon Tatham
f888a30d23 library: find tty device name of process quicker
The procps library attempts to work out the tty of a process
through several methods. For things like /dev/tty123 or
/dev/foo it works fine.

For tty devices that put the minor number in a directory
of the major name this fails. So then we have to fallback
to stating things like the processes STDERR and try again.

Considering a lot of processes sit on ttys such as
/dev/pts/3 this is a lot of wasted time. At the point of
entering driver_name we know "/dev/pts" and we know "3"
we just didn't join them up the right way as this is old
code.

This change now looks for /dev/pts/3 as well. It does it
after looking for /dev/pts3 so the behaviour is the same.

References:
 https://bugs.debian.org/770215

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-07-03 10:47:25 +10:00
Jim Warner
80ad63dc31 library: refactor exposed pointers management, 3rd gen
This commit brings all of those 'fetch' type functions
(supporting some form of 'reap') into closer alignment
with one another. The biggest impact is to be found in
the <stat> module, which now provides for the separate
copy of stack pointers which will be exposed to users.

The reason such a copy was not employed initially with
<stat>, unlike those for <pids> and <slabinfo>, is due
to the fact that such stacks were never sortable. Thus
the original raw consolidated extent pointers wouldn't
have been disturbed. But that meant no NULL delimiter.

So with this commit, all reap/fetch operations now use
pointer copies when returning results to callers. And,
all such arrays are now NULL delimited meaning callers
can choose their own access fencepost: totals or NULL.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
4fe52ccd44 library: reduce copies of items to minimum, <STAT> api
This commit will consolidate the three separate copies
of the item enumerators currently supporting that reap
function (summary, cpus & nodes) into one shared copy.

That select function will continue to maintain its own
dedicated items copy, albeit via a new item structure.

[ and while we're at it, we'll move the 'select' guy ]
[ to its proper alphabetical place, after our 'reap' ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
8cd1214aac library: stop treating lxcname differently, <PIDS> api
Unlike other cached string fields (such as USER name),
that lxcname field was defined as 'const char *'. This
required a custom 'set' function using a cast in order
to avoid a compiler warning regarding that assignment.

So this commit brings lxcname into line with all those
other cached string fields. And while we're at it, the
reason some string fields have no 'freefunc' will also
be explained with some new comments in the Item_table.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
eff9fbc06e library: standardize extents_free_all() logic, 3rd gen
As those 3rd generation newlib APIs evolved so too did
the extents_free_all() function. Most versions of this
function required the callers to first verify that the
extents anchor wasn't empty, which was poor etiquette.

This simple function should have been much more robust
and forgiving. With this commit, it fnally becomes so.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Craig Small
96e6600c84 library: Cater for 32 char device names
The new library has this boundary set in a define.
Also fixed the off-by-one problem with the buffer and scanf

References:
 commit 1794875ab6
2016-07-02 15:01:11 +10:00
Jim Warner
380253ff7f library: more pids_fetch struct opaqueness, <PIDS> api
With all our 3rd generation interfaces, we're now well
positioned to preserve binary compatibility should new
fields be added to any public structure (assuming that
the 'result' union already contains its largest type).

This remains true even for the <pids> interface, which
unlike the others, has one structure embedded within a
separate struct rather than declaring a pointer to it.

The counts struct was positioned after the stacks ptrs
array so as to preserve that ABI if ever new ints were
added. Logically, however, the counts (especially that
total) should precede the stacks array if we wished to
properly place a horse (total) before a cart (stacks).

So to enable relocating those counts we will no longer
embed that structure, but provide a pointer to it. And
this will make accessing syntax feel more natural too.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-28 21:11:25 +10:00
Jim Warner
ddb4754b33 library: partial revert of that numa 'fix', <STAT> api
This patch represents the partial revert of the commit
referenced below. And, so that yours truly (the author
for goodness sake) doesn't shoot his tootsies again in
the future, a cautionary programmer comment was added.

Reference(s):
commit dea4033418

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-28 21:11:25 +10:00
Jim Warner
8444a6fe0b library: a couple of miscellaneous changes, <PIDS> api
This patch represents the following minor adjustments:

. old PROCTAB used with select & reap more descriptive

. reformatted PROCPS_PIDS_VAL macro like other 3rd gen

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
e41b40e6b0 library: <SLABINFO> api, change that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
8f1fb67a78 library: <MEMINFO> api, changed that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
e8d7f869b5 library: <VMSTAT> api, change in the 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
8c7f89ad8d library: <STAT> api, change for that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
dea4033418 library: bug fix if libnuma.so unavailable, <STAT> api
All our numa logic was well encapsulated under #ifndef
NUMA_DISABLE (as ./configure --disable-numa), with the
exception of 1 case label. The reason it didn't create
any problems is because the sole consumer (top) itself
responded to the presence of #define NUMA_DISABLE too.

But if that option wasn't used, an oops still awaited.

When experimenting with a 32-bit library plus a 64-bit
kernel, a bug was revealed should the numa library not
have been found. Our 'reap' function must tolerate the
potential of a 0 return from that stacks_fetch_tics().

Now, if numa is desired but not possible, we'll be ok.

[ and, we'll build numa history from fresher sources ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Craig Small
5a244c1095 library: rename clashing pwcache functions
On MacOS the system already has user_from_uid and group_from_gid.
These are renamed pwcache_get_user and pwcache_get_group.

They were also exported but did not appear in the symbol file
or used by any of the procps binaries. They are no longer exported.

References:
 https://gitlab.com/procps-ng/procps/issues/34

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-06-18 08:17:45 +10:00
Jim Warner
d7100d071d library: optional parms protection missing, <PIDS> api
When those items were made dynamic at 'new' time, some
other functions, previously assured of their presence,
failed to verify a 'reset' had acually been requested.

This commit just corrects that oversight and avoids an
attempt to 'assign_results' when no items are present.

Reference(s):
. when items/numitems became optional
commit 9ebadc1438

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 21:44:29 +10:00
Jim Warner
4a0e974b7f library: more tweaks for code and/or comments, 3rd gen
Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.

<meminfo> ............................................
. eliminated duplicate decl of 'struct procps_meminfo'
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. how did i miss relocating all these friggin' #undefs
. cleanup 'get' return logic (remove a redundant 'if')

<pids> ...............................................
. repositioned the procps_pidsinfo structure in header
. removed the extra trailing comma from enum pids_item
. standardized/normalized results struct union members

<slabinfo> ...........................................
. corrected comment typo (jeeze, in an 'aligned' para)
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. removed an obsolete #undef from procps_slabinfo_sort
. cleanup 'get' return logic (remove a redundant 'if')

<stat> ...............................................
. how did i miss relocating all these friggin' #undefs
. corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix
. removed the extra trailing comma from enum stat_item
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. strengthen those parm checks in procps_stat_get func
. cleanup 'get' return logic (remove a redundant 'if')

<vmstat> .............................................
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. cleanup 'get' return logic (remove a redundant 'if')

[ virtually all of these tweaks reflect the author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 21:44:29 +10:00
Jim Warner
92c72166db library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.

[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]

[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-13 10:33:37 +10:00
Jim Warner
876ec555c3 library: final tweaks to code and/or comments, 3rd gen
With the dust now settling on all those 3rd generation
upgrades, this patch tries to provide some consistency
among the separate modules involved. Someday we should
consider a 4th generation where all redundant code has
been removed and isolated in a new shared source file.

Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.

<meminfo> ............................................
. strictly formatting/comment changes, code unaffected

<pids> ...............................................
. replaced a local mkSTR macro with existing STRINGIFY
. added fetch narrative explaining duplicate addresses

<slabinfo> ...........................................
. rearranged some free logic for procps_slabinfo_unref
. added fetch narrative explaining duplicate addresses

<stat> ...............................................
. added #define ENFORCE_LOGICAL, just as in <slabinfo>
. replaced a local mkSTR macro with existing STRINGIFY
. alphabetized the function declarations in the header

<vmstat> .............................................
. made one coverity concession with read_vmstat_failed

[ several of these changes may reflect this author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-13 10:33:37 +10:00
Jim Warner
adfa2bc75a library: please keep procps-private.h free of #include
The 'procps.h' header includes all other headers which
contain exported (public) functions, while this header
has some (private) macros required for implementation.

If we mix the two, by including procps.h in this file,
we'll lose all hope of the compiler catching the kinds
of errors corrected in an immediately preceding patch.

[ we must be diligent, always constantly striving to ]
[ protect jimmy from ill effects due to copy & paste ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-11 11:50:37 +10:00
Jim Warner
6a70466ae5 library: overcome effect of copy/paste, <SLABINFO> api
Needless to say, when one copies and then pastes, it's
always better when those results are refined somewhat.

The qsort callback declarations used the wrong results
type and 2 of their 3 input parameters were wrong too.

So this patch will fix that & generalize declarations.

[ plus add comment guidance about noop & extra enums ]
[ & provide for 'noop' sorting, as is done in <PIDS> ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-11 11:50:37 +10:00
Jim Warner
f897a495ee library: adjust 'noop' callback definition, <PIDS> api
Though all those callback's parameters are ignored and
qsort treats them as pointers to void, it's wrong when
3rd parm is 'enum pids_item', not 'struct sort_parms'.

So we will fix it in a way that lessens the likelihood
of another such a mistake when some new type is added.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-11 11:50:37 +10:00
Jim Warner
aa9f00dcaf library: misc tweaks for code and comments, <PIDS> api
This commit simply tries to keep naming plus formating
conventions on a par with the continuing climb up that
learning curve. These changes were suggested following
<slabinfo> sources upgrade from 2nd to 3rd generation.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
335cbc2e61 library: make struct name more descriptive, <STAT> api
After normalizing the <SLABINFO> module, much of which
was based on this module, a structure which is crucial
to concurrent select/reap support is renamed the same.

Such a need for concurrent support was revealed during
slabtop testing. That program requests (select) global
data after calling for individual node data (reap) but
before those stacks have been accessed. Therefore, one
set of 'items'/'extents' could not possibly be shared.

So now we will know the former struct fetch_support as
ext_support. The former name was potentially confusing
since the struct was used by both 'select' and 'reap'.
However, only 'reap' ever called the 'fetch' function.

[ this <STAT> already accommodated concurrent usage. ]
[ in fact it contains 3 separate sets of items/exts. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
8650518b5a library: fix upper bounds enum delimiter, <VMSTAT> api
Oops, the PROCPS_VMSTAT_logical_end enum reflected the
source state before all those DELTA enum's were added.

[ plus add a couple of overlooked #undef directives, ]
[ and whack an unneeded stacks_alloc assignment too! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
b700d91f84 library: whack a superfluous assignment, <MEMINFO> api
This patch was prompted through work on the <slabinfo>
upgrade from 2nd gen to 3rd. And while this assignment
caused no real harm, it most certainly was misleading.

[ plus add a couple of overlooked #undef directives! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
5d5a52a380 library: normalize/standardize the i/f, <SLABINFO> api
Before this major redesign, the slabs interface likely
was our messiest 2nd generation attempt at opaqueness.
Beyond the standard 'new', 'ref' & 'unref', there were
a total of 12 exported functions. Now, there are four.

The 1st step was to remove several of those functions.
These were quick to go since they were not used (yet):
. procps_slabnode_count
. procps_slabnode_getname
. procps_slabnode_getstack

Then, the following were internalized so users needn't
be burdened with implementation details in the future:
. procps_slabinfo_read (renamed: read_slabinfo_failed)
. procps_slabnode_stacks_alloc (renamed: stacks_alloc)

Still others evolved into the minimal interface we had
strived for in the other upgraded 3rd generation APIs:
. procps_slabnode_get -----------> procps_slabinfo_get
. separate stack_alloc/fill --> procps_slabinfo_select
. separate stacks_alloc/fill ---> procps_slabinfo_reap
. procps_slabnode_stacks_sort --> procps_slabinfo_sort

------------------------------------------------------
Beyond those reductions, the major modifications were:

. This API tries to be as forgiving as possible and as
such won't throw errors when a caller request makes no
sense. For example, if a 'get' or 'select' requested a
SLABNODE item (with no current means to id that node),
results will be zero. By the same token, should 'reap'
include a global SLABS item (meaning those values will
be duplicated in *every* node stack) it'll be allowed.

. If the above behavior is undesired, a new #define of
ENFORCE_LOGICAL can be used to restrict certain items.

. Permission problems will now be caught at 'new' time
thanks to a priming 'read' call. That read also serves
to make DELTA values potentially useful at 1st access.

. Separate slab/slabnode enumerators were consolidated
into one, simplifying validation & the results struct.

. Several internal parameter checks were relaxed since
they were already checked by the caller. Besides if we
cannot trust our own code we might as well hang it up.

. That sort provision was made more efficient and will
offer the ascending choice, in addition to descending.

------------------------------------------------------
Lastly, some additional thoughts regarding the future:

. It would not be difficult to expand 'select' to also
accept a nodeid, or to clone it as 'select_node'. And,
should the same be extended to 'get', a results struct
could be returned instead of signed long accommodating
the extra data type(s) like a node name (string data).

. The 'get' function is not currently affected by that
 define ENFORCE_LOGICAL. However, at some future point
perhaps -EINVAL would be more appropriate than a zero.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
5be4167782 library: rename the 'slab' sources as 'slabinfo' files
Where possible, libprocps files convey the name of the
actual source pseudo file under the '/proc' directory.

This patch brings slab into line with such a standard.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Craig Small
d2b29312bb library: fix new and unref pids test
The original test did not NULL the unallocated info pointer. This
was incorrectly calling the procps_pids_new() function.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2016-06-07 21:13:57 +10:00
Jim Warner
d69a2b6899 library: normalize/standardize interface, <VMSTAT> api
This interface represented a 2nd generation attempt at
the opaque newlib approach. In other words, it did not
involve the 1st generation 'chains'. Instead, 'stacks'
were employed. But the interface wasn't user friendly.

Users were required to create their own stacks, before
calling 'getstack' to retrieve multiple results with a
single call. Even worse, sometimes 'read' was required
before calling 'get' when working with single results.

So this commit represents the 3rd generation approach.
We eliminate the burden of 'read' and creating stacks.
Rather, beyond those standard 'new', 'ref' and 'unref'
functions, we'll offer just 'get' (single result) plus
a 'select' function (for multiple results in 1 stack).

And along the way, this commit vastly expands the data
extracted from /proc/vmstat. All values that currently
exist (and their delta equivalents) are now available.
Deltas were included for everything because there's no
real runtime costs beyond using a little extra memory.

The only problem is a lack of documentation for all of
those fields, as is reflected in the references below.
Oh well, maybe someday someone will dig through kernel
sources & finally plug that rather large document gap.

[ as an aside, rather than using a 'strcmp' approach ]
[ when parsing the /proc/vmstat file, as is found in ]
[ the <meminfo> module, we exploit those hash search ]
[ provisions that are found in the <search.h> header ]

Reference(s):
http://www.spinics.net/lists/linux-man/msg09096.html
http://www.linuxinsight.com/proc_vmstat.html

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-07 21:04:43 +10:00
Jim Warner
2aaae6f29b library: improve internal 'get' processing, <STAT> api
With an eye to the future, rather than managing a long
switch/case construct in the procps_stat_get function,
we'll adopt the approach used in the <meminfo> module.

By making 'get' processing table driven too, just like
'select' is already, that may ease future maintenance.

Along the way a rather large boo-boo was fixed dealing
with that /proc/stat 'procs_running' field which crept
in with the commit referenced below. It wasn't spelled
correctly and thus was never captured as PROC_RUNNING.

Reference(s):
commit abc71a46ad

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-07 21:04:43 +10:00
Jim Warner
af0c65900b library: add parameter checks for 'get', <MEMINFO> api
When this interface was normalized/standardized, under
the commit referenced below, the parameters were never
validated in the 'get' function. Let's plug that hole.

Reference(s):
commit 407f1b71de

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-07 21:04:43 +10:00
Craig Small
b96c994390 library: Fix pids API tests
Update the pids tests for tweaked API. Unsure why the toomany
test doesn't work, may point to a problem in the change as it used
to trigger, or the library has flexibility.
2016-05-22 22:12:54 +10:00
Jim Warner
09503dc597 library: eliminated a final potential NULL, <PIDS> api
In that reference below a specific systemd problem was
fixed in the commit shown. However lurking deep within
the <pids> interface was yet one final case where NULL
could be returned, involving 'strv' and the following:

. a user requested both a single string vector (always
returned as a normal string) & the vectorized version,
as with PROCPS_PIDS_CMDLINE and PROCPS_PIDS_CMDLINE_V.

. a user simply duplicated some vectorized enum items.

The root of that NULL problem is the fact those single
string vectors shared the same proc_t field with their
true vectorized version. So while multiple occurrences
for most strings could be satisfied with strdup versus
the normal ownership usurpation, those true vectorized
fields could not be quite so easily copied/duplicated.

Thus newlib chose to return a NULL result.strv pointer
under either of the above scenarios (which perhaps was
just a user boo-boo in the first place). In any event,
the NULL was a potential for true string vectors only.

Now, since newlib is the sole caller into the readproc
module, separate fields have been created for what are
just normal strings (never vectorized) and those which
remain the true vectorized versions. And, former flags
which only worked if combined, now act as stand alone.

Thus, both PROCPS_PIDS_CMDLINE & PROCPS_PIDS_CMDLINE_V
can be used simultaneously (as they should have been).

Also with this patch, items which a user duplicates in
the stack (beyond the first such item) will return the
the string "[ duplicate ENUM_ID ]". This practice will
apply to both single strings and true vectorized ones.
In addition to informing users of their error, it will
also mean potential NULLs need now never be a concern.

Reference(s);
http://www.freelists.org/post/procps/systemd-binary-vs-library
commit 0580a7b4c6

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-22 21:59:18 +10:00
Craig Small
8d7945fd0c library: move QUICK_THREADS hack before return
Minor complaint where a line to stop GCC from complaining occured
after the return.
2016-05-17 21:56:21 +10:00
Jim Warner
0511ab0245 library: respond to coverity (reluctantly), <PIDS> api
Calls to free() have now been reintroduce in the new()
function to quiet coverity warnings. Those free's were
removed originally as that library 'new' was returning
with a fatal error and a caller should end abnormally.

Plus, it is virtually impossible to fail a malloc call
under linux. And lastly, they required braces with the
if statement making the code considerably less pretty.

[ commit also includes 2 unrelated whitespace tweaks ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-17 21:13:34 +10:00
Jim Warner
0580a7b4c6 library: avoid any --with-systemd conflict, <PIDS> api
A potential conflict arises should should some program
attempt to access systemd data using our library built
without that support (--disable-systemd). And while we
could argue that all callers should check against NULL
string pointers, it's not expected of libprocps users.

So we'll guarantee 'em valid string consisting of "?".

Reference(s):
http://www.freelists.org/post/procps/systemd-binary-vs-library

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-16 21:36:54 +10:00
Jim Warner
f68dfabc35 library: try different alignment for types, <PIDS> api
Rather than adopt an approach offered below, involving
changing all enumerator names to convey types, perhaps
this much more modest change is a worthwhile 1st step.

By just changing the comments to 'right justification'
it dramatically improves readability, at least it does
to my eye.  Perhaps such an approach can postpone that
massive alternative effort for the foreseeable future.

Reference(s):
http://www.freelists.org/post/procps/newlib-drip-drip,4

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-16 19:58:20 +10:00
Jim Warner
540342620b library: try to minimize the results types, <PIDS> api
This is just beginning an effort to minimize/normalize
the sheer variety of results types in use for our API.

In taking these first baby steps, a few anomalies were
found. There'll no doubt be many more yet to discover.

. the _FLT_ (fault) fields were already signed long in
the proc_t (even though their sscanf format used %lu).

. although strtoul will alway return an unsigned long,
all of the _VM_ fields were made signed long just like
other memory fields (& signed sorts more efficiently).

Reference(s):
http://www.freelists.org/post/procps/newlib-drip-drip,4

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-16 19:58:20 +10:00
Jim Warner
9ebadc1438 library: standardize portions of interface, <PIDS> api
This represents a rather major interface redesign. The
following highlights most of the changes/enhancements.

. The 'read' interface (employed by pgrep & pidof) saw
the biggest change. The 'open', 'next' and 'shut' guys
all went bye-bye, replaced by a single 'get' function.

. The items specified at 'new' time no longer serve as
the maximum. In fact, items & numitems are now treated
as optional, should callers prefer to wait until later
when the 'reset' function would then become mandatory.

. Even at 'reset' time, the stacks are not tied to any
sort of maximum. They will grow dynamically as needed.

. The order of some parameters was changed to parallel
that found in our other APIs. Specifically, when items
& numitems are needed they're specified in that order.

. A user will no longer be prevented from concurrently
employing any accessor functions. In other words, that
'get' (old 'read') won't preclude 'reap' and 'select'.

. A duplicate enumerator was found dealing with locked
resident pages. So, the name VM_LOCK was eliminated in
favor of VM_RSS_LOCKED, which is way more descriptive.

. The struct address returned to callers following any
reap() or select() is now more sharable as pids_fetch.

. Some input parameter names were changed to make them
more descriptive of the intended purpose/requirements.

------------------------------------------------------
Internally, there were numerous implementation changes
made that did not directly impact any potential users.

. That #define FPRINT_STACKS was eliminated along with
the associated supporting function and its invocation.

. Addresses returned following 'reap' or 'select' will
now be NULL delimited, so one has the option of stacks
access via the total count or this new NULL fencepost.

. Input params were simplified and generalized in both
oldproc_open() & close() to enable more than 1 PROCTAB
to be open simultaneously, which was required for get.

. The PROCPS_PIDS_logical_end enum was relocated after
the Item_table making the need to keep it synchronized
more apparent (if the table expands it's right there).

. The 'Public function' section of the source file was
subdivided into 1) the three basic required functions;
and 2) functions that can sometimes vary between APIs.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-16 19:58:20 +10:00
Craig Small
bfb7361980 library: oldproc_open has always yes check
if (info->flags | PROC_UID)
Something OR a non-zero constant is always true.
Looks like it should be and'ed for the standard flag masking
pattern.

References:
  Coverity #99118

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2016-05-14 22:55:16 +10:00
Craig Small
f85d9a2b95 library: Remove dead branch in file2strvec
A while loop used n >=0
A branch inside the loop had a test for n<0
That's never going to happen!
So the branch must go. There is similiar code outside
the branch. Yes, I miss pythons while else here.

Also cleaned up the ***-awful indentation this function had.
No wonder that branch lived for so long there.

References:
 Coverity #99119

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2016-05-14 22:43:19 +10:00
Craig Small
4f6b8c9c60 library: slab sort derefence after check
procps_slabnode_stacks_sort() would check if stacks was NULL
*after* the pointer was derefenced in the initialisation of
the variable p.

p is now assigned after the check.

References:
 Coverity #99160
2016-05-14 22:32:35 +10:00
Jim Warner
90753e2d5b library: remove the ull_int result type, <MEMINFO> api
Because of the vast quantities of virtual memory which
may be allocated, it initially seemed like a good idea
to provide for a widest possible range through the use
of a 'ull_int' result type. However, on second thought
the implementation was a bit flawed for these reasons:

. that underlying meminfo_data variable 'VmallocTotal'
is 'unsigned long' not a required 'unsigned long long'

. there wasn't a convenient way to value it since each
variable was set with a strtoul() call, not strtoull()

So this patch will standardize on the 'ul_int' results
type (and reduce the associated delta to 's_int' too).
For now, we'll rely on protections under a 64-bit arch
where a 'ull_int' & 'ul_int' yield identical capacity.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 21:15:01 +10:00
Jim Warner
fac5e6fea0 library: allow negative delta values for 2, <STAT> api
A recent buglet in the <meminfo> interface, where many
delta values could legitimately be negative, suggested
a review of this module where a minus was forced to 0.

As it turns out, there are two delta items that indeed
could be negative. They involve the current processes.

So henceforth, DELTA_PROC_BLOCKED & DELTA_PROC_RUNNING
will now be allowed to go negative. I believe that all
other items can only grow. But, if we find more later,
at least the adaptation approach has been established.

[ this whole business of checking for less than zero ]
[ harks back to an old kernel anomaly where negative ]
[ tics were sometimes experienced. top was affected. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 21:13:47 +10:00
Jim Warner
93a60022dc library: ain't like your father's delta, <MEMINFO> api
When the code for DELTA values (among other stuff) was
stolen from the recently revised <stat> interface, the
concept of ever growing values was propagated too. But
here we must manage both growing and shrinking values.

Thus former protections against a negative delta don't
have any place in this module and are hereby banished.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 21:13:47 +10:00
Craig Small
b4beb162fd library: minor fix for procps_meminfo_select
Thus function returns a pointer, not an int, so if there is
an error return NULL and not -errno.

proc/meminfo.c: In function ‘procps_meminfo_select’:
proc/meminfo.c:994:20: warning: return makes pointer from integer
without a cast [-Wint-conversion]
             return -ENOMEM;

References:
 commit 407f1b71de
2016-05-12 07:52:36 +10:00
Jim Warner
407f1b71de library: improve/normalize an interface, <MEMINFO> api
This represents the refinement of this interface after
the <stat> API was redesigned. We now follow a pattern
of 'get' for single item retrieval & 'select' for when
multiple items are desired, with just 1 function call.

And again following the <stat> lead this interface now
provides for delta values encompassing most items. The
reason I went cuckoo nuts with those deltas is because
they are essentially free. At the cost of a little RAM
and just one memcpy there's no other price to be paid.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 07:51:10 +10:00
Jim Warner
5ec5002b0d library: lift item restrictions on 'get()', <STAT> api
In the commit referenced below it was acknowledged the
procps_stat_get() function will intentionally restrict
returned values by excluding DELTA items among others.

Upon reflection that decision seemed rather arbitrary,
and so has now been lifted. And, while the initial use
of a DELTA will return 0, subsequent calls to that get
function will now return the difference (providing one
second, at least, has elapsed between any such calls).

Reference(s):
. reference to design decisions
commit abc71a46ad

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 07:51:10 +10:00
Jim Warner
1417ba56b5 library; add more of my gratuitous changes, <STAT> api
This commit is just my usual tweaking after an initial
submission, once the dust has settled & some more desk
checking was performed. Here are the changes included:

. get function need not check the 'stat_was_read' flag
( first time in save_sec == 0 so branch always taken )

. some table logic appeared outside the proper section
. cleanup_stack's loop made to work like assign_result
. eliminated an include of procps.h from stat.h header
. removed 'ext_numitems' from the stacks_extent struct
. changed the alignment of three prototypes for stat.h
. reorganized the pointers for 'stacks_extents' struct
. improved types indentation in header for readability

. lastly, some really gratuitous changes made to align
- comments within that private 'stacks_alloc' function

Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-12 07:51:10 +10:00
Jim Warner
abc71a46ad library: improve/standardize one interface, <STAT> api
This commit represents a complete redesign of the stat
interface. Gone are the confusing 8 separate accessors
along with their 2 additional read functions. In their
place we have just 3 accessors, with no read required.

That old interface also suffered an inflexibility with
respect to structures.  Now we deal with an unchanging
standard 'result' struct enabling future changes where
the binary interface will no longer need to be broken.

And gone is that former unnecessary typedef, used when
dealing with jiffies. Now the standard C type is used.

Our new API also adds some brand new functionality. If
a caller plans to employ successive 'select' or 'reap'
invocations, then delta values are available (which is
actually only what that top program is interested in).

At some future point a 'sort' function could be easily
introduced to complement the 'reap' function. However,
I saw no need for it at present and so it was omitted.

There were several design decisions which everyone may
not agree with. In support I'll offer these rationals:

. The 'get' function returns a signed long long result
which means a potential loss of some significance. But
I felt the ability to distinguish actual errors (minus
values) from true zero results were worth such a risk.

. The DELTA item enumerators were also made signed and
smaller than their parents. And they are intentionally
grouped as last so as to emphasize those distinctions.

. The SYS type items were excluded from the new 'reap'
function. It would not make sense to duplicate them in
each results stack. They're limited to 'get'/'select'.

. By the same token, some items (DELTA, etc.) will not
be allowed under that 'get' routine. That function was
already open to significant internal overhead (through
subsequent calls like in vmstat.c). That is why it has
been limited via 1 second between reads of /proc/stat.

Lastly, when we finally get around to documenting this
interface there's a real potential toe stubber when it
comes to the numa node portion. The libnuma.so doesn't
really provide any means to retrieve the active nodes.
Thus, any total reported by <stat> is just the highest
node number plus one, as reported by the numa library.

Any unused/inactive nodes are identified through these
. PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID

By the same token after the STAT_REAP_CPUS_ONLY 'reap'
. PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID

Reference(s):
http://www.freelists.org/post/procps/newlib-stat-interface

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-08 21:12:22 +10:00
Jim Warner
5854f2d956 library: remove an obsolete 'jiffs' typedef in sysinfo
During work on the new <stat> interface the typedef of
jiffs was eliminated along with the clang warning. The
exact same warning in sysinfo.h now goes bye-bye also.

Reference(s):
./proc/sysinfo.h:16:28: warning: redefinition of typedef 'jiff' is a C11 feature [-Wtypedef-redefinition]
typedef unsigned long long jiff;

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-08 21:12:22 +10:00
Craig Small
d2df396ba9 misc: Few more resource leak fixes
free after malloc in signals.c
closedir after opendir in diskstat
2016-05-03 21:58:13 +10:00
Craig Small
19a515e314 library: Fix LINUX_VERSION macro
The previous commit did not take into account operator evaluation
order so always gave 0. Fixed the macro and added some checks for
the macro.

References:
 commit 9abf7d879d
2016-05-01 17:46:25 +10:00
Craig Small
9abf7d879d library: protect against large version numbers.
Linux release numbers are x.y.z we assumed but never protected
against x> 0x7fff and y,z > 0xff before.

Linux release in 1991, 1 major release per 6 years so we're fine
until 7452, unless they do way too many minor rels (max being 39)
2016-05-01 17:14:48 +10:00
Craig Small
6b5cb345c5 library: procps_uptime() return value is a status
procps_uptime, previously just plain uptime() used to put the
uptime (as a double) in the first argument and return uptime
(as an int).

It meant if you ran
 myuptime2 = procps_uptime(&myuptime1, NULL);
You might get different results for myuptime1 and myuptime2 because
they are different types.

Most library calls use the return value to return the status,
procps_uptime was in the middle.

Until now.

This function will return 0 on success. If you want (for whatever
reason) uptime as an int then cast it.

All of the procps binaries didn't use the return value for uptime
except ps which set a variable to it but never used it anywhere.
2016-05-01 16:50:25 +10:00
Craig Small
222945c672 library: provide ref and unref for diskstat
While procps_diskstat_ref and procps_diskstat_unref were declared
they actually weren't implemented in the library. Linking some
binary that used these functions gave the following errors:

  CCLD     vmstat
vmstat.o: In function `disksum_format':
vmstat.c:719: undefined reference to `procps_diskstat_unref'
vmstat.o: In function `diskformat':
vmstat.c:591: undefined reference to `procps_diskstat_unref'
2016-05-01 16:15:49 +10:00
Jim Warner
3a48427d5d library: rename those readstat.c & h sources to 'stat'
In an attempt to normalize the 'stat' interface, we'll
first shed any reminders of the old readproc interface
by changing file names to be more descriptive & brief.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-26 22:27:16 +10:00
Jim Warner
b778a267fe library: fix boo-boo left by earlier patch, <PIDS> api
After the commit referenced below the potential exists
for a SEGV (resulting from an out-of-bounds Item_table
reference if PROCPS_PIDS_physical_end is encountered).

So this patch eliminates that PROCPS_PIDS_physical_end
as no longer necessary and completes the task of using
PROCPS_PIDS_logical_end as a sole necessary fencepost.

Reference(s):
commit e7585992d9
2016-04-26 22:27:16 +10:00
Jim Warner
8c38a58d94 library: reorder (alphabetize) some things, <PIDS> api
Without breaking either ABI or API just rearrange some
stuff to provide a little more consistent source file.

[ these were prompted by some work on the <stat> API ]
[ in preparation for him borrowing some of our code. ]

Reference(s):

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-26 22:27:16 +10:00
Craig Small
40de1c9c7c library: fix order of operations for %use of slabinfo
In some environments, 100 * nr_active_objs is calculated at first,
and lower 32bit of the result is divided by nr_objs.
If 100 * nr_active_objs > 42949672, %use will be incorrect.

Reported by Takayuki Nagata <tnagata@redhat.com> and adopted
his patch for new library (see reference)

References:
 commit 99d71ad581
 http://www.freelists.org/post/procps/PATCH-bprocps-fix-order-of-operations-for-use-of-slabinfo
2016-04-25 20:24:20 +10:00
Craig Small
aa16ab0dc1 tests: update template and add pids
Generalised the library API tests and created a common
test-runner. Instead of copy and pasting the same code in
each time.

First cut of pids API test, for _new so far.
2016-04-19 21:33:02 +10:00
Jim Warner
edb124ec86 library: changed use of 'fill' to 'select', <pids> API
Remove a remnant of this new API's evolution.  Here we
no longer fill stacks, rather we reap and select them.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-19 20:38:18 +10:00
Jim Warner
e7585992d9 library: protect against a future breakage, <pids> ABI
By co-mingling both external/internal identifiers with
actual implementation code, potential future additions
to our API would have been considerably more difficult.

So, this patch will now rely solely on internal/hidden
identifiers serving as fenceposts in validation logic.

And if the following convention is used for new fields
we will maintain that enumerator alphabetic ordering a
a little longer (even though 2 user fields now don't):

. PROCPS_PIDS_XTRA_FOO_A, PROCPS_PIDS_XTRA_FOO_B, etc.

Reference(s):
http://www.freelists.org/post/procps/me-too-newlib,7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-19 20:38:18 +10:00
Jim Warner
b4d21c74ac library: correct the procps_pid_length() +1 distortion
Unfortunately, reading that '/proc/sys/kernel/pid_max'
file returns a newline, which we will now account for.

[ also, we should use the existing dedicated buffer ]

Reference(s):
. original 'procps_pid_length' introduction
commit ccb6ae8de1

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-18 19:29:41 +10:00
Jim Warner
81e0f15ac3 library: remove remaining 'likely' & 'unlikely' macros
Say goodbye to the 'makes it hard to read' macro shit.

Reference(s):
http://www.freelists.org/post/procps/me-too-newlib,4

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-18 19:29:41 +10:00
Craig Small
d916d5db86 library: re-arrange escape commands
escaped_copy(): only appears in ps, moved to ps/output.c
escape_strlist() only used in escape.c made static
escape_command() used in library, made internal
procps.h no longer includes escape.h

escape_str() used by library and ps so needs to be exported
definition put into procps.h including the odd define required.
Far from ideal to have it this way, will look at it another time
to have it all in, all out or split nicer so its not in the API;
perhaps a lib/ file?
2016-04-17 14:45:19 +10:00
Craig Small
887bb51016 library: cleanup of readproc functions
readproc still had some of the old API hanging around that
was good while we were trying it out, but its time to say
goodbye:

readproc.h removed from public procps.h header file
enum ns_type - not used - removed
get_ns_name() - not defined - removed
get_ns_id() - not defined - removed
PROCTAB proc_t only used internal to library
readproctab() and 2,3 friends not used - removed
proc_data_t was used by readproctab23() - removed
readtask() - not used - removed
read_cmdline() - copy,renamed and made generic - remove original
freeproc() - not used - removed
get_proc_status - not used - removed, however there should be
a new function created that does this. Given a PID return data
about it instead of scanning the entire procfs. Maybe it already does.

Left as internal-to-library only functions:
 readproc(), readeither(), look_up_our_self(), openproc(), closeproc()

Updated libprocps.sym to export only what we use.
2016-04-17 14:14:27 +10:00
Jim Warner
67bf272f5d library: trade a deprecated oomem field for proper one
Now that the conditional OOMEM_ENABLE has been removed
and, after reviewing current library support, it turns
out we've been using a deprecated /proc/<pid>/oom_adj.

What we should use instead is that more recent tunable
/proc/<pid>/oom_score_adj. This new field will provide
a range of -1000 thru +1000 (former was -17 thru +15).

Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
. linux, partial oom_adj revert (Nov, 2012)
commit fa0cbbf145aabbf29c6f28f8a11935c0b0fd86fc
. linux, removal oom_adj (Oct, 2012)
commit 01dc52ebdf472f77cca623ca693ca24cfc0f1bbe

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-17 09:12:02 +10:00
Craig Small
8e20fa7786 library: document and tests for uptime functions
man pages for the three procps_uptime* functions and simple
test scripts for same functions.
2016-04-16 22:02:10 +10:00
Craig Small
ccb6ae8de1 library: cleanup of library includes
The includes used to define a lot of things a library include
should not. It was also a bit messy what was exposed in the library
and what was not.

get_pid_digits -> procps_pid_length and exported correctly

MALLOC attribute move into relevant .c files
NORETURN attribute moved to relevant .c, not used in library
PURE attribute removed, it wasn't used
KLONG/KLF/STRTOUKL were fixed for long, so now just use long

HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT
seems to do the same (opposite) thing.

likely/unlikely removed from most places, its highly debateable
this does anything useful as CPUs have gotten smarter about branches.

Re-arranged the includes, ALL external programs should just #include
<proc/procps.h> then proc/procps.h includes headers for files that
have exported functions. procps.h and the headers it includes should
not use items that are not exportable (e.g. hidden functions or
macros) they go in procps-private.h
2016-04-16 17:03:57 +10:00
Craig Small
8639a97250 libprocps version test and documentation
test binary and man page for the version part of libprocps.
It's a simple start, but it's a start!
2016-04-14 22:28:38 +10:00
Craig Small
bf97da3059 Replace %Lu with standard %llu
Multiple scanf()s use the GNU-permitted %Lu. This is not supported in
other libraries and isn't to the POSIX specification. The L modifier
is only used for floats in POSIX.

Replacing %Lu with %llu is the same for GNU libc (scanf(3) says as much)
but means other libraries will work fine.

From master commit da715e3

References:
 http://pubs.opengroup.org/onlinepubs/009695399/functions/fscanf.html
2016-04-14 21:21:27 +10:00
Jim Warner
8dc378f6a8 library: exploit linux-4.5 resident memory enhancement
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
 . RssAnon - size of resident anonymous memory
 . RssFile - size of resident file mappings
 . RssShmem - size of resident shared memory

This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.

p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.

Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-14 21:03:03 +10:00
Jim Warner
65000d7c64 library: miscellaneous tweaks for code and/or comments
Summarized below, miscellany addressed in this commit:

. deleted extraneous newline(s) for consistent spacing

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-03-12 14:52:56 +11:00
Jim Warner
2b0dd2d702 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>
2015-10-28 20:58:28 +11:00
Jim Warner
9db796f8cb library: correct one <pids> reference from str to strv
While not changing generated code this commit corrects
one free reference from 'str' to a more proper 'strv'.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-28 20:58:12 +11:00
Craig Small
602b9a02ce 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.

References:
 http://www.freelists.org/post/procps/OmegaPhilxxxxxxxxxxxxx-Bug799716-free-considers-cached-to-include-SUnreclaim
 https://github.com/brndnmtthws/conky/issues/130
 https://bugs.debian.org/799716

Commits:
 05d751c4f0
 6cb75efef8
2015-10-24 14:29:25 +11:00
Jim Warner
88489be542 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>
2015-10-14 21:50:31 +11:00
Jim Warner
a59a269661 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>
2015-10-14 21:48:41 +11:00
Jim Warner
838e7852cb 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>
2015-10-14 21:47:04 +11:00
Jim Warner
c9388ed512 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>
2015-10-14 21:35:53 +11:00
Jim Warner
bc616b3615 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.

Reference(s):
commit 0c953eccc5
commit 747dfc5987

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-09 21:35:04 +11:00
Jim Warner
0354fc1c8f 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.

Reference(s):
commit 747dfc5987.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-09 21:33:14 +11:00
Jim Warner
747dfc5987 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>
2015-10-05 21:48:45 +11:00
Jim Warner
0c953eccc5 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>
2015-10-05 21:47:50 +11:00
Jim Warner
30997b967a 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>
2015-10-05 21:42:07 +11:00
Jim Warner
042cfa71e7 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>
2015-10-05 21:39:37 +11:00
Jim Warner
d66000588a 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>
2015-10-05 21:37:08 +11:00
Jim Warner
27283bbc6f 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>
2015-10-05 21:32:54 +11:00
Craig Small
5321868929 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.
2015-09-26 14:39:37 +10:00
Jim Warner
86b155b83f 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>
2015-09-21 22:39:40 +10:00
Jim Warner
007e032805 library: introduce a fatal 'proc not mounted' function
Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-21 22:38:38 +10:00