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

93 lines
1.9 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 09:18:43 +11:00
LIBPROCPS_0 {
library.map
2003-01-24 10:15:23 +00:00
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 13:29:54 +01:00
closeproc;
dev_to_tty;
escape_command;
escape_str;
escape_strlist;
escaped_copy;
library: introduce a fatal 'proc not mounted' function Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-11 00:00:00 -05:00
fatal_proc_unmounted;
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 13:29:54 +01:00
get_pid_digits;
look_up_our_self;
lookup_wchan;
openproc;
readproc;
readproctab2;
readproctab3;
readproctab;
readtask;
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 22:31:36 +10:00
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 22:42:06 +10:00
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 22:16:16 +10:00
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 21:00:46 +10:00
procps_linux_version;
library: loadavg change to procps_loadavg
2015-07-01 21:47:30 +10:00
procps_loadavg;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 23:08:47 +10:00
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 00:00:00 -05:00
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 22:32:19 +10:00
procps_ns_get_name;
procps_ns_get_id;
procps_ns_read_pid;
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 00:00:00 -05:00
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 00:00:00 -05:00
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 00:00:00 -05:00
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 00:00:00 -05:00
procps_pids_select;
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 00:00:00 -05:00
procps_pids_stacks_sort;
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-03 23:59:59 -05:00
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 00:00:00 -05:00
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 00:00:00 -05:00
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 00:00:00 -05:00
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 00:00:00 -05:00
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 07:43:02 +10:00
procps_stat_new;
procps_stat_read;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 00:00:00 -05:00
procps_stat_read_jiffs;
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 07:43:02 +10:00
procps_stat_ref;
procps_stat_unref;
library: readstat redesigned 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: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . 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 00:00:00 -05:00
procps_stat_cpu_get;
procps_stat_cpu_getstack;
procps_stat_jiffs_get;
procps_stat_jiffs_hist_get;
procps_stat_jiffs_fill;
procps_stat_jiffs_hist_fill;
procps_stat_sys_get;
procps_stat_sys_getstack;
library: Update uptime calls to standard format Changed all the uptime related functions to use the standard naming procps_uptime_*
2015-06-29 22:09:59 +10:00
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 07:43:02 +10:00
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 00:00:00 -05:00
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 13:29:54 +01:00
local:
*;
new gcc+ld+gas features
2003-01-15 10:52:39 +00:00
};
Reference in New Issue Copy Permalink