emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
9d1f6cb4ea
procps/proc/meminfo.h

170 lines
6.1 KiB
C
Raw Normal View History

library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
/*
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
* libprocps - Library to read proc filesystem
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +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
*/
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#ifndef PROC_MEMINFO_H
#define PROC_MEMINFO_H
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
#include <sys/cdefs.h>
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
__BEGIN_DECLS
enum meminfo_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
MEMINFO_noop, // ( never altered )
MEMINFO_extra, // ( reset to zero )
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
/*
note: all of the following values are exressed as KiB
*/
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
MEMINFO_MEM_ACTIVE, // ul_int
MEMINFO_MEM_ACTIVE_ANON, // ul_int
MEMINFO_MEM_ACTIVE_FILE, // ul_int
MEMINFO_MEM_ANON, // ul_int
MEMINFO_MEM_AVAILABLE, // ul_int
MEMINFO_MEM_BOUNCE, // ul_int
MEMINFO_MEM_BUFFERS, // ul_int
MEMINFO_MEM_CACHED, // ul_int
MEMINFO_MEM_COMMIT_LIMIT, // ul_int
MEMINFO_MEM_COMMITTED_AS, // ul_int
MEMINFO_MEM_HARD_CORRUPTED, // ul_int
MEMINFO_MEM_DIRTY, // ul_int
MEMINFO_MEM_FREE, // ul_int
MEMINFO_MEM_HUGE_ANON, // ul_int
MEMINFO_MEM_HUGE_FREE, // ul_int
MEMINFO_MEM_HUGE_RSVD, // ul_int
MEMINFO_MEM_HUGE_SIZE, // ul_int
MEMINFO_MEM_HUGE_SURPLUS, // ul_int
MEMINFO_MEM_HUGE_TOTAL, // ul_int
MEMINFO_MEM_INACTIVE, // ul_int
MEMINFO_MEM_INACTIVE_ANON, // ul_int
MEMINFO_MEM_INACTIVE_FILE, // ul_int
MEMINFO_MEM_KERNEL_STACK, // ul_int
MEMINFO_MEM_LOCKED, // ul_int
MEMINFO_MEM_MAPPED, // ul_int
MEMINFO_MEM_NFS_UNSTABLE, // ul_int
MEMINFO_MEM_PAGE_TABLES, // ul_int
MEMINFO_MEM_SHARED, // ul_int
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
MEMINFO_MEM_SHMEM_HUGE, // ul_int
MEMINFO_MEM_SHMEM_HUGE_MAP, // ul_int
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
MEMINFO_MEM_SLAB, // ul_int
MEMINFO_MEM_SLAB_RECLAIM, // ul_int
MEMINFO_MEM_SLAB_UNRECLAIM, // ul_int
MEMINFO_MEM_TOTAL, // ul_int
MEMINFO_MEM_UNEVICTABLE, // ul_int
MEMINFO_MEM_USED, // ul_int
MEMINFO_MEM_VM_ALLOC_CHUNK, // ul_int
MEMINFO_MEM_VM_ALLOC_TOTAL, // ul_int
MEMINFO_MEM_VM_ALLOC_USED, // ul_int
MEMINFO_MEM_WRITEBACK, // ul_int
MEMINFO_MEM_WRITEBACK_TMP, // ul_int
MEMINFO_DELTA_ACTIVE, // s_int
MEMINFO_DELTA_ACTIVE_ANON, // s_int
MEMINFO_DELTA_ACTIVE_FILE, // s_int
MEMINFO_DELTA_ANON, // s_int
MEMINFO_DELTA_AVAILABLE, // s_int
MEMINFO_DELTA_BOUNCE, // s_int
MEMINFO_DELTA_BUFFERS, // s_int
MEMINFO_DELTA_CACHED, // s_int
MEMINFO_DELTA_COMMIT_LIMIT, // s_int
MEMINFO_DELTA_COMMITTED_AS, // s_int
MEMINFO_DELTA_HARD_CORRUPTED, // s_int
MEMINFO_DELTA_DIRTY, // s_int
MEMINFO_DELTA_FREE, // s_int
MEMINFO_DELTA_HUGE_ANON, // s_int
MEMINFO_DELTA_HUGE_FREE, // s_int
MEMINFO_DELTA_HUGE_RSVD, // s_int
MEMINFO_DELTA_HUGE_SIZE, // s_int
MEMINFO_DELTA_HUGE_SURPLUS, // s_int
MEMINFO_DELTA_HUGE_TOTAL, // s_int
MEMINFO_DELTA_INACTIVE, // s_int
MEMINFO_DELTA_INACTIVE_ANON, // s_int
MEMINFO_DELTA_INACTIVE_FILE, // s_int
MEMINFO_DELTA_KERNEL_STACK, // s_int
MEMINFO_DELTA_LOCKED, // s_int
MEMINFO_DELTA_MAPPED, // s_int
MEMINFO_DELTA_NFS_UNSTABLE, // s_int
MEMINFO_DELTA_PAGE_TABLES, // s_int
MEMINFO_DELTA_SHARED, // s_int
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
MEMINFO_DELTA_SHMEM_HUGE, // s_int
MEMINFO_DELTA_SHMEM_HUGE_MAP, // s_int
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
MEMINFO_DELTA_SLAB, // s_int
MEMINFO_DELTA_SLAB_RECLAIM, // s_int
MEMINFO_DELTA_SLAB_UNRECLAIM, // s_int
MEMINFO_DELTA_TOTAL, // s_int
MEMINFO_DELTA_UNEVICTABLE, // s_int
MEMINFO_DELTA_USED, // s_int
MEMINFO_DELTA_VM_ALLOC_CHUNK, // s_int
MEMINFO_DELTA_VM_ALLOC_TOTAL, // s_int
MEMINFO_DELTA_VM_ALLOC_USED, // s_int
MEMINFO_DELTA_WRITEBACK, // s_int
MEMINFO_DELTA_WRITEBACK_TMP, // s_int
MEMINFO_MEMHI_FREE, // ul_int
MEMINFO_MEMHI_TOTAL, // ul_int
MEMINFO_MEMHI_USED, // ul_int
MEMINFO_MEMLO_FREE, // ul_int
MEMINFO_MEMLO_TOTAL, // ul_int
MEMINFO_MEMLO_USED, // ul_int
MEMINFO_SWAP_CACHED, // ul_int
MEMINFO_SWAP_FREE, // ul_int
MEMINFO_SWAP_TOTAL, // ul_int
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
MEMINFO_SWAP_USED // ul_int
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
};
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
struct meminfo_result {
enum meminfo_item item;
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
union {
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
signed int s_int;
library: remove the ull_int result type, <MEMINFO> api Because of the vast quantities of virtual memory which may be allocated, it initially seemed like a good idea to provide for a widest possible range through the use of a 'ull_int' result type. However, on second thought the implementation was a bit flawed for these reasons: . that underlying meminfo_data variable 'VmallocTotal' is 'unsigned long' not a required 'unsigned long long' . there wasn't a convenient way to value it since each variable was set with a strtoul() call, not strtoull() So this patch will standardize on the 'ul_int' results type (and reduce the associated delta to 's_int' too). For now, we'll rely on protections under a 64-bit arch where a 'ull_int' & 'ul_int' yield identical capacity. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 10:30:00 +05:30
unsigned long ul_int;
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
} result;
library: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
};
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
struct meminfo_stack {
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
struct meminfo_result *head;
};
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: ensure that all those 'GET' macros are robust When users call the native 'get' functions they have a responsibility to check that the result struct address was indeed returned. But when using those 'GET' macros there was no protection for possible NULL dereference. So this patch will add some protection for a potential failure of an underlying 'get' function. And should it occur then those 'GET' macros will just return a zero. Plus, we'll also mirror that behavior in the debugging header should the XTRA_PROCPS_DEBUG #define be active. And, we might as well add a warning when invalid items are passed to 'GET' macros, just like we do for 'VAL'. [ lastly, we added the missing opening parens/braces ] [ to 2 'GET' macros in that xtra-procps-debug.h file ] [ which went unnoticed until the qa folks caught up. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-06 21:41:11 +05:30
#define MEMINFO_GET( info, actual_enum, type ) ( { \
struct meminfo_result *r = procps_meminfo_get( info, actual_enum ); \
r ? r->result . type : 0; } )
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
library: expand VAL macros to include the context parm This patch will set the stage for validating the types referenced in the result union. For now, the parameter representing that 'info' structure will remain unused. [ and while we're at it, let us correct a faulty GET ] [ macro in the diskstats header. that puppy missed a ] [ parm which ain't so good if that guy is ever used! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#define MEMINFO_VAL( relative_enum, type, stack, info ) \
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
stack -> head [ relative_enum ] . result . type
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 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 meminfo_info;
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 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
int procps_meminfo_new (struct meminfo_info **info);
int procps_meminfo_ref (struct meminfo_info *info);
int procps_meminfo_unref (struct meminfo_info **info);
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
struct meminfo_result *procps_meminfo_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 meminfo_info *info,
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
enum meminfo_item item);
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
struct meminfo_stack *procps_meminfo_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 meminfo_info *info,
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
enum meminfo_item *items,
int numitems);
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
__END_DECLS
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#endif
Reference in New Issue Copy Permalink