emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
03437d7dd3
procps/proc/pids.h

247 lines
8.5 KiB
C
Raw 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
/*
* pids.h - task/thread/process related declarations for libproc
*
* Copyright (C) 1998-2005 Albert Cahalan
* Copyright (C) 2015 Craig Small <csmall@enc.com.au>
* Copyright (C) 2015 Jim Warner <james.warner@comcast.net>
*
* 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
*/
#ifndef _PROC_PIDS_H
#define _PROC_PIDS_H
__BEGIN_DECLS
enum pids_item {
library: exchange <pids> 'addr' for that 'ul_int' type Work on converting ps has revealed the desirability of trading a void pointer for that ul_int type. There was much arithmetic employed against such values and casts would otherwise have been required. Even pmap needed a cast on occasions when comparing an internal variable. Besides, there is much to be said for reducing demands on (and the complexity of) the result structure union. [ we choose ul_int over ull_int since that former is ] [ the exact same size and capacity as a void pointer ] [ regardless of whether compiled as 32-bit or 64-bit ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-09 10:30:00 +05:30
PROCPS_PIDS_ADDR_END_CODE, // ul_int
PROCPS_PIDS_ADDR_KSTK_EIP, // ul_int
PROCPS_PIDS_ADDR_KSTK_ESP, // ul_int
PROCPS_PIDS_ADDR_START_CODE, // ul_int
PROCPS_PIDS_ADDR_START_STACK, // ul_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
PROCPS_PIDS_ALARM, // sl_int
library: added PROCPS_PIDS_CGNAME for <pids> interface The ps program was modified to print the control group names, based on the library provided list of all those control groups to which a process belongs. But this is probably something the newlib should be doing for all. So this commit borrows the ps approach to cg names and thus will make that available to all future consumers. [ but stay tuned! there is a commit coming soon that ] [ represents a rather major internal redesign, which ] [ was prompted by the ps and top adaptation testing. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-12 10:30:00 +05:30
PROCPS_PIDS_CGNAME, // 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
PROCPS_PIDS_CGROUP, // str
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
PROCPS_PIDS_CGROUP_V, // 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
PROCPS_PIDS_CMD, // str
PROCPS_PIDS_CMDLINE, // str
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
PROCPS_PIDS_CMDLINE_V, // 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
PROCPS_PIDS_ENVIRON, // str
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
PROCPS_PIDS_ENVIRON_V, // 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
PROCPS_PIDS_EXIT_SIGNAL, // s_int
PROCPS_PIDS_FLAGS, // ul_int
PROCPS_PIDS_FLT_MAJ, // ul_int
PROCPS_PIDS_FLT_MAJ_C, // ul_int
PROCPS_PIDS_FLT_MAJ_DELTA, // ul_int
PROCPS_PIDS_FLT_MIN, // ul_int
PROCPS_PIDS_FLT_MIN_C, // ul_int
PROCPS_PIDS_FLT_MIN_DELTA, // ul_int
PROCPS_PIDS_ID_EGID, // u_int
PROCPS_PIDS_ID_EGROUP, // str
PROCPS_PIDS_ID_EUID, // u_int
PROCPS_PIDS_ID_EUSER, // str
PROCPS_PIDS_ID_FGID, // u_int
PROCPS_PIDS_ID_FGROUP, // str
PROCPS_PIDS_ID_FUID, // u_int
PROCPS_PIDS_ID_FUSER, // str
PROCPS_PIDS_ID_PGRP, // s_int
PROCPS_PIDS_ID_PID, // s_int
PROCPS_PIDS_ID_PPID, // s_int
PROCPS_PIDS_ID_RGID, // u_int
PROCPS_PIDS_ID_RGROUP, // str
PROCPS_PIDS_ID_RUID, // u_int
PROCPS_PIDS_ID_RUSER, // str
PROCPS_PIDS_ID_SESSION, // s_int
PROCPS_PIDS_ID_SGID, // u_int
PROCPS_PIDS_ID_SGROUP, // str
PROCPS_PIDS_ID_SUID, // u_int
PROCPS_PIDS_ID_SUSER, // str
PROCPS_PIDS_ID_TGID, // s_int
PROCPS_PIDS_ID_TPGID, // s_int
PROCPS_PIDS_LXCNAME, // str
PROCPS_PIDS_MEM_CODE, // sl_int
PROCPS_PIDS_MEM_CODE_KIB, // ul_int
PROCPS_PIDS_MEM_DATA, // sl_int
PROCPS_PIDS_MEM_DATA_KIB, // ul_int
PROCPS_PIDS_MEM_DT, // sl_int
PROCPS_PIDS_MEM_LRS, // sl_int
PROCPS_PIDS_MEM_RES, // sl_int
PROCPS_PIDS_MEM_RES_KIB, // ul_int
PROCPS_PIDS_MEM_SHR, // sl_int
PROCPS_PIDS_MEM_SHR_KIB, // ul_int
PROCPS_PIDS_MEM_VIRT, // sl_int
PROCPS_PIDS_MEM_VIRT_KIB, // ul_int
PROCPS_PIDS_NICE, // sl_int
PROCPS_PIDS_NLWP, // s_int
PROCPS_PIDS_NS_IPC, // ul_int
PROCPS_PIDS_NS_MNT, // ul_int
PROCPS_PIDS_NS_NET, // ul_int
PROCPS_PIDS_NS_PID, // ul_int
PROCPS_PIDS_NS_USER, // ul_int
PROCPS_PIDS_NS_UTS, // ul_int
PROCPS_PIDS_OOM_ADJ, // s_int
PROCPS_PIDS_OOM_SCORE, // s_int
PROCPS_PIDS_PRIORITY, // s_int
PROCPS_PIDS_PROCESSOR, // u_int
PROCPS_PIDS_RSS, // sl_int
PROCPS_PIDS_RSS_RLIM, // ul_int
PROCPS_PIDS_RTPRIO, // ul_int
PROCPS_PIDS_SCHED_CLASS, // ul_int
PROCPS_PIDS_SD_MACH, // str
PROCPS_PIDS_SD_OUID, // str
PROCPS_PIDS_SD_SEAT, // str
PROCPS_PIDS_SD_SESS, // str
PROCPS_PIDS_SD_SLICE, // str
PROCPS_PIDS_SD_UNIT, // str
PROCPS_PIDS_SD_UUNIT, // str
PROCPS_PIDS_SIGBLOCKED, // str
PROCPS_PIDS_SIGCATCH, // str
PROCPS_PIDS_SIGIGNORE, // str
PROCPS_PIDS_SIGNALS, // str
PROCPS_PIDS_SIGPENDING, // str
PROCPS_PIDS_STATE, // s_ch
PROCPS_PIDS_SUPGIDS, // str
PROCPS_PIDS_SUPGROUPS, // str
PROCPS_PIDS_TICS_ALL, // ull_int
PROCPS_PIDS_TICS_ALL_C, // ull_int
PROCPS_PIDS_TICS_DELTA, // u_int
PROCPS_PIDS_TICS_SYSTEM, // ull_int
PROCPS_PIDS_TICS_SYSTEM_C, // ull_int
PROCPS_PIDS_TICS_USER, // ull_int
PROCPS_PIDS_TICS_USER_C, // ull_int
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
PROCPS_PIDS_TIME_ALL, // ull_int
PROCPS_PIDS_TIME_ELAPSED, // ull_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
PROCPS_PIDS_TIME_START, // ull_int
PROCPS_PIDS_TTY, // s_int
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
PROCPS_PIDS_TTY_NAME, // str
library: add abbreviated TTY_NUMBER to that <pids> API While not documented in the man page, ps allows 'tty4' as a valid output specifier complimenting 'tty8' & its derivatives. So, in order to eliminate a dev_to_name() call in the ps program the library will now offer this abbreviated tty version (consisting of a number only). Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-30 10:30:00 +05:30
PROCPS_PIDS_TTY_NUMBER, // 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
PROCPS_PIDS_VM_DATA, // ul_int
PROCPS_PIDS_VM_EXE, // ul_int
PROCPS_PIDS_VM_LIB, // ul_int
PROCPS_PIDS_VM_LOCK, // ul_int
PROCPS_PIDS_VM_RSS, // ul_int
PROCPS_PIDS_VM_SIZE, // ul_int
PROCPS_PIDS_VM_STACK, // ul_int
PROCPS_PIDS_VM_SWAP, // ul_int
PROCPS_PIDS_VM_USED, // ul_int
PROCPS_PIDS_VSIZE_PGS, // ul_int
library: exchange <pids> 'addr' for that 'ul_int' type Work on converting ps has revealed the desirability of trading a void pointer for that ul_int type. There was much arithmetic employed against such values and casts would otherwise have been required. Even pmap needed a cast on occasions when comparing an internal variable. Besides, there is much to be said for reducing demands on (and the complexity of) the result structure union. [ we choose ul_int over ull_int since that former is ] [ the exact same size and capacity as a void pointer ] [ regardless of whether compiled as 32-bit or 64-bit ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-09 10:30:00 +05:30
PROCPS_PIDS_WCHAN_ADDR, // ul_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
PROCPS_PIDS_WCHAN_NAME, // str
library: extend 'noop' concept to a resettable 'extra' The presence of that PROCPS_PIDS_noop may yet see some use in the future with its 'no alter' library promise. However, when top used that item to reflect the forest view nesting level, the unchanging nature of that item became more of an inconvenience than benefit. For each refresh top was forced to loop through all the stacks, resetting that PROCPS_PIDS_noop result struct to zero. So this commit will now offer users a choice between a new re-initialized item (PROCPS_PIDS_extra) & the noop invariant. Since the library already resets all those result structures, top will now utilize it at no cost. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-03 10:30:00 +05:30
PROCPS_PIDS_extra, // ( reset to zero )
PROCPS_PIDS_noop // ( never altered )
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_fill_type {
PROCPS_FILL_PID = 0x1000,
PROCPS_FILL_UID = 0x4000
};
enum pids_reap_type {
PROCPS_REAP_TASKS_ONLY = 0,
PROCPS_REAP_THREADS_TOO = 1
};
enum pids_sort_order {
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
PROCPS_SORT_ASCEND = +1,
PROCPS_SORT_DESCEND = -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
};
struct procps_pidsinfo;
struct pids_result {
enum pids_item item;
union {
char s_ch;
int s_int;
unsigned int u_int;
long sl_int;
unsigned long ul_int;
unsigned long long ull_int;
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
char * str;
char ** 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
} result;
};
struct pids_stack {
struct pids_result *head;
};
struct pids_counts {
int total;
int running, sleeping, stopped, zombied;
};
struct pids_reap {
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
struct pids_counts counts;
};
library: introduce pids 'value extractor' helper macro As an experiment a helper macro used to extract values from a result stack has been added to the header file. Don't force callers to reinvent that particular wheel. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
#define PROCPS_PIDS_VAL(rel_enum,type,stack) \
stack -> head [ rel_enum ] . result . type
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
struct pids_stack *fatal_proc_unmounted (
struct procps_pidsinfo *info,
int return_self);
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 procps_pids_new (
struct procps_pidsinfo **info,
int maxitems,
enum pids_item *items);
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
struct pids_stack *procps_pids_read_next (
struct procps_pidsinfo *info);
int procps_pids_read_open (
struct procps_pidsinfo *info,
enum pids_reap_type which);
int procps_pids_read_shut (
struct procps_pidsinfo *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_reap *procps_pids_reap (
struct procps_pidsinfo *info,
enum pids_reap_type which);
int procps_pids_ref (
struct procps_pidsinfo *info);
int procps_pids_reset (
struct procps_pidsinfo *info,
int newmaxitems,
enum pids_item *newitems);
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
struct pids_reap *procps_pids_select (
struct procps_pidsinfo *info,
unsigned *these,
int maxthese,
enum pids_fill_type which);
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
struct pids_stack **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
struct procps_pidsinfo *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,
enum pids_item sort,
enum pids_sort_order order);
int procps_pids_unref (
struct procps_pidsinfo **info);
__END_DECLS
#endif /* _PROC_PIDS_H */
Reference in New Issue Copy Permalink