Commit 345996c620 disabled the
-Wunused-but-set-variable warning on CLang, beacuse it warned
on variables that were unread, but we relied on the side effects
of their destructors.
Reinstate the warning now that all the occurrences have been fixed.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Clang has previously had trouble with G_DEFINE_AUTOPTR_CLEANUP_FUNC
generated code, thinking it was unused. We turn off -Wunused-function
to avoid tripping up on that with CLang.
New Clang has started having trouble with g_autoptr now too. In usage
scenarios where the variable is set, but never again read, it thinks
it is unused not realizing the destructor has useful side effects.
For this we have to skip -Wunused-but-set-variable on CLang.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
test-lib.sh needs these to be set.
Export them so that the virsh-* tests can be run using:
builddir$ ./run srcdir/tests/virsh-snapshot
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
When building with sanitizers on Fedora we get a wierd error
message
In file included from /usr/include/string.h:519,
from ../src/internal.h:28,
from ../src/util/virsocket.h:21,
from ../src/util/virsocketaddr.h:21,
from ../src/util/virnetdevip.h:21,
from ../src/util/virnetdevip.c:21:
In function ‘memcpy’,
inlined from ‘virNetDevGetifaddrsAddress’ at ../src/util/virnetdevip.c:702:13,
inlined from ‘virNetDevIPAddrGet’ at ../src/util/virnetdevip.c:754:16:
/usr/include/bits/string_fortified.h:29:10: error: ‘__builtin_memcpy’ offset [2, 27] from the object at ‘addr’ is out of the bounds of referenced subobject ‘ss_family’ with type ‘short unsigned int’ at offset 0 [-Werror=array-bounds]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/bits/socket.h:175,
from /usr/include/sys/socket.h:33,
from ../src/util/virsocket.h:66,
from ../src/util/virsocketaddr.h:21,
from ../src/util/virnetdevip.h:21,
from ../src/util/virnetdevip.c:21:
../src/util/virnetdevip.c: In function ‘virNetDevIPAddrGet’:
/usr/include/bits/socket.h:193:5: note: subobject ‘ss_family’ declared here
193 | __SOCKADDR_COMMON (ss_); /* Address family, etc. */
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The code is correct, and this only happens when building at -O2.
The docs for -Warray-bounds say that a value of "2" is known to
be liable to generate false positives. Rather than downgrade the
check everywhere, we do it selectively for sanitizers.
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We have several other options that depend on result of `driver_remote`
option check so we need to do it early to have the result available.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/185
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When 'driver_remote' is 'auto', the 'enabled()' method does not
evaluate to true, causing the libssh/libssh2 checks to be skipped.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With the traditional libvirtd, the virConnectOpen call will probe active
drivers server side to find which one to use when the URI is NULL/empty.
With the modular daemons though, the remote client does not know which
daemon to connect in the first place, so we can't rely on virConnectOpen
probing. Currently the virtproxyd daemon has code to probe for a
possible driver by looking at which sockets are listening or which
binaries are installed. The remote client can thus connect to virtproxyd
which in turn can connect to a real hypervisor driver.
The virtproxyd probing code though isn't something that needs to live in
virtproxyd. By moving it into the remote client we can get probing
client side in all scenarios and avoid the extra trip via virtproxyd in
the common case.
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Platforms supported by libvirt have the following Xen versions
openSUSE Leap 15.2: 4.13
openSUSE Leap 15.3: 4.14
Fedora 33: 4.14
Ubuntu 18.04: 4.9
Ubuntu 20.04: 4.11
Debian Stable: 4.11
Bumping the minimum version doesn't allow us to drop much code, but it
does provide better alignment with libvirt's platform support statement.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When enabling sanitizers, clang adds some function symbols when
instrumenting the code. The exact names of those functions are an
implementation detail and should therefore not be added to any
syms file. This patch prevents build failures due to those symbols
not present in the syms file when building with sanitizers enabled.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When enabling sanitizers, gcc adds some instrumentation to the code
that may enlarge stack frames. Some function's stack frames are already
close to the limit of 4096 and are enlarged past that threshold,
e.g. virLXCProcessStart which reaches a frame size of 4624 bytes.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We are already compiling libvirt with -Wvla - so it does not make
too much sense to still allow people to use alloca() instead. Thus
put it on the list of things we want to warn about. Fortunately,
there is currently no warning with this flag, so the current
sources should be clean.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The flag has a typo in it, it's "...-than=..." and not "...-then=...",
so this was in fact never used. Since we're also using -Wvla (without
size), we should already get warnings about any variable length arrays
anyway, so the additional "-Wvla-larger-than" does not make much sense
and thus we can simply drop this.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Cloud-Hypervisor is a KVM virtualization using hypervisor. It
functions similarly to qemu and the libvirt Cloud-Hypervisor driver
uses a very similar structure to the libvirt driver.
The biggest difference from the libvirt perspective is that the
"monitor" socket is seperated into two sockets one that commands are
issued to and one that events are notified from. The current
implementation only uses the command socket (running over a REST API
with json encoded data) with future changes to add support for the
event socket (to better handle shutdowns from inside the VM).
This patch adds support for the following initial VM actions using the
Cloud-Hypervsior API:
* vm.create
* vm.delete
* vm.boot
* vm.shutdown
* vm.reboot
* vm.pause
* vm.resume
To use the Cloud-Hypervisor driver, the v15.0 release of
Cloud-Hypervisor is required to be installed.
Some additional notes:
* The curl handle is persistent but not useful to detect ch process
shutdown/crash (a future patch will address this shortcoming)
* On a 64-bit host Cloud-Hypervisor needs to support PVH and so can
emulate 32-bit mode but it isn't fully tested (a 64-bit kernel and
32-bit userspace is fine, a 32-bit kernel isn't validated)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: William Douglas <william.douglas@intel.com>
These checks look different than most similar ones for no
particular reason.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Similar knobs, such as firewalld_zone and sysctl_config, are
already features, so convert this one as well to comply with
expectations.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Attempting to enable apparmor_profiles when apparmor support
is not enabled should result in an error.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This is the preferred way to figure out whether a library is
available, and for the most part we can just adopt it right
away; in a few cases, unfortunately, we're stuck with using
cc.find_library() until further down the road, when all our
target platforms ship with pkg-config enabled versions of the
various libraries.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
libacl is Linux-only, so we don't need to explicitly check for
either the target platform or header availability, and we can
simply rely on cc.find_library() instead. The corresponding
preprocessor define is renamed to more accurately reflect the
nature of the check.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
firewalld is Linux-only, so it should be disabled by default
everywhere else and attempts to explicitly enable firewalld
support on non-Linux targets should result in an error.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This makes it possible to explicitly disable firewalld support
regardless of the platform that's being targeted.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If the feature is disabled, the corresponding flags should not
show up in the compiler command line.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The new version will report an error if the user asks for
polkit support to be enabled on Windows instead of silently
ignoring such requests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If the user explicitly asked for sanlock support to be enabled,
then failure to find the corresponding library should result in
an error.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We're supposed to error out if the user has explicitly asked
for vstorage support to be enabled and that can't be done, but
we've been looking at the wrong option.
Fixes: 2127d53f2f
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Meson already knows how to look for pcap using pkg-config
first, and falling back to pcap-config if that didn't work.
https://mesonbuild.com/Dependencies.html#pcap
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Meson offers a native convenience method that can be used to
fetch pkg-config variables from a dependency, so we can use
that instead of calling pkg-config manually.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If this looks familiar, that's because it's literally *the
same code* that we used to work around *the same issue* in
readline before 1635dca26f :)
Note that the issue only really affects people building from
source on Apple Silicon: on Intel, Homebrew installs header
files under directories that are part of the default search
path, which explains why our CI pipeline never ran into it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
So far we have three places where glib version is recorded:
meson.build and then in config.h. The latter is so well hidden
that it's easy to miss when bumping minimal glib version in the
former. With a bit of python^Wmeson string magic
GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED macros can
be defined to match glib_version from meson.build.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Meson has its own mechanism to turn on -Werror with the --werror option.
If this is set, then there is no reason for libvirt to check for -Werror
itself.
We remove the summary line output because it is potentially misleading
when libvirt hasn't enabled -Werror, but meson has.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Meson defines a warning_level option which has the following behaviour
with C code
0: no warning flags
1: -Wall
2: -Wall -Wextra
3: -Wall -Wextra -Wpedantic
Currently we add our extra warning flags unconditionally if the compiler
supports them, regardless of the meson warning_level setting. This has
effectively nullified the warning_level setting in meson, and also
results in meson printing these messages:
meson.build:498: WARNING: Consider using the built-in warning_level option instead of using "-Wall".
meson.build:498: WARNING: Consider using the built-in warning_level option instead of using "-Wextra".
Semantically we can think of our huge list of flags as being an "extra"
set of warnings, and thus we ought to only add them when meson would
itself use -Wextra. aka warning_level == 2 or 3.
In practice libvirt code can't be built with -Wpedantic so we can ignore
meson warning_level 3, and only add our flags when warning_level==2.
In doing this change, we no longer have to check -Wall/-Wextra ourselves
as we can assume meson already set them.
-W is an alias of -Wextra so it is removed too.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In several cases we check if a compiler flag is supported, and then add
it to the 'cc_flags' array. The entire 'cc_flags' array is then later
tested to see if each flag is supported, which duplicates the check in
some cases.
Move the check of cc_flags earlier, and for the extra flags append
directly to supported_cc_flags to avoid the duplicate check
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The split of arrays is fairly arbitrary and a hang over from the way we
had to structure lists of flags when we used GNULIB's compiler flag
checking m4 logic.
The separate lists leads to cases where we enable a flag in one list and
have contradictory setting in another list, which leads to confusion.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virStrerror function no longer exists in libvirt so is not a
constraint. At the current stack limit of 4k, and default Linux
stack size of 8 MB, we have a recursion limit of 2048 in the
absolute worst case, and much higher in common case. Even with
smaller stack sizes, we're going to be fine as we don't deeply
recurse in code.
Thus it is not worth spending effort to optimize below our current
4k worst case limit. Removing the comment will stop encouraging
people to spend time on this in future.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All other warning flags are checked for compiler support, so we
shouldn't blindly assume this one always exists.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We're not using these warning flags with libvirt, and it is not worth
keeping them just to issue a warning if someone tries to enable them.
If someone does try to enable them, either libvirt will build cleanly
or it won't.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Ján Tomko