Upon reflection, at the point where the 'priming read'
was introduced, any possibility of history distortions
was also eliminated. This was true because all of the
'old' (zeroed) data will have been replaced with 'new'
data whenever a user finally calls get, select & reap.
Thus, any DELTA values will automatically reflect that
interval between 'new' and subsequent retrieval calls.
[ diskstats didn't actually employ a 1st time switch ]
[ like the others so we have changed a comment only. ]
[ but that module will retain something similar used ]
[ inside node_update whenever a new node is created. ]
Reference(s):
. priming read added to slabinfo
commit 5d5a52a380
. priming read added to diskstats
commit ecd64f4445
. priming read added to meminfo, stat, vmstat
commit 1a2b62c779
Signed-off-by: Jim Warner <james.warner@comcast.net>
In each module employing a priming read at 'new' time,
should that read fail, a call to 'unref' will be made.
However, there is a hidden dependency that these calls
must never occur before the context 'refcount' was set
due to the way an 'unref' conditional was constructed.
So this commit just ensures that 'unref' will function
as expected, even if called with a 'refcount' of zero.
Signed-off-by: Jim Warner <james.warner@comcast.net>
A priming read at 'new' time in that <slabinfo> module
was important so that permission problems are detected
early. Plus, it also had the potential of making delta
values valid when 'get' or 'select' were first called.
It is for that latter reason that such a read was also
incorporated in the <diskstats> module 'new' function.
No other module, however, employed such priming reads.
This patch just brings those potential benefits to all
of our other newlib modules with the exception of that
<pids> guy. That module is, of necessity, sufficiently
different from those others to justify such exclusion.
Not only are there precious few DELTA enums in <pids>,
but the costs of a priming read would be much greater.
[ otherwise, these newly added priming reads have no ]
[ measurable negative impact on performance/timings. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will begin some refinements associated with
gprof. Initially, functions names have been changed to
help in identifying potential bottlenecks. This effort
also included the obscure set, free and sort routines.
Plus the following additional modifications were made:
. the stacks_alloc prologue was generalized plus added
to a couple of modules where it had not yet propagated
. a couple of the '// end ...' comments were corrected
. some functions have been formally tagged as 'inline'
Signed-off-by: Jim Warner <james.warner@comcast.net>
The immediately prior commit demonstrated how our APIs
might be expanded in at some point in the future while
maintaining binary compatibility in previous programs.
However, since we've yet to release the 1st version of
our new library, there's no need to violate alphabetic
ordering just yet. So, this patch restores that order.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the 4.8 kernel, 2 new fields will be added to the
meminfo pseudo file. This commit, soon to be replaced,
is intended as an example of how such changes might be
incorporated plus still maintain binary compatibility.
This actually goes further than is strictly necessary,
by retaining meminfo_item ordering for 'set' functions
and the creation of hash table entries. However, there
is only 1 true requirement, that of Item_table entries
which must always agree exactly with item enumerators.
All of the other changes could be done alphabetically.
Ok, so what happens when an old program encounters the
new expanded meminfo items? Well, if it was thoroughly
tested against an old library, it won't even see those
new fields. On the other hand, if it somehow exceeds a
previous MEMINFO_logical_end, then it will just get an
extra result structure or two, with no real harm done.
[ this patch is being replace by the very next patch ]
[ so that our iniitial newlib release can maintain a ]
[ strict alphabetic ordering in all areas initially! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Rather than return a 0 result for all VAL type errors,
return what would have been without validation active.
This will enable a program like pgrep to still print a
result even though it used some incorrect type member.
With this commit, our VAL macro validations logic will
behave in exactly the same way as the GET validations.
While warning messages may be issued, except for a bad
enumerator, values will always be returned to callers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
One ought not to assume that random memory access will
always succeed or, when it does, that an obviously bad
item enumerator will always be found at that location.
Thus, this patch corrects some really poor assumptions
associated with the 'xtra_procps_debug.h' header file.
[ and it does so in somewhat contorted ways so as to ]
[ avoid several darn gcc -Wnonnull warning messages! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When users call the native 'get' functions they have a
responsibility to check that the result struct address
was indeed returned. But when using those 'GET' macros
there was no protection for possible NULL dereference.
So this patch will add some protection for a potential
failure of an underlying 'get' function. And should it
occur then those 'GET' macros will just return a zero.
Plus, we'll also mirror that behavior in the debugging
header should the XTRA_PROCPS_DEBUG #define be active.
And, we might as well add a warning when invalid items
are passed to 'GET' macros, just like we do for 'VAL'.
[ lastly, we added the missing opening parens/braces ]
[ to 2 'GET' macros in that xtra-procps-debug.h file ]
[ which went unnoticed until the qa folks caught up. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
During development, we now have a means for validating
that a type referenced in application code matches the
actual type set by the library. The new feature can be
activated through either of the following two methods:
1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms)
2) an #include <proc/xtra-procps-debug.h> (single pgm)
[ in the future, one could add a formal configure.ac ]
[ provision. but for now a manual approach is safer. ]
Lastly, for any module which provides a sort function,
the handling for both 'noop' & 'extra' enumerators was
made consistent. Now, 'noop' is not sorted and 'extra'
will be sorted as that module's widest supported type.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch attempts to standardize the naming of those
most important (declared not defined) context structs.
The present practice represents a hodge podge of names
only some of which reflect the source /proc file name.
And 2 of those file names embed a literal 'info' which
is likely the origin of that required parm identifier.
Now we'll append a universal '_info' to such structure
names, while including the names of those /proc pseudo
files where possible. In any case, that context struct
will *always* begin with the actual module/header file
name. And only the following two sound a little weird!
---------> 'meminfo_info' + 'slabinfo_info' <---------
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
Not sure how this one has gone unnoticed until now but
with valgrind's help it's going bye-bye lickety-split.
Reference(s):
==26533== Conditional jump or move depends on uninitialised value(s)
==26533== at 0x4E4082B: procps_meminfo_stack_fill (meminfo.c:408)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just corrects the oversight wherein 'item'
was being employed when 'these' was actually intended.
Also, it trades some 'item' use for a more descriptive
input parameter which henceforth is known as a 'dest'.
And, there was one leftover 'next' pointer eliminated.
Finally, some logic was made a tad less dependent upon
enumerator names and a few comments were also updated.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the new perspective on potential uses of a 'noop'
enumerator (or whatever we decide to call it) there is
no longer a need to provide for any extra 'user' space
in the stack header structures used by slab & meminfo.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to that text shown below the line which is
common to several commit messages, this patch contains
the following additional change without an API impact:
. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.
------------------------------------------------------
. The former 'chains' have now become 'stacks' without
the 'next' pointer in each result struct. The pointers
initially seemed to offer some flexibility with memory
allocations and benefits for the library access logic.
However, user access was always via displacement and a
a statically allocated chain was cumbersome to define.
. An enumerator ending in '_noop' will no longer serve
as a fencepost delimiter. Rather, it has become a much
more important and flexible user oriented tool. Adding
one or more such 'items' in any items list passed into
the library becomes the means of extending the 'stack'
to also include user (not just library) data. Any such
data is guaranteed to never be altered by the library.
. Anticipating PID support, where many different types
must be represented in a result structure, we'll adopt
a common naming standard. And, while not every results
structure currently needs to reflect disparate types a
union will be employed so the same dot qualifier ('.')
can be used consistently when accessing all such data.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With a little help from smatch, this commit eliminates
some inappropriate code. Also some programmer comments
were (barely) improved (i hope) in some small measure.
Reference(s):
smatch: 406 procps_meminfo_chain_fill() warn: variable dereferenced before check 'chain' (see line 403)
Signed-off-by: Jim Warner <james.warner@comcast.net>
An earlier approach to meminfo chaining, referenced in
the patch shown below, represents the first baby steps
toward the goal of some generalized approach with PIDs
processing. However, statically allocating a chain for
each task or thread is totally impractical. And, while
a single chain could serve all PIDs, that would mean a
separate call to our library for each running process.
This commit is intended as the next evolutionary step,
dynamically allocating some 'result' chains to contain
as many or as few 'items' as a caller wishes. In other
words, holding only those 'items' of current interest.
This is the kind of service useful for both top and ps
programs if we finally get around to /proc/<PID> data.
Reference(s):
commit c3fd7473c5
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier attempt at protecting these functions from
already freed memory worked just fine until the memory
was, in fact, reused by the OS. At that point, the ref
count would most likely fail an existing a test for 0.
So this commit will take control of the 'info' pointer
and force it to NULL when a reference count reaches 0.
Plus, since it makes little sense returning an address
that a caller already has, henceforth we will return a
reference count out of the 'ref' and 'unref functions.
Reference(s):
commit 74beff80ff
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since we are not using a higher level standard C fopen
all of the read requests were made signal sensitive as
that can result in a 'temporarily' failed i/o request.
Also, protection against some user calling the 'unref'
function on already free memory has been incorporated.
This will protect us from some nasty 'Abort' surprise.
Signed-off-by: Jim Warner <james.warner@comcast.net>
If a caller chooses to reduce the overhead of repeated
function calls, this commit provides for acquiring all
the desired information in just a single library call.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch fills in some missing fields which have top
dependencies. Additionally, I've tried to mirror those
calculations Jaromir added for release 3.3.10. The one
calculation that remains missing is 'available' memory
for some kernels. For this API, we'll use a fall-back.
Lastly the lxc safeguards which were recently added to
the old procps library were incorporated here as well.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch mostly just eliminates darn tab characters.
Plus the library function declarations and definitions
have been standardized. Most visibly, the input params
now have all been indented on their own separate line.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Created new set of functions for meminfo related calls. Liked the
format of that better so changed vmstat around so the look similar.
Missed the makefile change for uptime so added it in now.
