procps/proc/libprocps.sym

85 lines
1.7 KiB
Plaintext
Raw Normal View History

LIBPROCPS_0 {
2003-01-24 15:45:23 +05:30
global:
closeproc;
dev_to_tty;
escape_command;
escape_str;
escape_strlist;
escaped_copy;
freeproc;
get_ns_id;
get_ns_name;
get_pid_digits;
look_up_our_self;
lookup_wchan;
openproc;
readeither;
readproc;
readproctab2;
readproctab3;
readproctab;
readtask;
tty_to_dev;
user_from_uid;
procps_cpu_count;
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;
procps_hertz_get;
procps_linux_version;
procps_loadavg;
procps_meminfo_new;
procps_meminfo_read;
procps_meminfo_ref;
procps_meminfo_unref;
procps_meminfo_get;
2015-07-21 10:30:00 +05:30
procps_meminfo_getstack;
procps_meminfo_stack_fill;
procps_meminfo_stack_alloc;
2015-07-04 10:29:59 +05:30
procps_slabinfo_new;
procps_slabinfo_read;
procps_slabinfo_ref;
procps_slabinfo_unref;
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;
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;
procps_stat_new;
procps_stat_read;
procps_stat_read_jiffs;
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 10:30:00 +05:30
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;
procps_uptime;
procps_uptime_sprint;
procps_uptime_sprint_short;
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;
local:
*;
2003-01-15 16:22:39 +05:30
};