emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
5ec5002b0d
procps/proc/libprocps.sym

73 lines
1.5 KiB
Plaintext
Raw Normal View History

Renaming libprocfs to libprocps The library used to be called libprocps but it was renamed to make sure there was only one. However the formatting of the library SONAME has changed so there cannot be any confusion. libprocps makes it clear that its a library from this project and not a set of functions directly on the filesystem.
2011-12-23 03:48:43 +05:30
LIBPROCPS_0 {
library.map
2003-01-24 15:45:23 +05:30
global:
libproc-ng: fix ld version script file support Notice that contents of file library.map file are almost certainly wrong as it is making everything exported. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-11-05 17:59:54 +05:30
escape_str;
library: introduce a fatal 'proc not mounted' function Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-11 10:30:00 +05:30
fatal_proc_unmounted;
library: Replace smp_num_cpu with function Instead of exposing a variable smp_num_cpus that is updated with cpuinfo, use procps_cpu_count() which returns the same value.
2015-06-29 18:01:36 +05:30
procps_cpu_count;
library: Update diskstat API The calls for reading diskstat have been moved out of sysinfo and into new files diskstat.[ch] These new library calls follow the standard pattern for the new libprocps. vmstat is updated to use the new API and also got the weighted IO time added. vmstat -p previously would only show partitions, not disks. There does not appear to be any good reason to artifically deny a user to use this command on a disk, rather than a partition so this restriction was lifted. I also realised using int for devid means you can send the library negative numbers, the index uses unsigned int. Other similiar calls will need to be fixed too. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-07-07 18:12:06 +05:30
procps_diskstat_dev_count;
procps_diskstat_dev_get;
procps_diskstat_dev_getbyname;
procps_diskstat_dev_getname;
procps_diskstat_dev_isdisk;
procps_diskstat_new;
procps_diskstat_read;
procps_diskstat_ref;
procps_diskstat_unref;
library: more mem and stat fixes Make distcheck now succeeds. Changed some of the binaries to use the new API.
2015-06-24 17:46:16 +05:30
procps_hertz_get;
library: Change linux version Added function procps_linux_version() which used to be an exported integer instead. Also changed the method of obtaining the linux version (more correctly the os release) to use a specific procfs entry. This works for both Linux and FreeBSD.
2015-06-19 16:30:46 +05:30
procps_linux_version;
library: loadavg change to procps_loadavg
2015-07-01 17:17:30 +05:30
procps_loadavg;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
procps_meminfo_new;
procps_meminfo_read;
procps_meminfo_ref;
procps_meminfo_unref;
procps_meminfo_get;
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
procps_meminfo_getstack;
procps_meminfo_stack_fill;
procps_meminfo_stack_alloc;
library: rework namespace calls Functions related to namespaces were half-in half-out of the procps library and didn't fit the standard naming scheme. While struct { long ns[x]} is a bit clunky, its the only way to "lock in" x. The alternative is to use ns_* variables. This work was needed before pgrep could be converted.
2015-09-03 18:02:19 +05:30
procps_ns_get_name;
procps_ns_get_id;
procps_ns_read_pid;
library: cleanup of library includes The includes used to define a lot of things a library include should not. It was also a bit messy what was exposed in the library and what was not. get_pid_digits -> procps_pid_length and exported correctly MALLOC attribute move into relevant .c files NORETURN attribute moved to relevant .c, not used in library PURE attribute removed, it wasn't used KLONG/KLF/STRTOUKL were fixed for long, so now just use long HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT seems to do the same (opposite) thing. likely/unlikely removed from most places, its highly debateable this does anything useful as CPUs have gotten smarter about branches. Re-arranged the includes, ALL external programs should just #include <proc/procps.h> then proc/procps.h includes headers for files that have exported functions. procps.h and the headers it includes should not use items that are not exportable (e.g. hidden functions or macros) they go in procps-private.h
2016-04-16 12:33:57 +05:30
procps_pid_length;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
procps_pids_new;
library: add sequential access to that pids collection To ease the transition to the new interface, for other than that top program, individual read provisions have been added to the <proc/pids.h> API. This represents a refinement of a position stated in a post noted below. Reference(s): http://www.freelists.org/post/procps/newlib-ps-fix Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-26 10:30:00 +05:30
procps_pids_read_next;
procps_pids_read_open;
procps_pids_read_shut;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
procps_pids_reap;
procps_pids_ref;
procps_pids_reset;
library: normalize the <pids> fill/selection interface After wrestling with the conversion of both top and ps the differences between reap (all) & fill (select) has become increasingly inconvenient. So this patch simply normalizes that API making returned results identical. The former procps_pids_stacks_fill identifier will now be known as procps_pids_select which serves as logical counterpart to the existing procps_pids_reap function. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-01 10:30:00 +05:30
procps_pids_select;
library: rename the 'procps_pids_stacks_sort' function The above function was the sole public function in the <pids> interface to use the word 'stacks' in its name. All of the others dealt exclusively with their duties, So this commit normalizes that outlier by renaming it. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-10-11 10:30:00 +05:30
procps_pids_sort;
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 10:30:00 +05:30
procps_pids_unref;
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
procps_slabinfo_new;
procps_slabinfo_read;
procps_slabinfo_ref;
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
procps_slabs_get;
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
procps_slabs_getstack;
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
procps_slabnode_count;
procps_slabnode_getname;
procps_slabnode_get;
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
procps_slabnode_getstack;
procps_slabnode_stack_fill;
procps_slabnode_stack_alloc;
procps_slabnode_stacks_fill;
procps_slabnode_stacks_sort;
procps_slabnode_stacks_alloc;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
procps_stat_new;
procps_stat_ref;
procps_stat_unref;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
procps_stat_get;
procps_stat_reap;
procps_stat_select;
library: Update uptime calls to standard format Changed all the uptime related functions to use the standard naming procps_uptime_*
2015-06-29 17:39:59 +05:30
procps_uptime;
procps_uptime_sprint;
procps_uptime_sprint_short;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
procps_vmstat_new;
procps_vmstat_read;
procps_vmstat_ref;
procps_vmstat_unref;
procps_vmstat_get;
library: vmstat redesign now using '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: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
procps_vmstat_getstack;
libproc-ng: fix ld version script file support Notice that contents of file library.map file are almost certainly wrong as it is making everything exported. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-11-05 17:59:54 +05:30
local:
*;
new gcc+ld+gas features
2003-01-15 16:22:39 +05:30
};
Reference in New Issue Copy Permalink