emo
/
procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
procps/library/pids.c

1681 lines
66 KiB
C
Raw Permalink Normal View History

library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
/*
misc: Update the copyrights of files The copyrights of the source files were all out of date and were not the same format. This has been corrected. The source of the authors was examining the git log for each file. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 15:39:48 +05:30
* pids.c - process related definitions for libproc2
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
*
misc: Update the copyrights of files The copyrights of the source files were all out of date and were not the same format. This has been corrected. The source of the authors was examining the git log for each file. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 15:39:48 +05:30
* Copyright © 2015-2023 Jim Warner <james.warner@comcast.net>
* Copyright © 2015-2023 Craig Small <csmall@dropbear.xyz>
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
//efine _GNU_SOURCE // for qsort_r
#include <ctype.h>
#include <errno.h>
#include <fcntl.h>
#include <limits.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
build-sys: Relocate library to library/ All the dependent programs needed to have their includes moved too Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 14:32:44 +05:30
#include "devname.h"
#include "misc.h"
#include "numa.h"
#include "readproc.h"
#include "wchan.h"
#include "procps-private.h"
#include "pids.h"
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: strictly cosmetic, absolutely no code changes This commit just contains some tweaks to comments plus a few adjustments to whitespace for alignment purposes and a normalization of the header inclusion #define's. [ plus a spelling error in one header file was fixed ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-28 20:40:10 +05:30
//#define UNREF_RPTHASH // report hash details at uref() time
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: strictly cosmetic, absolutely no code changes This commit just contains some tweaks to comments plus a few adjustments to whitespace for alignment purposes and a normalization of the header inclusion #define's. [ plus a spelling error in one header file was fixed ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-28 20:40:10 +05:30
#define FILL_ID_MAX 255 // upper limit with select of pid/uid
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
#define STACKS_INIT 1024 // amount of initial stack allocation
#define STACKS_GROW 128 // amount reap stack allocations grow
#define NEWOLD_INIT 1024 // amount for initial hist allocation
#define NEWOLD_GROW 128 // amt by which hist allocations grow
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
/* ------------------------------------------------------------------------- +
this provision can be used to ensure that our Item_table was synchronized |
with those enumerators found in the associated header file. It's intended |
to only be used locally (& temporarily) at some point prior to a release! | */
// #define ITEMTABLE_DEBUG //----------------------------------------------- |
// ------------------------------------------------------------------------- +
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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-01 10:30:00 +05:30
struct stacks_extent {
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int ext_numstacks;
struct stacks_extent *next;
library: normalize stacks_extent struct layout, <PIDS> This patch just rearranges 1 item in the stacks_extent struct to make it equivalent to all the other modules. Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-09-14 10:30:00 +05:30
struct pids_stack **stacks;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
};
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
struct fetch_support {
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-14 10:30:00 +05:30
struct pids_stack **anchor; // reap/select consolidated extents
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
int n_alloc; // number of above pointers allocated
int n_inuse; // number of above pointers occupied
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-06 10:30:00 +05:30
int n_alloc_save; // last known results.stacks allocation
struct pids_fetch results; // counts + stacks for return to caller
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-23 10:30:00 +05:30
struct pids_counts counts; // actual counts pointed to by 'results'
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
};
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info {
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int refcount;
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 e7585992d9c0743246247b3d6ee0041942fe07d5
2016-04-25 10:30:00 +05:30
int maxitems; // includes 'logical_end' delimiter
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int curitems; // includes 'logical_end' delimiter
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 e7585992d9c0743246247b3d6ee0041942fe07d5
2016-04-25 10:30:00 +05:30
enum pids_item *items; // includes 'logical_end' delimiter
library: enable an 'invariant' stack for that pids API After peeking at possible conversion of the ps program it appeared that we may ultimately need the concept of a 'static' pids_stack in suport of look_up_our_self(). In other words, one not impacted by procps_pids_reset. This patch simply sets the stage for that possibility. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-10 10:30:00 +05:30
struct stacks_extent *extents; // anchor for all resettable extents
library: refactor flawed function fatal_proc_unmounted This commit addresses a potentially disastrous flaw in that fatal_proc_unmounted() function wherein requested item(s) might not have been returned to the caller yet were specified at the time of a 'new' or 'reset' call. The root cause, uncovered by Craig, was due to the old library look_up_our_self() support function which only would populate a proc_t with limited 'stat' file data. This routine will now act the same as all other <pids> functions which return a stack or stacks. Whatever was specified with a 'new' or 'reset' will be returned, if the passed 'return_self' parameter is other than zero. [ as is so often the case, when flawed code is fixed ] [ former complexity can be reduced as a side benefit ] Reference(s): https://www.freelists.org/post/procps/issue-245-plus-one,2 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
struct stacks_extent *otherexts; // anchor for invariant extents // <=== currently unused
struct fetch_support fetch; // support for procps_pids_reap, select, fatal
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int history_yes; // need historical data
struct history_info *hist; // pointer to historical support data
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
proc_t*(*read_something)(PROCTAB*, proc_t*); // readproc/readeither via which
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
unsigned pgs2k_shift; // to convert some proc vaules
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-06 10:30:00 +05:30
unsigned oldflags; // the old library PROC_FILL flagss
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-18 10:30:00 +05:30
PROCTAB *fetch_PT; // oldlib interface for 'select' & 'reap'
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
unsigned long hertz; // for the 'TIME' & 'UTILIZATION' calculations
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
unsigned long long boot_tics; // for TIME_ELAPSED & 'UTILIZATION' calculations
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-18 10:30:00 +05:30
PROCTAB *get_PT; // oldlib interface for active 'get'
library: tweak support for get/select/reap, <PIDS> api When the <pids> api was refactored in the commit shown below, one objective was enabling the simultaneous use of 'get' & 'select/reap' functions. Unlike other 'get' functions, this <pids> 'get' acts as an iterator where successive calls will return successive tasks/threads. However, that goal wasn't quite met since a stack used by 'get' was commingled with the 'select/reap' stacks. Such commingling supported the 'reset' function, again a provision which was unique to this <pids> interface. Unfortunately, some poor assumptions in 'stacks_fetch' produced a SEGV whenever 'reap/select' followed 'get'. Thus, this patch addresses those issues and guarantees such commingled stacks (extents) will be accommodated. Reference(s): . standardize portions of interface, <PIDS> api commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-02 10:30:00 +05:30
struct stacks_extent *get_ext; // for active 'get' (also within 'extents')
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-14 10:30:00 +05:30
enum pids_fetch_type get_type; // last known type of 'get' request
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
int seterr; // an ENOMEM encountered during assign
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
proc_t get_proc; // the proc_t used by procps_pids_get
proc_t fetch_proc; // the proc_t used by pids_stacks_fetch
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
};
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
// ___ Free Storage Support |||||||||||||||||||||||||||||||||||||||||||||||||||
#define freNAME(t) free_pids_ ## t
static void freNAME(str) (struct pids_result *R) {
if (R->result.str) free(R->result.str);
}
static void freNAME(strv) (struct pids_result *R) {
if (R->result.strv && *R->result.strv) free(*R->result.strv);
}
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
#define setNAME(e) set_pids_ ## e
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define setDECL(e) static void setNAME(e) \
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
(struct pids_info *I, struct pids_result *R, proc_t *P)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
/* convert pages to kib */
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define CVT_set(e,t,x) setDECL(e) { \
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-15 10:30:00 +05:30
R->result. t = (long)(P-> x) << I -> pgs2k_shift; }
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
/* strdup of a static char array */
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define DUP_set(e,x) setDECL(e) { \
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
freNAME(str)(R); \
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (!(R->result.str = strdup(P-> x))) I->seterr = 1; }
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
/* regular assignment copy */
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define REG_set(e,t,x) setDECL(e) { \
(void)I; R->result. t = P-> x; }
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
/* take ownership of a normal single string if possible, else return
some sort of hint that they duplicated this char * item ... */
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define STR_set(e,x) setDECL(e) { \
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
freNAME(str)(R); \
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (NULL != P-> x) { R->result.str = P-> x; P-> x = NULL; } \
else { R->result.str = strdup("[ duplicate " STRINGIFY(e) " ]"); \
if (!R->result.str) I->seterr = 1; } }
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
/* take ownership of true vectorized strings if possible, else return
some sort of hint that they duplicated this char ** item ... */
#define VEC_set(e,x) setDECL(e) { \
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
freNAME(strv)(R); \
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (NULL != P-> x) { R->result.strv = P-> x; P-> x = NULL; } \
library: correct 'vectorized' string logic, <PIDS> api The commit referenced below addressed (some) anomalies surrounding 'strv' pointers. However, there remained a couple quirks involving a potential NULL return value. Any NULL values returned from the old library readproc guys would cause no real harm for newlib. But they did produce the misleading "[ duplicate ENUM_ID ]" result. The following all represent potential NULL results and suggest shortcomings in testing of that earlier patch. . kernel threads do not have cgroup, cmdline & environ . even if present environ could require root to access So, this patch reverts a portion of the earlier commit and ensures when some vectored string is not available a traditional dash ('-') is the 'strv' returned value. [ and we'll also correct one typo in the header file ] Reference(s): . eliminated a final potential NULL, <PIDS> api commit 09503dc59792ab0147de604ab48342b8508f2d7b Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-04-25 10:30:00 +05:30
else { R->result.strv = vectorize_this_str("[ duplicate " STRINGIFY(e) " ]"); \
library: correct one reference typo in that <PIDS> api This patch will just correct an oops introduced in the commit shown below. Thank goodness both 'str' & 'strv' occupy the same storage location in that result union. Reference(s): . standardize 'errno' management commit 06be33b43e5ff3f2658e77ef79441ac2e970cfd7 Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-09-26 10:30:00 +05:30
if (!R->result.strv) I->seterr = 1; } }
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
setDECL(noop) { (void)I; (void)R; (void)P; }
setDECL(extra) { (void)I; (void)P; R->result.ull_int = 0; }
library: fix a few source/origin notations, <pids> api After removing brackets from those 'derived' notations I was surprised to discover that several origin/source comments were wrong. So this patch fixes those errors. [ along the way a couple enumerators were renamed to ] [ better (i hope) reflect what they're representing. ] [ that, in turn, also required a little rearranging. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-03-09 11:30:00 +05:30
REG_set(ADDR_CODE_END, ul_int, end_code)
REG_set(ADDR_CODE_START, ul_int, start_code)
REG_set(ADDR_CURR_EIP, ul_int, kstk_eip)
REG_set(ADDR_CURR_ESP, ul_int, kstk_esp)
REG_set(ADDR_STACK_START, ul_int, start_stack)
library: add provision for displaying autogroup values In the link referenced below there's an explanation of the linux autogroup feature which has been around ever since linux-2.6.38. With that explanation there's also surprising (maybe shocking) revelations about the nice and renice commands if CONFIG_SCHED_AUTOGROUP was set. When autogroups are active, such programs are rendered mostly useless because the nice value will only affect scheduling priority relative to other processes in the same autogroup. In order to accomplish what we thought of as renice, that nice value in /proc/<pid>/autogroup must be changed. Altering any single member of a group will also affect every other member of that autogroup. So, this commit will set the stage for users of newlib to display autogroup identifiers plus their associated nice values (now that their importance is understood). Reference(s): https://github.com/nlburgin/reallynice Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-05 10:30:00 +05:30
REG_set(AUTOGRP_ID, s_int, autogrp_id)
REG_set(AUTOGRP_NICE, s_int, autogrp_nice)
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
STR_set(CGNAME, cgname)
STR_set(CGROUP, cgroup)
VEC_set(CGROUP_V, cgroup_v)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
STR_set(CMD, cmd)
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
STR_set(CMDLINE, cmdline)
VEC_set(CMDLINE_V, cmdline_v)
STR_set(ENVIRON, environ)
VEC_set(ENVIRON_V, environ_v)
library: expanded to provide for the 'executable path' This patch is the first of three implementing a newlib branch version of that Jan Rybar master merge request. With this series we'll ultimately extend 'EXE' support to both ps and top (plus, everyone else who wants it). Reference(s): . master branch merge request https://gitlab.com/procps-ng/procps/merge_requests/66 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-22 10:30:00 +05:30
STR_set(EXE, exe)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(EXIT_SIGNAL, s_int, exit_signal)
REG_set(FLAGS, ul_int, flags)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(FLT_MAJ, ul_int, maj_flt)
library: refactored some header file items and origins This commit is intended as a refinement of the patches mentioned below, where origins/sources of newlib items were added to the header files for user documentation. However, if those additions are to be truly effective, along with kernel documentation (where available), the following prerequisites must also have been satisfied: . our identifiers closely align with linux field names . our derived items are documented or self-documenting Satisfying those prerequisites prompted this patch and for these changes, kernel sources were emphasized over available documentation (shame on me, it should always have been so). And, while some 'new' fields were found to be conditional, they were included unconditionally. These changes appear more extensive than they actually need be since I have attempted to enforce some spacing conventions. So, I've summarize the significant things in the sections that follow. For a proper perspective, use: 'git diff --ignore-space-change' (good as alias). ___________________________________________ <PIDS> api This api is unique in that there exists many different file/directory origins subordinate to /proc/<pid>. And our item identifiers are sometimes coerced so as to be able to group related or similar enumerators together. So, users needed more help relating our identifiers to an actual documented field. Thus, we will now also add the field names as with 'stat: delayacct_blkio_ticks'. Each item ending with a '_C' now consistently includes both the parent's count/time plus waited for children. That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT since its original name is an implementation artifact. ___________________________________________ <STAT> api The only api change was to correct a typo ('dervied'). _________________________________________ <VMSTAT> api Even ignoring white space, this interface received the largest number of changes. Mostly, this was because of deficiencies in the proc(5) documentation. Recall that this documentation already sorely lacks any substance. Usually, just kernel releases are noted, not contents. When compared to kernel source, that proc(5) contained many non-existent fields and also omitted many others. ________________________________________ <MEMINFO> api Sadly, with this api many of the changes were simply a correction of some earlier 'human error' where several fields where hashed then tracked but never represented with an item enumerator in this meminfo.h header file. _______________________________________ <SLABINFO> api The 'SLABS' (summary) & 'SLABNODE' items were reversed since the former are derived from the separate caches. More significantly, those 'SLABNODE' guys were renamed to 'SLAB' since they concern individual caches and the concept of 'nodes' is really an implementation detail. Also, several enumerators were changed to more closely agree with official slabinfo(5) documentation referred to in what we're treating as a base document: proc(5). Lastly, while those 'SLABS' items are solely a product of our library and not represented in slabinfo(5), the names attempt to parallel those found as 'SLAB' items. ______________________________________ <DISKSTATS> api One enumeration identifier was changed so as to better reflect its relationship to that actual documentation: 'Documentation/iostats.txt', as referenced in proc(5). Reference(s): . 12/2018, item origins added (and commit msg history) commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 . 01/2019, <stat> origins tweaked commit 201e816b26ddaccc923ec40977c92037cdd0c34e Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
setDECL(FLT_MAJ_C) { (void)I; R->result.ul_int = P->maj_flt + P->cmaj_flt; }
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(FLT_MAJ_DELTA, s_int, maj_delta)
REG_set(FLT_MIN, ul_int, min_flt)
library: refactored some header file items and origins This commit is intended as a refinement of the patches mentioned below, where origins/sources of newlib items were added to the header files for user documentation. However, if those additions are to be truly effective, along with kernel documentation (where available), the following prerequisites must also have been satisfied: . our identifiers closely align with linux field names . our derived items are documented or self-documenting Satisfying those prerequisites prompted this patch and for these changes, kernel sources were emphasized over available documentation (shame on me, it should always have been so). And, while some 'new' fields were found to be conditional, they were included unconditionally. These changes appear more extensive than they actually need be since I have attempted to enforce some spacing conventions. So, I've summarize the significant things in the sections that follow. For a proper perspective, use: 'git diff --ignore-space-change' (good as alias). ___________________________________________ <PIDS> api This api is unique in that there exists many different file/directory origins subordinate to /proc/<pid>. And our item identifiers are sometimes coerced so as to be able to group related or similar enumerators together. So, users needed more help relating our identifiers to an actual documented field. Thus, we will now also add the field names as with 'stat: delayacct_blkio_ticks'. Each item ending with a '_C' now consistently includes both the parent's count/time plus waited for children. That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT since its original name is an implementation artifact. ___________________________________________ <STAT> api The only api change was to correct a typo ('dervied'). _________________________________________ <VMSTAT> api Even ignoring white space, this interface received the largest number of changes. Mostly, this was because of deficiencies in the proc(5) documentation. Recall that this documentation already sorely lacks any substance. Usually, just kernel releases are noted, not contents. When compared to kernel source, that proc(5) contained many non-existent fields and also omitted many others. ________________________________________ <MEMINFO> api Sadly, with this api many of the changes were simply a correction of some earlier 'human error' where several fields where hashed then tracked but never represented with an item enumerator in this meminfo.h header file. _______________________________________ <SLABINFO> api The 'SLABS' (summary) & 'SLABNODE' items were reversed since the former are derived from the separate caches. More significantly, those 'SLABNODE' guys were renamed to 'SLAB' since they concern individual caches and the concept of 'nodes' is really an implementation detail. Also, several enumerators were changed to more closely agree with official slabinfo(5) documentation referred to in what we're treating as a base document: proc(5). Lastly, while those 'SLABS' items are solely a product of our library and not represented in slabinfo(5), the names attempt to parallel those found as 'SLAB' items. ______________________________________ <DISKSTATS> api One enumeration identifier was changed so as to better reflect its relationship to that actual documentation: 'Documentation/iostats.txt', as referenced in proc(5). Reference(s): . 12/2018, item origins added (and commit msg history) commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 . 01/2019, <stat> origins tweaked commit 201e816b26ddaccc923ec40977c92037cdd0c34e Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
setDECL(FLT_MIN_C) { (void)I; R->result.ul_int = P->min_flt + P->cmin_flt; }
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(FLT_MIN_DELTA, s_int, min_delta)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(ID_EGID, u_int, egid)
REG_set(ID_EGROUP, str, egroup)
REG_set(ID_EUID, u_int, euid)
REG_set(ID_EUSER, str, euser)
REG_set(ID_FGID, u_int, fgid)
REG_set(ID_FGROUP, str, fgroup)
REG_set(ID_FUID, u_int, fuid)
REG_set(ID_FUSER, str, fuser)
library: expanded to provide for the UID used at login This patch represents the newlib implementation of Jan Rybar's merge request referenced below. It essentially moves that code out of the ps program and into our new library where it's available via the <pids> interface. Reference(s): https://gitlab.com/procps-ng/procps/merge_requests/57 https://bugzilla.redhat.com/show_bug.cgi?id=1518986 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-11 12:41:11 +05:30
REG_set(ID_LOGIN, s_int, luid)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(ID_PGRP, s_int, pgrp)
REG_set(ID_PID, s_int, tid)
REG_set(ID_PPID, s_int, ppid)
REG_set(ID_RGID, u_int, rgid)
REG_set(ID_RGROUP, str, rgroup)
REG_set(ID_RUID, u_int, ruid)
REG_set(ID_RUSER, str, ruser)
REG_set(ID_SESSION, s_int, session)
REG_set(ID_SGID, u_int, sgid)
REG_set(ID_SGROUP, str, sgroup)
REG_set(ID_SUID, u_int, suid)
REG_set(ID_SUSER, str, suser)
REG_set(ID_TGID, s_int, tgid)
library: insert 'PIDS_ID_TID' for symmetry, <PIDS> api This change is being made in anticipation of adding the source origin of each item to the <pids.h> header file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-12-01 11:30:00 +05:30
REG_set(ID_TID, s_int, tid)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(ID_TPGID, s_int, tpgid)
library: adding IO accounting This is a modification of MR !122 by @renit1609 to fit the new library. Problem statement: The procps library has no PROC_FILLIO flag to fetch the proc field "/proc/[pid]/io" data process-wise. IO Accounting is not included as part of procps. Requirement: We have a requirement to fetch process wise IO utilization which can be used for monitoring. When looking through the procps library, I see that IO Accounting (/proc/[pid]/io) is not being included as part of procps. There is no such flag like PROC_FILLIO being included in readproc.h . Solution: While looking at the implementation done for other proc fields, I used the spare bits in app code. I renamed PROC_SPARE_1 as PROC_FILLIO, the spare bit from PROC_SPARE_* and used it for fetching /proc/[pid]/io data as part of the procps library similar to other fields. I moved the PROC_SPARE_* bits each by 1 bit to retain the spare bits. Meanwhile added the IO fields in proc_t structure. References: procps-ng/procps!122 procps-ng/procps#184
2021-04-24 18:08:48 +05:30
REG_set(IO_READ_BYTES, ul_int, read_bytes)
REG_set(IO_READ_CHARS, ul_int, rchar)
REG_set(IO_READ_OPS, ul_int, syscr)
REG_set(IO_WRITE_BYTES, ul_int, write_bytes)
REG_set(IO_WRITE_CBYTES, ul_int, cancelled_write_bytes)
REG_set(IO_WRITE_CHARS, ul_int, wchar)
REG_set(IO_WRITE_OPS, ul_int, syscw)
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-01 10:30:00 +05:30
REG_set(LXCNAME, str, lxcname)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
CVT_set(MEM_CODE, ul_int, trs)
REG_set(MEM_CODE_PGS, ul_int, trs)
CVT_set(MEM_DATA, ul_int, drs)
REG_set(MEM_DATA_PGS, ul_int, drs)
CVT_set(MEM_RES, ul_int, resident)
REG_set(MEM_RES_PGS, ul_int, resident)
CVT_set(MEM_SHR, ul_int, share)
REG_set(MEM_SHR_PGS, ul_int, share)
CVT_set(MEM_VIRT, ul_int, size)
REG_set(MEM_VIRT_PGS, ul_int, size)
REG_set(NICE, s_int, nice)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(NLWP, s_int, nlwp)
library: bring namespaces up to date with linux kernel Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-05-05 10:30:00 +05:30
REG_set(NS_CGROUP, ul_int, ns.ns[0])
REG_set(NS_IPC, ul_int, ns.ns[1])
REG_set(NS_MNT, ul_int, ns.ns[2])
REG_set(NS_NET, ul_int, ns.ns[3])
REG_set(NS_PID, ul_int, ns.ns[4])
REG_set(NS_TIME, ul_int, ns.ns[5])
REG_set(NS_USER, ul_int, ns.ns[6])
REG_set(NS_UTS, ul_int, ns.ns[7])
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(OOM_ADJ, s_int, oom_adj)
REG_set(OOM_SCORE, s_int, oom_score)
REG_set(PRIORITY, s_int, priority)
library: refactored some header file items and origins This commit is intended as a refinement of the patches mentioned below, where origins/sources of newlib items were added to the header files for user documentation. However, if those additions are to be truly effective, along with kernel documentation (where available), the following prerequisites must also have been satisfied: . our identifiers closely align with linux field names . our derived items are documented or self-documenting Satisfying those prerequisites prompted this patch and for these changes, kernel sources were emphasized over available documentation (shame on me, it should always have been so). And, while some 'new' fields were found to be conditional, they were included unconditionally. These changes appear more extensive than they actually need be since I have attempted to enforce some spacing conventions. So, I've summarize the significant things in the sections that follow. For a proper perspective, use: 'git diff --ignore-space-change' (good as alias). ___________________________________________ <PIDS> api This api is unique in that there exists many different file/directory origins subordinate to /proc/<pid>. And our item identifiers are sometimes coerced so as to be able to group related or similar enumerators together. So, users needed more help relating our identifiers to an actual documented field. Thus, we will now also add the field names as with 'stat: delayacct_blkio_ticks'. Each item ending with a '_C' now consistently includes both the parent's count/time plus waited for children. That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT since its original name is an implementation artifact. ___________________________________________ <STAT> api The only api change was to correct a typo ('dervied'). _________________________________________ <VMSTAT> api Even ignoring white space, this interface received the largest number of changes. Mostly, this was because of deficiencies in the proc(5) documentation. Recall that this documentation already sorely lacks any substance. Usually, just kernel releases are noted, not contents. When compared to kernel source, that proc(5) contained many non-existent fields and also omitted many others. ________________________________________ <MEMINFO> api Sadly, with this api many of the changes were simply a correction of some earlier 'human error' where several fields where hashed then tracked but never represented with an item enumerator in this meminfo.h header file. _______________________________________ <SLABINFO> api The 'SLABS' (summary) & 'SLABNODE' items were reversed since the former are derived from the separate caches. More significantly, those 'SLABNODE' guys were renamed to 'SLAB' since they concern individual caches and the concept of 'nodes' is really an implementation detail. Also, several enumerators were changed to more closely agree with official slabinfo(5) documentation referred to in what we're treating as a base document: proc(5). Lastly, while those 'SLABS' items are solely a product of our library and not represented in slabinfo(5), the names attempt to parallel those found as 'SLAB' items. ______________________________________ <DISKSTATS> api One enumeration identifier was changed so as to better reflect its relationship to that actual documentation: 'Documentation/iostats.txt', as referenced in proc(5). Reference(s): . 12/2018, item origins added (and commit msg history) commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 . 01/2019, <stat> origins tweaked commit 201e816b26ddaccc923ec40977c92037cdd0c34e Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
REG_set(PRIORITY_RT, s_int, rtprio)
library: change 'PIDS_PROCESSOR' into a signed integer This change is really being made on behalf of the ps & top programs. Besides, over 2 billion CPUs are plenty! Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-12-14 11:30:00 +05:30
REG_set(PROCESSOR, s_int, processor)
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
setDECL(PROCESSOR_NODE) { (void)I; R->result.s_int = numa_node_of_cpu(P->processor); }
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(RSS, ul_int, rss)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(RSS_RLIM, ul_int, rss_rlim)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(SCHED_CLASS, s_int, sched)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
STR_set(SD_MACH, sd_mach)
STR_set(SD_OUID, sd_ouid)
STR_set(SD_SEAT, sd_seat)
STR_set(SD_SESS, sd_sess)
STR_set(SD_SLICE, sd_slice)
STR_set(SD_UNIT, sd_unit)
STR_set(SD_UUNIT, sd_uunit)
DUP_set(SIGBLOCKED, blocked)
DUP_set(SIGCATCH, sigcatch)
DUP_set(SIGIGNORE, sigignore)
DUP_set(SIGNALS, signal)
DUP_set(SIGPENDING, _sigpnd)
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
REG_set(SMAP_ANONYMOUS, ul_int, smap_Anonymous)
REG_set(SMAP_HUGE_ANON, ul_int, smap_AnonHugePages)
REG_set(SMAP_HUGE_FILE, ul_int, smap_FilePmdMapped)
REG_set(SMAP_HUGE_SHMEM, ul_int, smap_ShmemPmdMapped)
library: rename/reposition two enumerators, <pids> api The two special hugetlbfs items were misnamed. The TBL reference (table) should be TLB (transaction lookaside buffer). Besides, I never liked their position anyway! [ and one macro argument tweak is being snuck in too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-30 10:30:00 +05:30
REG_set(SMAP_HUGE_TLBPRV, ul_int, smap_Private_Hugetlb)
REG_set(SMAP_HUGE_TLBSHR, ul_int, smap_Shared_Hugetlb)
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
REG_set(SMAP_LAZY_FREE, ul_int, smap_LazyFree)
REG_set(SMAP_LOCKED, ul_int, smap_Locked)
REG_set(SMAP_PRV_CLEAN, ul_int, smap_Private_Clean)
REG_set(SMAP_PRV_DIRTY, ul_int, smap_Private_Dirty)
library: add new derived smaps_rollup item, <pids> api That recent addition of USS to the ps program prompted this change. Rather than have it (and soon top) add 2 separate items to yield the desired value, we will let our new library perform the arithmetic when necessary. Outside of a little extra storage, there is no runtime costs for such an extension. There is, however, a real benefit to having such code in the library. Now should callers choose to sort on this new field, results will be guaranteed to be what was expected (i.e. accurate). Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-06-16 10:30:00 +05:30
setDECL(SMAP_PRV_TOTAL) { (void)I; R->result.ul_int = P->smap_Private_Clean + P->smap_Private_Dirty; }
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
REG_set(SMAP_PSS, ul_int, smap_Pss)
REG_set(SMAP_PSS_ANON, ul_int, smap_Pss_Anon)
REG_set(SMAP_PSS_FILE, ul_int, smap_Pss_File)
REG_set(SMAP_PSS_SHMEM, ul_int, smap_Pss_Shmem)
REG_set(SMAP_REFERENCED, ul_int, smap_Referenced)
REG_set(SMAP_RSS, ul_int, smap_Rss)
REG_set(SMAP_SHR_CLEAN, ul_int, smap_Shared_Clean)
REG_set(SMAP_SHR_DIRTY, ul_int, smap_Shared_Dirty)
REG_set(SMAP_SWAP, ul_int, smap_Swap)
REG_set(SMAP_SWAP_PSS, ul_int, smap_SwapPss)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(STATE, s_ch, state)
STR_set(SUPGIDS, supgid)
STR_set(SUPGROUPS, supgrp)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
setDECL(TICS_ALL) { (void)I; R->result.ull_int = P->utime + P->stime; }
setDECL(TICS_ALL_C) { (void)I; R->result.ull_int = P->utime + P->stime + P->cutime + P->cstime; }
library: lessen chance of distortion on TICS_ALL_DELTA That old library defined this field as 'unsigned int'. However, here it was known as a 'signed int'. Thus for consistency we'll now also treat it as 'unsigned int'. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
REG_set(TICS_ALL_DELTA, u_int, pcpu)
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
REG_set(TICS_BEGAN, ull_int, start_time)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(TICS_BLKIO, ull_int, blkio_tics)
REG_set(TICS_GUEST, ull_int, gtime)
setDECL(TICS_GUEST_C) { (void)I; R->result.ull_int = P->gtime + P->cgtime; }
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(TICS_SYSTEM, ull_int, stime)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
setDECL(TICS_SYSTEM_C) { (void)I; R->result.ull_int = P->stime + P->cstime; }
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(TICS_USER, ull_int, utime)
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
setDECL(TICS_USER_C) { (void)I; R->result.ull_int = P->utime + P->cutime; }
library: trade 'float' type for a 'double', <pids> api While we really do not need the extra precision, we'll trade that recently introduced float type for a double for efficiency on a 64 bit platform. Additionally, the UTILIZATION algorithm was tweaked producing less code. The net result is four fewer machine instructions with a reduction of 14 total bytes in that function's size. Reference(s): . introduced 'real' type & 'utilization' item commit c69104b2b835176f9801dfd1a1d893579879a5b6 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 11:30:00 +05:30
setDECL(TIME_ALL) { R->result.real = ((double)P->utime + P->stime) / I->hertz; }
setDECL(TIME_ALL_C) { R->result.real = ((double)P->utime + P->stime + P->cutime + P->cstime) / I->hertz; }
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
setDECL(TIME_ELAPSED) { double t = I->boot_tics - P->start_time; if (t > 0) R->result.real = t / I->hertz; }
library: trade 'float' type for a 'double', <pids> api While we really do not need the extra precision, we'll trade that recently introduced float type for a double for efficiency on a 64 bit platform. Additionally, the UTILIZATION algorithm was tweaked producing less code. The net result is four fewer machine instructions with a reduction of 14 total bytes in that function's size. Reference(s): . introduced 'real' type & 'utilization' item commit c69104b2b835176f9801dfd1a1d893579879a5b6 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 11:30:00 +05:30
setDECL(TIME_START) { R->result.real = (double)P->start_time / I->hertz; }
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
REG_set(TTY, s_int, tty)
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
setDECL(TTY_NAME) { char buf[64]; freNAME(str)(R); dev_to_tty(buf, sizeof(buf), P->tty, P->tid, ABBREV_DEV); if (!(R->result.str = strdup(buf))) I->seterr = 1; }
setDECL(TTY_NUMBER) { char buf[64]; freNAME(str)(R); dev_to_tty(buf, sizeof(buf), P->tty, P->tid, ABBREV_DEV|ABBREV_TTY|ABBREV_PTS); if (!(R->result.str = strdup(buf))) I->seterr = 1; }
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
setDECL(UTILIZATION) { double t = I->boot_tics - P->start_time; if (t > 0) R->result.real = ((P->utime + P->stime) * 100.0f) / t; }
setDECL(UTILIZATION_C) { double t = I->boot_tics - P->start_time; if (t > 0) R->result.real = ((P->utime + P->stime + P->cutime + P->cstime) * 100.0f) / t; }
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
REG_set(VM_DATA, ul_int, vm_data)
REG_set(VM_EXE, ul_int, vm_exe)
REG_set(VM_LIB, ul_int, vm_lib)
REG_set(VM_RSS, ul_int, vm_rss)
REG_set(VM_RSS_ANON, ul_int, vm_rss_anon)
REG_set(VM_RSS_FILE, ul_int, vm_rss_file)
REG_set(VM_RSS_LOCKED, ul_int, vm_lock)
REG_set(VM_RSS_SHARED, ul_int, vm_rss_shared)
REG_set(VM_SIZE, ul_int, vm_size)
REG_set(VM_STACK, ul_int, vm_stack)
REG_set(VM_SWAP, ul_int, vm_swap)
setDECL(VM_USED) { (void)I; R->result.ul_int = P->vm_swap + P->vm_rss; }
library: change misnamed VSIZE_PGS item to VSIZE_BYTES Gosh this particular flaw originated way back in 2015. [ that was when we burdened a caller with additional ] [ responsibilities for 'stacks_alloc', 'stacks_fill' ] [ and 'stacks_dealloc'. damn implementation details. ] Reference(s): . Aug, 2015 - introduced<pids> api commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
REG_set(VSIZE_BYTES, ul_int, vsize)
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
setDECL(WCHAN_NAME) { freNAME(str)(R); if (!(R->result.str = strdup(lookup_wchan(P->tid)))) I->seterr = 1;; }
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef setDECL
#undef CVT_set
#undef DUP_set
#undef REG_set
#undef STR_set
#undef VEC_set
// ___ Sorting Support ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
struct sort_parms {
int offset;
enum pids_sort_order order;
};
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
#define srtNAME(t) sort_pids_ ## t
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-09 10:30:00 +05:30
#define srtDECL(t) static int srtNAME(t) \
(const struct pids_stack **A, const struct pids_stack **B, struct sort_parms *P)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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-09 10:30:00 +05:30
#define NUM_srt(T) srtDECL(T) { \
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
const struct pids_result *a = (*A)->head + P->offset; \
const struct pids_result *b = (*B)->head + P->offset; \
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-13 10:30:00 +05:30
return P->order * (a->result. T - b->result. T); }
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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-09 10:30:00 +05:30
#define REG_srt(T) srtDECL(T) { \
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
const struct pids_result *a = (*A)->head + P->offset; \
const struct pids_result *b = (*B)->head + P->offset; \
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-13 10:30:00 +05:30
if ( a->result. T > b->result. T ) return P->order > 0 ? 1 : -1; \
if ( a->result. T < b->result. T ) return P->order > 0 ? -1 : 1; \
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return 0; }
NUM_srt(s_ch)
NUM_srt(s_int)
REG_srt(u_int)
REG_srt(ul_int)
REG_srt(ull_int)
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
REG_srt(real)
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-09 10:30:00 +05:30
srtDECL(str) {
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
const struct pids_result *a = (*A)->head + P->offset;
const struct pids_result *b = (*B)->head + P->offset;
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-13 10:30:00 +05:30
return P->order * strcoll(a->result.str, b->result.str);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
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-09 10:30:00 +05:30
srtDECL(strv) {
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
const struct pids_result *a = (*A)->head + P->offset;
const struct pids_result *b = (*B)->head + P->offset;
if (!a->result.strv || !b->result.strv) return 0;
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-13 10:30:00 +05:30
return P->order * strcoll((*a->result.strv), (*b->result.strv));
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
}
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-09 10:30:00 +05:30
srtDECL(strvers) {
library: add PROCPS_PIDS_TTY_NAME to compliment number OK, ok, this was kind of a huge omission. So please do not select the TTY field for display in top quite yet, at least until a next patch has been pushed to GitLab. And to produce a correct sort order for this new field the GNU 'strverscmp' routine was a necessary addition. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-07 10:30:00 +05:30
const struct pids_result *a = (*A)->head + P->offset;
const struct pids_result *b = (*B)->head + P->offset;
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-13 10:30:00 +05:30
return P->order * strverscmp(a->result.str, b->result.str);
library: add PROCPS_PIDS_TTY_NAME to compliment number OK, ok, this was kind of a huge omission. So please do not select the TTY field for display in top quite yet, at least until a next patch has been pushed to GitLab. And to produce a correct sort order for this new field the GNU 'strverscmp' routine was a necessary addition. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-07 10:30:00 +05:30
}
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-09 10:30:00 +05:30
srtDECL(noop) {
(void)A; (void)B; (void)P;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return 0;
}
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-09 10:30:00 +05:30
#undef srtDECL
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef NUM_srt
#undef REG_srt
// ___ Controlling Table ||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: prefer /proc/stat before /proc/status, <pids> Long ago, in a galaxy far away (when top was in charge of library FILL flgs) /proc/status was to be preferred over /proc/stat if a field could be satisfied by both. This was done to avoid costly 64-bit math emulation in a 32-bit application due to 'unsigned long long' data. Well it's time to acknowledge the prevalence of 64-bit platforms. And in such an environment the cost picture has shifted significantly. It now costs 14 times (wow) as much to access /proc/status compared to /proc/stat. In other words, even with '%llu' variables, a sscanf() call in stat2proc() beats the pants off that home brew gperf based hashing employed by the status2proc() guy. In fact, status2proc incurs higher costs than found in the most expensive aspect of top's forest view option. Here's a gprof extract to illustrate the costs. It was produced with an rcfile requiring fields from both the /proc/stat & /proc/status pseudo files (among others). There were 5000 iterations in each of 4 separate gprof runs subsequently merged into 1 gmon.sum for analysis. % self self time seconds calls us/call name ----- ------- ------- ------- ----------- 28.65 4.10 4689423 0.87 status2proc 26.14 3.74 40000 93.50 forest_adds ... 01.96 0.28 4689427 0.06 stat2proc [ since forest_adds is recursive, the calls value is ] [ the non-recursive #, its 'call graph' shows totals ] Anyway, now that such cost is known this patch becomes what is euphemistically known as the usual no-brainer. [ jeeze, was it really this long between profilings? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
#define f_either PROC_SPARE_1 // either status or stat (favor stat)
library: expanded to provide for the 'executable path' This patch is the first of three implementing a newlib branch version of that Jan Rybar master merge request. With this series we'll ultimately extend 'EXE' support to both ps and top (plus, everyone else who wants it). Reference(s): . master branch merge request https://gitlab.com/procps-ng/procps/merge_requests/66 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-22 10:30:00 +05:30
#define f_exe PROC_FILL_EXE
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define f_grp PROC_FILLGRP
library: some miscellaneous tweaks before smaps_rollup This commit is strictly cosmetic. It was an attempt to normalize/standardize/alphabetize those #define/#undef statements. Some missing #undef's were added plus some comments regarding sources corrected/standardized too. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
#define f_io PROC_FILLIO
library: expanded to provide for the UID used at login This patch represents the newlib implementation of Jan Rybar's merge request referenced below. It essentially moves that code out of the ps program and into our new library where it's available via the <pids> interface. Reference(s): https://gitlab.com/procps-ng/procps/merge_requests/57 https://bugzilla.redhat.com/show_bug.cgi?id=1518986 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-11 12:41:11 +05:30
#define f_login PROC_FILL_LUID
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define f_lxc PROC_FILL_LXC
#define f_ns PROC_FILLNS
#define f_oom PROC_FILLOOM
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
#define f_smaps PROC_FILLSMAPS
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define f_stat PROC_FILLSTAT
#define f_statm PROC_FILLMEM
#define f_status PROC_FILLSTATUS
#define f_systemd PROC_FILLSYSTEMD
#define f_usr PROC_FILLUSR
library: accumulated changes to <pids> code & comments A patch containing the following miscellaneous tweaks: . avoided distortions unique to PROCPS_PIDS_TICS_DELTA . addressed several smatch warnings and/or suggestions . ensured oldproc_close invoked should tally_proc fail . keeping that namespace clean, added a missing #undef . added 2 comments acknowledging pids_item as unsigned . added/clarified comments regarding proc flags & strv From smatch analysis: . these were indeed boo-boos pids.c:580 make_hist() warn: the 'Hr' macro might need parens pids.c:1058 procps_pids_reap() warn: variable dereferenced before check 'info' (see line 1056) . these were not errors (and we did double check) pids.c:1067 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 pids.c:1068 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-28 10:30:00 +05:30
// these next three will yield true verctorized strings
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
#define v_arg PROC_FILLARG
#define v_cgroup PROC_FILLCGROUP
#define v_env PROC_FILLENV
library: some miscellaneous tweaks before smaps_rollup This commit is strictly cosmetic. It was an attempt to normalize/standardize/alphabetize those #define/#undef statements. Some missing #undef's were added plus some comments regarding sources corrected/standardized too. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
// these next three will yield a single string (never vectorized)
#define x_cgroup PROC_EDITCGRPCVT
#define x_cmdline PROC_EDITCMDLCVT
#define x_environ PROC_EDITENVRCVT
library: tweak 'other' user/group names for efficiency This commit just ensures that the relatively expensive ID to name conversions aren't performed unless they're explicitly requested. It also internalizes those flags that required the PROC_FILLSTATUS flag to also be set. [ requiring a caller, in our case pids.c, to provide ] [ two flags when a single field was the objective is ] [ wrong & represents a future potential toe-stubber. ] [ moreover, what's worse is that those two flags are ] [ seemingly unrelated. but, without both, a SEGV can ] [ can be expected when a result.str pointer is NULL. ] [ by contrast, in the master branch those fields are ] [ arrays which, when set to zeroes, produce an empty ] [ string. So, there is no abend (but no name either) ] [ when one of those two required flags were omitted. ] [ and worth noting, in that branch it's not just one ] [ caller required to observe a two flag requirement. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-02 11:30:00 +05:30
// these next three will also force PROC_FILLSTATUS
#define x_ogroup PROC_FILL_OGROUPS
#define x_ouser PROC_FILL_OUSERS
#define x_supgrp PROC_FILL_SUPGRP
library: add provision for displaying autogroup values In the link referenced below there's an explanation of the linux autogroup feature which has been around ever since linux-2.6.38. With that explanation there's also surprising (maybe shocking) revelations about the nice and renice commands if CONFIG_SCHED_AUTOGROUP was set. When autogroups are active, such programs are rendered mostly useless because the nice value will only affect scheduling priority relative to other processes in the same autogroup. In order to accomplish what we thought of as renice, that nice value in /proc/<pid>/autogroup must be changed. Altering any single member of a group will also affect every other member of that autogroup. So, this commit will set the stage for users of newlib to display autogroup identifiers plus their associated nice values (now that their importance is understood). Reference(s): https://github.com/nlburgin/reallynice Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-05 10:30:00 +05:30
// placed here so an 'f' prefix wouldn't make 'em first
#define z_autogrp PROC_FILLAUTOGRP
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
typedef void (*SET_t)(struct pids_info *, struct pids_result *, proc_t *);
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
typedef void (*FRE_t)(struct pids_result *);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
typedef int (*QSR_t)(const void *, const void *, void *);
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
#ifdef ITEMTABLE_DEBUG
#define RS(e) (SET_t)setNAME(e), PIDS_ ## e, STRINGIFY(PIDS_ ## e)
#else
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define RS(e) (SET_t)setNAME(e)
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
#endif
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-07 10:30:00 +05:30
#define FF(t) (FRE_t)freNAME(t)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define QS(t) (QSR_t)srtNAME(t)
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
#define TS(t) STRINGIFY(t)
#define TS_noop ""
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
/*
* Need it be said?
* This table must be kept in the exact same order as
* those 'enum pids_item' guys ! */
static struct {
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
SET_t setsfunc; // the actual result setting routine
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
#ifdef ITEMTABLE_DEBUG
int enumnumb; // enumerator (must match position!)
char *enum2str; // enumerator name as a char* string
#endif
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
unsigned oldflags; // PROC_FILLxxxx flags for this item
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
FRE_t freefunc; // free function for strings storage
QSR_t sortfunc; // sort cmp func for a specific type
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
int needhist; // a result requires history support
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
char *type2str; // the result type as a string value
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
} Item_table[] = {
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
/* setsfunc oldflags freefunc sortfunc needhist type2str
--------------------- ---------- --------- ------------- -------- ----------- */
{ RS(noop), 0, NULL, QS(noop), 0, TS_noop }, // user only, never altered
{ RS(extra), 0, NULL, QS(ull_int), 0, TS_noop }, // user only, reset to zero
library: fix a few source/origin notations, <pids> api After removing brackets from those 'derived' notations I was surprised to discover that several origin/source comments were wrong. So this patch fixes those errors. [ along the way a couple enumerators were renamed to ] [ better (i hope) reflect what they're representing. ] [ that, in turn, also required a little rearranging. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-03-09 11:30:00 +05:30
{ RS(ADDR_CODE_END), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(ADDR_CODE_START), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(ADDR_CURR_EIP), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(ADDR_CURR_ESP), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(ADDR_STACK_START), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
library: add provision for displaying autogroup values In the link referenced below there's an explanation of the linux autogroup feature which has been around ever since linux-2.6.38. With that explanation there's also surprising (maybe shocking) revelations about the nice and renice commands if CONFIG_SCHED_AUTOGROUP was set. When autogroups are active, such programs are rendered mostly useless because the nice value will only affect scheduling priority relative to other processes in the same autogroup. In order to accomplish what we thought of as renice, that nice value in /proc/<pid>/autogroup must be changed. Altering any single member of a group will also affect every other member of that autogroup. So, this commit will set the stage for users of newlib to display autogroup identifiers plus their associated nice values (now that their importance is understood). Reference(s): https://github.com/nlburgin/reallynice Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-05 10:30:00 +05:30
{ RS(AUTOGRP_ID), z_autogrp, NULL, QS(s_int), 0, TS(s_int) },
{ RS(AUTOGRP_NICE), z_autogrp, NULL, QS(s_int), 0, TS(s_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(CGNAME), x_cgroup, FF(str), QS(str), 0, TS(str) },
{ RS(CGROUP), x_cgroup, FF(str), QS(str), 0, TS(str) },
{ RS(CGROUP_V), v_cgroup, FF(strv), QS(strv), 0, TS(strv) },
{ RS(CMD), f_either, FF(str), QS(str), 0, TS(str) },
{ RS(CMDLINE), x_cmdline, FF(str), QS(str), 0, TS(str) },
{ RS(CMDLINE_V), v_arg, FF(strv), QS(strv), 0, TS(strv) },
{ RS(ENVIRON), x_environ, FF(str), QS(str), 0, TS(str) },
{ RS(ENVIRON_V), v_env, FF(strv), QS(strv), 0, TS(strv) },
library: expanded to provide for the 'executable path' This patch is the first of three implementing a newlib branch version of that Jan Rybar master merge request. With this series we'll ultimately extend 'EXE' support to both ps and top (plus, everyone else who wants it). Reference(s): . master branch merge request https://gitlab.com/procps-ng/procps/merge_requests/66 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-22 10:30:00 +05:30
{ RS(EXE), f_exe, FF(str), QS(str), 0, TS(str) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(EXIT_SIGNAL), f_stat, NULL, QS(s_int), 0, TS(s_int) },
{ RS(FLAGS), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(FLT_MAJ), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(FLT_MAJ_C), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(FLT_MAJ_DELTA), f_stat, NULL, QS(s_int), +1, TS(s_int) },
{ RS(FLT_MIN), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(FLT_MIN_C), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(FLT_MIN_DELTA), f_stat, NULL, QS(s_int), +1, TS(s_int) },
{ RS(ID_EGID), 0, NULL, QS(u_int), 0, TS(u_int) }, // oldflags: free w/ simple_read
{ RS(ID_EGROUP), f_grp, NULL, QS(str), 0, TS(str) },
{ RS(ID_EUID), 0, NULL, QS(u_int), 0, TS(u_int) }, // oldflags: free w/ simple_read
{ RS(ID_EUSER), f_usr, NULL, QS(str), 0, TS(str) }, // freefunc NULL w/ cached string
{ RS(ID_FGID), f_status, NULL, QS(u_int), 0, TS(u_int) },
{ RS(ID_FGROUP), x_ogroup, NULL, QS(str), 0, TS(str) },
{ RS(ID_FUID), f_status, NULL, QS(u_int), 0, TS(u_int) },
{ RS(ID_FUSER), x_ouser, NULL, QS(str), 0, TS(str) }, // freefunc NULL w/ cached string
library: expanded to provide for the UID used at login This patch represents the newlib implementation of Jan Rybar's merge request referenced below. It essentially moves that code out of the ps program and into our new library where it's available via the <pids> interface. Reference(s): https://gitlab.com/procps-ng/procps/merge_requests/57 https://bugzilla.redhat.com/show_bug.cgi?id=1518986 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-02-11 12:41:11 +05:30
{ RS(ID_LOGIN), f_login, NULL, QS(s_int), 0, TS(s_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(ID_PGRP), f_stat, NULL, QS(s_int), 0, TS(s_int) },
{ RS(ID_PID), 0, NULL, QS(s_int), 0, TS(s_int) }, // oldflags: free w/ simple_nextpid
{ RS(ID_PPID), f_either, NULL, QS(s_int), 0, TS(s_int) },
{ RS(ID_RGID), f_status, NULL, QS(u_int), 0, TS(u_int) },
{ RS(ID_RGROUP), x_ogroup, NULL, QS(str), 0, TS(str) },
{ RS(ID_RUID), f_status, NULL, QS(u_int), 0, TS(u_int) },
{ RS(ID_RUSER), x_ouser, NULL, QS(str), 0, TS(str) }, // freefunc NULL w/ cached string
{ RS(ID_SESSION), f_stat, NULL, QS(s_int), 0, TS(s_int) },
{ RS(ID_SGID), f_status, NULL, QS(u_int), 0, TS(u_int) },
{ RS(ID_SGROUP), x_ogroup, NULL, QS(str), 0, TS(str) },
{ RS(ID_SUID), f_status, NULL, QS(u_int), 0, TS(u_int) },
{ RS(ID_SUSER), x_ouser, NULL, QS(str), 0, TS(str) }, // freefunc NULL w/ cached string
{ RS(ID_TGID), 0, NULL, QS(s_int), 0, TS(s_int) }, // oldflags: free w/ simple_nextpid
library: insert 'PIDS_ID_TID' for symmetry, <PIDS> api This change is being made in anticipation of adding the source origin of each item to the <pids.h> header file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-12-01 11:30:00 +05:30
{ RS(ID_TID), 0, NULL, QS(s_int), 0, TS(s_int) }, // oldflags: free w/ simple_nexttid
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(ID_TPGID), f_stat, NULL, QS(s_int), 0, TS(s_int) },
library: adding IO accounting This is a modification of MR !122 by @renit1609 to fit the new library. Problem statement: The procps library has no PROC_FILLIO flag to fetch the proc field "/proc/[pid]/io" data process-wise. IO Accounting is not included as part of procps. Requirement: We have a requirement to fetch process wise IO utilization which can be used for monitoring. When looking through the procps library, I see that IO Accounting (/proc/[pid]/io) is not being included as part of procps. There is no such flag like PROC_FILLIO being included in readproc.h . Solution: While looking at the implementation done for other proc fields, I used the spare bits in app code. I renamed PROC_SPARE_1 as PROC_FILLIO, the spare bit from PROC_SPARE_* and used it for fetching /proc/[pid]/io data as part of the procps library similar to other fields. I moved the PROC_SPARE_* bits each by 1 bit to retain the spare bits. Meanwhile added the IO fields in proc_t structure. References: procps-ng/procps!122 procps-ng/procps#184
2021-04-24 18:08:48 +05:30
{ RS(IO_READ_BYTES), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(IO_READ_CHARS), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(IO_READ_OPS), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(IO_WRITE_BYTES), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(IO_WRITE_CBYTES), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(IO_WRITE_CHARS), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(IO_WRITE_OPS), f_io, NULL, QS(ul_int), 0, TS(ul_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(LXCNAME), f_lxc, NULL, QS(str), 0, TS(str) }, // freefunc NULL w/ cached string
{ RS(MEM_CODE), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_CODE_PGS), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_DATA), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_DATA_PGS), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_RES), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_RES_PGS), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_SHR), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_SHR_PGS), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_VIRT), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(MEM_VIRT_PGS), f_statm, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(NICE), f_stat, NULL, QS(s_int), 0, TS(s_int) },
{ RS(NLWP), f_either, NULL, QS(s_int), 0, TS(s_int) },
library: bring namespaces up to date with linux kernel Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-05-05 10:30:00 +05:30
{ RS(NS_CGROUP), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(NS_IPC), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(NS_MNT), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(NS_NET), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(NS_PID), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
library: bring namespaces up to date with linux kernel Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-05-05 10:30:00 +05:30
{ RS(NS_TIME), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(NS_USER), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(NS_UTS), f_ns, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(OOM_ADJ), f_oom, NULL, QS(s_int), 0, TS(s_int) },
{ RS(OOM_SCORE), f_oom, NULL, QS(s_int), 0, TS(s_int) },
{ RS(PRIORITY), f_stat, NULL, QS(s_int), 0, TS(s_int) },
library: refactored some header file items and origins This commit is intended as a refinement of the patches mentioned below, where origins/sources of newlib items were added to the header files for user documentation. However, if those additions are to be truly effective, along with kernel documentation (where available), the following prerequisites must also have been satisfied: . our identifiers closely align with linux field names . our derived items are documented or self-documenting Satisfying those prerequisites prompted this patch and for these changes, kernel sources were emphasized over available documentation (shame on me, it should always have been so). And, while some 'new' fields were found to be conditional, they were included unconditionally. These changes appear more extensive than they actually need be since I have attempted to enforce some spacing conventions. So, I've summarize the significant things in the sections that follow. For a proper perspective, use: 'git diff --ignore-space-change' (good as alias). ___________________________________________ <PIDS> api This api is unique in that there exists many different file/directory origins subordinate to /proc/<pid>. And our item identifiers are sometimes coerced so as to be able to group related or similar enumerators together. So, users needed more help relating our identifiers to an actual documented field. Thus, we will now also add the field names as with 'stat: delayacct_blkio_ticks'. Each item ending with a '_C' now consistently includes both the parent's count/time plus waited for children. That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT since its original name is an implementation artifact. ___________________________________________ <STAT> api The only api change was to correct a typo ('dervied'). _________________________________________ <VMSTAT> api Even ignoring white space, this interface received the largest number of changes. Mostly, this was because of deficiencies in the proc(5) documentation. Recall that this documentation already sorely lacks any substance. Usually, just kernel releases are noted, not contents. When compared to kernel source, that proc(5) contained many non-existent fields and also omitted many others. ________________________________________ <MEMINFO> api Sadly, with this api many of the changes were simply a correction of some earlier 'human error' where several fields where hashed then tracked but never represented with an item enumerator in this meminfo.h header file. _______________________________________ <SLABINFO> api The 'SLABS' (summary) & 'SLABNODE' items were reversed since the former are derived from the separate caches. More significantly, those 'SLABNODE' guys were renamed to 'SLAB' since they concern individual caches and the concept of 'nodes' is really an implementation detail. Also, several enumerators were changed to more closely agree with official slabinfo(5) documentation referred to in what we're treating as a base document: proc(5). Lastly, while those 'SLABS' items are solely a product of our library and not represented in slabinfo(5), the names attempt to parallel those found as 'SLAB' items. ______________________________________ <DISKSTATS> api One enumeration identifier was changed so as to better reflect its relationship to that actual documentation: 'Documentation/iostats.txt', as referenced in proc(5). Reference(s): . 12/2018, item origins added (and commit msg history) commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 . 01/2019, <stat> origins tweaked commit 201e816b26ddaccc923ec40977c92037cdd0c34e Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
{ RS(PRIORITY_RT), f_stat, NULL, QS(s_int), 0, TS(s_int) },
library: change 'PIDS_PROCESSOR' into a signed integer This change is really being made on behalf of the ps & top programs. Besides, over 2 billion CPUs are plenty! Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-12-14 11:30:00 +05:30
{ RS(PROCESSOR), f_stat, NULL, QS(s_int), 0, TS(s_int) },
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
{ RS(PROCESSOR_NODE), f_stat, NULL, QS(s_int), 0, TS(s_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(RSS), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(RSS_RLIM), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SCHED_CLASS), f_stat, NULL, QS(s_int), 0, TS(s_int) },
{ RS(SD_MACH), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SD_OUID), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SD_SEAT), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SD_SESS), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SD_SLICE), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SD_UNIT), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SD_UUNIT), f_systemd, FF(str), QS(str), 0, TS(str) },
{ RS(SIGBLOCKED), f_status, FF(str), QS(str), 0, TS(str) },
{ RS(SIGCATCH), f_status, FF(str), QS(str), 0, TS(str) },
{ RS(SIGIGNORE), f_status, FF(str), QS(str), 0, TS(str) },
{ RS(SIGNALS), f_status, FF(str), QS(str), 0, TS(str) },
{ RS(SIGPENDING), f_status, FF(str), QS(str), 0, TS(str) },
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
{ RS(SMAP_ANONYMOUS), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_HUGE_ANON), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_HUGE_FILE), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_HUGE_SHMEM), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
library: rename/reposition two enumerators, <pids> api The two special hugetlbfs items were misnamed. The TBL reference (table) should be TLB (transaction lookaside buffer). Besides, I never liked their position anyway! [ and one macro argument tweak is being snuck in too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-30 10:30:00 +05:30
{ RS(SMAP_HUGE_TLBPRV), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_HUGE_TLBSHR), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
{ RS(SMAP_LAZY_FREE), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_LOCKED), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_PRV_CLEAN), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_PRV_DIRTY), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
library: add new derived smaps_rollup item, <pids> api That recent addition of USS to the ps program prompted this change. Rather than have it (and soon top) add 2 separate items to yield the desired value, we will let our new library perform the arithmetic when necessary. Outside of a little extra storage, there is no runtime costs for such an extension. There is, however, a real benefit to having such code in the library. Now should callers choose to sort on this new field, results will be guaranteed to be what was expected (i.e. accurate). Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-06-16 10:30:00 +05:30
{ RS(SMAP_PRV_TOTAL), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
{ RS(SMAP_PSS), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_PSS_ANON), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_PSS_FILE), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_PSS_SHMEM), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_REFERENCED), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_RSS), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_SHR_CLEAN), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_SHR_DIRTY), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_SWAP), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(SMAP_SWAP_PSS), f_smaps, NULL, QS(ul_int), 0, TS(ul_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(STATE), f_either, NULL, QS(s_ch), 0, TS(s_ch) },
{ RS(SUPGIDS), f_status, FF(str), QS(str), 0, TS(str) },
{ RS(SUPGROUPS), x_supgrp, FF(str), QS(str), 0, TS(str) },
{ RS(TICS_ALL), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_ALL_C), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
library: lessen chance of distortion on TICS_ALL_DELTA That old library defined this field as 'unsigned int'. However, here it was known as a 'signed int'. Thus for consistency we'll now also treat it as 'unsigned int'. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
{ RS(TICS_ALL_DELTA), f_stat, NULL, QS(u_int), +1, TS(u_int) },
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
{ RS(TICS_BEGAN), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(TICS_BLKIO), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_GUEST), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_GUEST_C), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_SYSTEM), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_SYSTEM_C), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_USER), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
{ RS(TICS_USER_C), f_stat, NULL, QS(ull_int), 0, TS(ull_int) },
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
{ RS(TIME_ALL), f_stat, NULL, QS(real), 0, TS(real) },
{ RS(TIME_ALL_C), f_stat, NULL, QS(real), 0, TS(real) },
{ RS(TIME_ELAPSED), f_stat, NULL, QS(real), 0, TS(real) },
{ RS(TIME_START), f_stat, NULL, QS(real), 0, TS(real) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(TTY), f_stat, NULL, QS(s_int), 0, TS(s_int) },
{ RS(TTY_NAME), f_stat, FF(str), QS(strvers), 0, TS(str) },
{ RS(TTY_NUMBER), f_stat, FF(str), QS(strvers), 0, TS(str) },
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
{ RS(UTILIZATION), f_stat, NULL, QS(real), 0, TS(real) },
library: introduced a 'UTILIZATION_C' item, <pids> api Some items in the <pids> API carry a '_C' suffix which implies such values include reaped children. So, we'll now extend this practice to that new UTILIZATION item. Reference(s): . Mar, 2022 - tweak PIDS_UTILIZATION commit 9c0e8e9429d232a85baef3d6fa8269963fd80741 . Feb, 2022 - added PIDS_UTILIZATION commit c69104b2b835176f9801dfd1a1d893579879a5b6 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-03-06 11:30:00 +05:30
{ RS(UTILIZATION_C), f_stat, NULL, QS(real), 0, TS(real) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(VM_DATA), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_EXE), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_LIB), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_RSS), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_RSS_ANON), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_RSS_FILE), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_RSS_LOCKED), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_RSS_SHARED), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_SIZE), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_STACK), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_SWAP), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
{ RS(VM_USED), f_status, NULL, QS(ul_int), 0, TS(ul_int) },
library: change misnamed VSIZE_PGS item to VSIZE_BYTES Gosh this particular flaw originated way back in 2015. [ that was when we burdened a caller with additional ] [ responsibilities for 'stacks_alloc', 'stacks_fill' ] [ and 'stacks_dealloc'. damn implementation details. ] Reference(s): . Aug, 2015 - introduced<pids> api commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
{ RS(VSIZE_BYTES), f_stat, NULL, QS(ul_int), 0, TS(ul_int) },
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
{ RS(WCHAN_NAME), 0, FF(str), QS(str), 0, TS(str) }, // oldflags: tid already free
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
};
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-07 10:30:00 +05:30
/* please note,
* this enum MUST be 1 greater than the highest value of any enum */
library: eliminate one potential source of human error There's a huge toe-stubber awaiting future maintenance as reflected in that commit below which deals with the addition of new enumerators to the Item_table. Namely, whenever the table is grown, one must remember to also change that existing 'logical_end' enumerator's value. Well, not anymore! Since that MAXTABLE macro was added to the procps-private.h header we can now also exploit it so a 'logical_end' automatically tracks table size. This change also renders some code associated with the ITEMTABLE_DEBUG #define unnecessary. So it's gone too. Reference(s): . 08/2016, add new enumerators commit 09e1886c9e731f8b8c89a55d11f72f53f030b2de . 08/2020, added MAXTABLE macro commit c865b06c304e645c05eae0f5e06a1f49ea105285 . 08/2020, introduced ITEMTABLE_DEBUG commit 92d0297e1e4d5946c5b098e37c91c7e524a0eca0 Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-22 10:30:00 +05:30
enum pids_item PIDS_logical_end = MAXTABLE(Item_table);
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-14 10:30:00 +05:30
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef setNAME
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
#undef freNAME
#undef srtNAME
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-06 10:30:00 +05:30
#undef RS
#undef FF
#undef QS
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
//#undef f_either // needed later
library: some miscellaneous tweaks before smaps_rollup This commit is strictly cosmetic. It was an attempt to normalize/standardize/alphabetize those #define/#undef statements. Some missing #undef's were added plus some comments regarding sources corrected/standardized too. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
#undef f_exe
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef f_grp
library: some miscellaneous tweaks before smaps_rollup This commit is strictly cosmetic. It was an attempt to normalize/standardize/alphabetize those #define/#undef statements. Some missing #undef's were added plus some comments regarding sources corrected/standardized too. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
#undef f_io
#undef f_login
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef f_lxc
#undef f_ns
#undef f_oom
library: add support for smaps_rollup file, <pids> api A couple of people have suggested that smaps_rollup be added to the ps program and/or top program. This patch is intended to set the stage for just such extensions. There are currently 20 displayable items in the rollup file. And newlib sometimes uses sscanf when populating the target, sometimes hsearch and one customized gperf approach. None of these fit well with the smaps items. Thus, an approach using a simple table lookup was used and, by disabling 1 code line, it could be made immune from changes to the items order (unlike a sscanf call) and doesn't carry the greater cost of a hsearch/gperf. Note: The next patch will allow top to display some of these new fields. Then, it'll be possible to determine the colossal costs of accessing the smaps_rollup file. Here is a small preview of just what you will discover when using the command 'time top/top -d0 -n1000' while configured with just two fields: PID + 1 memory field. ------------------------------------ as a regular user with only PID + RES (statm) real 0m2.605s user 0m1.060s sys 0m1.377s with only PID + RSS (smaps) real 0m26.397s 10x more costly user 0m1.253s sys 0m24.915s ----------------- as a root (thus smaps for all tasks) with only PID + RES (statm) real 0m2.651s user 0m1.177s sys 0m1.286s with only PID + RSS (smaps) real 0m33.040s 12x more costly user 0m1.256s sys 0m31.533s Reference(s): . ps: expose shared/private memory separately https://gitlab.com/procps-ng/procps/-/issues/201 . top/ps: add support for PSS reporting https://gitlab.com/procps-ng/procps/-/issues/112 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-26 10:30:00 +05:30
#undef f_smaps
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
//#undef f_stat // needed later
#undef f_statm
//#undef f_status // needed later
#undef f_systemd
#undef f_usr
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
#undef v_arg
#undef v_cgroup
#undef v_env
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef x_cgroup
#undef x_cmdline
#undef x_environ
#undef x_ogroup
#undef x_ouser
#undef x_supgrp
library: add provision for displaying autogroup values In the link referenced below there's an explanation of the linux autogroup feature which has been around ever since linux-2.6.38. With that explanation there's also surprising (maybe shocking) revelations about the nice and renice commands if CONFIG_SCHED_AUTOGROUP was set. When autogroups are active, such programs are rendered mostly useless because the nice value will only affect scheduling priority relative to other processes in the same autogroup. In order to accomplish what we thought of as renice, that nice value in /proc/<pid>/autogroup must be changed. Altering any single member of a group will also affect every other member of that autogroup. So, this commit will set the stage for users of newlib to display autogroup identifiers plus their associated nice values (now that their importance is understood). Reference(s): https://github.com/nlburgin/reallynice Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-05 10:30:00 +05:30
#undef z_autogrp
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
// ___ History Support Private Functions ||||||||||||||||||||||||||||||||||||||
// ( stolen from top when he wasn't looking ) -------------------------------
library: tweak that history hash algorithm, <pids> api This patch just raises the size of the hash table used to calculate elapsed task stuff. The net result should be less need for 'chaining' under pid hash collisions. [ the hash scheme is intentionally kept as primitive ] [ and, therefore, as fast as possible. it employs an ] [ 'and' approach versus a 'mod' operation since both ] [ yield similar distribution but the former approach ] [ was 4 fewer cpu instructions in terms of overhead. ] [ additionally, for hash collisions, 'chaining' uses ] [ an array index rather than the usual pointer since ] [ the HST_t guys may move when they are reallocated. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-01 10:30:00 +05:30
#define HHASH_SIZE 4096
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#define _HASH_PID_(K) (K & (HHASH_SIZE - 1))
#define Hr(x) info->hist->x // 'hist ref', minimize stolen impact
typedef unsigned long long TIC_t;
typedef struct HST_t {
TIC_t tics; // last frame's tics count
library: normalize & minimize result types, <PIDS> api This commit attempts to minimize the variety of types currently used. Plus, the following were also changed: . the MEM fields were switched to parallel the VM guys . PIDS_MEM_VIRT -> PIDS_MEM_VIRT_PGS . PIDS_MEM_VIRT_KIB -> PIDS_MEM_VIRT . made NICE 's_int' so that it then parallels PRIORITY . change RTPRIO & SCHED_CLASS from 'ul_int' to 's_int' . removed Item_table 'oldflags' for an obsoleted field . PIDS_WCHAN_ADDR . added calculations like TICS_ALL_C for the following . PIDS_TICS_USER_C . PIDS_TICS_SYSTEM_C . these three new 'TICS' fields have been incorporated . PIDS_TICS_BLKIO - jiffies spent in block i/o . PIDS_TICS_GUEST - jiffies spent as a guest . PIDS_TICS_GUEST_C - as above, includes dead children . that PIDS_TICS_DELTA was renamed PIDS_TICS_ALL_DELTA ( so it did not hide between TICS_BLKIO & TICS_GUEST ) ( and to make clearer what's included: utime + stime ) . eliminated 'sl_int' entirely from that result struct [ often, the <pids> module changes necessitated that ] [ readproc header and source files had to change too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-31 10:30:00 +05:30
unsigned long maj, min; // last frame's maj/min_flt counts
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int pid; // record 'key'
int lnk; // next on hash chain
} HST_t;
struct history_info {
int num_tasks; // used as index (tasks tallied)
int HHist_siz; // max number of HST_t structs
HST_t *PHist_sav; // alternating 'old/new' HST_t anchors
HST_t *PHist_new;
int HHash_one [HHASH_SIZE]; // the actual hash tables
int HHash_two [HHASH_SIZE]; // (accessed via PHash_sav/PHash_new)
int HHash_nul [HHASH_SIZE]; // an 'empty' hash table image
int *PHash_sav; // alternating 'old/new' hash tables
int *PHash_new; // (aka. the 'one/two' actual tables)
};
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static void pids_config_history (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
int i;
for (i = 0; i < HHASH_SIZE; i++) // make the 'empty' table image
Hr(HHash_nul[i]) = -1;
memcpy(Hr(HHash_one), Hr(HHash_nul), sizeof(Hr(HHash_nul)));
memcpy(Hr(HHash_two), Hr(HHash_nul), sizeof(Hr(HHash_nul)));
Hr(PHash_sav) = Hr(HHash_one); // alternating 'old/new' hash tables
Hr(PHash_new) = Hr(HHash_two);
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_config_history
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline HST_t *pids_histget (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int pid)
{
int V = Hr(PHash_sav[_HASH_PID_(pid)]);
while (-1 < V) {
if (Hr(PHist_sav[V].pid) == pid)
return &Hr(PHist_sav[V]);
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-07 10:30:00 +05:30
V = Hr(PHist_sav[V].lnk);
}
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return NULL;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_histget
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline void pids_histput (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
unsigned this)
{
int V = _HASH_PID_(Hr(PHist_new[this].pid));
Hr(PHist_new[this].lnk) = Hr(PHash_new[V]);
Hr(PHash_new[V] = this);
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_histput
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef _HASH_PID_
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline int pids_make_hist (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
proc_t *p)
{
TIC_t tics;
HST_t *h;
library: lower addr resolution cost for TICS_ALL_DELTA Rather than run risks of more expensive and repetitive address resolution, we will establish this local index for a one time cost and avoid any potential gcc bloat. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
int slot = info->hist->num_tasks;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: lower addr resolution cost for TICS_ALL_DELTA Rather than run risks of more expensive and repetitive address resolution, we will establish this local index for a one time cost and avoid any potential gcc bloat. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
if (slot + 1 >= Hr(HHist_siz)) {
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
Hr(HHist_siz) += NEWOLD_GROW;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
Hr(PHist_sav) = realloc(Hr(PHist_sav), sizeof(HST_t) * Hr(HHist_siz));
Hr(PHist_new) = realloc(Hr(PHist_new), sizeof(HST_t) * Hr(HHist_siz));
library: accumulated changes to <pids> code & comments A patch containing the following miscellaneous tweaks: . avoided distortions unique to PROCPS_PIDS_TICS_DELTA . addressed several smatch warnings and/or suggestions . ensured oldproc_close invoked should tally_proc fail . keeping that namespace clean, added a missing #undef . added 2 comments acknowledging pids_item as unsigned . added/clarified comments regarding proc flags & strv From smatch analysis: . these were indeed boo-boos pids.c:580 make_hist() warn: the 'Hr' macro might need parens pids.c:1058 procps_pids_reap() warn: variable dereferenced before check 'info' (see line 1056) . these were not errors (and we did double check) pids.c:1067 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 pids.c:1068 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-28 10:30:00 +05:30
if (!Hr(PHist_sav) || !Hr(PHist_new))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 0;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
library: lower addr resolution cost for TICS_ALL_DELTA Rather than run risks of more expensive and repetitive address resolution, we will establish this local index for a one time cost and avoid any potential gcc bloat. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
Hr(PHist_new[slot].pid) = p->tid;
Hr(PHist_new[slot].maj) = p->maj_flt;
Hr(PHist_new[slot].min) = p->min_flt;
Hr(PHist_new[slot].tics) = tics = (p->utime + p->stime);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: lower addr resolution cost for TICS_ALL_DELTA Rather than run risks of more expensive and repetitive address resolution, we will establish this local index for a one time cost and avoid any potential gcc bloat. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
pids_histput(info, slot);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if ((h = pids_histget(info, p->tid))) {
library: fix an insidious bug affecting TICS_ALL_DELTA This simple two line code change fixes an intermittent bug whereby %CPU for parent(s) with collapsed children could be vastly understated from those displayed under the current 3.3.17 publicly available top & libprocps. If one started several top instances in the background using very a small delay interval (zero?), then if the shell under which they were running was collapsed, you would see similar %CPU results for both the libraries. However, when running a demanding 'make' like a kernel compile (especially if backed by fast processors and a SSD), then newlib would generally show only 1/3 to 1/2 of the collapsed %CPU values that appeared for 3.3.17. Of course, now that the bug has been swatted with this commit the disparities between those results is easily explained. Since newly created tasks never contributed tics during the interval where they were created, only with many short lived tasks would differences surface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-22 10:30:00 +05:30
tics -= h->tics;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
p->maj_delta = p->maj_flt - h->maj;
p->min_delta = p->min_flt - h->min;
}
library: fix an insidious bug affecting TICS_ALL_DELTA This simple two line code change fixes an intermittent bug whereby %CPU for parent(s) with collapsed children could be vastly understated from those displayed under the current 3.3.17 publicly available top & libprocps. If one started several top instances in the background using very a small delay interval (zero?), then if the shell under which they were running was collapsed, you would see similar %CPU results for both the libraries. However, when running a demanding 'make' like a kernel compile (especially if backed by fast processors and a SSD), then newlib would generally show only 1/3 to 1/2 of the collapsed %CPU values that appeared for 3.3.17. Of course, now that the bug has been swatted with this commit the disparities between those results is easily explained. Since newly created tasks never contributed tics during the interval where they were created, only with many short lived tasks would differences surface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-22 10:30:00 +05:30
/* here we're saving elapsed tics, which will include any
tasks not previously seen via that pids_histget() guy! */
p->pcpu = tics;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: lower addr resolution cost for TICS_ALL_DELTA Rather than run risks of more expensive and repetitive address resolution, we will establish this local index for a one time cost and avoid any potential gcc bloat. [ this commit was made in pursuit of a bug involving ] [ the distortion of elapsed task tics. but, it turns ] [ out these changes had nothing to do with that bug. ] [ however, the patch is being retained as desirable. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-21 10:30:00 +05:30
info->hist->num_tasks++;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_make_hist
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline void pids_toggle_history (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
void *v;
v = Hr(PHist_sav);
Hr(PHist_sav) = Hr(PHist_new);
Hr(PHist_new) = v;
v = Hr(PHash_sav);
Hr(PHash_sav) = Hr(PHash_new);
Hr(PHash_new) = v;
memcpy(Hr(PHash_new), Hr(HHash_nul), sizeof(Hr(HHash_nul)));
info->hist->num_tasks = 0;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_toggle_history
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#ifdef UNREF_RPTHASH
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static void pids_unref_rpthash (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
int i, j, pop, total_occupied, maxdepth, maxdepth_sav, numdepth
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
, cross_foot, sz = HHASH_SIZE * (int)sizeof(int)
, hsz = (int)sizeof(HST_t) * Hr(HHist_siz);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int depths[HHASH_SIZE];
for (i = 0, total_occupied = 0, maxdepth = 0; i < HHASH_SIZE; i++) {
int V = Hr(PHash_new[i]);
j = 0;
if (-1 < V) {
++total_occupied;
while (-1 < V) {
V = Hr(PHist_new[V].lnk);
if (-1 < V) j++;
}
}
depths[i] = j;
if (maxdepth < j) maxdepth = j;
}
maxdepth_sav = maxdepth;
fprintf(stderr,
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
"\n History Memory Costs:"
"\n\tHST_t size = %d, total allocated = %d,"
"\n\tthus PHist_new & PHist_sav consumed %dk (%d) total bytes."
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
"\n"
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
"\n\tTwo hash tables provide for %d entries each + 1 extra 'empty' image,"
"\n\tthus %dk (%d) bytes per table for %dk (%d) total bytes."
"\n"
"\n\tGrand total = %dk (%d) bytes."
"\n"
"\n Hash Results Report:"
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
"\n\tTotal hashed = %d"
"\n\tLevel-0 hash entries = %d (%d%% occupied)"
"\n\tMax Depth = %d"
"\n\n"
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
, (int)sizeof(HST_t), Hr(HHist_siz)
, hsz / 1024, hsz
, HHASH_SIZE
, sz / 1024, sz, (sz * 3) / 1024, sz * 3
, (hsz + (sz * 3)) / 1024, hsz + (sz * 3)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
, info->hist->num_tasks
, total_occupied, (total_occupied * 100) / HHASH_SIZE
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
, maxdepth);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
if (total_occupied) {
for (pop = total_occupied, cross_foot = 0; maxdepth; maxdepth--) {
for (i = 0, numdepth = 0; i < HHASH_SIZE; i++)
if (depths[i] == maxdepth) ++numdepth;
library: a tweak to the UNREF_RPTHASH code, <pids> api If a hash results report is output (via UNREF_RPTHASH) a portion is devoted to occupied table entries ordered by depth. There is a possibility that some depths will not be found among existing occupied table entries and to avoid any confusion probably should not be printed. [ to illustrate the potential for confusion prior to ] [ this patch, force a very small table size (like 8) ] [ & then trigger the procps_pids_unref() eoj report. ] So this patch ensures only 'in use' entries are shown. [ admittedly, all of the remaining logic in the loop ] [ could/should be subordinate to this new 'if' test, ] [ but we will keep the change to a minimum. besides, ] [ there's no harm subtracting/adding a zero numdepth ] [ especially since the chance of a zero is very low. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-19 10:30:00 +05:30
if (numdepth) fprintf(stderr,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
"\t %5d (%3d%%) hash table entries at depth %d\n"
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
, numdepth, (numdepth * 100) / total_occupied, maxdepth);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
pop -= numdepth;
cross_foot += numdepth;
if (0 == pop && cross_foot == total_occupied) break;
}
if (pop) {
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
fprintf(stderr, "\t %5d (%3d%%) unchained entries (at depth 0)\n"
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
, pop, (pop * 100) / total_occupied);
cross_foot += pop;
}
fprintf(stderr,
"\t -----\n"
"\t %5d total entries occupied\n", cross_foot);
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
if (maxdepth_sav > 1) {
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
fprintf(stderr, "\n PIDs at max depth: ");
for (i = 0; i < HHASH_SIZE; i++)
if (depths[i] == maxdepth_sav) {
j = Hr(PHash_new[i]);
fprintf(stderr, "\n\tpos %4d: %05d", i, Hr(PHist_new[j].pid));
while (-1 < j) {
j = Hr(PHist_new[j].lnk);
if (-1 < j) fprintf(stderr, ", %05d", Hr(PHist_new[j].pid));
}
}
fprintf(stderr, "\n");
}
}
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_unref_rpthash
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#endif // UNREF_RPTHASH
library: accumulated changes to <pids> code & comments A patch containing the following miscellaneous tweaks: . avoided distortions unique to PROCPS_PIDS_TICS_DELTA . addressed several smatch warnings and/or suggestions . ensured oldproc_close invoked should tally_proc fail . keeping that namespace clean, added a missing #undef . added 2 comments acknowledging pids_item as unsigned . added/clarified comments regarding proc flags & strv From smatch analysis: . these were indeed boo-boos pids.c:580 make_hist() warn: the 'Hr' macro might need parens pids.c:1058 procps_pids_reap() warn: variable dereferenced before check 'info' (see line 1056) . these were not errors (and we did double check) pids.c:1067 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 pids.c:1068 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-28 10:30:00 +05:30
#undef Hr
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
#undef HHASH_SIZE
// ___ Standard Private Functions |||||||||||||||||||||||||||||||||||||||||||||
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
static inline int pids_assign_results (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
struct pids_stack *stack,
proc_t *p)
{
struct pids_result *this = stack->head;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
info->seterr = 0;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
for (;;) {
enum pids_item item = this->item;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (item >= PIDS_logical_end)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
break;
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
Item_table[item].setsfunc(info, this, p);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
++this;
}
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return !info->seterr;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_assign_results
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline void pids_cleanup_stack (
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-14 10:30:00 +05:30
struct pids_result *this)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
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-14 10:30:00 +05:30
for (;;) {
enum pids_item item = this->item;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (item >= PIDS_logical_end)
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-18 10:30:00 +05:30
break;
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-14 10:30:00 +05:30
if (Item_table[item].freefunc)
Item_table[item].freefunc(this);
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
this->result.ull_int = 0;
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-14 10:30:00 +05:30
++this;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_cleanup_stack
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline void pids_cleanup_stacks_all (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
struct stacks_extent *ext = info->extents;
int i;
while (ext) {
for (i = 0; ext->stacks[i]; i++)
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_cleanup_stack(ext->stacks[i]->head);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
ext = ext->next;
};
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_cleanup_stacks_all
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: refactor flawed function fatal_proc_unmounted This commit addresses a potentially disastrous flaw in that fatal_proc_unmounted() function wherein requested item(s) might not have been returned to the caller yet were specified at the time of a 'new' or 'reset' call. The root cause, uncovered by Craig, was due to the old library look_up_our_self() support function which only would populate a proc_t with limited 'stat' file data. This routine will now act the same as all other <pids> functions which return a stack or stacks. Whatever was specified with a 'new' or 'reset' will be returned, if the passed 'return_self' parameter is other than zero. [ as is so often the case, when flawed code is fixed ] [ former complexity can be reduced as a side benefit ] Reference(s): https://www.freelists.org/post/procps/issue-245-plus-one,2 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
#if 0 // not currently needed after 'fatal_proc_unmounted' was refactored
library: enable an 'invariant' stack for that pids API After peeking at possible conversion of the ps program it appeared that we may ultimately need the concept of a 'static' pids_stack in suport of look_up_our_self(). In other words, one not impacted by procps_pids_reset. This patch simply sets the stage for that possibility. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-10 10:30:00 +05:30
/*
* This routine exists in case we ever want to offer something like
* 'static' or 'invarient' results stacks. By unsplicing an extent
* from the info anchor it will be isolated from future reset/free. */
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static struct stacks_extent *pids_extent_cut (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
struct stacks_extent *ext)
{
struct stacks_extent *p = info->extents;
if (ext) {
if (ext == p) {
info->extents = p->next;
library: enable an 'invariant' stack for that pids API After peeking at possible conversion of the ps program it appeared that we may ultimately need the concept of a 'static' pids_stack in suport of look_up_our_self(). In other words, one not impacted by procps_pids_reset. This patch simply sets the stage for that possibility. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-10 10:30:00 +05:30
return ext;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
do {
if (ext == p->next) {
p->next = p->next->next;
library: enable an 'invariant' stack for that pids API After peeking at possible conversion of the ps program it appeared that we may ultimately need the concept of a 'static' pids_stack in suport of look_up_our_self(). In other words, one not impacted by procps_pids_reset. This patch simply sets the stage for that possibility. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-10 10:30:00 +05:30
return ext;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
p = p->next;
} while (p);
}
library: enable an 'invariant' stack for that pids API After peeking at possible conversion of the ps program it appeared that we may ultimately need the concept of a 'static' pids_stack in suport of look_up_our_self(). In other words, one not impacted by procps_pids_reset. This patch simply sets the stage for that possibility. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-10 10:30:00 +05:30
return NULL;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_extent_cut
library: refactor flawed function fatal_proc_unmounted This commit addresses a potentially disastrous flaw in that fatal_proc_unmounted() function wherein requested item(s) might not have been returned to the caller yet were specified at the time of a 'new' or 'reset' call. The root cause, uncovered by Craig, was due to the old library look_up_our_self() support function which only would populate a proc_t with limited 'stat' file data. This routine will now act the same as all other <pids> functions which return a stack or stacks. Whatever was specified with a 'new' or 'reset' will be returned, if the passed 'return_self' parameter is other than zero. [ as is so often the case, when flawed code is fixed ] [ former complexity can be reduced as a side benefit ] Reference(s): https://www.freelists.org/post/procps/issue-245-plus-one,2 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
#endif // ----------------------------------------------------------------
library: enable an 'invariant' stack for that pids API After peeking at possible conversion of the ps program it appeared that we may ultimately need the concept of a 'static' pids_stack in suport of look_up_our_self(). In other words, one not impacted by procps_pids_reset. This patch simply sets the stage for that possibility. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-10 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline struct pids_result *pids_itemize_stack (
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-25 10:30:00 +05:30
struct pids_result *p,
int depth,
enum pids_item *items)
{
struct pids_result *p_sav = p;
int i;
for (i = 0; i < depth; i++) {
p->item = items[i];
++p;
}
return p_sav;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_itemize_stack
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-25 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static void pids_itemize_stacks_all (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
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-14 10:30:00 +05:30
{
struct stacks_extent *ext = info->extents;
while (ext) {
int i;
for (i = 0; ext->stacks[i]; i++)
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_itemize_stack(ext->stacks[i]->head, info->curitems, info->items);
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-14 10:30:00 +05:30
ext = ext->next;
};
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_itemize_stacks_all
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-14 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline int pids_items_check_failed (
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 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-15 10:30:00 +05:30
enum pids_item *items,
int numitems)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
int i;
library: beef up 'enum pids_item' parameter validation I was surprised to find that ol' gcc silently converts a single (different) enum into an address where one or more enums were expected to be dereferenced. Of course this was just yet another way to generate an old SEGV. So this commit will strengthen those parameter checks. [ we will *not* blame Craig for a failure to consult ] [ the documentation, since it doesn't even exist yet ] Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix,8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-30 10:30:00 +05:30
/* if an enum is passed instead of an address of one or more enums, ol' gcc
* will silently convert it to an address (possibly NULL). only clang will
* offer any sort of warning like the following:
*
* warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'enum pids_item *'
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
* if (procps_pids_new(&info, PIDS_noop, 3) < 0)
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 00:44:14 +05:30
* ^~~~~~~~~~~~~~~~
library: beef up 'enum pids_item' parameter validation I was surprised to find that ol' gcc silently converts a single (different) enum into an address where one or more enums were expected to be dereferenced. Of course this was just yet another way to generate an old SEGV. So this commit will strengthen those parameter checks. [ we will *not* blame Craig for a failure to consult ] [ the documentation, since it doesn't even exist yet ] Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix,8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-30 10:30:00 +05:30
*/
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-14 10:30:00 +05:30
if (numitems < 1
library: more miscellaneous pids implementation tweaks A patch containing the following miscellaneous tweaks: . make a supposedly robust parameter test truly robust [ ensure the largest enum value used with validation ] . remove duplicate item test in cleanup_stack function [ is already subordinate to test of PROCPS_PIDS_noop ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-01 10:30:00 +05:30
|| (void *)items < (void *)0x8000) // twice as big as our largest enum
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
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-14 10:30:00 +05:30
for (i = 0; i < numitems; i++) {
library: accumulated changes to <pids> code & comments A patch containing the following miscellaneous tweaks: . avoided distortions unique to PROCPS_PIDS_TICS_DELTA . addressed several smatch warnings and/or suggestions . ensured oldproc_close invoked should tally_proc fail . keeping that namespace clean, added a missing #undef . added 2 comments acknowledging pids_item as unsigned . added/clarified comments regarding proc flags & strv From smatch analysis: . these were indeed boo-boos pids.c:580 make_hist() warn: the 'Hr' macro might need parens pids.c:1058 procps_pids_reap() warn: variable dereferenced before check 'info' (see line 1056) . these were not errors (and we did double check) pids.c:1067 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 pids.c:1068 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-28 10:30:00 +05:30
// a pids_item is currently unsigned, but we'll protect our future
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
if (items[i] < 0)
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (items[i] >= PIDS_logical_end) {
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
}
return 0;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_items_check_failed
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline void pids_libflags_set (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
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 e7585992d9c0743246247b3d6ee0041942fe07d5
2016-04-25 10:30:00 +05:30
enum pids_item e;
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 0580a7b4c67d0297629d37281b4f690894429626 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-19 10:30:00 +05:30
int i;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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-14 10:30:00 +05:30
info->oldflags = info->history_yes = 0;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
for (i = 0; i < info->curitems; i++) {
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (((e = info->items[i])) >= PIDS_logical_end)
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 e7585992d9c0743246247b3d6ee0041942fe07d5
2016-04-25 10:30:00 +05:30
break;
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-14 10:30:00 +05:30
info->oldflags |= Item_table[e].oldflags;
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 e7585992d9c0743246247b3d6ee0041942fe07d5
2016-04-25 10:30:00 +05:30
info->history_yes |= Item_table[e].needhist;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
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-14 10:30:00 +05:30
if (info->oldflags & f_either) {
library: prefer /proc/stat before /proc/status, <pids> Long ago, in a galaxy far away (when top was in charge of library FILL flgs) /proc/status was to be preferred over /proc/stat if a field could be satisfied by both. This was done to avoid costly 64-bit math emulation in a 32-bit application due to 'unsigned long long' data. Well it's time to acknowledge the prevalence of 64-bit platforms. And in such an environment the cost picture has shifted significantly. It now costs 14 times (wow) as much to access /proc/status compared to /proc/stat. In other words, even with '%llu' variables, a sscanf() call in stat2proc() beats the pants off that home brew gperf based hashing employed by the status2proc() guy. In fact, status2proc incurs higher costs than found in the most expensive aspect of top's forest view option. Here's a gprof extract to illustrate the costs. It was produced with an rcfile requiring fields from both the /proc/stat & /proc/status pseudo files (among others). There were 5000 iterations in each of 4 separate gprof runs subsequently merged into 1 gmon.sum for analysis. % self self time seconds calls us/call name ----- ------- ------- ------- ----------- 28.65 4.10 4689423 0.87 status2proc 26.14 3.74 40000 93.50 forest_adds ... 01.96 0.28 4689427 0.06 stat2proc [ since forest_adds is recursive, the calls value is ] [ the non-recursive #, its 'call graph' shows totals ] Anyway, now that such cost is known this patch becomes what is euphemistically known as the usual no-brainer. [ jeeze, was it really this long between profilings? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (!(info->oldflags & (f_stat | f_status)))
info->oldflags |= f_stat;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
return;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_libflags_set
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline void pids_oldproc_close (
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-14 10:30:00 +05:30
PROCTAB **this)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
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-14 10:30:00 +05:30
if (*this != NULL) {
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
int errsav = errno;
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-14 10:30:00 +05:30
closeproc(*this);
*this = NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = errsav;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_oldproc_close
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline int pids_oldproc_open (
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-14 10:30:00 +05:30
PROCTAB **this,
unsigned flags,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
...)
{
va_list vl;
int *ids;
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
int num = 0;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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-14 10:30:00 +05:30
if (*this == NULL) {
va_start(vl, flags);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
ids = va_arg(vl, int*);
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-14 10:30:00 +05:30
if (flags & PROC_UID) num = va_arg(vl, int);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
va_end(vl);
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-14 10:30:00 +05:30
if (NULL == (*this = openproc(flags, ids, num)))
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return 0;
}
return 1;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_oldproc_open
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static inline int pids_proc_tally (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
struct pids_counts *counts,
proc_t *p)
{
switch (p->state) {
case 'R':
++counts->running;
break;
library: account for idle state ('I') threads in total With the documentation update in the commit referenced below, we should also account for such threads as they will already be represented in the task/thread totals. [ and do it in a way that might avoid future changes ] Reference(s): commit 91df65b9e778b9d7da7952d766e129f58423b807 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-01-13 11:30:00 +05:30
case 'D': // 'D' (disk sleep)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
case 'S':
++counts->sleeping;
break;
library: account for idle state ('I') threads in total With the documentation update in the commit referenced below, we should also account for such threads as they will already be represented in the task/thread totals. [ and do it in a way that might avoid future changes ] Reference(s): commit 91df65b9e778b9d7da7952d766e129f58423b807 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-01-13 11:30:00 +05:30
case 't': // 't' (tracing stop)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
case 'T':
++counts->stopped;
break;
case 'Z':
++counts->zombied;
break;
library: account for idle state ('I') threads in total With the documentation update in the commit referenced below, we should also account for such threads as they will already be represented in the task/thread totals. [ and do it in a way that might avoid future changes ] Reference(s): commit 91df65b9e778b9d7da7952d766e129f58423b807 Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-01-13 11:30:00 +05:30
default:
/* currently: 'I' (idle),
'P' (parked),
'X' (dead - actually 'dying' & probably never seen)
*/
++counts->other;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
break;
}
++counts->total;
if (info->history_yes)
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return pids_make_hist(info, p);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return 1;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_proc_tally
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
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-01 10:30:00 +05:30
/*
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
* pids_stacks_alloc():
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-01 10:30:00 +05:30
*
* Allocate and initialize one or more stacks each of which is anchored in an
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
* associated context structure.
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-01 10:30:00 +05:30
*
* All such stacks will will have their result structures properly primed with
* 'items', while the result itself will be zeroed.
*
* Returns an array of pointers representing the 'heads' of each new stack.
*/
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static struct stacks_extent *pids_stacks_alloc (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
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-01 10:30:00 +05:30
int maxstacks)
{
struct stacks_extent *p_blob;
struct pids_stack **p_vect;
struct pids_stack *p_head;
size_t vect_size, head_size, list_size, blob_size;
void *v_head, *v_list;
int i;
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-14 10:30:00 +05:30
vect_size = sizeof(void *) * maxstacks; // size of the addr vectors |
vect_size += sizeof(void *); // plus NULL addr delimiter |
head_size = sizeof(struct pids_stack); // size of that head struct |
list_size = sizeof(struct pids_result) * info->maxitems; // any single results stack |
blob_size = sizeof(struct stacks_extent); // the extent anchor itself |
blob_size += vect_size; // plus room for addr vects |
blob_size += head_size * maxstacks; // plus room for head thing |
blob_size += list_size * maxstacks; // plus room for our stacks |
/* note: all of our memory is allocated in a single blob, facilitating a later free(). |
as a minimum, it is important that the result structures themselves always be |
contiguous for every stack since they are accessed through relative position. | */
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-01 10:30:00 +05:30
if (NULL == (p_blob = calloc(1, blob_size)))
return NULL;
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-14 10:30:00 +05:30
p_blob->next = info->extents; // push this extent onto... |
info->extents = p_blob; // ...some existing extents |
p_vect = (void *)p_blob + sizeof(struct stacks_extent); // prime our vector pointer |
p_blob->stacks = p_vect; // set actual vectors start |
v_head = (void *)p_vect + vect_size; // prime head pointer start |
v_list = v_head + (head_size * maxstacks); // prime our stacks pointer |
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-01 10:30:00 +05:30
for (i = 0; i < maxstacks; i++) {
p_head = (struct pids_stack *)v_head;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
p_head->head = pids_itemize_stack((struct pids_result *)v_list, info->curitems, info->items);
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-01 10:30:00 +05:30
p_blob->stacks[i] = p_head;
v_list += list_size;
v_head += head_size;
}
p_blob->ext_numstacks = maxstacks;
return p_blob;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_stacks_alloc
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-01 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
static int pids_stacks_fetch (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
{
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-14 10:30:00 +05:30
#define n_alloc info->fetch.n_alloc
#define n_inuse info->fetch.n_inuse
#define n_saved info->fetch.n_alloc_save
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
struct stacks_extent *ext;
// initialize stuff -----------------------------------
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-14 10:30:00 +05:30
if (!info->fetch.anchor) {
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
if (!(info->fetch.anchor = calloc(STACKS_INIT, sizeof(void *))))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1;
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
if (!(ext = pids_stacks_alloc(info, STACKS_INIT)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1; // here, errno was set to ENOMEM
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
memcpy(info->fetch.anchor, ext->stacks, sizeof(void *) * STACKS_INIT);
n_alloc = STACKS_INIT;
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-14 10:30:00 +05:30
}
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_toggle_history(info);
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-23 10:30:00 +05:30
memset(&info->fetch.counts, 0, sizeof(struct pids_counts));
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
// iterate stuff --------------------------------------
n_inuse = 0;
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
while (info->read_something(info->fetch_PT, &info->fetch_proc)) {
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
if (!(n_inuse < n_alloc)) {
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
n_alloc += STACKS_GROW;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (!(info->fetch.anchor = realloc(info->fetch.anchor, sizeof(void *) * n_alloc))
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
|| (!(ext = pids_stacks_alloc(info, STACKS_GROW))))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1; // here, errno was set to ENOMEM
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
memcpy(info->fetch.anchor + n_inuse, ext->stacks, sizeof(void *) * STACKS_GROW);
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
}
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
if (!pids_proc_tally(info, &info->fetch.counts, &info->fetch_proc))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1; // here, errno was set to ENOMEM
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
if (!pids_assign_results(info, info->fetch.anchor[n_inuse++], &info->fetch_proc))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1; // here, errno was set to ENOMEM
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
}
library: added some justification emphasis, <pids> api I almost feel like I should apologize for this kind of patch ( *almost* ). But, since this comment was unique to the <pids> api and since it was especially designed to align with the following comment and since the next comment already carried the alignment emphasis, I will refrain from issuing any apology and submit it anyway. [ plus to prove that i am not totally anal-retentive ] [ and can exercise some restraint there are two more ] [ places where i COULD have added alignment emphasis ] [ see lines 804-806 and lines 1360-1361 for my proof ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-24 20:54:57 +05:30
/* while the possibility is extremely remote, the readproc.c (read_something) |
simple_readproc and simple_readtask guys could have encountered this error |
in which case they would have returned a NULL, thus ending our while loop. | */
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (errno == ENOMEM)
return -1;
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
// finalize stuff -------------------------------------
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-09 10:30:00 +05:30
/* note: we go to this trouble of maintaining a duplicate of the consolidated |
extent stacks addresses represented as our 'anchor' since these ptrs |
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-01 10:30:00 +05:30
are exposed to a user (um, not that we don't trust 'em or anything). |
plus, we can NULL delimit these ptrs which we couldn't do otherwise. | */
if (n_saved < n_inuse + 1) {
n_saved = n_inuse + 1;
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-06 10:30:00 +05:30
if (!(info->fetch.results.stacks = realloc(info->fetch.results.stacks, sizeof(void *) * n_saved)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1;
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-14 10:30:00 +05:30
}
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-06 10:30:00 +05:30
memcpy(info->fetch.results.stacks, info->fetch.anchor, sizeof(void *) * n_inuse);
info->fetch.results.stacks[n_inuse] = NULL;
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-01 10:30:00 +05:30
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
return n_inuse; // callers beware, this might be zero !
#undef n_alloc
#undef n_inuse
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-14 10:30:00 +05:30
#undef n_saved
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
} // end: pids_stacks_fetch
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-01 10:30:00 +05:30
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
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-14 10:30:00 +05:30
// --- standard required functions --------------------------------------------
library: introduce a fatal 'proc not mounted' function Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-11 10:30:00 +05:30
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
/*
* procps_pids_new():
*
* @info: location of returned new structure
*
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-13 10:30:00 +05:30
* Returns: < 0 on failure, 0 on success along with
* a pointer to a new context struct
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
*/
PROCPS_EXPORT int procps_pids_new (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info **info,
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-14 10:30:00 +05:30
enum pids_item *items,
int numitems)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *p;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int pgsz;
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
#ifdef ITEMTABLE_DEBUG
int i, failed = 0;
for (i = 0; i < MAXTABLE(Item_table); i++) {
if (i != Item_table[i].enumnumb) {
fprintf(stderr, "%s: enum/table error: Item_table[%d] was %s, but its value is %d\n"
, __FILE__, i, Item_table[i].enum2str, Item_table[i].enumnumb);
failed = 1;
}
}
library: extend ITEMTABLE_DEBUG just a tad, <PIDS> api Under the above #define this commit now also addresses 2 additional possible toe stubbers involving 'select'. If some readproc.h constants were uncoupled from their pids.h enumerators a 'make check-lib' will now detect. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-21 11:30:00 +05:30
if (PIDS_SELECT_PID != PROC_PID) {
fprintf(stderr, "%s: header error: PIDS_SELECT_PID = 0x%04x, PROC_PID = 0x%04x\n"
, __FILE__, PIDS_SELECT_PID, PROC_PID);
failed = 1;
}
library: repair <pids> api boo-boo in the 'select' i/f The patch referenced below corrected some flaws in the procps_pids_select implementation. But, there remained one flaw which this commit will now hopefully address. Rather than assume callers wished to select only tasks and not threads meant a command like 'top -H -p 10329' works differently under newlib than release 3.3.17. It fails to honor the '-H' (threads) switch under newlib. So, to fix that oops, we'll allow that select function to get threads or tasks depending on its 'which' parm. Reference(s): . Oct 2015, some flaws corrected commit bc616b361596bc3008800de839b88446508cfdd0 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-07 10:30:00 +05:30
if (PIDS_SELECT_PID_THREADS != PIDS_SELECT_PID + 1) {
fprintf(stderr, "%s: header error: PIDS_SELECT_PID_THREADS = 0x%04x, should be 0x%04x\n"
, __FILE__, PIDS_SELECT_PID_THREADS, PIDS_SELECT_PID + 1);
failed = 1;
}
library: extend ITEMTABLE_DEBUG just a tad, <PIDS> api Under the above #define this commit now also addresses 2 additional possible toe stubbers involving 'select'. If some readproc.h constants were uncoupled from their pids.h enumerators a 'make check-lib' will now detect. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-21 11:30:00 +05:30
if (PIDS_SELECT_UID != PROC_UID) {
fprintf(stderr, "%s: header error: PIDS_SELECT_UID = 0x%04x, PROC_UID = 0x%04x\n"
, __FILE__, PIDS_SELECT_UID, PROC_UID);
failed = 1;
}
library: repair <pids> api boo-boo in the 'select' i/f The patch referenced below corrected some flaws in the procps_pids_select implementation. But, there remained one flaw which this commit will now hopefully address. Rather than assume callers wished to select only tasks and not threads meant a command like 'top -H -p 10329' works differently under newlib than release 3.3.17. It fails to honor the '-H' (threads) switch under newlib. So, to fix that oops, we'll allow that select function to get threads or tasks depending on its 'which' parm. Reference(s): . Oct 2015, some flaws corrected commit bc616b361596bc3008800de839b88446508cfdd0 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-07 10:30:00 +05:30
if (PIDS_SELECT_UID_THREADS != PIDS_SELECT_UID + 1) {
fprintf(stderr, "%s: header error: PIDS_SELECT_UID_THREADS = 0x%04x, should be 0x%04x\n"
, __FILE__, PIDS_SELECT_UID_THREADS, PIDS_SELECT_UID + 1);
failed = 1;
}
// our select() function & select enumerators assume the following ...
if (PIDS_FETCH_THREADS_TOO != 1) {
fprintf(stderr, "%s: header error: PIDS_FETCH_THREADS_TOO = %d, should be 1\n"
, __FILE__, PIDS_FETCH_THREADS_TOO);
failed = 1;
}
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
if (failed) _Exit(EXIT_FAILURE);
#endif
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
if (info == NULL || *info != NULL)
return -EINVAL;
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
if (!(p = calloc(1, sizeof(struct pids_info))))
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return -ENOMEM;
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-14 10:30:00 +05:30
/* if we're without items or numitems, a later call to
procps_pids_reset() will become mandatory */
if (items && numitems) {
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if (pids_items_check_failed(items, numitems)) {
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 00:44:14 +05:30
free(p);
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-14 10:30:00 +05:30
return -EINVAL;
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 00:44:14 +05:30
}
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
// allow for our PIDS_logical_end
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-14 10:30:00 +05:30
p->maxitems = numitems + 1;
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 00:44:14 +05:30
if (!(p->items = calloc(p->maxitems, sizeof(enum pids_item)))) {
free(p);
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-14 10:30:00 +05:30
return -ENOMEM;
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 00:44:14 +05:30
}
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-14 10:30:00 +05:30
memcpy(p->items, items, sizeof(enum pids_item) * numitems);
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
p->items[numitems] = PIDS_logical_end;
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-14 10:30:00 +05:30
p->curitems = p->maxitems;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_libflags_set(p);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
}
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
if (!(p->hist = calloc(1, sizeof(struct history_info)))
|| (!(p->hist->PHist_new = calloc(NEWOLD_INIT, sizeof(HST_t))))
|| (!(p->hist->PHist_sav = calloc(NEWOLD_INIT, sizeof(HST_t))))) {
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 00:44:14 +05:30
free(p->items);
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
if (p->hist) {
free(p->hist->PHist_sav); // this & next might be NULL ...
free(p->hist->PHist_new);
free(p->hist);
}
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 00:44:14 +05:30
free(p);
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-14 10:30:00 +05:30
return -ENOMEM;
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 00:44:14 +05:30
}
library: tweak the memory allocation logic, <pids> api This patch separates the memory allocations into those used initially from those used in later reallocations. Thus, we can reduce that iterative realloc() overhead. Additionally, we'll correct a long standing oops where multiple history_info structures were created at 'new' time when only one should have been allocated (jeeze). [ originally the allocation was strangely based upon ] [ number of 'items' (???) & later a #define constant ] Reference(s): . May, 2016 - subsequent bad history_info logic commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f . Aug, 2015 - original faulty history_info code commit 7e6a371d8a36b250a2edddff9f5d059640b8132e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-30 10:30:00 +05:30
p->hist->HHist_siz = NEWOLD_INIT;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_config_history(p);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
pgsz = getpagesize();
while (pgsz > 1024) { pgsz >>= 1; p->pgs2k_shift++; }
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-09-30 10:30:00 +05:30
p->hertz = procps_hertz_get();
library: tweak logic for /proc not mounted, <pids> api Since 'procps_uptime' will access the /proc filesystem the <pids> 'new' guy should should protect against the possibility /proc isn't mounted when 'boot_seconds' is established. A zero is better than the negative value. [ the only distortion would be to PIDS_TIME_ELAPSED. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-14 11:30:00 +05:30
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
numa_init();
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-23 10:30:00 +05:30
p->fetch.results.counts = &p->fetch.counts;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
p->refcount = 1;
*info = p;
return 0;
} // end: procps_pids_new
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-14 10:30:00 +05:30
PROCPS_EXPORT int procps_pids_ref (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info)
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
{
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-14 10:30:00 +05:30
if (info == NULL)
return -EINVAL;
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
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-14 10:30:00 +05:30
info->refcount++;
return info->refcount;
} // end: procps_pids_ref
PROCPS_EXPORT int procps_pids_unref (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info **info)
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-14 10:30:00 +05:30
{
if (info == NULL || *info == NULL)
return -EINVAL;
(*info)->refcount--;
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
if ((*info)->refcount < 1) {
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-14 10:30:00 +05:30
#ifdef UNREF_RPTHASH
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_unref_rpthash(*info);
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-14 10:30:00 +05:30
#endif
if ((*info)->extents) {
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_cleanup_stacks_all(*info);
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-14 10:30:00 +05:30
do {
struct stacks_extent *p = (*info)->extents;
(*info)->extents = (*info)->extents->next;
free(p);
} while ((*info)->extents);
}
if ((*info)->otherexts) {
struct stacks_extent *nextext, *ext = (*info)->otherexts;
while (ext) {
nextext = ext->next;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_cleanup_stack(ext->stacks[0]->head);
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-14 10:30:00 +05:30
free(ext);
ext = nextext;
};
}
if ((*info)->fetch.anchor)
free((*info)->fetch.anchor);
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-06 10:30:00 +05:30
if ((*info)->fetch.results.stacks)
free((*info)->fetch.results.stacks);
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-14 10:30:00 +05:30
if ((*info)->items)
free((*info)->items);
if ((*info)->hist) {
free((*info)->hist->PHist_sav);
free((*info)->hist->PHist_new);
free((*info)->hist);
}
library: tweak support for get/select/reap, <PIDS> api When the <pids> api was refactored in the commit shown below, one objective was enabling the simultaneous use of 'get' & 'select/reap' functions. Unlike other 'get' functions, this <pids> 'get' acts as an iterator where successive calls will return successive tasks/threads. However, that goal wasn't quite met since a stack used by 'get' was commingled with the 'select/reap' stacks. Such commingling supported the 'reset' function, again a provision which was unique to this <pids> interface. Unfortunately, some poor assumptions in 'stacks_fetch' produced a SEGV whenever 'reap/select' followed 'get'. Thus, this patch addresses those issues and guarantees such commingled stacks (extents) will be accommodated. Reference(s): . standardize portions of interface, <PIDS> api commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-02 10:30:00 +05:30
if ((*info)->get_ext)
pids_oldproc_close(&(*info)->get_PT);
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
numa_uninit();
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-14 10:30:00 +05:30
free(*info);
*info = NULL;
return 0;
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
}
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-14 10:30:00 +05:30
return (*info)->refcount;
} // end: procps_pids_unref
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
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-14 10:30:00 +05:30
// --- variable interface functions -------------------------------------------
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
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-14 10:30:00 +05:30
PROCPS_EXPORT struct pids_stack *fatal_proc_unmounted (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
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-14 10:30:00 +05:30
int return_self)
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
{
library: refactor flawed function fatal_proc_unmounted This commit addresses a potentially disastrous flaw in that fatal_proc_unmounted() function wherein requested item(s) might not have been returned to the caller yet were specified at the time of a 'new' or 'reset' call. The root cause, uncovered by Craig, was due to the old library look_up_our_self() support function which only would populate a proc_t with limited 'stat' file data. This routine will now act the same as all other <pids> functions which return a stack or stacks. Whatever was specified with a 'new' or 'reset' will be returned, if the passed 'return_self' parameter is other than zero. [ as is so often the case, when flawed code is fixed ] [ former complexity can be reduced as a side benefit ] Reference(s): https://www.freelists.org/post/procps/issue-245-plus-one,2 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
struct pids_fetch *fetched;
unsigned tid;
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
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 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-15 10:30:00 +05:30
/* this is very likely the *only* newlib function where the
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
context (pids_info) of NULL will ever be permitted */
library: address an 'uninitialised value' VALGRIND bug Thanks to valgrind and his --track-origins=yes option, the problem and solution was suggested as shown below. [ and it was created in that commit referenced below ] But, after attacking this problem by adding a memset() call in pids.c, a 2nd valgrind oops, also shown below, was encountered. The dynamically acquired 'cmd' again! [ might help to explain why changes appear excessive ] Reference(s): . 1st valgrind discovery ==11111== Conditional jump or move depends on uninitialised value(s) ==11111== at 0x13425D: stat2proc (readproc.c:582) ==11111== by 0x137436: look_up_our_self (readproc.c:1613) ==11111== by 0x132196: fatal_proc_unmounted (pids.c:1388) ==11111== by 0x11BA4D: before (top.c:3580) ==11111== by 0x127E10: main (top.c:7173) ==11111== Uninitialised value was created by a stack allocation ==11111== at 0x132165: fatal_proc_unmounted (pids.c:1381) . Jul, 2022 - fatal_proc_unmounted refactored commit 52bd019d8ca09ecfec34b5020eb7b8d612c315f8 . 2nd valgrind discovery ==22222== 16 bytes in 1 blocks are definitely lost ==22222== by 0x4A0E60E: strdup (strdup.c:42) ==22222== by 0x133D00: stat2proc (readproc.c:587) ==22222== by 0x136E67: look_up_our_self (readproc.c:1613) ==22222== by 0x131BC7: fatal_proc_unmounted (pids.c:1390) ==22222== by 0x11B7C6: before (top.c:3580) ==22222== by 0x127828: main (top.c:7173) Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-07 10:30:00 +05:30
if (!look_up_our_self()
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
|| (!return_self))
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-14 10:30:00 +05:30
return NULL;
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
library: refactor flawed function fatal_proc_unmounted This commit addresses a potentially disastrous flaw in that fatal_proc_unmounted() function wherein requested item(s) might not have been returned to the caller yet were specified at the time of a 'new' or 'reset' call. The root cause, uncovered by Craig, was due to the old library look_up_our_self() support function which only would populate a proc_t with limited 'stat' file data. This routine will now act the same as all other <pids> functions which return a stack or stacks. Whatever was specified with a 'new' or 'reset' will be returned, if the passed 'return_self' parameter is other than zero. [ as is so often the case, when flawed code is fixed ] [ former complexity can be reduced as a side benefit ] Reference(s): https://www.freelists.org/post/procps/issue-245-plus-one,2 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
tid = getpid();
if (!(fetched = procps_pids_select(info, &tid, 1, PIDS_SELECT_PID)))
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 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-15 10:30:00 +05:30
return NULL;
library: refactor flawed function fatal_proc_unmounted This commit addresses a potentially disastrous flaw in that fatal_proc_unmounted() function wherein requested item(s) might not have been returned to the caller yet were specified at the time of a 'new' or 'reset' call. The root cause, uncovered by Craig, was due to the old library look_up_our_self() support function which only would populate a proc_t with limited 'stat' file data. This routine will now act the same as all other <pids> functions which return a stack or stacks. Whatever was specified with a 'new' or 'reset' will be returned, if the passed 'return_self' parameter is other than zero. [ as is so often the case, when flawed code is fixed ] [ former complexity can be reduced as a side benefit ] Reference(s): https://www.freelists.org/post/procps/issue-245-plus-one,2 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-07-28 10:30:00 +05:30
return fetched->stacks[0];
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-14 10:30:00 +05:30
} // end: fatal_proc_unmounted
PROCPS_EXPORT struct pids_stack *procps_pids_get (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
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-14 10:30:00 +05:30
enum pids_fetch_type which)
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
{
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
double up_secs;
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-14 10:30:00 +05:30
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
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-14 10:30:00 +05:30
if (info == NULL)
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (which != PIDS_FETCH_TASKS_ONLY && which != PIDS_FETCH_THREADS_TOO)
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-14 10:30:00 +05:30
return NULL;
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 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-15 10:30:00 +05:30
/* with items & numitems technically optional at 'new' time, it's
expected 'reset' will have been called -- but just in case ... */
if (!info->curitems)
return NULL;
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-14 10:30:00 +05:30
if (!info->get_ext) {
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if (!(info->get_ext = pids_stacks_alloc(info, 1)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return NULL; // here, errno was overridden with ENOMEM
library: tweak support for get/select/reap, <PIDS> api When the <pids> api was refactored in the commit shown below, one objective was enabling the simultaneous use of 'get' & 'select/reap' functions. Unlike other 'get' functions, this <pids> 'get' acts as an iterator where successive calls will return successive tasks/threads. However, that goal wasn't quite met since a stack used by 'get' was commingled with the 'select/reap' stacks. Such commingling supported the 'reset' function, again a provision which was unique to this <pids> interface. Unfortunately, some poor assumptions in 'stacks_fetch' produced a SEGV whenever 'reap/select' followed 'get'. Thus, this patch addresses those issues and guarantees such commingled stacks (extents) will be accommodated. Reference(s): . standardize portions of interface, <PIDS> api commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-02 10:30:00 +05:30
fresh_start:
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if (!pids_oldproc_open(&info->get_PT, info->oldflags))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return NULL; // here, errno was overridden with ENOMEM/others
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-14 10:30:00 +05:30
info->get_type = which;
info->read_something = which ? readeither : readproc;
}
if (info->get_type != which) {
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_oldproc_close(&info->get_PT);
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-14 10:30:00 +05:30
goto fresh_start;
}
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
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-14 10:30:00 +05:30
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
/* when in a namespace with proc mounted subset=pid,
we will be restricted to process information only */
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
info->boot_tics = 0;
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
if (0 >= procps_uptime(&up_secs, NULL))
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
info->boot_tics = up_secs * info->hertz;
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
if (NULL == info->read_something(info->get_PT, &info->get_proc))
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-14 10:30:00 +05:30
return NULL;
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
if (!pids_assign_results(info, info->get_ext->stacks[0], &info->get_proc))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return NULL;
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-14 10:30:00 +05:30
return info->get_ext->stacks[0];
} // end: procps_pids_get
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
/* procps_pids_reap():
*
* Harvest all the available tasks/threads and provide the result
* stacks along with a summary of the information gathered.
*
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-14 10:30:00 +05:30
* Returns: pointer to a pids_fetch struct on success, NULL on error.
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
*/
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-14 10:30:00 +05:30
PROCPS_EXPORT struct pids_fetch *procps_pids_reap (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
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-14 10:30:00 +05:30
enum pids_fetch_type which)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
double up_secs;
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
int rc;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
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-14 10:30:00 +05:30
if (info == NULL)
library: fix major oops in procps_pids_reap() function In my zeal to finalize the initial pids implementation I omitted some quite important parameter checking from the above function. Thank goodness top was kind to us. Also, in anticipation of the additions of single stack read and supporting functions some items were renamed. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (which != PIDS_FETCH_TASKS_ONLY && which != PIDS_FETCH_THREADS_TOO)
library: fix major oops in procps_pids_reap() function In my zeal to finalize the initial pids implementation I omitted some quite important parameter checking from the above function. Thank goodness top was kind to us. Also, in anticipation of the additions of single stack read and supporting functions some items were renamed. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
return NULL;
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 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-15 10:30:00 +05:30
/* with items & numitems technically optional at 'new' time, it's
expected 'reset' will have been called -- but just in case ... */
if (!info->curitems)
return NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if (!pids_oldproc_open(&info->fetch_PT, info->oldflags))
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return NULL;
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
info->read_something = which ? readeither : readproc;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
/* when in a namespace with proc mounted subset=pid,
we will be restricted to process information only */
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
info->boot_tics = 0;
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
if (0 >= procps_uptime(&up_secs, NULL))
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
info->boot_tics = up_secs * info->hertz;
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
rc = pids_stacks_fetch(info);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_oldproc_close(&info->fetch_PT);
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
// we better have found at least 1 pid
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-06 10:30:00 +05:30
return (rc > 0) ? &info->fetch.results : NULL;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
} // end: procps_pids_reap
PROCPS_EXPORT int procps_pids_reset (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
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-14 10:30:00 +05:30
enum pids_item *newitems,
int newnumitems)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
{
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-14 10:30:00 +05:30
if (info == NULL || newitems == NULL)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return -EINVAL;
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if (pids_items_check_failed(newitems, newnumitems))
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return -EINVAL;
library: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
pids_cleanup_stacks_all(info);
library: tweak support for get/select/reap, <PIDS> api When the <pids> api was refactored in the commit shown below, one objective was enabling the simultaneous use of 'get' & 'select/reap' functions. Unlike other 'get' functions, this <pids> 'get' acts as an iterator where successive calls will return successive tasks/threads. However, that goal wasn't quite met since a stack used by 'get' was commingled with the 'select/reap' stacks. Such commingling supported the 'reset' function, again a provision which was unique to this <pids> interface. Unfortunately, some poor assumptions in 'stacks_fetch' produced a SEGV whenever 'reap/select' followed 'get'. Thus, this patch addresses those issues and guarantees such commingled stacks (extents) will be accommodated. Reference(s): . standardize portions of interface, <PIDS> api commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-02 10:30:00 +05:30
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
/* shame on this caller, they didn't change anything. and unless they have
altered the depth of the stacks we're not gonna change anything either! */
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-14 10:30:00 +05:30
if (info->curitems == newnumitems + 1
&& !memcmp(info->items, newitems, sizeof(enum pids_item) * newnumitems))
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return 0;
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-14 10:30:00 +05:30
if (info->maxitems < newnumitems + 1) {
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
while (info->extents) {
struct stacks_extent *p = info->extents;
info->extents = p->next;
free(p);
};
library: tweak support for get/select/reap, <PIDS> api When the <pids> api was refactored in the commit shown below, one objective was enabling the simultaneous use of 'get' & 'select/reap' functions. Unlike other 'get' functions, this <pids> 'get' acts as an iterator where successive calls will return successive tasks/threads. However, that goal wasn't quite met since a stack used by 'get' was commingled with the 'select/reap' stacks. Such commingling supported the 'reset' function, again a provision which was unique to this <pids> interface. Unfortunately, some poor assumptions in 'stacks_fetch' produced a SEGV whenever 'reap/select' followed 'get'. Thus, this patch addresses those issues and guarantees such commingled stacks (extents) will be accommodated. Reference(s): . standardize portions of interface, <PIDS> api commit 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-02 10:30:00 +05:30
if (info->get_ext) {
pids_oldproc_close(&info->get_PT);
info->get_ext = NULL;
}
if (info->fetch.anchor) {
free(info->fetch.anchor);
info->fetch.anchor = NULL;
}
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
// allow for our PIDS_logical_end
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-14 10:30:00 +05:30
info->maxitems = newnumitems + 1;
if (!(info->items = realloc(info->items, sizeof(enum pids_item) * info->maxitems)))
return -ENOMEM;
}
memcpy(info->items, newitems, sizeof(enum pids_item) * newnumitems);
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
info->items[newnumitems] = PIDS_logical_end;
// account for above PIDS_logical_end
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-14 10:30:00 +05:30
info->curitems = newnumitems + 1;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
misc: just a couple cosmetic changes for comments only Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-19 11:30:00 +05:30
// if extents were freed above, this next guy will have no effect
// so we'll rely on pids_stacks_alloc() to itemize ...
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_itemize_stacks_all(info);
pids_libflags_set(info);
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-14 10:30:00 +05:30
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return 0;
} // end: procps_pids_reset
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
/* procps_pids_select():
*
* Harvest any processes matching the specified PID or UID and provide the
* result stacks along with a summary of the information gathered.
*
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-14 10:30:00 +05:30
* Returns: pointer to a pids_fetch struct on success, NULL on error.
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
*/
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-14 10:30:00 +05:30
PROCPS_EXPORT struct pids_fetch *procps_pids_select (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
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-01 10:30:00 +05:30
unsigned *these,
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-14 10:30:00 +05:30
int numthese,
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-18 10:30:00 +05:30
enum pids_select_type which)
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-01 10:30:00 +05:30
{
unsigned ids[FILL_ID_MAX + 1];
library: trade 'float' type for a 'double', <pids> api While we really do not need the extra precision, we'll trade that recently introduced float type for a double for efficiency on a 64 bit platform. Additionally, the UTILIZATION algorithm was tweaked producing less code. The net result is four fewer machine instructions with a reduction of 14 total bytes in that function's size. Reference(s): . introduced 'real' type & 'utilization' item commit c69104b2b835176f9801dfd1a1d893579879a5b6 Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-27 11:30:00 +05:30
double up_secs;
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
int rc;
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-01 10:30:00 +05:30
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
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-14 10:30:00 +05:30
if (info == NULL || these == NULL)
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-01 10:30:00 +05:30
return NULL;
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-14 10:30:00 +05:30
if (numthese < 1 || numthese > FILL_ID_MAX)
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-01 10:30:00 +05:30
return NULL;
library: repair <pids> api boo-boo in the 'select' i/f The patch referenced below corrected some flaws in the procps_pids_select implementation. But, there remained one flaw which this commit will now hopefully address. Rather than assume callers wished to select only tasks and not threads meant a command like 'top -H -p 10329' works differently under newlib than release 3.3.17. It fails to honor the '-H' (threads) switch under newlib. So, to fix that oops, we'll allow that select function to get threads or tasks depending on its 'which' parm. Reference(s): . Oct 2015, some flaws corrected commit bc616b361596bc3008800de839b88446508cfdd0 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-07 10:30:00 +05:30
if ((which != PIDS_SELECT_PID && which != PIDS_SELECT_UID)
&& ((which != PIDS_SELECT_PID_THREADS && which != PIDS_SELECT_UID_THREADS)))
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-01 10:30:00 +05:30
return NULL;
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 9ebadc1438a6665a98a9f0782523b0f9a2a6248f Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-15 10:30:00 +05:30
/* with items & numitems technically optional at 'new' time, it's
expected 'reset' will have been called -- but just in case ... */
if (!info->curitems)
return NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
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-01 10:30:00 +05:30
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
// this zero delimiter is really only needed with PIDS_SELECT_PID
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-14 10:30:00 +05:30
memcpy(ids, these, sizeof(unsigned) * numthese);
ids[numthese] = 0;
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-01 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
if (!pids_oldproc_open(&info->fetch_PT, (info->oldflags | which), ids, numthese))
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-01 10:30:00 +05:30
return NULL;
library: repair <pids> api boo-boo in the 'select' i/f The patch referenced below corrected some flaws in the procps_pids_select implementation. But, there remained one flaw which this commit will now hopefully address. Rather than assume callers wished to select only tasks and not threads meant a command like 'top -H -p 10329' works differently under newlib than release 3.3.17. It fails to honor the '-H' (threads) switch under newlib. So, to fix that oops, we'll allow that select function to get threads or tasks depending on its 'which' parm. Reference(s): . Oct 2015, some flaws corrected commit bc616b361596bc3008800de839b88446508cfdd0 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-07 10:30:00 +05:30
info->read_something = (which & PIDS_FETCH_THREADS_TOO) ? readeither : readproc;
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-01 10:30:00 +05:30
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
/* when in a namespace with proc mounted subset=pid,
we will be restricted to process information only */
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
info->boot_tics = 0;
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
if (0 >= procps_uptime(&up_secs, NULL))
library: tighten up some TIME calculations, <pids> api This patch trades some recurring per-task calculations for calculations performed once at get, select or reap time. It was prompted by the openSUSE dif named below. [ my next commit will deal more thoroughly with that ] Reference(s) . openSUSE patch named: 'procps-ng-4.0.0-accuracy.dif' Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-04-15 10:30:00 +05:30
info->boot_tics = up_secs * info->hertz;
library: added important new functionality, <pids> api This commit introduces some new capabilities available in libproc-2 under the <PIDS> interface. Along the way errors impacting some item values have been corrected. The following summarizes the major changes being made. 1. The PIDS_TIME_START item was represented as seconds since system boot but really held tics since boot. And some programs properly divided it by Hertz to actually yield seconds while others acted as if it already was. So, now we have a new PIDS_TICS_BEGAN field and all of the 'TIME' fields properly reflect seconds. With those 'TIME' fields, the type was changed to 'float/real' so one could convert it back to tics without loss of some centiseconds reflected in the Hertz guy (usually 100). 2. The boot_seconds was established in procps_pids_new meaning it was fixed/unchanging. As a result, one item (PIDS_TIME_ELAPSED) was rendered useless. So now, each of the three retrieval functions establishes a current boot_seconds well before the set functions are called. 3. Added a PIDS_UTILIZATION item that will provide the CPU usage over the life of a process, as a percentage. 4. Added PIDS_TIME_ALL_C for symmetry with the similar item called PIDS_TICS_ALL_C (which reflects raw tics). 5. That 'derived from' notation has been added to some additional header items to reflect their true origins. Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-02-25 11:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
rc = pids_stacks_fetch(info);
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-01 10:30:00 +05:30
library: most function names now more profile friendly 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>
2016-08-21 10:30:00 +05:30
pids_oldproc_close(&info->fetch_PT);
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 0c953eccc5fe7240be9d272e1b6c0ce8769d8ed2 commit 747dfc5987e6e91ea3a8575de307e2892790c598 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-08 10:30:00 +05:30
// no guarantee any pids/uids were found
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return (rc >= 0) ? &info->fetch.results : NULL;
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-01 10:30:00 +05:30
} // end: procps_pids_select
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
/*
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-11 10:30:00 +05:30
* procps_pids_sort():
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
*
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-07 10:30:00 +05:30
* Sort stacks anchored in the passed stack pointers array
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
* based on the designated sort enumerator and specified order.
*
* Returns those same addresses sorted.
*
* Note: all of the stacks must be homogeneous (of equal length and content).
*/
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-11 10:30:00 +05:30
PROCPS_EXPORT struct pids_stack **procps_pids_sort (
library: standardize all the 'context' structure names 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>
2016-07-21 10:30:00 +05:30
struct pids_info *info,
library: miscellaneous tweaks to pid code and comments . traded a complex misaligned memory allocation scheme in the make_hist function for a simple aligned scheme. plus memory allocation increases are globally defined. . changed 1 parameter for procps_pids_stacks_sort() to better reflect the 'array of pointers', not an address of a pointer as is used with guys such as 'new/unref'. . the pids_reap struct was changed slightly to make it more reflective of it's actual implementation details. . the Item_table member .mustfree is now .needfree and that .makehist was now made .needhist for consistency. . reduced the number of separate 'return NULL;' source statements in that primary procps_pids_reap() routine. . ensured consistent reference to sizeof(void *) & not occasional reference to sizeof(void*) without a space. . rather than enable/disable validate_stacks via a #if in the function body, it is now handled via a #define. . some comments in the procps_pids_reset function were adjusted to reflect this current implementation. shown originally, they reflected an aborted attempt to avoid a testing aberration not fully understood at the time. . added a summary of the memory overhead cost of HST_t processing to that UNREF_RPTHASH output at unref time. . a 'PIDs at max depth:' portion of that UNREF_RPTHASH enabled #define is now published only when the maximum depth of hash table entry chains exceed depths of one. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-20 10:30:00 +05:30
struct pids_stack *stacks[],
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
int numstacked,
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-14 10:30:00 +05:30
enum pids_item sortitem,
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
enum pids_sort_order order)
{
struct sort_parms parms;
struct pids_result *p;
int offset;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
if (info == NULL || stacks == NULL)
return NULL;
library: accumulated changes to <pids> code & comments A patch containing the following miscellaneous tweaks: . avoided distortions unique to PROCPS_PIDS_TICS_DELTA . addressed several smatch warnings and/or suggestions . ensured oldproc_close invoked should tally_proc fail . keeping that namespace clean, added a missing #undef . added 2 comments acknowledging pids_item as unsigned . added/clarified comments regarding proc flags & strv From smatch analysis: . these were indeed boo-boos pids.c:580 make_hist() warn: the 'Hr' macro might need parens pids.c:1058 procps_pids_reap() warn: variable dereferenced before check 'info' (see line 1056) . these were not errors (and we did double check) pids.c:1067 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 pids.c:1068 procps_pids_reap() warn: double check that we're allocating correct size: 8 vs 128 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-28 10:30:00 +05:30
// a pids_item is currently unsigned, but we'll protect our future
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (sortitem < 0 || sortitem >= PIDS_logical_end)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (order != PIDS_SORT_ASCEND && order != PIDS_SORT_DESCEND)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return NULL;
if (numstacked < 2)
return stacks;
offset = 0;
p = stacks[0]->head;
for (;;) {
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-14 10:30:00 +05:30
if (p->item == sortitem)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
break;
++offset;
if (offset >= info->curitems)
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes 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>
2016-07-21 10:30:00 +05:30
if (p->item >= PIDS_logical_end)
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return NULL;
++p;
}
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
parms.offset = offset;
parms.order = order;
library: add real string vectors to the pids interface After experimenting with an adaptation of pidof to the new pids interface, it became apparent that vectorized versions of those command lines would be necessary. So this commit adds that option and the strv result type. And since the stage had been set, a vectorized version of PROCPS_PIDS_ENVIRON & PROCPS_PIDS_CGROUP was added. Lastly, any use of 'const' in the result structure was removed so callers need not be bothered with casts and compiler warnings. Hopefully, they'll respect a stack. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
qsort_r(stacks, numstacked, sizeof(void *), (QSR_t)Item_table[p->item].sortfunc, &parms);
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
return stacks;
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-11 10:30:00 +05:30
} // end: procps_pids_sort
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
// --- special debugging function(s) ------------------------------------------
/*
* The following isn't part of the normal programming interface. Rather,
* it exists to validate result types referenced in application programs.
*
* It's used only when:
* 1) the 'XTRA_PROCPS_DEBUG' has been defined, or
library: show allowable range in relative enum warning This patch just trades the 'typestr' for the much more meaningful 'valid range' when a relative enum has been deemed invalid under that XTRA_PROCPS_DEBUG provision. [ and we'll also make one comment a bit more generic ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-13 10:30:00 +05:30
* 2) an #include of 'xtra-procps-debug.h' is used
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
*/
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
PROCPS_EXPORT struct pids_result *xtra_pids_val (
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
int relative_enum,
const char *typestr,
const struct pids_stack *stack,
struct pids_info *info,
const char *file,
int lineno)
{
char *str;
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
int i;
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
for (i = 0; stack->head[i].item < PIDS_logical_end; i++)
;
if (relative_enum < 0 || relative_enum >= i) {
library: show allowable range in relative enum warning This patch just trades the 'typestr' for the much more meaningful 'valid range' when a relative enum has been deemed invalid under that XTRA_PROCPS_DEBUG provision. [ and we'll also make one comment a bit more generic ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-13 10:30:00 +05:30
fprintf(stderr, "%s line %d: invalid relative_enum = %d, valid range = 0-%d\n"
, file, lineno, relative_enum, i-1);
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
return NULL;
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
}
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
str = Item_table[stack->head[relative_enum].item].type2str;
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
if (str[0]
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
&& (strcmp(typestr, str))) {
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
library: strengthen the VAL macro validation functions 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>
2016-08-08 11:53:45 +05:30
}
return &stack->head[relative_enum];
library: clean up some miscellaneous compiler warnings Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-03 10:30:00 +05:30
(void)info;
library: provide for validating result type references 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>
2016-08-05 10:30:00 +05:30
} // end: xtra_pids_val