Now that the procio logic was removed from the library
we must move the header file, lest we break make dist.
In the process, we will relocate that source file too.
[ we'll take a slightly different approach than that ]
[ used under the master branch by exploiting those 2 ]
[ non-library directories 'include' and 'lib', while ]
[ avoiding any sysctl hard coded function prototype. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The procio functions that were in the library have been
moved into sysctl. sysctl is not linked to libprocps in
newlib and none of the other procps binaries would need
to read/write large data to the procfs.
References:
be6b048a41
to be able to read and write large buffers below /proc.
The buffers and file offsets are handled dynamically
on the required buffer size at read, that is lseek(2)
is used to determine this size. Large buffers at
write are split at a delimeter into pieces and also
lseek(2) is used to write each of them.
Signed-off-by: Werner Fink <werner@suse.de>
In response to that suggestion referenced below, these
changes allow display of task/thread level NUMA nodes.
Currently, only the 'top' program offers any NUMA type
support and it is limited to the Summary Area display.
With this commit both the 'top' and 'ps' programs will
be able to display NUMA nodes associated with threads.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/58
Signed-off-by: Jim Warner <james.warner@comcast.net>
During development, we now have a means for validating
that a type referenced in application code matches the
actual type set by the library. The new feature can be
activated through either of the following two methods:
1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms)
2) an #include <proc/xtra-procps-debug.h> (single pgm)
[ in the future, one could add a formal configure.ac ]
[ provision. but for now a manual approach is safer. ]
Lastly, for any module which provides a sort function,
the handling for both 'noop' & 'extra' enumerators was
made consistent. Now, 'noop' is not sorted and 'extra'
will be sorted as that module's widest supported type.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Where possible, libprocps files convey the name of the
actual source pseudo file under the '/proc' directory.
This brings diskstats into line with such an approach.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Previously there was a commit to change all noinst_PROGRAMS into
check_PROGRAMS. This was not a good idea.
check_PROGRAMS are built before TESTS are run. However they are
NOT build before the dejagnu tests are run, causing those tests
to fail.
So:
If the program is required for dejagnu, it needs to go into
noinst_PROGRAMS
If the program is required for TESTS or is one of those TESTS,
it needs to go into check_PROGRAMS
For some unknown reason, check_PROGRAMS are not built before check.
They are built before recheck and after check, which isn't very
useful.
This means any tests by dejagnu that need those programs will fail.
On my console I get a build error, the CI merrily reports the error
but considers the build OK; go figure.
The kludge adds check_PROGRAMS to be a dependency to check.
Note, TESTS don't need to be included in this, because they are
properly compliled after the dejagnu tests but before they are
run.
Where possible, libprocps files convey the name of the
actual source pseudo file under the '/proc' directory.
This patch brings slab into line with such a standard.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In an attempt to normalize the 'stat' interface, we'll
first shed any reminders of the old readproc interface
by changing file names to be more descriptive & brief.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the configure option --enable-harden-flags the CFLAGS and
LDFLAGS are manipulated to provide some hardening protection
to the binaries.
psmisc uses these flags on by default with no troubles, however
it doesn't have a library in it either.
References:
https://wiki.debian.org/Hardening
Generalised the library API tests and created a common
test-runner. Instead of copy and pasting the same code in
each time.
First cut of pids API test, for _new so far.
There is a need in some utilities to have a way of accepting both
types of decimal points "." and ",". The only way seems to be to
rebuild strtod().
This new function will accept "123.456" and "123,456" as 123.456
and considers them the same number. It means we lose thousands
separator, but this is rarely used.
test scripts are added to check the function returns the proper
values. There was simpler predecessor that got stuck on negative
0 or -0.123 which these tests flushed out.
References:
The first part of fixing skill/snice to use the library instead
of directly readdir()ing /proc which is what it does now.
Remove the kill code from the skill/snice code and put common
elements into lib/signals.c Not 100% sure that is the right
destination instead of a new lib file, but ok for now.
kill shares some parsing logic with skill/snice but mainly
around signal specifications. The "do it" code is very different.
Signed-off-by: Craig Small <csmall@enc.com.au>
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.
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>
procps v3.3.11 will bring Library API 5:0:0
The reason for the change is the removal of some calls and
the addition of others. The newlib branch should hopefully
reset some of these changes to a much slower pace.
Signed-off-by: Craig Small <csmall@enc.com.au>
.version is created in the top_srdir which when building normally
doesn't present a problem. When make distcheck is run, the source
directory is made read-only and it fails with permission denied.
The version of misc/git-version-gen is old and is missing the
instruction to add .version to EXTRA_DIST. This commit does just
that.
make distcheck now passes.
References:
https://github.com/gagern/gnulib/blob/master/build-aux/git-version-genhttps://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00000.html
Signed-off-by: Craig Small <csmall@enc.com.au>
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>
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.
This patch handles signal related functions in two ways:
For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.
For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.
To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
Created new set of functions for meminfo related calls. Liked the
format of that better so changed vmstat around so the look similar.
Missed the makefile change for uptime so added it in now.
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>
pwdx doesn't actually use any of the libprocps functions but
it is linked because it is the default. This specific LDADD
removes that unrequired linking.
Several Debian based distributions were recently found
to have omitted a kernel configuration option that had
the effect of rendering /proc/#/stat and /proc/#/wchan
useless for providing any 'sleeping in function' info.
That problem also prompted a reevaluation of the whole
approach to wchan matters which had grown increasingly
complex as our library evolved over the last 13 years.
The net result was a decision to rely on /proc/#/wchan
which arrived along with the 2.5 kernel. This then let
us vastly simplify the internal code plus the external
interface which will benefit both the top and ps pgms.
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11https://lkml.org/lkml/2008/11/6/12https://bugs.debian.org/711592
Signed-off-by: Jim Warner <james.warner@comcast.net>
