The machine types are not strictly increasing anymore since Z16, therefore,
we cannot use numerical comparison to find out the correct HSA size
of a machine.
Fixes: 2515832469 ("util_arch: Add IBM z16 as known machine")
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Remove `-rdynamic` since it's a linker flag. This should not cause any problems
because we differentiate between compilation and linking by default. While at
it, adapt the `print_backtrace` documentation accordingly.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Return the partition number which contains the given block range,
before it was tested for exact match between a partition block range
and the one provided by user. The old behavior with exact match
should still work, this change just relaxes the partition matching
algorithm and allows one to find a partition which contains the given
block range.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add generic functions
util_sysdir();
util_sysdir_path()
and their special cases supplied for users:
util_libdir();
util_libdir_path();
util_datadir();
util_datadir_path()
The function util_sysdir() determines the absolute name of a
s390-tools system directory. It could be data, or library directory.
The function util_sysdir_path() determines the absolute name of a
file installed in the s390-tools system directory.
The function util_libdir() determines the absolute name of a
s390-tools library directory. By default that name is defined
by the compile-time macro TOOLS_LIBDIR (/lib/s390-tools).
Users can specify an override by setting environment variable
S390TOOLS_LIBDIR.
The function util_libdir_path() determines the absolute name of a
file installed in the s390-tools library directory.
The function util_datadir() determines the absolute name of a
s390-tools system data directory. By default the name is defined
by the compile-time macro TOOLS_DATADIR (/usr/share/s390-tools/).
Users can specify an override by setting environment variable
S390TOOLS_DATADIR.
The function util_datadir_path() determines the absolute name of a
file installed in the s390-tools data directory.
The ability to override the setting for TOOLS_LIBDIR and
TOOLS_DATADIR is required for implementing tests on tools that are
not installed in their default system path locations.
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The util_arch module is supposed to provide general information about
the underlying architecture of the machine in use.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The only user of util_proc_mnt_get_entry() so far was util_path_sysfs().
With the simplified version there is no user left. Remove
util_proc_mnt_get_entry() and related code.
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Using util_path_sysfs always leaves 5 bytes of memory unfreed as the
value for the sysfs mount point is stored in a static variable to avoid
multiple queries of /proc/mount.
$ valgrind ./util_path_example sysfs
==3629315== Memcheck, a memory error detector
==3629315== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3629315== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3629315== Command: ./util_path_example sysfs
==3629315==
Path for cpu: "/sys/devices/system/cpu"
Path for memory: "/sys/devices/system/memory"
==3629315==
==3629315== HEAP SUMMARY:
==3629315== in use at exit: 5 bytes in 1 blocks
==3629315== total heap usage: 22 allocs, 21 frees, 18,435 bytes allocated
==3629315==
==3629315== LEAK SUMMARY:
==3629315== definitely lost: 0 bytes in 0 blocks
==3629315== indirectly lost: 0 bytes in 0 blocks
==3629315== possibly lost: 0 bytes in 0 blocks
==3629315== still reachable: 5 bytes in 1 blocks
==3629315== suppressed: 0 bytes in 0 blocks
==3629315== Rerun with --leak-check=full to see details of leaked memory
==3629315==
==3629315== For lists of detected and suppressed errors, rerun with: -s
==3629315== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
As per the Kernel rules for accessing sysfs information [1], searching
for the sysfs mount point is a waste of time and systems that don't have
sysfs mounted at /sys are considered broken.
With those things in mind, util_path_sysfs() and especially
sys_mount_point() can be simplified. sys_mount_point() will always
return '/sys' unless the environment variable SYSFS_ROOT is set.
With SYSFS_ROOT still being present, special container setups or test
case scenarios are still possible but might need to be modified if they
previously relied on util_path_sysfs() automatically finding the correct
sysfs mount point.
To make things more secure against malicious strings in SYSFS_ROOT,
secure_getenv() is being used and the ordering of creating the formatted
path string in util_path_sysfs() is changed slightly.
Furthermore, the static variable is removed as no complicated query of
the /proc fs is required anymore. Memory for the sysfs mount point value
is properly freed now at the end of util_path_sysfs().
[1] https://www.kernel.org/doc/html/latest/admin-guide/sysfs-rules.html
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A compile with sparse (make C=1) shows the following warnings:
util_rec.c:211:6: warning: symbol 'rec_print_wide' was not declared.
Should it be static?
util_rec.c:383:6: warning: symbol 'rec_print_csv_hdr' was not declared.
Should it be static?
util_rec.c:404:6: warning: symbol 'rec_print_csv' was not declared.
Should it be static?
These functions are only used internally from function util_rec_print_hdr(),
declare them as static.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A compile with sparse (make C=1) shows the following warnings:
util_opt.c:42:19: warning: symbol 'util_opt_l' was not declared.
Should it be static?
util_prg.c:28:19: warning: symbol 'util_prg_l' was not declared.
Should it be static?
util_opt_l and util_prg_l are not used anywhere, and also not declared in
any header file. Looks like they are superfluous, remove them.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Build:
$ make -C libutil/util_log_example
* Every time a -V option is passed, the verbosity level increases and extra
messages are enabled.
Test:
$ ./libutil/util_log_example
# No output
$ ./libutil/util_log_example -V
ERROR: This is an ERROR message
$ ./libutil/util_log_example -VV
ERROR: This is an ERROR message
WARN: This is a WARN message
$ ./libutil/util_log_example -VVV
ERROR: This is an ERROR message
WARN: This is a WARN message
INFO: This is an INFO message
$ ./libutil/util_log_example -VVVV
ERROR: This is an ERROR message
WARN: This is a WARN message
INFO: This is an INFO message
DEBUG: This is a DEBUG message
$ ./libutil/util_log_example -VVVVV
ERROR: This is an ERROR message
WARN: This is a WARN message
INFO: This is an INFO message
DEBUG: This is a DEBUG message
TRACE: This is a TRACE message
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The goal of util_log is to provide a facility for a multi-level message
logging on stderr. This allows to selectively enable/disable log messages
via a log level which can be adjusted at runtime.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Modern systems have systemd manage system mount points like sysfs which
specify 'sysfs' as a keyword for the device as there is no device
associated with this special filesystem. However, any arbitrary string
could be specified here and the determination of the sysfs mount point
would fail in such a case.
To make sure that the mount point of the sysfs is still found when
mounted with a device keyword specified other than 'sysfs', check for
the filesystem type instead, which is more specific.
Fixes: https://github.com/ibm-s390-tools/s390-tools/issues/91
Suggested-by: Mark Post <mpost@suse.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
util_sys_get_dev_addr() returns the device address for a given blockdevice.
This does not work for partitions but some tools rely on the ability to get
the device address for partitions.
Add code that first determines the base device for a partition.
Fixes: 6014d07cb1 ("dasdview/libdasd/zipl: Use util_sys_get_dev_addr() instead of u2s_getbusid()")
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Some operations are only possible on base devices not on partitions.
Add functions to determine if a given device is a partition or a base
device and to get the base device to a given partition.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the -fPIC option when building the libutil objects to generate
position-independent code, and allow them to be used in dynamically
loaded shared libraries.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Function util_opt_init() build the option string for getopt_long().
If a command has been set via util_opt_set_command(), then util_opt_init()
must honor that command and only add those options that match the command,
or are command independent.
That way the same option can be used in different commands with different
flags and different argument settings. E.g. for command 'a' option '-x'
might require an argument, for command 'b' the same option '-x' might not
require an argument.
The behavior of util_opt_init() is unchanged if no command is set, and
also if different commands use the same option, but with the same flags
and argument settings. Currently only the zkey tools set a command, but
use unique options per command.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The util_opt_example allows to specify '-l' and '-m, --manual' options,
but does not handle them. This leads to error message 'PANIC: The
application terminated due to an unrecoverable error' with 'Option 'l'
should not be handled here' and the program is aborted.
Add the required case statements in the switch to handle those options.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The functions use the C99 _Bool type in form of the alias bool from
stdbool.h as return type. Scalars are implicitly converted to _Bool.
Values equal to zero to 0 (false). Nonzero values to 1 (true).
Therefore the explicit conversion using the ternary operator ?: with
true and false is not required.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Testing whether a file is a directory or a regular file by masking the
struct stat field st_mode with S_IFDIR or S_IFREG is wrong. Depending
on the values of the macros S_IF* sockets and symbolic links might
erroneously be considered as regular files and block special files as
directories.
The file type encoded in the struct stat field st_mode is actually an
enumeration. To test whether a file is a directory or a regular file
either extract the file type from st_mode using the mask S_IFMT and
compare it against S_IFDIR or S_IFREG or simply use the macros S_ISDIR()
and S_ISREG().
Fixes: b627b8d8e1 ("Initial s390-tools-2.0.0 import")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For root the functions util_path_is_readable() and util_path_is_writable()
do not take the path's permissions into account. The function access()
succeeds as root is allowed to read/write any file regardless of its
permissions.
Introduce the functions util_path_is_readonly_file() and
util_path_is_writeonly_file() to test whether a path is a regular file and
is either read-only (neither user, group, nor other have write permission,
but one or more of user, group, and other have read permission) or
write-only (neither user, group, nor other have read permission, but one
or more of user, group, and other have write permission).
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Many tools need to identify the device address of a given device. So
far, either the tool had its own implementation, or u2s_getbusid() was
used. Though, u2s_getbusid() was mainly designed for and used by the
DASD tools.
Introduce util_sys with a first function util_sys_get_dev_addr() which
provides a more universal way to identify the device address which is
not limited to one particular device type. The device address represents
either a busid (e.g. DASD), slot address (NVMe), H:C:T:L tuple (SCSI),
or other id types associated with a device.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Show how to use util_rec_set_indent() and util_rec_print_separator()
in util_rec_example.c
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In wide format the header is separated from the rest of the
records by a separator line. Add support to print such a
separator line also between some records.
Add function util_rec_print_separator() that prints the
separator line for wide format only. For other formats this
is a NOP.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Functions rec_print_xxx allows to print records in
different formats. Add support to optionally indent
the output by a specific number of characters.
The indention is set using a new function util_rec_set_indent().
The default indention is zero, thus existing applications
will behave the same as before.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Commit 851f685993 ("Makefile: Add dependency between libvmcp and
libutil to fix -j builds") introduced the following regression
$ make clean
CLEAN /home2/holzheu/src/s390-tools
...
CLEAN libccw
CC libutil/util_base.o
CC libutil/util_path.o
For the "clean" target the new library dependency triggers a build
of libutil.
So remove the dependency again.
To fix the parallel build issue, no longer build the examples with
"make all" and add a new target "examples" that can now be used for building
the example programs.
Fixes: 851f685993 ("Makefile: Add dependency between libvmcp and libutil to fix -j builds")
Signed-off-by: Michael Holzheu <holzheu@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The strlcpy() implementation in libu2s is beneficial for other tools as
well. Move the implementation to libutils and replace misc_strlcpy() in
libu2s accordingly.
Change the link order in zipl to make it build again.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The util_scandir_* functions may return 0 or -1, in which case no vector
is allocated in libutil/util_scandir.c. util_ptr_vec_free, called by
util_scandir_free or directly from lschp.c and lsscm.c, does always
call free for the vector which might be not initialized.
Fix this by always initializing the vector with NULL in __scandir and
add some api hardening by checking the vector and count in
util_ptr_vec_free before iterating over the vector.
And update the comment for util_scandir to indicate that -1 may be
returned in error cases plus that the vector is initialized with NULL.
Fixes: https://github.com/ibm-s390-tools/s390-tools/issues/43
Reported-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add missing long options for --help and --version in util_prg_example.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This patch
- moves function util_strstrip to libutil/util_libc.c and deletes the
extra files util_strstip.[ch]
- adds doxygen comments for util_strstrip()
- provides an example on how to use util_strstrip().
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Function strstrip strips leading and trailung
spaces from a given string.
During review it was decided to move this function
to the libutil library to make it available for other tools.
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since now util_list_new() internally fails for out-of-memory situations,
we can also remove some NULL pointer checks.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
When building libutil in parallel, it can happen that the archive
file is created twice:
$ cd libutil
$ make -j
...
CC libutil/util_rec_example.o
AR libutil/libutil.a
AR libutil/libutil.a
LINK libutil/util_base_example
This can lead to the following build error:
$ make -j OPT_FLAGS="-pipe"
..//libutil/libutil.a(util_path.o): In function `sys_mount_point':
util_path.c:56: undefined reference to `util_proc_mnt_get_entry'
util_path.c:60: undefined reference to `util_proc_mnt_free_entry'
collect2: error: ld returned 1 exit status
../common.mak:232: recipe for target 'util_path_example' failed
The problem is that the following rule from common.mak is triggered in
the libutil directory:
$(rootdir)/libutil/libutil.a: $(rootdir)/libutil
$(MAKE) -C $(rootdir)/libutil/ libutil.a
.PHONY: $(rootdir)/libutil
To prevent this rule, use the local "libutil.a" as dependency for the
example binaries.
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
