procps/proc/libprocps.sym
Jim Warner 5d5a52a380 library: normalize/standardize the i/f, <SLABINFO> api
Before this major redesign, the slabs interface likely
was our messiest 2nd generation attempt at opaqueness.
Beyond the standard 'new', 'ref' & 'unref', there were
a total of 12 exported functions. Now, there are four.

The 1st step was to remove several of those functions.
These were quick to go since they were not used (yet):
. procps_slabnode_count
. procps_slabnode_getname
. procps_slabnode_getstack

Then, the following were internalized so users needn't
be burdened with implementation details in the future:
. procps_slabinfo_read (renamed: read_slabinfo_failed)
. procps_slabnode_stacks_alloc (renamed: stacks_alloc)

Still others evolved into the minimal interface we had
strived for in the other upgraded 3rd generation APIs:
. procps_slabnode_get -----------> procps_slabinfo_get
. separate stack_alloc/fill --> procps_slabinfo_select
. separate stacks_alloc/fill ---> procps_slabinfo_reap
. procps_slabnode_stacks_sort --> procps_slabinfo_sort

------------------------------------------------------
Beyond those reductions, the major modifications were:

. This API tries to be as forgiving as possible and as
such won't throw errors when a caller request makes no
sense. For example, if a 'get' or 'select' requested a
SLABNODE item (with no current means to id that node),
results will be zero. By the same token, should 'reap'
include a global SLABS item (meaning those values will
be duplicated in *every* node stack) it'll be allowed.

. If the above behavior is undesired, a new #define of
ENFORCE_LOGICAL can be used to restrict certain items.

. Permission problems will now be caught at 'new' time
thanks to a priming 'read' call. That read also serves
to make DELTA values potentially useful at 1st access.

. Separate slab/slabnode enumerators were consolidated
into one, simplifying validation & the results struct.

. Several internal parameter checks were relaxed since
they were already checked by the caller. Besides if we
cannot trust our own code we might as well hang it up.

. That sort provision was made more efficient and will
offer the ascending choice, in addition to descending.

------------------------------------------------------
Lastly, some additional thoughts regarding the future:

. It would not be difficult to expand 'select' to also
accept a nodeid, or to clone it as 'select_node'. And,
should the same be extended to 'get', a results struct
could be returned instead of signed long accommodating
the extra data type(s) like a node name (string data).

. The 'get' function is not currently affected by that
 define ENFORCE_LOGICAL. However, at some future point
perhaps -EINVAL would be more appropriate than a zero.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00

59 lines
1.2 KiB
Plaintext

LIBPROCPS_0 {
global:
escape_str;
fatal_proc_unmounted;
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_ref;
procps_meminfo_unref;
procps_meminfo_get;
procps_meminfo_select;
procps_ns_get_name;
procps_ns_get_id;
procps_ns_read_pid;
procps_pid_length;
procps_pids_new;
procps_pids_ref;
procps_pids_unref;
procps_pids_get;
procps_pids_reap;
procps_pids_reset;
procps_pids_select;
procps_pids_sort;
procps_slabinfo_new;
procps_slabinfo_ref;
procps_slabinfo_unref;
procps_slabinfo_get;
procps_slabinfo_reap;
procps_slabinfo_select;
procps_slabinfo_sort;
procps_stat_new;
procps_stat_ref;
procps_stat_unref;
procps_stat_get;
procps_stat_reap;
procps_stat_select;
procps_uptime;
procps_uptime_sprint;
procps_uptime_sprint_short;
procps_vmstat_new;
procps_vmstat_ref;
procps_vmstat_unref;
procps_vmstat_get;
procps_vmstat_select;
local:
*;
};