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

92 lines
2.7 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: memory and vmstat API changes Created new set of functions for meminfo related calls. Liked the format of that better so changed vmstat around so the look similar. Missed the makefile change for uptime so added it in now.
2015-06-21 13:52:28 +05:30
* meminfo - Memory statistics part of procps
*
* Copyright (C) 1992-1998 by Michael K. Johnson <johnsonm@redhat.com>
* Copyright (C) 1998-2003 Albert Cahalan
* Copyright (C) 2015 Craig Small <csmall@enc.com.au>
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
#include <proc/procps.h>
__BEGIN_DECLS
enum meminfo_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
PROCPS_MEMHI_FREE, // ul_int
PROCPS_MEMHI_TOTAL, // ul_int
PROCPS_MEMHI_USED, // ul_int
PROCPS_MEMLO_FREE, // ul_int
PROCPS_MEMLO_TOTAL, // ul_int
PROCPS_MEMLO_USED, // ul_int
PROCPS_MEM_ACTIVE, // ul_int
PROCPS_MEM_AVAILABLE, // ul_int
PROCPS_MEM_BUFFERS, // ul_int
PROCPS_MEM_CACHED, // ul_int
PROCPS_MEM_FREE, // ul_int
PROCPS_MEM_INACTIVE, // ul_int
PROCPS_MEM_SHARED, // ul_int
PROCPS_MEM_TOTAL, // ul_int
PROCPS_MEM_USED, // ul_int
PROCPS_SWAP_FREE, // ul_int
PROCPS_SWAP_TOTAL, // ul_int
PROCPS_SWAP_USED, // ul_int
PROCPS_MEM_noop, // n/a
PROCPS_MEM_stack_end // n/a
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
struct procps_meminfo;
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 {
unsigned long ul_int;
} 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
int procps_meminfo_new (struct procps_meminfo **info);
int procps_meminfo_read (struct procps_meminfo *info);
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
int procps_meminfo_ref (struct procps_meminfo *info);
int procps_meminfo_unref (struct procps_meminfo **info);
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
unsigned long procps_meminfo_get (
struct procps_meminfo *info,
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
int procps_meminfo_getstack (
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 procps_meminfo *info,
struct meminfo_result *these);
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
int procps_meminfo_stack_fill (
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 procps_meminfo *info,
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 *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
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 *procps_meminfo_stack_alloc (
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 procps_meminfo *info,
int maxitems,
enum meminfo_item *items);
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
#endif
Reference in New Issue Copy Permalink