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

85 lines
1.7 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
closeproc;
dev_to_tty;
escape_command;
escape_str;
escape_strlist;
escaped_copy;
Expose freeproc for libproc freeproc was missing from the libproc API which meant while you could allocate proc structures, you couldn't free them! Bug-Debian: http://bugs.debian.org/681653
2013-01-01 07:43:44 +05:30
freeproc;
procps: add support for linux namespaces Each process in Linux has a /proc/<pid>/ns directory which contains symbolic links to pipes that identify which namespaces that process belongs to. This patch adds support for ps to display that information optionally. Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
2013-04-09 00:33:13 +05:30
get_ns_id;
get_ns_name;
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
get_pid_digits;
look_up_our_self;
lookup_wchan;
openproc;
readeither;
readproc;
readproctab2;
readproctab3;
readproctab;
readtask;
tty_to_dev;
user_from_uid;
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: 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_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 10:30:00 +05:30
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 03:13:02 +05:30
procps_stat_ref;
procps_stat_unref;
procps_stat_get_cpu;
library: add chaining provisions to readstat cpu & sys If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
procps_stat_get_cpu_chain;
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 10:30:00 +05:30
procps_stat_get_jiffs;
procps_stat_get_jiffs_all;
procps_stat_get_jiffs_hist;
procps_stat_get_jiffs_hist_all;
library: tweak formatting for readstat header and code This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. The following names were changed to more closely match meminfo.c or provide a certain symmetry. Unfortunately that also impacted some other pgms which were updated. . 'procps_stat_get' evolved into 'procps_stat_get_sys' . 'procps_stat_info' is now known as 'procps_statinfo' [and just a little trailing whitespace was eliminated] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
procps_stat_get_sys;
library: add chaining provisions to readstat cpu & sys If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
procps_stat_get_sys_chain;
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: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
procps_vmstat_get_chain;
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