Commit Graph

1912 Commits

Author SHA1 Message Date
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
458845f575 watch: truncate command in non-8 bit mode
When the screen width is not long enough to display the entire
command, watch puts three dots ... like elipses at the end of
the truncated line.

It's been like that for years, perhaps noone uses non 8-bit
watch?

References:
 commit 367b8bb616

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-07-02 16:27:50 +10:00
Jesse Hathaway
80594403cc watch: Add hostname to the header
watch has the hostname added to the header so you know what device
if you have many it is running on.

Signed-off-by: Craig Small <csmall@enc.com.au>
2016-07-02 15:47:39 +10:00
Craig Small
96da4bad5e kill: Correct pid type
Previous commit used a pid type of int in the printf, this should
be a long.

References:
 commit 5e9c522eea
2016-07-02 15:04:22 +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
Craig Small
5e9c522eea kill: report error if cannot kill process
Shell kill would report a problem if you tried to kill a process
while procps kill was silent. This meant it looked like kill worked
when it actually failed.

References:
 commit 07642b8ea6
 https://bugs.debian.org/733172
2016-07-02 14:49:51 +10:00
Jim Warner
a2c79b6237 misc: adapt others to struct layout change, <PIDS> api
With the change to struct pids_fetch, we'll just trade
some dot ('.') code for some pointer to ('->') syntax.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-28 21:11:25 +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
428ef496a6 misc: adapt others to the changes in 'get' return type
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
Jan Rybar
2a7d3f7d70 - Fixing incorrect memory usage assessment due to skipping vmflags parsing
- Resolves Red Hat Bugzilla #1262864, affecting upstream
2016-06-17 21:58:39 +10:00
Jim Warner
93ae9ac718 top: some miscellaneous tweaks to code and/or comments
This patch contains the following collection of stuff:

. an identifier Pids_read is now Pids_reap like <stat>
. eliminate redundant param from the <stat> VAL macros
. eliminate the unneeded tailored <stat> SUM_VAL macro
. corrected comment spelling for 'gouped' to 'grouped'

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 21:44:29 +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
5ce94f9bb0 top: improved that #define PRETENDNOCAP implementation
This development (only) define can be used to turn top
into a simple text program, disabling termcap effects.
But input (at screen bottom) suffers from a line wrap.

So, this commit just makes the input prompt processing
a little more effective by adding one leading newline.

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
61647f1b95 top: swat nasty obscure bug associated with numa nodes
When experimenting with two macro constants for stat.c
(#define STACKS_INCR & #define NEWOLD_INCR), a bug was
revealed in top, only surfacing if both were set to 1.

At those settings an absolute minimum number of stacks
would be allocated for CPUs & numa NODEs. This in turn
led top to overrun the lessor number of nodes since he
used the cpu index when accessing those numa stack(s).

What he should have been accessing was the cpu stacks.

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
e80b48ce58 slabtop: correct the sort behavior for that NAME field
When our <SLABINFO> was recently re-designed, the sort
callback functions became table driven, whereas before
a single callback used switch/case constructs based on
an 'item'. Thus, sorting was made a tad more efficient
but, it introduced a buglet into that slabtop program.

The root cause of this bug was the fact that the field
NAME required a low-to-high sort and all other slabtop
fields used high-to-low. Fortunately, along with those
<SLABINFO> table driven sort changes, that i/f offered
users the option of either low-to-high or high-to-low.

So this patch just exploits that choice. And, it means
that such responsibilities are now properly located in
calling code, not in what's a general purpose library.

Reference(s):
. most recent lib sort enhancement & breakage
commit 5d5a52a380

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-11 11:50:37 +10:00
Jim Warner
b09014a7b6 top: share the rcfile between master & newlib branches
Since the decision was made to also add that Linux-4.5
support (was only in this newlib branch) to our master
branch, a tweak to newlib's top is necessary. In order
to share the rcfile between them, any fields unique to
a branch must appear last in it's list of enumerators.

And the troublesome field in question above is CGNAME.

It doesn't matter if a unique field is on or off, only
that it, as a higher enum/char, appear after all other
shared fields. Otherwise one risks the 'corrupt' error
message from the top without that field or the display
of the wrong column in the top with that unique field.

[ and strictly speaking, the changes under top_nls.c ]
[ were technically not really necessary. however, we ]
[ choose to maintain strict ordering via enum value. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
5f2570c384 misc: adapt pgms to pids_sort_order change, <PIDS> api
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +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
8a7fcc02d1 misc: adapted other pgms to changes in, <SLABINFO> api
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
acb83a2b74 vmstat: adapted to the interface changes, <VMSTAT> api
This commit just eliminates all the procps_vmstat_read
calls since the interface now handles that requirement
as needed when the 'get' and 'select' guys are called.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-07 21:04:43 +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
fa0d983a7d vmstat: fix 1st time enumerators so zeros aren't shown
Some DELTA versions were used where raw totals needed.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-07 21:04:43 +10:00
Jim Warner
0196a4e350 top: just miscellaneous tweaks to code and/or comments
This patch represents the following minor adjustments:

. the official PROCPS_MEMINFO_VAL macro has become the
basis for our own abbreviated MEM_VAL derivative macro
just like was done for all the other newlib interfaces

. it felt like time to change those forest_?? function
names while maintaining their special relationships to
one another (alphabetic, with each 1 longer than prev)

. and some whitespace was altered and some lines added

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