96d59cbf46
A lack of documentation seems to be the major obstacle to releasing this new library. So, in an effort to get the ball rolling again, this patch adds the origins of each item as a comment to six of the new header files. However, before reviewing how such changes may benefit that documentation objective, it seemed appropriate to first reflect on newlib's background & current status. ___________________________________________ BACKGROUND Discussions about and work on a new library began back in July 2012 but quickly died. After a lull of 2 years those discussions were resumed in August 2014 but soon died also (and no code survived the gitorious demise). With those early discussions, the recommended approach was to encapsulate all of the libprocps data offerings in individual functions. When it came to extensibility it was suggested we should rely on symbols versioning. Unfortunately that approach would have made for a huge Application Programming Interface virtually impossible to master or even document. And, runtime call overhead would have been substantial for ps and especially top. So, an alternative design was sought but there were no new suggestions/contributions via freelists or gitlab. Thus, in spite of a lack of library design experience, the procps-ng team (Craig & Jim) set out to develop an alternative API, more concise and with lower overhead. Reference(s): . 07/01/2012, begin library design discussion https://www.freelists.org/post/procps/Old-library-calls . 08/12/2014, revival of library design discussion https://www.freelists.org/post/procps/libprocs-redesign _____________________________________ DESIGN EVOLUTION Our newlib branch first appeared on June 14, 2015. And our current API actually represents the 4th generation during the past 3 years of evolution. First, there was a basic 'new', 'get' and 'unref' approach, using enums to minimize the proliferation of 'get' function calls. Then, in anticipation of other programs like ps, where multiple fields times multiple processes would greatly increase the number of 'get' function calls, a concept of 'chains' was introduced. This became generation #2. Such 'chains' proved unnecessarily complex so 'stacks' replaced them. This was considered the 3rd generation, but too many implementation details were still exposed requiring those users to 'alloc', 'read', 'fill', etc. Finally, a 4th generation emerged representing several refinements to standardize and minimize those exported functions, thus hiding all implementation details from the users. Lastly, handling of 'errno' was normalized. Reference(s): . 06/14/2015, revival of new API discussion https://www.freelists.org/post/procps/The-library-API-again . 06/24/2015, birth of the newlib branch https://www.freelists.org/post/procps/new-library . 06/29/2015, 2nd generation introduced 'chains' https://www.freelists.org/post/procps/new-library,8 . 07/22/2015, 3rd generation introduced 'stacks' https://www.freelists.org/post/procps/newlib-stacks-vs-chains . 06/18/2016, 4th generation refinements begin https://www.freelists.org/post/procps/newlib-generation-35 . 11/10/2017, 4th generation standardized 'errno' https://www.freelists.org/post/procps/some-more-master-newlib-stuff _______________________________________ CURRENT DESIGN Central to this new design is a simple 'result' struct reflecting an item plus its value (thanks to a union). As a user option, these item structures can be grouped into 'stacks', yielding many results with just 1 call. Such a 'stack' can be seen as a variable length record whose content/order is determined solely by the users. Within that 'result' structure, the union has standard C language types so there is never a doubt how a value should be used in a printf statement. Given that linux requires a least a 32-bit platform the only difference in capacity surrounds 'long' integers. And, where such types might be used, the 32-bit maximums are adequate. The items themselves are simply enumerators defined in the respective header files. A user can name any items of interest then the library magically provides result structure(s). The approach was proven to be extensible without breaking the ABI (in commit referenced below). The 6 major APIs each provide for the following calls: . 'new' ---------> always required as the first call . . 'ref' -------------------------> strictly optional . . 'unref' --------> optional, if ill-behaved program . . 'get' --------------------> retrieve a single item . . 'select' ----------------> retrieve multiple items . And the 'get' and 'select' functions provide for delta results representing the difference between successive get/select calls (or a 'new' then 'get/select' call). For the <diskstats>, <pids>, <slabinfo> & <stat> APIs, where results are unpredictable, a 'reap' function can return multiple result structures for multiple stacks. The <pids> API differs from others in that those items of interest must be provided at 'new' or 'reset' time, a function unique to this API. And the <pids> 'select' function requires PIDs or UIDs which are to be fetched which then operates as a subset of 'reap'. Lastly, the 'get' function is an iterator for successive PIDs/TIDs returning items previously identified via 'new/reset'. To provide assistance to users during development, the special header 'proc/xtra-procps-debug.h' is available to check type usage against library expectations. That check is activated by including this header explicitly or via build using: ./configure '-DXTRA_PROCPS_DEBUG'. Reference(s): . 08/05/2016, type validation introduced https://www.freelists.org/post/procps/newlib-types-validation commite3270d463d. 08/11/2016, extensibility while preserving ABI example https://www.freelists.org/post/procps/new-meminfo-fields commit09e1886c9e_________________________ INITIAL DOCUMENTATION EFFORT The initial attempt, referenced below, dealt primarily with the <pids> interface. Separate man pages for each exported function were created. Plus there was another document describing the items, among other miscellany. Adopting such an approach encounters several problems: 1. In order to use these man pages, users are required to already know how to use the library. Or alternately one could randomly search each of them while trying to ascertain which function call satisfies their need and what exactly was the proper compliment/order required. 2. While we can explain what all of those <pids> items represent, that certainly isn't true for all the APIs. See the gaps in kernel documentation for <meminfo> and complete lack of documentation with that <vmstat> API. 3. Our documentation effort should take pains to avoid unnecessary implementation details. Here's an example: . "The pointer to info will have memory" . "allocated and a structure created." Alternatively, the following conveys user requirements while not offering any internal implementation detail: . "You must provide the address of a NULL" . "info structure pointer." Reference(s): . 01/04/2017, initial documentation offering https://www.freelists.org/post/procps/Using-reap-and-get commit2598e9f2ce___________________ RECOMMENDED DOCUMENTATION APPROACH I recommend that the newlib documentation consist of 3 man pages only. The first would cover the 5 major APIs and their common functions. The second would deal with the <pids> API exclusively, explaining how it differs. Any remaining exported libproc functions which are yet to be included could be represented in a 3rd document. For these new documents the following are are assumed: 1. Since we will not be able to document all items, we shouldn't try to document any items. We should instead rely on proc(5) or Documentation/filesystems/proc.txt. 2. Program development often involves referencing some header file(s). So, make that an absolute requirement. 3. With the addition of item origins, represented with this commit, and considering that 'types' were already present, the header file might be all some users need. 4. And who knows, when a user of our libproc complains about gaps in their documentation, it might prompt the kernel folks to correct those long standing omissions. To summarize, I suggest that we replace that libproc.3 document with a more general one explaining the basics of accessing this new library and the common calls for most of the major interfaces. We can then create a new document (libproc-pids.3?), which explains differences in using the <PIDS> application programming interface. A final document (libproc-misc.3?) covers what's left. Signed-off-by: Jim Warner <james.warner@comcast.net>
142 lines
4.6 KiB
C
142 lines
4.6 KiB
C
/*
|
|
* libprocps - Library to read proc filesystem
|
|
*
|
|
* Copyright (C) 1998-2005 Albert Cahalan
|
|
* Copyright (C) 2015 Craig Small <csmall@enc.com.au>
|
|
* Copyright (C) 2016 Jim Warnerl <james.warner@comcast.net>
|
|
*
|
|
* This library is free software; you can redistribute it and/or
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
* License as published by the Free Software Foundation; either
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
*
|
|
* This library is distributed in the hope that it will be useful,
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
* Lesser General Public License for more details.
|
|
*
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
* License along with this library; if not, write to the Free Software
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
*/
|
|
|
|
#ifndef PROCPS_SLABINFO_H
|
|
#define PROCPS_SLABINFO_H
|
|
|
|
#ifdef __cplusplus
|
|
extern "C "{
|
|
#endif
|
|
|
|
enum slabinfo_item {
|
|
SLABINFO_noop, // ( never altered )
|
|
SLABINFO_extra, // ( reset to zero )
|
|
// returns origin, see proc(5)
|
|
// ------- -------------------
|
|
SLABS_OBJS, // u_int /proc/slabinfo
|
|
SLABS_AOBJS, // u_int "
|
|
SLABS_PAGES, // u_int "
|
|
SLABS_SLABS, // u_int "
|
|
SLABS_ASLABS, // u_int "
|
|
SLABS_CACHES, // u_int "
|
|
SLABS_ACACHES, // u_int "
|
|
SLABS_SIZE_AVG, // u_int "
|
|
SLABS_SIZE_MIN, // u_int "
|
|
SLABS_SIZE_MAX, // u_int "
|
|
SLABS_SIZE_ACTIVE, // ul_int "
|
|
SLABS_SIZE_TOTAL, // ul_int "
|
|
|
|
SLABS_DELTA_OBJS, // s_int dervied from above
|
|
SLABS_DELTA_AOBJS, // s_int "
|
|
SLABS_DELTA_PAGES, // s_int "
|
|
SLABS_DELTA_SLABS, // s_int "
|
|
SLABS_DELTA_ASLABS, // s_int "
|
|
SLABS_DELTA_CACHES, // s_int "
|
|
SLABS_DELTA_ACACHES, // s_int "
|
|
SLABS_DELTA_SIZE_AVG, // s_int "
|
|
SLABS_DELTA_SIZE_MIN, // s_int "
|
|
SLABS_DELTA_SIZE_MAX, // s_int "
|
|
SLABS_DELTA_SIZE_ACTIVE, // s_int "
|
|
SLABS_DELTA_SIZE_TOTAL, // s_int "
|
|
|
|
SLABNODE_NAME, // str /proc/slabinfo
|
|
SLABNODE_OBJS, // u_int "
|
|
SLABNODE_AOBJS, // u_int "
|
|
SLABNODE_OBJ_SIZE, // u_int "
|
|
SLABNODE_OBJS_PER_SLAB, // u_int "
|
|
SLABNODE_PAGES_PER_SLAB, // u_int "
|
|
SLABNODE_SLABS, // u_int "
|
|
SLABNODE_ASLABS, // u_int "
|
|
SLABNODE_USE, // u_int "
|
|
SLABNODE_SIZE // ul_int "
|
|
};
|
|
|
|
enum slabinfo_sort_order {
|
|
SLABINFO_SORT_ASCEND = +1,
|
|
SLABINFO_SORT_DESCEND = -1
|
|
};
|
|
|
|
|
|
struct slabinfo_result {
|
|
enum slabinfo_item item;
|
|
union {
|
|
signed int s_int;
|
|
unsigned int u_int;
|
|
unsigned long ul_int;
|
|
char *str;
|
|
} result;
|
|
};
|
|
|
|
struct slabinfo_stack {
|
|
struct slabinfo_result *head;
|
|
};
|
|
|
|
struct slabinfo_reap {
|
|
int total;
|
|
struct slabinfo_stack **stacks;
|
|
};
|
|
|
|
|
|
#define SLABINFO_GET( info, actual_enum, type ) ( { \
|
|
struct slabinfo_result *r = procps_slabinfo_get( info, actual_enum ); \
|
|
r ? r->result . type : 0; } )
|
|
|
|
#define SLABINFO_VAL( relative_enum, type, stack, info ) \
|
|
stack -> head [ relative_enum ] . result . type
|
|
|
|
|
|
struct slabinfo_info;
|
|
|
|
int procps_slabinfo_new (struct slabinfo_info **info);
|
|
int procps_slabinfo_ref (struct slabinfo_info *info);
|
|
int procps_slabinfo_unref (struct slabinfo_info **info);
|
|
|
|
struct slabinfo_result *procps_slabinfo_get (
|
|
struct slabinfo_info *info,
|
|
enum slabinfo_item item);
|
|
|
|
struct slabinfo_reap *procps_slabinfo_reap (
|
|
struct slabinfo_info *info,
|
|
enum slabinfo_item *items,
|
|
int numitems);
|
|
|
|
struct slabinfo_stack *procps_slabinfo_select (
|
|
struct slabinfo_info *info,
|
|
enum slabinfo_item *items,
|
|
int numitems);
|
|
|
|
struct slabinfo_stack **procps_slabinfo_sort (
|
|
struct slabinfo_info *info,
|
|
struct slabinfo_stack *stacks[],
|
|
int numstacked,
|
|
enum slabinfo_item sortitem,
|
|
enum slabinfo_sort_order order);
|
|
|
|
|
|
#ifdef XTRA_PROCPS_DEBUG
|
|
# include <proc/xtra-procps-debug.h>
|
|
#endif
|
|
#ifdef __cplusplus
|
|
}
|
|
#endif
|
|
#endif
|