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>
In addition to that text shown below the line which is
common to several commit messages, this patch contains
several minor changes with lessor impact upon the API:
. A call to procps_stat_read_jiffs() has been added to
those jiffs functions carrying the 'fill' nomenclature
to parallel like functions in some of our other files.
. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.
. Standard copyright boilerplate was added in .c file.
. The header file follows the conventions of indenting
(by 4 spaces) those parameters too lengthy for 1 line.
------------------------------------------------------
. 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>
The new library meminfo & vmstat modules use structure
names for their context which exactly mirror the names
of the very /proc/ files whose particulars they yield.
The one exception to this rule was the readstat module
whose struct was named statinfo yet the file was stat.
This commit simply renames that structure (only) so as
to hopefully establish such a naming convention as our
standard going forward. And, it's makes good symmetry.
[ this module's name itself is just perfect as it is ]
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>
There was not a way I could see to support top's needs
for cpu information with the new 'chained' provisions.
The sheer quantity of such data plus the unpredictable
number of potential processors suggested a totally new
approach was warranted while keeping internals opaque.
So this patch introduces two new structures solely for
use by potential callers (as seen in the API). They're
responsible for providing them to the library which is
then responsible for filling them with requested data.
The top program will continue to provide numa support,
without involving the library in any of those details.
[ not to mention all the 'dl' and 'stderr' numa crap ]
With this transfer of the cpu tics duty to our library
the provision associated with the CPU_ZEROTICS #define
could not initially be migrated. The commit referenced
below suggests it may have lost its importance. In any
case such logic may yet be incorporated in the future.
But for now, that #define has been completely removed.
Reference(s):
commit ee3ed4b45e
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 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.
The following names were changed to more closely match
meminfo.c or provide a certain symmetry. Unfortunately
that also impacted some other pgms which were updated.
. 'procps_stat_get' evolved into 'procps_stat_get_sys'
. 'procps_stat_info' is now known as 'procps_statinfo'
[and just a little trailing whitespace was eliminated]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Use the standard libc declarations.
For protecting the headers for C++ procps used to have its
own defines, this change makes them use the standard libc ones.
getstat() -> procps_stat_*
vminfo() -> procps_vmstat_*
These two components of the library now use the newer version of
the API with less exposed global variables. The old methods are
there for now.
Signed-off-by: Craig Small <csmall@enc.com.au>
