emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
7d20df9ef0
procps/proc/slabinfo.c

1071 lines
36 KiB
C
Raw Normal View History

miscellaneous: clean up trailing whitespace throughout The entire tree's polluted with inappropriate trailing whitespace. This commit rids our environment of all of those useless keystrokes. Unfortunately, it sure ain't a permanent solution and requires every contributor to instruct their editor(s) to prevent or eliminate them. Plus it's strongly recommended we all insert something like what's shown below to our '.gitconfig' file so as to provide at least some warnings when we try to apply any patches (git am) that do contain the #@!%& things! References(s): ~/.gitconfig excerpt --------------------------------- [core] whitespace = trailing-space, space-before-tab, blank-at-eof [apply] whitespace = warn --------------------------------- ~/.gitconfig excerpt Signed-off-by: Jim Warner <james.warner@comcast.net>
2013-03-11 11:30:00 +05:30
/*
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* slabinfo.c - slabinfo related functions for libproc
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
*
* Chris Rivera <cmrivera@ufl.edu>
* Robert Love <rml@tech9.net>
*
* Copyright (C) 2003 Chris Rivera
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* Copyright (C) 2004 Albert Cahalan
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
* Copyright (C) 2015 Craig Small <csmall@enc.com.au>
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* Copyright (C) 2016 Jim Warnerl <james.warner@comcast.net>
docs: clarification to license headers in files Add license header to all files. The summary of licensing is below, taken from Craig Small's email which is referred in commit message tail. sysctl and pgrep are GPL 2+ The rest is LGPL 2.1+ Reference: http://www.freelists.org/post/procps/Incorrect-FSF-address-in-the-license-files,8 Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=797962 CC: Craig Small <csmall@enc.com.au> CC: Jaromir Capik <jcapik@redhat.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-02 17:59:36 +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
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
*/
isalpha requires ctype.h
2004-07-19 10:26:10 +05:30
#include <ctype.h>
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
#include <errno.h>
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
#include <string.h>
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
#include <time.h>
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
#include <unistd.h>
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
#include <sys/stat.h>
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
#include <sys/types.h>
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#include <proc/procps-private.h>
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
#include <proc/slabinfo.h>
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
#define SLABINFO_FILE "/proc/slabinfo"
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
#define SLABINFO_LINE_LEN 2048
#define SLAB_INFO_NAME_LEN 128
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
#define STACKS_INCR 128
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/*
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
Because 'select' could, at most, return only node[0] values and since 'reap' |
would be forced to duplicate global slabs stuff in every node results stack, |
the following #define can be used to enforce strictly logical return values. |
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
select: allow only SLABINFO & SLABS items
reap: allow only SLABINFO & SLABNODE items
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
Without the #define, these functions always return something even if just 0. |
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
get: return only SLABS results, else 0
select: return only SLABINFO & SLABS results, else zero
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
reap: return any requested, even when duplicated in each node's stack */
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
//#define ENFORCE_LOGICAL // ensure only logical items accepted by select/reap
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_summ {
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
unsigned int nr_objs; /* number of objects, among all caches */
unsigned int nr_active_objs; /* number of active objects, among all caches */
unsigned int nr_pages; /* number of pages consumed by all objects */
unsigned int nr_slabs; /* number of slabs, among all caches */
unsigned int nr_active_slabs; /* number of active slabs, among all caches */
unsigned int nr_caches; /* number of caches */
unsigned int nr_active_caches; /* number of active caches */
unsigned int avg_obj_size; /* average object size */
unsigned int min_obj_size; /* size of smallest object */
unsigned int max_obj_size; /* size of largest object */
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
unsigned long active_size; /* size of all active objects */
unsigned long total_size; /* size of all objects */
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_node {
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
char name[SLAB_INFO_NAME_LEN]; /* name of this cache */
unsigned long cache_size; /* size of entire cache */
unsigned int nr_objs; /* number of objects in this cache */
unsigned int nr_active_objs; /* number of active objects */
unsigned int obj_size; /* size of each object */
unsigned int objs_per_slab; /* number of objects per slab */
unsigned int pages_per_slab; /* number of pages per slab */
unsigned int nr_slabs; /* number of slabs in this cache */
unsigned int nr_active_slabs; /* number of active slabs */
unsigned int use; /* percent full: total / active */
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_hist {
struct slabs_summ new;
struct slabs_summ old;
};
struct stacks_extent {
int ext_numstacks;
struct stacks_extent *next;
struct slabinfo_stack **stacks;
};
struct ext_support {
int numitems; // includes 'logical_end' delimiter
enum slabinfo_item *items; // includes 'logical_end' delimiter
struct stacks_extent *extents; // anchor for these extents
#ifdef ENFORCE_LOGICAL
enum slabinfo_item lowest; // range of allowable enums
enum slabinfo_item highest;
#endif
int dirty_stacks;
};
struct fetch_support {
struct slabinfo_stack **anchor; // fetch consolidated extents
int n_alloc; // number of above pointers allocated
int n_inuse; // number of above pointers occupied
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
int n_alloc_save; // last known reap.stacks allocation
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_reap results; // count + stacks for return to caller
};
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 slabinfo_info {
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
int refcount;
FILE *slabinfo_fp;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
int slabinfo_was_read;
library: <SLABINFO> api, change 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
int nodes_alloc; /* nodes alloc()ed */
int nodes_used; /* nodes using alloced memory */
struct slabs_node *nodes; /* first slabnode of this list */
struct slabs_hist hist; /* new/old slabs_summ data */
struct ext_support select_ext; /* supports concurrent select/reap */
struct ext_support fetch_ext; /* supports concurrent select/reap */
struct fetch_support fetch; /* support for procps_slabinfo_reap */
struct slabs_node nul_node; /* used by slabinfo_get/select */
struct slabinfo_result get_this; /* used by slabinfo_get */
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
#define setNAME(e) set_results_ ## e
#define setDECL(e) static void setNAME(e) \
(struct slabinfo_result *R, struct slabs_hist *S, struct slabs_node *N)
// regular assignment
#define REG_set(e,t,x) setDECL(e) { (void)N; R->result. t = S->new . x; }
#define NOD_set(e,t,x) setDECL(e) { (void)S; R->result. t = N-> x; }
// delta assignment
#define HST_set(e,t,x) setDECL(e) { (void)N; R->result. t = (signed long)S->new . x - S->old. x; }
setDECL(noop) { (void)R; (void)S; (void)N; }
setDECL(extra) { (void)R; (void)S; (void)N; }
REG_set(SLABS_OBJS, u_int, nr_objs)
REG_set(SLABS_AOBJS, u_int, nr_active_objs)
REG_set(SLABS_PAGES, u_int, nr_pages)
REG_set(SLABS_SLABS, u_int, nr_slabs)
REG_set(SLABS_ASLABS, u_int, nr_active_slabs)
REG_set(SLABS_CACHES, u_int, nr_caches)
REG_set(SLABS_ACACHES, u_int, nr_active_caches)
REG_set(SLABS_SIZE_AVG, u_int, avg_obj_size)
REG_set(SLABS_SIZE_MIN, u_int, min_obj_size)
REG_set(SLABS_SIZE_MAX, u_int, max_obj_size)
REG_set(SLABS_SIZE_ACTIVE, ul_int, active_size)
REG_set(SLABS_SIZE_TOTAL, ul_int, total_size)
HST_set(SLABS_DELTA_OBJS, s_int, nr_objs)
HST_set(SLABS_DELTA_AOBJS, s_int, nr_active_objs)
HST_set(SLABS_DELTA_PAGES, s_int, nr_pages)
HST_set(SLABS_DELTA_SLABS, s_int, nr_slabs)
HST_set(SLABS_DELTA_ASLABS, s_int, nr_active_slabs)
HST_set(SLABS_DELTA_CACHES, s_int, nr_caches)
HST_set(SLABS_DELTA_ACACHES, s_int, nr_active_caches)
HST_set(SLABS_DELTA_SIZE_AVG, s_int, avg_obj_size)
HST_set(SLABS_DELTA_SIZE_MIN, s_int, min_obj_size)
HST_set(SLABS_DELTA_SIZE_MAX, s_int, max_obj_size)
HST_set(SLABS_DELTA_SIZE_ACTIVE, s_int, active_size)
HST_set(SLABS_DELTA_SIZE_TOTAL, s_int, total_size)
NOD_set(SLABNODE_NAME, str, name)
NOD_set(SLABNODE_OBJS, u_int, nr_objs)
NOD_set(SLABNODE_AOBJS, u_int, nr_active_objs)
NOD_set(SLABNODE_OBJ_SIZE, u_int, obj_size)
NOD_set(SLABNODE_OBJS_PER_SLAB, u_int, objs_per_slab)
NOD_set(SLABNODE_PAGES_PER_SLAB, u_int, pages_per_slab)
NOD_set(SLABNODE_SLABS, u_int, nr_slabs)
NOD_set(SLABNODE_ASLABS, u_int, nr_active_slabs)
NOD_set(SLABNODE_USE, u_int, use)
NOD_set(SLABNODE_SIZE, ul_int, cache_size)
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#undef setDECL
#undef REG_set
#undef NOD_set
#undef HST_set
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// ___ Sorting Support ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
struct sort_parms {
int offset;
enum slabinfo_sort_order order;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
};
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#define srtNAME(t) sort_results_ ## t
#define srtDECL(t) static int srtNAME(t) \
(const struct slabinfo_stack **A, const struct slabinfo_stack **B, struct sort_parms *P)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
srtDECL(u_int) {
const struct slabinfo_result *a = (*A)->head + P->offset; \
const struct slabinfo_result *b = (*B)->head + P->offset; \
if ( a->result.u_int > b->result.u_int ) return P->order > 0 ? 1 : -1; \
if ( a->result.u_int < b->result.u_int ) return P->order > 0 ? -1 : 1; \
return 0;
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
srtDECL(ul_int) {
const struct slabinfo_result *a = (*A)->head + P->offset; \
const struct slabinfo_result *b = (*B)->head + P->offset; \
if ( a->result.ul_int > b->result.ul_int ) return P->order > 0 ? 1 : -1; \
if ( a->result.ul_int < b->result.ul_int ) return P->order > 0 ? -1 : 1; \
return 0;
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
srtDECL(str) {
const struct slabinfo_result *a = (*A)->head + P->offset;
const struct slabinfo_result *b = (*B)->head + P->offset;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return P->order * strcoll(a->result.str, b->result.str);
}
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
srtDECL(noop) { \
(void)A; (void)B; (void)P; \
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return 0;
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
}
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#undef srtDECL
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// ___ Controlling Table ||||||||||||||||||||||||||||||||||||||||||||||||||||||
typedef void (*SET_t)(struct slabinfo_result *, struct slabs_hist *, struct slabs_node *);
#define RS(e) (SET_t)setNAME(e)
typedef int (*QSR_t)(const void *, const void *, void *);
#define QS(t) (QSR_t)srtNAME(t)
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#define TS(t) STRINGIFY(t)
#define TS_noop ""
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/*
* Need it be said?
* This table must be kept in the exact same order as
* those *enum slabinfo_item* guys ! */
static struct {
SET_t setsfunc; // the actual result setting routine
QSR_t sortfunc; // sort cmp func for a specific type
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
char *type2str; // the result type as a string value
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} Item_table[] = {
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
/* setsfunc sortfunc type2str
---------------------------- ----------- ---------- */
{ RS(noop), QS(noop), TS_noop },
{ RS(extra), QS(ul_int), TS_noop },
{ RS(SLABS_OBJS), QS(noop), TS(u_int) },
{ RS(SLABS_AOBJS), QS(noop), TS(u_int) },
{ RS(SLABS_PAGES), QS(noop), TS(u_int) },
{ RS(SLABS_SLABS), QS(noop), TS(u_int) },
{ RS(SLABS_ASLABS), QS(noop), TS(u_int) },
{ RS(SLABS_CACHES), QS(noop), TS(u_int) },
{ RS(SLABS_ACACHES), QS(noop), TS(u_int) },
{ RS(SLABS_SIZE_AVG), QS(noop), TS(u_int) },
{ RS(SLABS_SIZE_MIN), QS(noop), TS(u_int) },
{ RS(SLABS_SIZE_MAX), QS(noop), TS(u_int) },
{ RS(SLABS_SIZE_ACTIVE), QS(noop), TS(ul_int) },
{ RS(SLABS_SIZE_TOTAL), QS(noop), TS(ul_int) },
{ RS(SLABS_DELTA_OBJS), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_AOBJS), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_PAGES), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_SLABS), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_ASLABS), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_CACHES), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_ACACHES), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_SIZE_AVG), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_SIZE_MIN), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_SIZE_MAX), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_SIZE_ACTIVE), QS(noop), TS(s_int) },
{ RS(SLABS_DELTA_SIZE_TOTAL), QS(noop), TS(s_int) },
{ RS(SLABNODE_NAME), QS(str), TS(str) },
{ RS(SLABNODE_OBJS), QS(u_int), TS(u_int) },
{ RS(SLABNODE_AOBJS), QS(u_int), TS(u_int) },
{ RS(SLABNODE_OBJ_SIZE), QS(u_int), TS(u_int) },
{ RS(SLABNODE_OBJS_PER_SLAB), QS(u_int), TS(u_int) },
{ RS(SLABNODE_PAGES_PER_SLAB), QS(u_int), TS(u_int) },
{ RS(SLABNODE_SLABS), QS(u_int), TS(u_int) },
{ RS(SLABNODE_ASLABS), QS(u_int), TS(u_int) },
{ RS(SLABNODE_USE), QS(u_int), TS(u_int) },
{ RS(SLABNODE_SIZE), QS(ul_int), TS(ul_int) },
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// dummy entry corresponding to SLABINFO_logical_end ...
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ NULL, NULL, NULL }
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
};
/* please note,
* this enum MUST be 1 greater than the highest value of any enum */
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
enum slabinfo_item SLABINFO_logical_end = SLABNODE_SIZE + 1;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
#undef setNAME
#undef srtNAME
#undef RS
#undef QS
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
// --- slabnode specific support ----------------------------------------------
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
/* Alloc up more slabnode memory, if required
Fabian fixes slabtop; prep for 3.2.1 release
2004-03-27 10:00:05 +05:30
*/
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static int alloc_slabnodes (
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 slabinfo_info *info)
Fabian fixes slabtop; prep for 3.2.1 release
2004-03-27 10:00:05 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_node *new_nodes;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
int new_count;
if (info->nodes_used < info->nodes_alloc)
return 0;
/* Increment the allocated number of slabs */
new_count = info->nodes_alloc * 5/4+30;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
new_nodes = realloc(info->nodes, sizeof(struct slabs_node) * new_count);
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
if (!new_nodes)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return -ENOMEM;
info->nodes = new_nodes;
info->nodes_alloc = new_count;
return 0;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: alloc_slabnodes
Fabian fixes slabtop; prep for 3.2.1 release
2004-03-27 10:00:05 +05:30
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
/*
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
* get_slabnode - allocate slab_info structures using a free list
*
* In the fast path, we simply return a node off the free list. In the slow
* list, we malloc() a new node. The free list is never automatically reaped,
* both for simplicity and because the number of slab caches is fairly
* constant.
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
*/
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
static int get_slabnode (
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 slabinfo_info *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_node **node)
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
{
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
int retval;
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
if (info->nodes_used == info->nodes_alloc) {
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if ((retval = alloc_slabnodes(info)) < 0)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return retval;
}
*node = &(info->nodes[info->nodes_used++]);
return 0;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: get_slabnode
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
/* parse_slabinfo20:
*
* sactual parse routine for slabinfo 2.x (2.6 kernels)
procps-ng : fix multi-line comment warnings slab.c:110:1: warning: multi-line comment slab.c:115:1: warning: multi-line comment slab.c:122:1: warning: multi-line comment slab.c:127:1: warning: multi-line comment Signed-off-by: Gilles Espinasse <g.esp@free.fr>
2013-03-26 14:11:03 +05:30
* Note: difference between 2.0 and 2.1 is in the ": globalstat" part where version 2.1
* has extra column <nodeallocs>. We don't use ": globalstat" part in both versions.
*
* Formats (we don't use "statistics" extensions)
*
* slabinfo - version: 2.1
* # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> \
* : tunables <batchcount> <limit> <sharedfactor> \
* : slabdata <active_slabs> <num_slabs> <sharedavail>
*
* slabinfo - version: 2.1 (statistics)
* # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> \
* : tunables <batchcount> <limit> <sharedfactor> \
* : slabdata <active_slabs> <num_slabs> <sharedavail> \
* : globalstat <listallocs> <maxobjs> <grown> <reaped> <error> <maxfreeable> <freelimit> <nodeallocs> \
* : cpustat <allochit> <allocmiss> <freehit> <freemiss>
*
* slabinfo - version: 2.0
* # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> \
* : tunables <batchcount> <limit> <sharedfactor> \
* : slabdata <active_slabs> <num_slabs> <sharedavail>
*
* slabinfo - version: 2.0 (statistics)
* # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> \
* : tunables <batchcount> <limit> <sharedfactor> \
* : slabdata <active_slabs> <num_slabs> <sharedavail> \
* : globalstat <listallocs> <maxobjs> <grown> <reaped> <error> <maxfreeable> <freelimit> \
* : cpustat <allochit> <allocmiss> <freehit> <freemiss>
*/
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
static int parse_slabinfo20 (
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 slabinfo_info *info)
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_node *node;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
char buffer[SLABINFO_LINE_LEN];
int retval;
int page_size = getpagesize();
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabs_summ *hist = &(info->hist.new);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
hist->min_obj_size = INT_MAX;
hist->max_obj_size = 0;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
while (fgets(buffer, SLABINFO_LINE_LEN, info->slabinfo_fp )) {
if (buffer[0] == '#')
continue;
if ((retval = get_slabnode(info, &node)) < 0)
return retval;
if (sscanf(buffer,
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
"%" STRINGIFY(SLAB_INFO_NAME_LEN) "s" \
"%u %u %u %u %u : tunables %*u %*u %*u : slabdata %u %u %*u",
node->name,
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
&node->nr_active_objs, &node->nr_objs,
&node->obj_size, &node->objs_per_slab,
&node->pages_per_slab, &node->nr_active_slabs,
&node->nr_slabs) < 8) {
if (errno != 0)
return -errno;
return -EINVAL;
}
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
if (!node->name[0])
snprintf(node->name, sizeof(node->name), "%s", "unknown");
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (node->obj_size < hist->min_obj_size)
hist->min_obj_size = node->obj_size;
if (node->obj_size > hist->max_obj_size)
hist->max_obj_size = node->obj_size;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
node->cache_size = (unsigned long)node->nr_slabs * node->pages_per_slab
* page_size;
if (node->nr_objs) {
library: fix order of operations for %use of slabinfo In some environments, 100 * nr_active_objs is calculated at first, and lower 32bit of the result is divided by nr_objs. If 100 * nr_active_objs > 42949672, %use will be incorrect. Reported by Takayuki Nagata <tnagata@redhat.com> and adopted his patch for new library (see reference) References: commit 99d71ad5810b8fbfab5c4c6be97f3e86953b6157 http://www.freelists.org/post/procps/PATCH-bprocps-fix-order-of-operations-for-use-of-slabinfo
2016-04-25 15:54:20 +05:30
node->use = (unsigned int)100 * (node->nr_active_objs / node->nr_objs);
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
hist->nr_active_caches++;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
} else
node->use = 0;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
hist->nr_objs += node->nr_objs;
hist->nr_active_objs += node->nr_active_objs;
hist->total_size += (unsigned long)node->nr_objs * node->obj_size;
hist->active_size += (unsigned long)node->nr_active_objs * node->obj_size;
hist->nr_pages += node->nr_slabs * node->pages_per_slab;
hist->nr_slabs += node->nr_slabs;
hist->nr_active_slabs += node->nr_active_slabs;
hist->nr_caches++;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (hist->nr_objs)
hist->avg_obj_size = hist->total_size / hist->nr_objs;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return 0;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: parse_slabinfo20
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/* read_slabinfo_failed():
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
*
* Read the data out of /proc/slabinfo putting the information
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
* into the supplied info container
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
*
* Returns: 0 on success, negative on error
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
*/
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static int read_slabinfo_failed (
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 slabinfo_info *info)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
char line[SLABINFO_LINE_LEN];
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
int retval, major, minor;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
memcpy(&info->hist.old, &info->hist.new, sizeof(struct slabs_summ));
memset(&(info->hist.new), 0, sizeof(struct slabs_summ));
if ((retval = alloc_slabnodes(info)) < 0)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return retval;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
memset(info->nodes, 0, sizeof(struct slabs_node)*info->nodes_alloc);
info->nodes_used = 0;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (NULL == info->slabinfo_fp
&& (info->slabinfo_fp = fopen(SLABINFO_FILE, "r")) == NULL)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return -errno;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
if (fseek(info->slabinfo_fp, 0L, SEEK_SET) < 0)
return -errno;
/* Parse the version string */
if (!fgets(line, SLABINFO_LINE_LEN, info->slabinfo_fp))
return -errno;
if (sscanf(line, "slabinfo - version: %d.%d", &major, &minor) != 2)
return -EINVAL;
if (major == 2)
retval = parse_slabinfo20(info);
else
return -ERANGE;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
if (!info->slabinfo_was_read) {
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
memcpy(&info->hist.old, &info->hist.new, sizeof(struct slabs_summ));
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
info->slabinfo_was_read = 1;
}
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return retval;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: read_slabinfo_failed
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
// --- generalized support ----------------------------------------------------
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static inline void assign_results (
struct slabinfo_stack *stack,
struct slabs_hist *summ,
struct slabs_node *node)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_result *this = stack->head;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
for (;;) {
enum slabinfo_item item = this->item;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (item >= SLABINFO_logical_end)
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
break;
Item_table[item].setsfunc(this, summ, node);
++this;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return;
} // end: assign_results
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static inline void cleanup_stack (
struct slabinfo_result *this)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
for (;;) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (this->item >= SLABINFO_logical_end)
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
break;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (this->item > SLABINFO_noop)
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
this->result.ul_int = 0;
++this;
}
} // end: cleanup_stack
static inline void cleanup_stacks_all (
struct ext_support *this)
{
struct stacks_extent *ext = this->extents;
library: the overlooked twerks (oops, tweaks), 3rd gen Yes, all of these changes are strictly cosmetic. It is likely symptomatic of some deep-seated character flaw. [ or, it might be because of a certain pride in this ] [ new library and the desire to make it even better! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-07 10:30:00 +05:30
int i;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
while (ext) {
for (i = 0; ext->stacks[i]; i++)
cleanup_stack(ext->stacks[i]->head);
ext = ext->next;
};
this->dirty_stacks = 0;
} // end: cleanup_stacks_all
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static void extents_free_all (
struct ext_support *this)
{
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
while (this->extents) {
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct stacks_extent *p = this->extents;
this->extents = this->extents->next;
free(p);
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: extents_free_all
static inline struct slabinfo_result *itemize_stack (
struct slabinfo_result *p,
int depth,
enum slabinfo_item *items)
{
struct slabinfo_result *p_sav = p;
int i;
for (i = 0; i < depth; i++) {
p->item = items[i];
p->result.ul_int = 0;
++p;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return p_sav;
} // end: itemize_stack
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static void itemize_stacks_all (
struct ext_support *this)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct stacks_extent *ext = this->extents;
while (ext) {
int i;
for (i = 0; ext->stacks[i]; i++)
itemize_stack(ext->stacks[i]->head, this->numitems, this->items);
ext = ext->next;
};
this->dirty_stacks = 0;
} // end: static void itemize_stacks_all
static inline int items_check_failed (
struct ext_support *this,
enum slabinfo_item *items,
int numitems)
{
int i;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/* if an enum is passed instead of an address of one or more enums, ol' gcc
* will silently convert it to an address (possibly NULL). only clang will
* offer any sort of warning like the following:
*
* warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'enum slabinfo_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
* my_stack = procps_slabinfo_select(info, SLABINFO_noop, num);
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* ^~~~~~~~~~~~~~~~
*/
if (numitems < 1
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|| (void *)items < (void *)(unsigned long)(2 * SLABINFO_logical_end))
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return -1;
for (i = 0; i < numitems; i++) {
#ifdef ENFORCE_LOGICAL
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (items[i] == SLABINFO_noop
|| (items[i] == SLABINFO_extra))
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
continue;
if (items[i] < this->lowest
|| (items[i] > this->highest))
return -1;
#else
// a slabinfo_item is currently unsigned, but we'll protect our future
if (items[i] < 0)
return -1;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (items[i] >= SLABINFO_logical_end)
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return -1;
#endif
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
}
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return 0;
} // end: items_check_failed
static struct stacks_extent *stacks_alloc (
struct ext_support *this,
int maxstacks)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct stacks_extent *p_blob;
struct slabinfo_stack **p_vect;
struct slabinfo_stack *p_head;
size_t vect_size, head_size, list_size, blob_size;
void *v_head, *v_list;
int i;
if (this == NULL || this->items == NULL)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (maxstacks < 1)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
vect_size = sizeof(void *) * maxstacks; // size of the addr vectors |
vect_size += sizeof(void *); // plus NULL addr delimiter |
head_size = sizeof(struct slabinfo_stack); // size of that head struct |
list_size = sizeof(struct slabinfo_result)*this->numitems;// any single results stack |
blob_size = sizeof(struct stacks_extent); // the extent anchor itself |
blob_size += vect_size; // plus room for addr vects |
blob_size += head_size * maxstacks; // plus room for head thing |
blob_size += list_size * maxstacks; // plus room for our stacks |
/* note: all of our memory is allocated in a single blob, facilitating a later free(). |
as a minimum, it is important that the result structures themselves always be |
contiguous for every stack since they are accessed through relative position. | */
if (NULL == (p_blob = calloc(1, blob_size)))
return NULL;
p_blob->next = this->extents; // push this extent onto... |
this->extents = p_blob; // ...some existing extents |
p_vect = (void *)p_blob + sizeof(struct stacks_extent); // prime our vector pointer |
p_blob->stacks = p_vect; // set actual vectors start |
v_head = (void *)p_vect + vect_size; // prime head pointer start |
v_list = v_head + (head_size * maxstacks); // prime our stacks pointer |
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
for (i = 0; i < maxstacks; i++) {
p_head = (struct slabinfo_stack *)v_head;
p_head->head = itemize_stack((struct slabinfo_result *)v_list, this->numitems, this->items);
p_blob->stacks[i] = p_head;
v_list += list_size;
v_head += head_size;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
p_blob->ext_numstacks = maxstacks;
return p_blob;
} // end: stacks_alloc
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static int stacks_fetch (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct slabinfo_info *info)
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
{
#define n_alloc info->fetch.n_alloc
#define n_inuse info->fetch.n_inuse
#define n_saved info->fetch.n_alloc_save
struct stacks_extent *ext;
// initialize stuff -----------------------------------
if (!info->fetch.anchor) {
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if (!(info->fetch.anchor = calloc(sizeof(void *), STACKS_INCR)))
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return -ENOMEM;
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
n_alloc = STACKS_INCR;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
}
if (!info->fetch_ext.extents) {
if (!(ext = stacks_alloc(&info->fetch_ext, n_alloc)))
return -ENOMEM;
memset(info->fetch.anchor, 0, sizeof(void *) * n_alloc);
memcpy(info->fetch.anchor, ext->stacks, sizeof(void *) * n_alloc);
itemize_stacks_all(&info->fetch_ext);
}
cleanup_stacks_all(&info->fetch_ext);
// iterate stuff --------------------------------------
n_inuse = 0;
while (n_inuse < info->nodes_used) {
if (!(n_inuse < n_alloc)) {
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
n_alloc += STACKS_INCR;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if ((!(info->fetch.anchor = realloc(info->fetch.anchor, sizeof(void *) * n_alloc)))
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
|| (!(ext = stacks_alloc(&info->fetch_ext, STACKS_INCR))))
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return -1;
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
memcpy(info->fetch.anchor + n_inuse, ext->stacks, sizeof(void *) * STACKS_INCR);
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
assign_results(info->fetch.anchor[n_inuse], &info->hist, &info->nodes[n_inuse]);
++n_inuse;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
}
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// finalize stuff -------------------------------------
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
/* note: we go to this trouble of maintaining a duplicate of the consolidated |
extent stacks addresses represented as our 'anchor' since these ptrs |
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
are exposed to a user (um, not that we don't trust 'em or anything). |
plus, we can NULL delimit these ptrs which we couldn't do otherwise. | */
if (n_saved < n_inuse + 1) {
n_saved = n_inuse + 1;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (!(info->fetch.results.stacks = realloc(info->fetch.results.stacks, sizeof(void *) * n_saved)))
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
return -ENOMEM;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
}
memcpy(info->fetch.results.stacks, info->fetch.anchor, sizeof(void *) * n_inuse);
info->fetch.results.stacks[n_inuse] = NULL;
info->fetch.results.total = n_inuse;
return n_inuse;
#undef n_alloc
#undef n_inuse
#undef n_saved
} // end: stacks_fetch
static int stacks_reconfig_maybe (
struct ext_support *this,
enum slabinfo_item *items,
int numitems)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (items_check_failed(this, items, numitems))
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return -EINVAL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/* is this the first time or have things changed since we were last called?
if so, gotta' redo all of our stacks stuff ... */
if (this->numitems != numitems + 1
|| memcmp(this->items, items, sizeof(enum slabinfo_item) * numitems)) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// allow for our SLABINFO_logical_end
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (!(this->items = realloc(this->items, sizeof(enum slabinfo_item) * (numitems + 1))))
return -ENOMEM;
memcpy(this->items, items, sizeof(enum slabinfo_item) * numitems);
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
this->items[numitems] = SLABINFO_logical_end;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
this->numitems = numitems + 1;
if (this->extents)
extents_free_all(this);
return 1;
}
return 0;
} // end: stacks_reconfig_maybe
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: also include a 'read' for slabnode_chain_fill While meminfo does implement only the singular version of 'xxxx_chain_fill', it was wrong to limit the 'read' to the plural version (only) within our new slabs API. This kind of inconsistency will only spell trouble for future users of the new libprocps API. So, this commit will mean that any form of xxxx_chain(s)_fill function also includes a 'read', whereas xxx_getchain does not. Reference(s): commit aab537bc1333b9ca57eaeec073b51af12f9280f8 http://www.freelists.org/post/procps/newlib-interfaces Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-13 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
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
// --- standard required functions --------------------------------------------
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
/*
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* procps_slabinfo_new():
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* @info: location of returned new structure
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
* Returns: < 0 on failure, 0 on success along with
* a pointer to a new context struct
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*/
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
PROCPS_EXPORT int procps_slabinfo_new (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct slabinfo_info **info)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +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 slabinfo_info *p;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
int rc;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (info == NULL)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return -EINVAL;
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (!(p = calloc(1, sizeof(struct slabinfo_info))))
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return -ENOMEM;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
#ifdef ENFORCE_LOGICAL
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
p->select_ext.lowest = SLABS_OBJS;
p->select_ext.highest = SLABS_DELTA_SIZE_TOTAL;
p->fetch_ext.lowest = SLABNODE_NAME;
p->fetch_ext.highest = SLABNODE_SIZE;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
#endif
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
p->refcount = 1;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
/* do a priming read here for the following potential benefits: |
1) see if that caller's permissions were sufficient (root) |
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
2) make delta results potentially useful, even if 1st time | */
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if ((rc = read_slabinfo_failed(p))) {
procps_slabinfo_unref(&p);
return rc;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
*info = p;
return 0;
} // end: procps_slabinfo_new
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
PROCPS_EXPORT int procps_slabinfo_ref (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct slabinfo_info *info)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (info == NULL)
return -EINVAL;
info->refcount++;
return info->refcount;
} // end: procps_slabinfo_ref
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
PROCPS_EXPORT int procps_slabinfo_unref (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct slabinfo_info **info)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (info == NULL || *info == NULL)
return -EINVAL;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
(*info)->refcount--;
if ((*info)->refcount == 0) {
if ((*info)->slabinfo_fp) {
fclose((*info)->slabinfo_fp);
(*info)->slabinfo_fp = NULL;
}
if ((*info)->select_ext.extents)
extents_free_all((&(*info)->select_ext));
if ((*info)->select_ext.items)
free((*info)->select_ext.items);
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
if ((*info)->fetch.anchor)
free((*info)->fetch.anchor);
if ((*info)->fetch.results.stacks)
free((*info)->fetch.results.stacks);
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if ((*info)->fetch_ext.extents)
extents_free_all(&(*info)->fetch_ext);
if ((*info)->fetch_ext.items)
free((*info)->fetch_ext.items);
free((*info)->nodes);
free(*info);
*info = NULL;
return 0;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return (*info)->refcount;
} // end: procps_slabinfo_unref
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
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
// --- variable interface functions -------------------------------------------
library: <SLABINFO> api, change 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
PROCPS_EXPORT struct slabinfo_result *procps_slabinfo_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 slabinfo_info *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item item)
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
static time_t sav_secs;
time_t cur_secs;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (info == NULL)
library: <SLABINFO> api, change 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
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (item < 0 || item >= SLABINFO_logical_end)
library: <SLABINFO> api, change 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
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/* we will NOT read the slabinfo file with every call - rather, we'll offer
a granularity of 1 second between reads ... */
cur_secs = time(NULL);
if (1 <= cur_secs - sav_secs) {
library: <SLABINFO> api, change 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
if (read_slabinfo_failed(info))
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
sav_secs = cur_secs;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
}
library: <SLABINFO> api, change 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
info->get_this.item = item;
// with 'get', we must NOT honor the usual 'noop' guarantee
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// if (item > SLABINFO_noop)
library: <SLABINFO> api, change 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
info->get_this.result.ul_int = 0;
Item_table[item].setsfunc(&info->get_this, &info->hist, &info->nul_node);
return &info->get_this;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: procps_slabinfo_get
/* procps_slabinfo_reap():
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
* Harvest all the requested SLABNODE (individual nodes) information
* providing the result stacks along with the total number of nodes.
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
library: overcome effect of copy/paste, <SLABINFO> api Needless to say, when one copies and then pastes, it's always better when those results are refined somewhat. The qsort callback declarations used the wrong results type and 2 of their 3 input parameters were wrong too. So this patch will fix that & generalize declarations. [ plus add comment guidance about noop & extra enums ] [ & provide for 'noop' sorting, as is done in <PIDS> ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
* Returns: pointer to a slabinfo_reap struct on success, NULL on error.
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*/
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
PROCPS_EXPORT struct slabinfo_reap *procps_slabinfo_reap (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct slabinfo_info *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item *items,
int numitems)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
if (info == NULL || items == NULL)
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (0 > stacks_reconfig_maybe(&info->fetch_ext, items, numitems))
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (info->fetch_ext.dirty_stacks)
cleanup_stacks_all(&info->fetch_ext);
if (read_slabinfo_failed(info))
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
stacks_fetch(info);
info->fetch_ext.dirty_stacks = 1;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
return &info->fetch.results;
} // end: procps_slabinfo_reap
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
/* procps_slabinfo_select():
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
*
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
* Obtain all the requested SLABS (global) information then return
* it in a single library provided results stack.
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
*
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* Returns: pointer to a slabinfo_stack struct on success, NULL on error.
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
*/
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
PROCPS_EXPORT struct slabinfo_stack *procps_slabinfo_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 slabinfo_info *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item *items,
int numitems)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (info == NULL || items == NULL)
return NULL;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (0 > stacks_reconfig_maybe(&info->select_ext, items, numitems))
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (!info->select_ext.extents
&& !(stacks_alloc(&info->select_ext, 1)))
return NULL;
if (info->select_ext.dirty_stacks)
cleanup_stacks_all(&info->select_ext);
if (read_slabinfo_failed(info))
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
assign_results(info->select_ext.extents->stacks[0], &info->hist, &info->nul_node);
info->select_ext.dirty_stacks = 1;
return info->select_ext.extents->stacks[0];
} // end: procps_slabinfo_select
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
/*
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* procps_slabinfo_sort():
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
*
library: the overlooked twerks (oops, tweaks), 3rd gen Yes, all of these changes are strictly cosmetic. It is likely symptomatic of some deep-seated character flaw. [ or, it might be because of a certain pride in this ] [ new library and the desire to make it even better! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-07 10:30:00 +05:30
* Sort stacks anchored in the passed stack pointers array
* based on the designated sort enumerator and specified order.
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
*
library: tweak new interface code and improve comments With a little help from smatch, this commit eliminates some inappropriate code. Also some programmer comments were (barely) improved (i hope) in some small measure. Reference(s): smatch: 406 procps_meminfo_chain_fill() warn: variable dereferenced before check 'chain' (see line 403) Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-13 10:30:00 +05:30
* Returns those same addresses sorted.
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
* Note: all of the stacks must be homogeneous (of equal length and content).
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
*/
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
PROCPS_EXPORT struct slabinfo_stack **procps_slabinfo_sort (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct slabinfo_info *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_stack *stacks[],
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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 numstacked,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item sortitem,
enum slabinfo_sort_order order)
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
{
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_result *p;
struct sort_parms parms;
int offset;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
if (info == NULL || stacks == NULL)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: slab sort derefence after check procps_slabnode_stacks_sort() would check if stacks was NULL *after* the pointer was derefenced in the initialisation of the variable p. p is now assigned after the check. References: Coverity #99160
2016-05-14 18:02:35 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
// a slabinfo_item is currently unsigned, but we'll protect our future
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (sortitem < 0 || sortitem >= SLABINFO_logical_end)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (order != SLABINFO_SORT_ASCEND && order != SLABINFO_SORT_DESCEND)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
if (numstacked < 2)
return stacks;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
offset = 0;
library: slab sort derefence after check procps_slabnode_stacks_sort() would check if stacks was NULL *after* the pointer was derefenced in the initialisation of the variable p. p is now assigned after the check. References: Coverity #99160
2016-05-14 18:02:35 +05:30
p = stacks[0]->head;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
for (;;) {
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
if (p->item == sortitem)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
break;
++offset;
misc: tweaks (mostly cosmetic) to several source files . a more appropriate error return code was substituted . a safer form of comparison is utilized in two places . a STAT_VAL macro replaced by more proper MEMINFO_VAL . several of the silly 'xerrx' formats had been missed . a few whitespace changes have also been incorporated Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if (p->item >= SLABINFO_logical_end)
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
++p;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
parms.offset = offset;
parms.order = order;
qsort_r(stacks, numstacked, sizeof(void *), (QSR_t)Item_table[p->item].sortfunc, &parms);
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
return stacks;
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
} // end: procps_slabinfo_sort
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
// --- special debugging function(s) ------------------------------------------
/*
* The following isn't part of the normal programming interface. Rather,
* it exists to validate result types referenced in application programs.
*
* It's used only when:
* 1) the 'XTRA_PROCPS_DEBUG' has been defined, or
* 2) the '#include <proc/xtra-procps-debug.h>' used
*/
PROCPS_EXPORT struct slabinfo_result *xtra_slabinfo_get (
struct slabinfo_info *info,
enum slabinfo_item actual_enum,
const char *typestr,
const char *file,
int lineno)
{
struct slabinfo_result *r = procps_slabinfo_get(info, actual_enum);
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
if (actual_enum < 0 || actual_enum >= SLABINFO_logical_end) {
fprintf(stderr, "%s line %d: invalid item = %d, type = %s\n"
, file, lineno, actual_enum, typestr);
}
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (r) {
char *str = Item_table[r->item].type2str;
if (str[0]
&& (strcmp(typestr, str)))
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
}
return r;
} // end: xtra_slabinfo_get_
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
PROCPS_EXPORT struct slabinfo_result *xtra_slabinfo_val (
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
int relative_enum,
const char *typestr,
const struct slabinfo_stack *stack,
struct slabinfo_info *info,
const char *file,
int lineno)
{
char *str;
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
int i;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
for (i = 0; stack->head[i].item < SLABINFO_logical_end; i++)
;
if (relative_enum < 0 || relative_enum >= i) {
fprintf(stderr, "%s line %d: invalid relative_enum = %d, type = %s\n"
, file, lineno, relative_enum, typestr);
return NULL;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
}
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
str = Item_table[stack->head[relative_enum].item].type2str;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (str[0]
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
&& (strcmp(typestr, str))) {
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
}
return &stack->head[relative_enum];
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
} // end: xtra_slabinfo_val
Reference in New Issue Copy Permalink