Commit 2aa167ca tried to fix the DBus interaction code to allow
callers to use native types instead of 4-byte bools.  But in
fixing the issue, I missed the case of an arrayref; Conrad Meyer
shows the following valid complaint issued by clang:

  CC       util/libvirt_util_la-virdbus.lo
util/virdbus.c:956:13: error: cast from 'bool *' to 'dbus_bool_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
            GET_NEXT_VAL(dbus_bool_t, bool_val, bool, "%d");
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/virdbus.c:858:17: note: expanded from macro 'GET_NEXT_VAL'
            x = (dbustype *)(*xptrptr + (*narrayptr - 1));              \
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.

But fixing that points out that we have NEVER supported arrayrefs
of sub-int types (byte, i16, u16, and now bool).  Again, while raw
types promote, arrays do not; so the macros HAVE to deal with both
size possibilities rather than assuming that an arrayref uses the
same sizing as the promoted raw type.

Obviously, our testsuite wasn't covering as much as it should have.

* src/util/virdbus.c (GET_NEXT_VAL): Also fix array cases.
(SET_NEXT_VAL): Fix uses of sub-int arrays.
* tests/virdbustest.c (testMessageArray, testMessageArrayRef):
Test it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use of an 'int' to represent a 'bool' value is confusing.  Just
because dbus made the mistake of cementing their 4-byte wire
format of dbus_bool_t into their API doesn't mean we have to
repeat the mistake.  With a little bit of finesse, we can
guarantee that we provide a large-enough value to the DBus
code, while still copying only the relevant one-byte bool
to the client code, and isolate the rest of our code base from
the DBus stupidity.

* src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
(virDBusMessageIterDecode): Adjust all clients.
* src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
* tests/virdbustest.c (testMessageSimple, testMessageStruct):
Test new behavior.
Signed-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

C guarantees that static variables are zero-initialized.  Some older
compilers (and also gcc -fno-zero-initialized-in-bss) create larger
binaries if you explicitly zero-initialize a static variable.

* src/libvirt.c: Fix initialization.
* src/util/viralloc.c: Likewise.
* src/util/virdbus.c: Likewise.
* src/util/virevent.c: Likewise.
* src/util/virfile.c (safezero): Likewise.
* src/util/virlog.c: Likewise.
* src/util/virnetlink.c: Likewise.
* src/util/virthread.h (VIR_ONCE_GLOBAL_INIT): Likewise.
* src/util/virprocess.c (virProcessGetStartTime): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Currently DBus dict values must be passed inline

   virDBusMessageEncode("a{ss}",
                        3,
                        "key1", "val1",
                        "key2", "val2",
                        "key3", "val3");
   virDBusMessageDecode("a{ss}",
                        3,
                        &key1, &val1,
                        &key2, &val2,
                        &key3, &val3);

This allows them to be passed by reference

   const char **dictin = {
      "key1", "val1",
      "key2", "val2",
      "key3", "val3"
   };
   char **dictout;
   size_t ndictout;

   virDBusMessageEncode("a&{ss}",
                        ARRAY_CARDINALITY(dict) / 2,
                        dictin);
   virDBusMessageDecode("a&{ss}",
                        &ndictout,
                        &dictout);
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

I'm about to add a syntax check that enforces our documented
HACKING style of always using matching {} on if-else statements.

This patch focuses on all remaining problems, where there weren't
enough issues to warrant splitting it further.

* src/remote/remote_driver.c (doRemoteOpen): Correct use of {}.
* src/security/virt-aa-helper.c (vah_add_path, valid_path, main):
Likewise.
* src/rpc/virnetsocket.c (virNetSocketNewConnectLibSSH2):
Likewise.
* src/esx/esx_vi_types.c (esxVI_Type_FromString): Likewise.
* src/uml/uml_driver.c (umlDomainDetachDevice): Likewise.
* src/util/viralloc.c (virShrinkN): Likewise.
* src/util/virbuffer.c (virBufferURIEncodeString): Likewise.
* src/util/virdbus.c (virDBusCall): Likewise.
* src/util/virnetdev.c (virNetDevValidateConfig): Likewise.
* src/util/virnetdevvportprofile.c
(virNetDevVPortProfileGetNthParent): Likewise.
* src/util/virpci.c (virPCIDeviceIterDevices)
(virPCIDeviceWaitForCleanup)
(virPCIDeviceIsBehindSwitchLackingACS): Likewise.
* src/util/virsocketaddr.c (virSocketAddrGetNumNetmaskBits):
Likewise.
* src/util/viruri.c (virURIParseParams): Likewise.
* daemon/stream.c (daemonStreamHandleAbort): Likewise.
* tests/testutils.c (virtTestResult): Likewise.
* tests/cputest.c (cpuTestBaseline): Likewise.
* tools/virsh-domain.c (cmdDomPMSuspend): Likewise.
* tools/virsh-host.c (cmdNodeSuspend): Likewise.
* src/esx/esx_vi_generator.py (Type.generate_typefromstring):
Tweak generated code.
Signed-off-by: NEric Blake <eblake@redhat.com>

If you trigger bug 1033369, we get the error message:

  error from service: Invalid argument

Which is a bit too generic to pinpoint what is actually failing. This
changes it to:

  error from service: CreateMachine: Invalid argument
Acked-by: NEric Blake <eblake@redhat.com>

This is the only callsite.

We drop use of localerror.name here, because it's not actually useful
to us: rather than the parameter name which received an invalid value
(which was assumed), it's actually the the dbus errno equivalent.
Just use the error string.
Acked-by: NEric Blake <eblake@redhat.com>

Commit 48976981 fixed the build without dbus by only building
the virSystemdPMSupportTarget with SYSTEMD_DAEMON.

Introduce a virDBusMessageUnref wrapper for dbus_message_unref
to let virsystemd.c build without dbus, while still allowing
virsystemdtest to run without SYSTEM_DAEMON.

Fix the build without dbus.

The caller may not want all DBus error conditions to be turned
into libvirt errors, so provide a way for the caller to get
back the full DBusError object. They can then check the errors
and only report those that they consider to be fatal.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the DBus helper APIs require the values for an array
to be passed inline in the variadic argument list. This change
introduces support for passing arrays using a pointer to a plain
C array of the basic type. This is of particular benefit for
decoding messages when you don't know how many array elements
are being received.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The dbus_connection_send_with_reply_and_block method will
automatically call dbus_set_error_from_message for us. We
mistakenly thought we had todo it because of a flaw in the
systemd unit test mock impl. The latter should have directly
set the error object, instead of creating an error message
object.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virDBusMessageRead method should not have side-effects on
the message parameter passed in, so unref'ing it is wrong.
The caller should unref only when they decided they are done
with it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The test suites often have to create DBus method reply messages
with payloads. Create two helpers for simplifying the process
of creating replies with payloads.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Split the virDBusMethodCall method into a couple of new methods
virDBusCall, virDBusCreateMethod and virDBusCreateMethodV.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If systemd is installed, but is not the init system,
systemd-machined fails with an unhelpful error message:
Launch helper exited with unknown return code 1

Currently we only check if the "machine1" service is
available (in ListActivatableNames).
Also check if "systemd1" service is registered with DBus
(ListNames).

This fixes https://bugs.gentoo.org/show_bug.cgi?id=493246#c22

Introduce virDBusIsServiceInList which can be used to call other
methods for listing services (ListNames), not just ListActivatableNames.

No functional change, fixed the 'Retruns' typo.

Two unused global variables, and DBUS_TYPE_INVALID used as a const
char*.
Signed-off-by: NEric Blake <eblake@redhat.com>

Currently the virDBusAddWatch does

  virEventAddHandle(fd, flags,
                    virDBusWatchCallback,
                    watch, NULL);
  dbus_watch_set_data(watch, info, virDBusWatchFree);

Unfortunately this is racy - since the event loop is in a
different thread, the virDBusWatchCallback method may be
run before we get to calling dbus_watch_set_data. We must
reverse the order of these calls

See https://bugzilla.redhat.com/show_bug.cgi?id=885445Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Previous commit

  commit 7ada155c
  Author: Gao feng <gaofeng@cn.fujitsu.com>
  Date:   Wed Sep 11 11:15:02 2013 +0800

    DBus: introduce virDBusIsServiceEnabled

Made the cgroups code fallback to non-systemd based setup
when dbus is not running. It was too big a hammer though,
as it did not check what error code was received when the
dbus connection failed. Thus it silently ignored serious
errors from dbus such as "too many client connections",
which should always be treated as fatal.

We only want to ignore errors if the dbus unix socket does
not exist, or if nothing is listening on it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If the dbus system bus connection is marked as private, then
allow it to be closed.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The dbus_bus_get() function returns a shared bus connection that
all libraries in a process can use. You are forbidden from calling
close on this connection though, since you can never know if any
other code might be using it.

Add an option to use private dbus bus connections, if the app
wants to be able to close the connection.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If virDBusMessageIterEncode hits an OOM condition it often
leaks the memory associated with the dbus iterator object
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This patch introduces virDBusIsServiceEnabled, we can use
this method to get if the service is supported.

In one case, if org.freedesktop.machine1 is unavailable on
host, we should skip creating machine through systemd.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Some systems may not use DBus in their system. Add a method to check if
the system bus is available that doesn't print error messages so that
code can later check for this condition and use an alternative approach.

The way we were casting small (<32bit) integers was broken
on big endian hosts, causing stack smashing. This was detected
in the test suite either by test failures due to incorrect
results, or by libc/gcc abort'ing with its stack canary
triggered.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Mingw headers pollute the namespace.

  CC       libvirt_util_la-virdbus.lo
../../src/util/virdbus.c:1102:35: error: expected ';', ',' or ')' before 'struct'
                       const char *interface,
                                   ^

* src/util/virdbus.c (virDBusCallMethod): Avoid 'interface'.
Signed-off-by: NEric Blake <eblake@redhat.com>

dbus 1.2.24 (on RHEL 6) lacks DBUS_TYPE_UNIX_FD; but as we aren't
trying to pass one of those anyways, we can just drop support for
it in our wrapper.  Solves this build error introduced in commit
834c9c94:

  CC     libvirt_util_la-virdbus.lo
util/virdbus.c:242: error: 'DBUS_TYPE_UNIX_FD' undeclared here (not in a function)

* src/util/virdbus.c (virDBusBasicTypes): Drop support for unix fds.
Signed-off-by: NEric Blake <eblake@redhat.com>

Current code for handling dbus errors only works for errors
received from the remote application itself. We must also
handle errors emitted by the bus itself, for example, when
it fails to spawn the target service.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 834c9c94 introduced virDBusMessageEncode and
virDBusMessageDecode functions, however corresponding stubs
were not added to !WITH_DBUS section, therefore 'make check'
started to fail when compiled w/out dbus support like that:

Expected symbol virDBusMessageDecode is not in ELF library

Doing DBus method calls using libdbus.so is tedious in the
extreme. systemd developers came up with a nice high level
API for DBus method calls (sd_bus_call_method). While
systemd doesn't use libdbus.so, their API design can easily
be ported to libdbus.so.

This patch thus introduces methods virDBusCallMethod &
virDBusMessageRead, which are based on the code used for
sd_bus_call_method and sd_bus_message_read. This code in
systemd is under the LGPLv2+, so we're license compatible.

This code is probably pretty unintelligible unless you are
familiar with the DBus type system. So I added some API
docs trying to explain how to use them, as well as test
cases to validate that I didn't screw up the adaptation
from the original systemd code.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>