diff options
68 files changed, 2676 insertions, 7103 deletions
diff --git a/Makefile.am b/Makefile.am index 10b96703..756ab8b9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -7,6 +7,7 @@ DISTCLEANFILES = \ dbus-1.pc EXTRA_DIST = \ + autogen.sh \ HACKING \ dbus-1.pc.in \ cleanup-man-pages.sh \ @@ -14,6 +15,7 @@ EXTRA_DIST = \ NEWS.pre-1-0 \ ChangeLog.pre-1-2 \ NEWS.pre-1-2 \ + README.valgrind \ README.win \ README.wince \ README.cygwin \ @@ -26,6 +28,7 @@ update-authors: git shortlog -s -e | cut -c 8- | sort > AUTHORS DISTCHECK_CONFIGURE_FLAGS = \ + --enable-xml-docs \ --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir) ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS} diff --git a/Makefile.in b/Makefile.in index c6d6d33f..f9f9fc40 100644 --- a/Makefile.in +++ b/Makefile.in @@ -267,7 +267,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -326,7 +327,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ @@ -443,6 +443,7 @@ DISTCLEANFILES = \ dbus-1.pc EXTRA_DIST = \ + autogen.sh \ HACKING \ dbus-1.pc.in \ cleanup-man-pages.sh \ @@ -450,6 +451,7 @@ EXTRA_DIST = \ NEWS.pre-1-0 \ ChangeLog.pre-1-2 \ NEWS.pre-1-2 \ + README.valgrind \ README.win \ README.wince \ README.cygwin \ @@ -457,6 +459,7 @@ EXTRA_DIST = \ cmake DISTCHECK_CONFIGURE_FLAGS = \ + --enable-xml-docs \ --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir) ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS} @@ -1,3 +1,87 @@ +D-Bus 1.7.0 (2013-02-22) +== + +The "Disingenuous Assertions" release. + +This is a new development release, starting the 1.7.x branch. D-Bus 1.6 +remains the recommended version for long-term-supported distributions +or the upcoming GNOME 3.8 release. + +Build-time configuration changes: + +• The --with-dbus-session-bus-default-address configure option is no longer + supported. Use the new --with-dbus-session-bus-connect-address and + --with-dbus-session-bus-listen-address options instead. On Windows, you + usually want them to have the same argument; on Unix, the defaults are + usually correct. + +• Similarly, the DBUS_SESSION_BUS_DEFAULT_ADDRESS CMake variable is no longer + supported; use the new DBUS_SESSION_BUS_LISTEN_ADDRESS and + DBUS_SESSION_BUS_CONNECT_ADDRESS variables instead. + +• cmake/cross-compile.sh has been removed. Instead, please use a + cross-toolchain file (-DCMAKE_TOOLCHAIN_FILE) as documented at + <http://www.vtk.org/Wiki/CMake_Cross_Compiling>; or use Autotools + as documented in "info automake Cross-Compilation", and set + PKG_CONFIG_PATH appropriately. + +Requirements: + +• Man pages now require xmlto (or either xmlto or meinproc, if using CMake). +• man2html is no longer used. + +Enhancements: + +• D-Bus Specification 0.20 + · actually say that /org/freedesktop/DBus is the object that + implements o.fd.DBus (fd.o #51865, Colin Walters) + · various reorganisation for better clarity (fd.o #38252, Simon McVittie) + · stop claiming that all basic types work just like INT32 (strings don't!) + +• The "source code" for the man pages is now Docbook XML, eliminating + the outdated duplicate copies used when building with CMake. + (fd.o #59805; Ralf Habacker, Simon McVittie) + +Fixes: + +• In the activation helper, when compiled for tests, do not reset the system + bus address, fixing the regression tests. (fd.o #52202, Simon) + +• Fix building with Valgrind 3.8, at the cost of causing harmless warnings + with Valgrind 3.6 on some compilers (fd.o #55932, Arun Raghavan) + +• Merge <servicehelper> from system-local.conf if necessary (fd.o #51560, + Krzysztof Konopko) + +• Under CMake, prefer xmlto over meinproc (fd.o #59733, Ralf Habacker) + +• Stop duplicating CMake's own logic to find libexpat + (fd.o #59733, Ralf Habacker) + +• Don't assume CMake host and build system are the same (fd.o #59733, + Ralf Habacker) + +• Avoid deprecation warnings for GLib 2.35 (fd.o #59971, Simon McVittie) + +• Unix-specific: + · Check for functions in libpthread correctly, fixing compilation on + (at least) OpenBSD (fd.o #47239, Simon) + · Don't leak temporary fds pointing to /dev/null (fd.o #56927, + Michel HERMIER) + · Update sd-daemon.[ch] from systemd (fd.o #60681) + · Add partial support for QNX (fd.o #60339, fd.o #61176; Matt Fischer) + +• Windows-specific: + · The default session bus listening and connecting address is now + "autolaunch:", which makes D-Bus on Windows interoperate with itself + and GDBus "out of the box". Use the configure options and cmake variables + described above if you require a different autolaunch scope. + (fd.o #38201, Simon McVittie) + · Avoid a CMake warning under Cygwin (fd.o #59401, Ralf Habacker) + +• Create session.d, system.d directories under CMake (fd.o #41319, + Ralf Habacker) + D-Bus 1.6.8 (2012-09-28) == diff --git a/README.valgrind b/README.valgrind new file mode 100644 index 00000000..c13f5304 --- /dev/null +++ b/README.valgrind @@ -0,0 +1,24 @@ +Running D-Bus clients with Valgrind +==== + +When running programs using libdbus in Valgrind, some special care needs to be +taken so as to avoid incorrect detection of leaks in libdbus. To avoid these +false positives, do the following: + +* Grab a copy of the D-Bus source code + +* Run configure with the --enable-developer and --with-valgrind options + +* Run make + +* Either make sure your code calls dbus_shutdown() (at least while running in + Valgrind) or set DBUS_MESSAGE_CACHE=0 in your environment + +* Run Valgrind on your program with the /path/to/dbus/source/dbus/.libs in your + LD_LIBRARY_PATH + +Your Valgrind log should now be free of any (spurious) libdbus-related leaks. + +For the curious, the DBUS_MESSAGE_CACHE=0 is required because by +default, libdbus uses a recyclable pool of message structs. These help +performance a bit. @@ -14,8 +14,8 @@ m4_ifndef([AC_AUTOCONF_VERSION], [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl -m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],, -[m4_warning([this file was generated for autoconf 2.68. +m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.69],, +[m4_warning([this file was generated for autoconf 2.69. You have another version of autoconf. It may work, but is not guaranteed to. If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'.])]) diff --git a/autogen.sh b/autogen.sh new file mode 100755 index 00000000..15581120 --- /dev/null +++ b/autogen.sh @@ -0,0 +1,111 @@ +#!/bin/sh +# Run this to generate all the initial makefiles, etc. + +srcdir=`dirname $0` +test -z "$srcdir" && srcdir=. + +ORIGDIR=`pwd` +cd $srcdir + +PROJECT=dbus +TEST_TYPE=-f +FILE=dbus-1.pc.in + +DIE=0 + +if [ -f .git/hooks/pre-commit.sample -a ! -f .git/hooks/pre-commit ] ; then + echo "Activating pre-commit hook." + cp -av .git/hooks/pre-commit.sample .git/hooks/pre-commit + chmod -c +x .git/hooks/pre-commit +fi + +(autoconf --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have autoconf installed to compile $PROJECT." + echo "Download the appropriate package for your distribution," + echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/" + DIE=1 +} + +# If the user hasn't explicitly chosen an Automake version, use 1.11. This is +# the earliest version that gives us silent rules. +if test -z "$AUTOMAKE"; then + AUTOMAKE=automake-1.11 + ACLOCAL=aclocal-1.11 +fi + +($AUTOMAKE --version) < /dev/null > /dev/null 2>&1 || { + AUTOMAKE=automake + ACLOCAL=aclocal +} + +($AUTOMAKE --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have automake installed to compile $PROJECT." + echo "Get ftp://ftp.cygnus.com/pub/home/tromey/automake-1.2d.tar.gz" + echo "(or a newer version if it is available)" + DIE=1 +} + +LIBTOOLIZE=`which libtoolize` +if ! test -f $LIBTOOLIZE; then + LIBTOOLIZE=`which glibtoolize` +fi + +($LIBTOOLIZE --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have libtoolize installed to compile $PROJECT." + echo "Install the libtool package from ftp.gnu.org or a mirror." + DIE=1 +} + +if test "$DIE" -eq 1; then + exit 1 +fi + +test $TEST_TYPE $FILE || { + echo "You must run this script in the top-level $PROJECT directory" + exit 1 +} + +if test -z "$*"; then + echo "I am going to run ./configure with no arguments - if you wish " + echo "to pass any to it, please specify them on the $0 command line." +fi + +$LIBTOOLIZE --copy --force + +$ACLOCAL -I m4 $ACLOCAL_FLAGS + +## optionally feature autoheader +(autoheader --version) < /dev/null > /dev/null 2>&1 && autoheader + +$AUTOMAKE -a $am_opt +autoconf || echo "autoconf failed - version 2.5x is probably required" + +cd $ORIGDIR + +if test x"$NOCONFIGURE" = x; then + run_configure=true + for arg in $*; do + case $arg in + --no-configure) + run_configure=false + ;; + *) + ;; + esac + done +else + run_configure=false +fi + +if $run_configure; then + $srcdir/configure --enable-developer --config-cache "$@" + echo + echo "Now type 'make' to compile $PROJECT." +else + echo + echo "Now run 'configure' and 'make' to compile $PROJECT." +fi + diff --git a/bus/Makefile.in b/bus/Makefile.in index f8835e3f..ccc8cccd 100644 --- a/bus/Makefile.in +++ b/bus/Makefile.in @@ -331,7 +331,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -390,7 +391,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ diff --git a/bus/activation-helper.c b/bus/activation-helper.c index cbc00d2f..8d7ae36f 100644 --- a/bus/activation-helper.c +++ b/bus/activation-helper.c @@ -154,11 +154,11 @@ clear_environment (DBusError *error) "could not clear environment\n"); return FALSE; } -#endif /* Ensure the bus is set to system */ _dbus_setenv ("DBUS_STARTER_ADDRESS", DBUS_SYSTEM_BUS_DEFAULT_ADDRESS); _dbus_setenv ("DBUS_STARTER_BUS_TYPE", "system"); +#endif return TRUE; } diff --git a/bus/config-parser.c b/bus/config-parser.c index 07e8fbb6..1d1b8bf0 100644 --- a/bus/config-parser.c +++ b/bus/config-parser.c @@ -323,7 +323,14 @@ merge_included (BusConfigParser *parser, parser->pidfile = included->pidfile; included->pidfile = NULL; } - + + if (included->servicehelper != NULL) + { + dbus_free (parser->servicehelper); + parser->servicehelper = included->servicehelper; + included->servicehelper = NULL; + } + while ((link = _dbus_list_pop_first_link (&included->listen_on))) _dbus_list_append_link (&parser->listen_on, link); diff --git a/bus/dir-watch-inotify.c b/bus/dir-watch-inotify.c index 2e9be988..d684831d 100644 --- a/bus/dir-watch-inotify.c +++ b/bus/dir-watch-inotify.c @@ -22,11 +22,15 @@ * */ +/* Be careful, this file is not Linux-only: QNX also uses it */ + #include <config.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> +/* QNX's inotify is broken, and requires stdint.h to be manually included first */ +#include <stdint.h> #include <sys/inotify.h> #include <sys/types.h> #include <signal.h> diff --git a/bus/session.conf.in b/bus/session.conf.in index e121ff93..716b5e79 100644 --- a/bus/session.conf.in +++ b/bus/session.conf.in @@ -12,7 +12,7 @@ the behavior of child processes. --> <keep_umask/> - <listen>@DBUS_SESSION_BUS_DEFAULT_ADDRESS@</listen> + <listen>@DBUS_SESSION_BUS_LISTEN_ADDRESS@</listen> <standard_session_servicedirs /> diff --git a/cmake/CMakeLists.txt b/cmake/CMakeLists.txt index 000acda2..9a37e40f 100644 --- a/cmake/CMakeLists.txt +++ b/cmake/CMakeLists.txt @@ -1,3 +1,9 @@ +# where to look first for cmake modules, before ${CMAKE_ROOT}/Modules/ is checked +list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/modules") + +# we do not need to have WIN32 defined +set(CMAKE_LEGACY_CYGWIN_WIN32 0) + project(dbus) # we need to be up to date @@ -6,8 +12,6 @@ if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) -# where to look first for cmake modules, before ${CMAKE_ROOT}/Modules/ is checked -set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/modules") # detect version include(MacrosAutotools) @@ -95,7 +99,7 @@ option (DBUS_ENABLE_STATS "enable bus daemon usage statistics" OFF) option (DBUS_ENABLE_STATS "enable bus daemon usage statistics" OFF) if (DBUS_USE_EXPAT) - find_package(LibExpat) + find_package(EXPAT) else () find_package(LibXml2) endif () @@ -295,14 +299,14 @@ if("${sysname}" MATCHES ".*SOLARIS.*") endif("${sysname}" MATCHES ".*SOLARIS.*") #AC_ARG_WITH(xml, AS_HELP_STRING([--with-xml=[libxml/expat]],[XML library to use])) -if(NOT LIBXML2_FOUND AND NOT LIBEXPAT_FOUND) +if(NOT LIBXML2_FOUND AND NOT EXPAT_FOUND) message(FATAL "Neither expat nor libxml2 found!") -endif(NOT LIBXML2_FOUND AND NOT LIBEXPAT_FOUND) +endif(NOT LIBXML2_FOUND AND NOT EXPAT_FOUND) if(DBUS_USE_EXPAT) SET(XML_LIB "Expat") - SET(XML_LIBRARY ${LIBEXPAT_LIBRARIES}) - SET(XML_INCLUDE_DIR ${LIBEXPAT_INCLUDE_DIR}) + SET(XML_LIBRARY ${EXPAT_LIBRARIES}) + SET(XML_INCLUDE_DIR ${EXPAT_INCLUDE_DIR}) else(DBUS_USE_EXPAT) SET(XML_LIB "LibXML2") SET(XML_LIBRARY ${LIBXML2_LIBRARIES}) @@ -431,18 +435,27 @@ endif (WIN32) set (DBUS_USER ) +# This won't work on Windows. It's not meant to - the system bus is +# meaningless on Windows anyway. +# +# This has to be suitable for hard-coding in client libraries as well as +# in the dbus-daemon's configuration, so it has to be valid to listen on +# and also to connect to. If this ever changes, it'll need to be split into +# two variables, one for the listening address and one for the connecting +# address. +set (DBUS_SYSTEM_BUS_DEFAULT_ADDRESS "unix:path=${EXPANDED_LOCALSTATEDIR}/run/dbus/system_bus_socket" CACHE STRING "system bus default address") if (WIN32) - set (DBUS_SYSTEM_BUS_DEFAULT_ADDRESS "nonce-tcp:" CACHE STRING "system bus default address") - set (DBUS_SESSION_BUS_DEFAULT_ADDRESS "nonce-tcp:" CACHE STRING "session bus default address") + set (DBUS_SESSION_BUS_LISTEN_ADDRESS "autolaunch:" CACHE STRING "session bus default listening address") + set (DBUS_SESSION_BUS_CONNECT_ADDRESS "autolaunch:" CACHE STRING "session bus fallback address for clients") set (DBUS_SYSTEM_CONFIG_FILE "etc/dbus-1/system.conf") set (DBUS_SESSION_CONFIG_FILE "etc/dbus-1/session.conf") # bus-test expects a non empty string set (DBUS_USER "Administrator") else (WIN32) - set (DBUS_SYSTEM_BUS_DEFAULT_ADDRESS "unix:tmpdir=" CACHE STRING "system bus default address") - set (DBUS_SESSION_BUS_DEFAULT_ADDRESS "unix:path=${DBUS_SESSION_SOCKET_DIR}" CACHE STRING "session bus default address") + set (DBUS_SESSION_BUS_LISTEN_ADDRESS "unix:tmpdir=${DBUS_SESSION_SOCKET_DIR}" CACHE STRING "session bus default listening address") + set (DBUS_SESSION_BUS_CONNECT_ADDRESS "autolaunch:" CACHE STRING "session bus fallback address for clients") set (sysconfdir "") set (configdir ${sysconfdir}/dbus-1 ) set (DBUS_SYSTEM_CONFIG_FILE ${configdir}/system.conf) @@ -562,7 +575,8 @@ message(" Using XML parser: ${XML_LIB} " message(" Daemon executable name: ${DBUS_DAEMON_NAME}") if (WIN32) message(" System bus address: ${DBUS_SYSTEM_BUS_DEFAULT_ADDRESS} ") -message(" Session bus address: ${DBUS_SESSION_BUS_DEFAULT_ADDRESS} ") +message(" Session bus listens on: ${DBUS_SESSION_BUS_LISTEN_ADDRESS} ") +message(" Session clients connect to: ${DBUS_SESSION_BUS_CONNECT_ADDRESS} ") else (WIN32) #message(" Init scripts style: ${with_init_scripts} ") #message(" Abstract socket names: ${have_abstract_sockets} ") diff --git a/cmake/bus/CMakeLists.txt b/cmake/bus/CMakeLists.txt index faf9a8e9..2657605e 100644 --- a/cmake/bus/CMakeLists.txt +++ b/cmake/bus/CMakeLists.txt @@ -12,7 +12,10 @@ set (config_DATA # config files for installation CONFIGURE_FILE( "${BUS_DIR}/session.conf.in" "${CMAKE_CURRENT_BINARY_DIR}/session.conf" IMMEDIATE @ONLY) +FILE(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/session.d) + CONFIGURE_FILE( "system.conf.cmake" "${CMAKE_CURRENT_BINARY_DIR}/system.conf" IMMEDIATE @ONLY) +FILE(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/system.d) # copy services for local daemon start to local service dir data/dbus-1/services SET (SERVICE_FILES test/data/valid-service-files) diff --git a/cmake/config.h.cmake b/cmake/config.h.cmake index 6221c190..76ccb866 100644 --- a/cmake/config.h.cmake +++ b/cmake/config.h.cmake @@ -15,8 +15,8 @@ #cmakedefine DBUS_SESSION_CONFIG_FILE "@DBUS_SESSION_CONFIG_FILE@" #cmakedefine DBUS_DAEMON_NAME "@DBUS_DAEMON_NAME@" #cmakedefine DBUS_SYSTEM_BUS_DEFAULT_ADDRESS "@DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@" +#cmakedefine DBUS_SESSION_BUS_CONNECT_ADDRESS "@DBUS_SESSION_BUS_CONNECT_ADDRESS@" #cmakedefine DBUS_MACHINE_UUID_FILE "@DBUS_MACHINE_UUID_FILE@" -#cmakedefine DBUS_SESSION_BUS_DEFAULT_ADDRESS "@DBUS_SESSION_BUS_DEFAULT_ADDRESS@" #cmakedefine DBUS_DAEMONDIR "@DBUS_DAEMONDIR@" #cmakedefine PACKAGE "@PACKAGE@" /* Version number of package */ diff --git a/cmake/cross-compile.sh b/cmake/cross-compile.sh deleted file mode 100755 index 49e66e50..00000000 --- a/cmake/cross-compile.sh +++ /dev/null @@ -1,110 +0,0 @@ -#!/bin/sh -# -# cross compile script for cmake -# -# initial written by Fridrich Strba -# refactored to debian/lenny by Ralf Habacker -# -# reported to work at least on debian/lenny -# - -if test -f /usr/bin/i686-pc-mingw32-gcc; then - cross_cc=i686-pc-mingw32 -elif test -f /usr/bin/i586-mingw32msvc-gcc; then - cross_cc=i586-mingw32msvc -else - echo "could not determine mingw cross compiler" - exit 1 -fi - -if test -d ~/$cross_cc; then - cross_root=~/$cross_cc -elif test -d /usr/$cross_cc/sys-root/mingw; then - cross_root=/usr/$cross_cc/sys-root/mingw -elif test -d /usr/$cross_cc/lib; then - cross_root=/usr/$cross_cc -else - echo "could not determine mingw cross compiler sdk" - exit 1 -fi - -if ! TEMP=`mktemp --tmpdir -d dbus-cross-compile.XXXXXX`; then - echo "mktemp failed, try with coreutils 6.10 or later?" >&2 - exit 1 -fi - -# make cmake happy -export TEMP - -HOST_CC=gcc; export HOST_CC; - -if test -d $cross_root/lib/pkgconfig; then - PKG_CONFIG_PATH="$cross_root/lib/pkgconfig:$cross_root/share/pkgconfig"; export PKG_CONFIG_PATH; -fi - -if test -d "$MINGW32_CLASSPATH" || test -f "$cross_root/share/java/libgcj.jar"; then - CLASSPATH="$CLASSPATH:${MINGW32_CLASSPATH:-$cross_root/share/java/libgcj.jar:$cross_root/share/java/libgcj-tools.jar}"; export CLASSPATH; -fi - -_PREFIX="/usr/bin/$cross_cc-"; -for i in `ls -1 ${_PREFIX}* | grep -v 'gcc-'`; do - x=`echo $i|sed "s,${_PREFIX},,"|sed "s,\.awk*,,"|tr "a-z+-" "A-ZX_"`; - declare -x $x="$i" ; export $x; -done; -unset _PREFIX; - -CC="${MINGW32_CC:-$cross_cc-gcc}"; export CC; -CFLAGS="${MINGW32_CFLAGS:--O2 -g -pipe -Wall -fexceptions -fno-omit-frame-pointer -fno-optimize-sibling-calls --param=ssp-buffer-size=4 -mms-bitfields}"; export CFLAGS; -LDFLAGS="${MINGW32_LDFLAGS:--Wl,--exclude-libs=libintl.a -Wl,--exclude-libs=libiconv.a}"; export LDFLAGS; - -if [ -x "/usr/bin/$cross_cc-g++" ]; then - CXX="${MINGW32_CXX:-$cross_cc-g++}"; export CXX; - CXXFLAGS="${MINGW32_CXXFLAGS:--O2 -g -pipe -Wall -fexceptions -fno-omit-frame-pointer -fno-optimize-sibling-calls --param=ssp-buffer-size=4 -mms-bitfields}"; export CXXFLAGS; -else - CXX=; export CXX; - ac_cv_prog_CXX=no; export ac_cv_prog_CXX; - CXXFLAGS=; export CXXFLAGS; -fi; -for i in `ls $cross_root/bin/*|grep -- "-config$"` ; do - x=`basename $i|tr "a-z+-" "A-ZX_"|sed "s,\.,,"`; - declare -x $x="$i" ; export $x; -done; -unset x i ; - -if ! test -f "$cross_root/lib/libexpat.dll.a"; then - (cd $TEMP && wget http://www.winkde.org/pub/kde/ports/win32/repository/win32libs/expat-2.0.1-bin.zip) - (cd $TEMP && wget http://www.winkde.org/pub/kde/ports/win32/repository/win32libs/expat-2.0.1-lib.zip) - (cd $cross_root && unzip -x $TMP/expat-2.0.1-bin.zip) - (cd $cross_root && unzip -x $TMP/expat-2.0.1-lib.zip) -fi - -if test -f "$cross_root/lib/libexpat.dll.a"; then - xml_library=-DDBUS_USE_EXPAT=On -DLIBEXPAT_INCLUDE_DIR:PATH=$cross_root/include -DLIBEXPAT_LIBRARIES:PATH=$cross_root/lib/libexpat.dll.a -else - echo "could not find a cross compile xml libraray" - exit 1 -fi - -cmake \ - -DCMAKE_SYSTEM_NAME="Windows" \ - -DCMAKE_VERBOSE_MAKEFILE=ON \ - -DCMAKE_INSTALL_PREFIX:PATH=$cross_root \ - -DCMAKE_INSTALL_LIBDIR:PATH=$cross_root/lib \ - -DINCLUDE_INSTALL_DIR:PATH=$cross_root/include \ - -DLIB_INSTALL_DIR:PATH=$cross_root/lib \ - -DSYSCONF_INSTALL_DIR:PATH=$cross_root/etc \ - -DSHARE_INSTALL_PREFIX:PATH=$cross_root/share \ - -DBUILD_SHARED_LIBS:BOOL=ON \ - -DCMAKE_C_COMPILER="/usr/bin/$cross_cc-gcc" \ - -DCMAKE_CXX_COMPILER="/usr/bin/$cross_cc-g++" \ - -DCMAKE_FIND_ROOT_PATH="$cross_root" \ - -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ - -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ - -DCMAKE_CXX_COMPILER="/usr/bin/$cross_cc-g++" \ - -DCMAKE_FIND_ROOT_PATH="$cross_root" \ - -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \ - -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \ - $xml_library \ - -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER \ - $* - diff --git a/cmake/dbus-env.bat.cmake b/cmake/dbus-env.bat.cmake index 85f70051..d859ce03 100644 --- a/cmake/dbus-env.bat.cmake +++ b/cmake/dbus-env.bat.cmake @@ -2,7 +2,7 @@ @echo off :: session bus address -set DBUS_SESSION_BUS_ADDRESS=@DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +set DBUS_SESSION_BUS_ADDRESS=@DBUS_SESSION_BUS_CONNECT_ADDRESS@ :: system bus address -set DBUS_SYSTEM_BUS_DEFAULT_ADDRESS=@DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@
\ No newline at end of file +set DBUS_SYSTEM_BUS_DEFAULT_ADDRESS=@DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ diff --git a/cmake/doc/CMakeLists.txt b/cmake/doc/CMakeLists.txt index df6b587b..15c05401 100644 --- a/cmake/doc/CMakeLists.txt +++ b/cmake/doc/CMakeLists.txt @@ -23,7 +23,12 @@ if (MEINPROC4_EXECUTABLE OR XMLTO_EXECUTABLE) OPTION(DBUS_ENABLE_XML_DOCS "build XML documentation (requires xmlto or meinproc4)" ON) endif (MEINPROC4_EXECUTABLE OR XMLTO_EXECUTABLE) -if (MEINPROC4_EXECUTABLE) +if (XMLTO_EXECUTABLE) + set (DOCBOOK_GENERATOR_NAME "xmlto" PARENT_SCOPE) + set(DBUS_XML_DOCS_ENABLED 1) + set(MEINPROC4_EXECUTABLE 0) + MESSAGE(STATUS "xmlto docbook generator found") +elseif (MEINPROC4_EXECUTABLE) set(DOCBOOK_GENERATOR_NAME "meinproc4" PARENT_SCOPE) set(DBUS_XML_DOCS_ENABLED 1) if(WIN32) @@ -33,38 +38,43 @@ if (MEINPROC4_EXECUTABLE) set(_meinproc_install_path ${CMAKE_INSTALL_PREFIX}) endif(WIN32) set(STYLESHEET "${_meinproc_install_path}/share/apps/ksgmltools2/docbook/xsl/html/docbook.xsl") -endif (MEINPROC4_EXECUTABLE) - - -if (XMLTO_EXECUTABLE) - set (DOCBOOK_GENERATOR_NAME "xmlto" PARENT_SCOPE) - set(DBUS_XML_DOCS_ENABLED 1) - MESSAGE(STATUS "xmlto docbook generator found") -endif (XMLTO_EXECUTABLE) +endif () if (DBUS_ENABLE_XML_DOCS) -macro (DOCBOOK _sources _options) +macro (DOCBOOK _sources _format) get_filename_component(_infile ${_sources} ABSOLUTE) - get_filename_component(_basename ${_infile} NAME_WE) - set(_outfile ${CMAKE_CURRENT_BINARY_DIR}/${_basename}.html) + get_filename_component(_name ${_infile} NAME) + + if (${_format} STREQUAL "man") + string(REPLACE ".xml" "" _outname ${_name}) + set(STYLESHEET "${DOCBOOKXSL_DIR}/manpages/docbook.xsl") + else() + string(REPLACE ".xml" ".html" _outname ${_name}) + set(STYLESHEET "${DOCBOOKXSL_DIR}/html/docbook.xsl") + endif () + set(_outfile ${CMAKE_CURRENT_BINARY_DIR}/${_outname}) if (EXISTS ${_sources}) if (MEINPROC4_EXECUTABLE) - ADD_CUSTOM_TARGET(${_basename}.html ALL - ${MEINPROC4_EXECUTABLE} --stylesheet ${STYLESHEET} -o ${_outfile} ${_infile} - DEPENDS ${_infile} + ADD_CUSTOM_TARGET(${_outname} ALL + ${MEINPROC4_EXECUTABLE} --stylesheet ${STYLESHEET} -o ${_outfile} ${_infile} + DEPENDS ${_infile} WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) endif () if (XMLTO_EXECUTABLE) - ADD_CUSTOM_TARGET(${_basename}.html ALL - ${XMLTO_EXECUTABLE} -vv ${_options} ${_infile} - DEPENDS ${_infile} + ADD_CUSTOM_TARGET(${_outname} ALL + ${XMLTO_EXECUTABLE} -vv ${_format} ${_infile} + DEPENDS ${_infile} WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) endif () - install(FILES ${_outfile} DESTINATION share/doc/dbus) + if (${_format} STREQUAL "man") + install(FILES ${_outfile} DESTINATION share/man/man1) + else () + install(FILES ${_outfile} DESTINATION share/doc/dbus) + endif () else () MESSAGE(STATUS "skipping xml doc generating for ${_infile}, file not found") endif () @@ -98,11 +108,26 @@ DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-test-plan.xml html-nochunks) DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-tutorial.xml html-nochunks) DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-specification.xml html-nochunks) DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-faq.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/bus/dbus-daemon.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-monitor.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-send.xml html-nochunks) -DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-launch.xml html-nochunks) - +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-cleanup-sockets.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-cleanup-sockets.1.xml) +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-daemon.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml) +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-launch.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-launch.1.xml) +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-monitor.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-monitor.1.xml) +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-send.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-send.1.xml) +configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-uuidgen.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-uuidgen.1.xml) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-cleanup-sockets.1.xml html-nochunks) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml html-nochunks) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-launch.1.xml html-nochunks) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-monitor.1.xml html-nochunks) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-send.1.xml html-nochunks) +DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-uuidgen.1.xml html-nochunks) +if (UNIX) + DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml man) + DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-monitor.1.xml man) + DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-send.1.xml man) + DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-launch.1.xml man) + DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-uuidgen.1.xml man) + DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-cleanup-sockets.1.xml man) +endif() # # handle html index file # diff --git a/cmake/modules/FindLibExpat.cmake b/cmake/modules/FindLibExpat.cmake deleted file mode 100644 index a07c8de4..00000000 --- a/cmake/modules/FindLibExpat.cmake +++ /dev/null @@ -1,61 +0,0 @@ -# - Try to find LIBEXPAT -# Once done this will define -# -# LIBEXPAT_FOUND - system has LIBEXPAT -# LIBEXPAT_INCLUDE_DIR - the LIBEXPAT include directory -# LIBEXPAT_LIBRARIES - the libraries needed to use LIBEXPAT -# LIBEXPAT_DEFINITIONS - Compiler switches required for using LIBEXPAT - -if (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) - - # in cache already - SET(LIBEXPAT_FOUND TRUE) - -else (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) - - IF (WIN32) - file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _progFiles) - find_FILE(LIBEXPAT_DIR expat Source/lib/expat.h - PATHS - "${_progFiles}" - ) - if (LIBEXPAT_DIR) - set (_LIBEXPATIncDir ${LIBEXPAT_DIR}/Source/lib) - set (_LIBEXPATLinkDir ${LIBEXPAT_DIR}/libs) - endif (LIBEXPAT_DIR) - ELSE (WIN32) - # use pkg-config to get the directories and then use these values - # in the FIND_PATH() and FIND_LIBRARY() calls - INCLUDE(UsePkgConfig) - PKGCONFIG(LIBEXPAT-2.0 _LIBEXPATIncDir _LIBEXPATLinkDir _LIBEXPATLinkFlags _LiIconvCflags) - SET(LIBEXPAT_DEFINITIONS ${_LIBEXPATCflags}) - ENDIF (WIN32) - - FIND_PATH(LIBEXPAT_INCLUDE_DIR expat.h - PATHS - ${_LIBEXPATIncDir} - PATH_SUFFIXES LIBEXPAT - ) - - FIND_LIBRARY(LIBEXPAT_LIBRARIES NAMES expat libexpat - PATHS - ${_LIBEXPATLinkDir} - ) - - if (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) - set(LIBEXPAT_FOUND TRUE) - endif (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) - - if (LIBEXPAT_FOUND) - if (NOT LIBEXPAT_FIND_QUIETLY) - message(STATUS "Found libexpat: ${LIBEXPAT_LIBRARIES}") - endif (NOT LIBEXPAT_FIND_QUIETLY) - else (LIBEXPAT_FOUND) - if (LIBEXPAT_FIND_REQUIRED) - message(SEND_ERROR "Could NOT find libexpat") - endif (LIBEXPAT_FIND_REQUIRED) - endif (LIBEXPAT_FOUND) - - MARK_AS_ADVANCED(LIBEXPAT_INCLUDE_DIR LIBEXPAT_LIBRARIES) - -endif (LIBEXPAT_INCLUDE_DIR AND LIBEXPAT_LIBRARIES) diff --git a/cmake/modules/Macros.cmake b/cmake/modules/Macros.cmake index b6371568..adb34b51 100644 --- a/cmake/modules/Macros.cmake +++ b/cmake/modules/Macros.cmake @@ -1,15 +1,12 @@ MACRO(TIMESTAMP RESULT) - IF(WIN32) + if (CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows") EXECUTE_PROCESS(COMMAND "cmd" " /C date /T" OUTPUT_VARIABLE DATE) string(REGEX REPLACE "(..)[/.](..)[/.](....).*" "\\3\\2\\1" DATE ${DATE}) EXECUTE_PROCESS(COMMAND "cmd" " /C time /T" OUTPUT_VARIABLE TIME) string(REGEX REPLACE "(..):(..)" "\\1\\2" TIME ${TIME}) set (${RESULT} "${DATE}${TIME}") - ELSEIF(UNIX) + else () EXECUTE_PROCESS(COMMAND "date" "+%Y%m%d%H%M" OUTPUT_VARIABLE ${RESULT}) - ELSE() - MESSAGE(SEND_ERROR "date not implemented") - SET(${RESULT} 000000000000) - ENDIF() + endif () ENDMACRO() diff --git a/config.h.in b/config.h.in index b939bebb..608c59b1 100644 --- a/config.h.in +++ b/config.h.in @@ -90,6 +90,9 @@ /* Prefix for installing DBUS */ #undef DBUS_PREFIX +/* Fallback address for session bus clients */ +#undef DBUS_SESSION_BUS_CONNECT_ADDRESS + /* Where per-session bus puts its sockets */ #undef DBUS_SESSION_SOCKET_DIR @@ -135,6 +138,12 @@ /* The name of the gettext domain */ #undef GETTEXT_PACKAGE +/* Prevent post-2.26 APIs */ +#undef GLIB_VERSION_MAX_ALLOWED + +/* Ignore post-2.26 deprecations */ +#undef GLIB_VERSION_MIN_REQUIRED + /* Disable GLib public API sanity checking */ #undef G_DISABLE_CHECKS @@ -4,7 +4,7 @@ # 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, # 2011, 2012 Free Software Foundation, Inc. -timestamp='2012-02-10' +timestamp='2012-04-18' # This file is (in principle) common to ALL GNU software. # The presence of a machine in this file suggests that SOME GNU software @@ -225,6 +225,12 @@ case $os in -isc*) basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'` ;; + -lynx*178) + os=-lynxos178 + ;; + -lynx*5) + os=-lynxos5 + ;; -lynx*) os=-lynxos ;; @@ -1537,6 +1543,9 @@ case $basic_machine in c4x-* | tic4x-*) os=-coff ;; + hexagon-*) + os=-elf + ;; tic54x-*) os=-coff ;; @@ -1,13 +1,11 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.68 for dbus 1.6.8. +# Generated by GNU Autoconf 2.69 for dbus 1.7.0. # # Report bugs to <https://bugs.freedesktop.org/enter_bug.cgi?product=dbus>. # # -# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, -# 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software -# Foundation, Inc. +# Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc. # # # This configure script is free software; the Free Software Foundation @@ -136,6 +134,31 @@ export LANGUAGE # CDPATH. (unset CDPATH) >/dev/null 2>&1 && unset CDPATH +# Use a proper internal environment variable to ensure we don't fall + # into an infinite loop, continuously re-executing ourselves. + if test x"${_as_can_reexec}" != xno && test "x$CONFIG_SHELL" != x; then + _as_can_reexec=no; export _as_can_reexec; + # We cannot yet assume a decent shell, so we have to provide a +# neutralization value for shells without unset; and this also +# works around shells that cannot unset nonexistent variables. +# Preserve -v and -x to the replacement shell. +BASH_ENV=/dev/null +ENV=/dev/null +(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV +case $- in # (((( + *v*x* | *x*v* ) as_opts=-vx ;; + *v* ) as_opts=-v ;; + *x* ) as_opts=-x ;; + * ) as_opts= ;; +esac +exec $CONFIG_SHELL $as_opts "$as_myself" ${1+"$@"} +# Admittedly, this is quite paranoid, since all the known shells bail +# out after a failed `exec'. +$as_echo "$0: could not re-execute with $CONFIG_SHELL" >&2 +as_fn_exit 255 + fi + # We don't want this to propagate to other subprocesses. + { _as_can_reexec=; unset _as_can_reexec;} if test "x$CONFIG_SHELL" = x; then as_bourne_compatible="if test -n \"\${ZSH_VERSION+set}\" && (emulate sh) >/dev/null 2>&1; then : emulate sh @@ -169,7 +192,8 @@ if ( set x; as_fn_ret_success y && test x = \"\$1\" ); then : else exitcode=1; echo positional parameters were not saved. fi -test x\$exitcode = x0 || exit 1" +test x\$exitcode = x0 || exit 1 +test -x / || exit 1" as_suggested=" as_lineno_1=";as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested" as_lineno_1a=\$LINENO as_lineno_2=";as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested" as_lineno_2a=\$LINENO eval 'test \"x\$as_lineno_1'\$as_run'\" != \"x\$as_lineno_2'\$as_run'\" && @@ -222,21 +246,25 @@ IFS=$as_save_IFS if test "x$CONFIG_SHELL" != x; then : - # We cannot yet assume a decent shell, so we have to provide a - # neutralization value for shells without unset; and this also - # works around shells that cannot unset nonexistent variables. - # Preserve -v and -x to the replacement shell. - BASH_ENV=/dev/null - ENV=/dev/null - (unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV - export CONFIG_SHELL - case $- in # (((( - *v*x* | *x*v* ) as_opts=-vx ;; - *v* ) as_opts=-v ;; - *x* ) as_opts=-x ;; - * ) as_opts= ;; - esac - exec "$CONFIG_SHELL" $as_opts "$as_myself" ${1+"$@"} + export CONFIG_SHELL + # We cannot yet assume a decent shell, so we have to provide a +# neutralization value for shells without unset; and this also +# works around shells that cannot unset nonexistent variables. +# Preserve -v and -x to the replacement shell. +BASH_ENV=/dev/null +ENV=/dev/null +(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV +case $- in # (((( + *v*x* | *x*v* ) as_opts=-vx ;; + *v* ) as_opts=-v ;; + *x* ) as_opts=-x ;; + * ) as_opts= ;; +esac +exec $CONFIG_SHELL $as_opts "$as_myself" ${1+"$@"} +# Admittedly, this is quite paranoid, since all the known shells bail +# out after a failed `exec'. +$as_echo "$0: could not re-execute with $CONFIG_SHELL" >&2 +exit 255 fi if test x$as_have_required = xno; then : @@ -340,6 +368,14 @@ $as_echo X"$as_dir" | } # as_fn_mkdir_p + +# as_fn_executable_p FILE +# ----------------------- +# Test if FILE is an executable regular file. +as_fn_executable_p () +{ + test -f "$1" && test -x "$1" +} # as_fn_executable_p # as_fn_append VAR VALUE # ---------------------- # Append the text in VALUE to the end of the definition contained in VAR. Take @@ -461,6 +497,10 @@ as_cr_alnum=$as_cr_Letters$as_cr_digits chmod +x "$as_me.lineno" || { $as_echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2; as_fn_exit 1; } + # If we had to re-execute with $CONFIG_SHELL, we're ensured to have + # already done that, so ensure we don't try to do so again and fall + # in an infinite loop. This has already happened in practice. + _as_can_reexec=no; export _as_can_reexec # Don't try to exec as it changes $[0], causing all sort of problems # (the dirname of $[0] is not the place where we might find the # original and so on. Autoconf is especially sensitive to this). @@ -495,16 +535,16 @@ if (echo >conf$$.file) 2>/dev/null; then # ... but there are two gotchas: # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail. # 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable. - # In both cases, we have to default to `cp -p'. + # In both cases, we have to default to `cp -pR'. ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe || - as_ln_s='cp -p' + as_ln_s='cp -pR' elif ln conf$$.file conf$$ 2>/dev/null; then as_ln_s=ln else - as_ln_s='cp -p' + as_ln_s='cp -pR' fi else - as_ln_s='cp -p' + as_ln_s='cp -pR' fi rm -f conf$$ conf$$.exe conf$$.dir/conf$$.file conf$$.file rmdir conf$$.dir 2>/dev/null @@ -516,28 +556,8 @@ else as_mkdir_p=false fi -if test -x / >/dev/null 2>&1; then - as_test_x='test -x' -else - if ls -dL / >/dev/null 2>&1; then - as_ls_L_option=L - else - as_ls_L_option= - fi - as_test_x=' - eval sh -c '\'' - if test -d "$1"; then - test -d "$1/."; - else - case $1 in #( - -*)set "./$1";; - esac; - case `ls -ld'$as_ls_L_option' "$1" 2>/dev/null` in #(( - ???[sx]*):;;*)false;;esac;fi - '\'' sh - ' -fi -as_executable_p=$as_test_x +as_test_x='test -x' +as_executable_p=as_fn_executable_p # Sed expression to map a string onto a valid CPP name. as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'" @@ -571,8 +591,8 @@ MAKEFLAGS= # Identity of this package. PACKAGE_NAME='dbus' PACKAGE_TARNAME='dbus' -PACKAGE_VERSION='1.6.8' -PACKAGE_STRING='dbus 1.6.8' +PACKAGE_VERSION='1.7.0' +PACKAGE_STRING='dbus 1.7.0' PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=dbus' PACKAGE_URL='' @@ -616,7 +636,8 @@ ac_subst_vars='am__EXEEXT_FALSE am__EXEEXT_TRUE LTLIBOBJS LIBOBJS -DBUS_SESSION_BUS_DEFAULT_ADDRESS +DBUS_SESSION_BUS_CONNECT_ADDRESS +DBUS_SESSION_BUS_LISTEN_ADDRESS DBUS_SESSION_SOCKET_DIR TEST_LISTEN TEST_SOCKET_DIR @@ -653,9 +674,6 @@ EXPANDED_LOCALSTATEDIR EXPANDED_PREFIX DBUS_CAN_UPLOAD_DOCS_FALSE DBUS_CAN_UPLOAD_DOCS_TRUE -DBUS_HAVE_MAN2HTML_FALSE -DBUS_HAVE_MAN2HTML_TRUE -MAN2HTML DBUS_XML_DOCS_ENABLED_FALSE DBUS_XML_DOCS_ENABLED_TRUE XMLTO @@ -925,7 +943,6 @@ with_console_owner_file with_launchd_agent_dir with_dbus_user with_dbus_daemondir -with_dbus_session_bus_default_address enable_embedded_tests enable_modular_tests enable_tests @@ -938,6 +955,8 @@ with_x enable_Werror with_systemdsystemunitdir with_dbus_test_dir +with_dbus_session_bus_listen_address +with_dbus_session_bus_connect_address enable_stats ' ac_precious_vars='build_alias @@ -961,12 +980,12 @@ DBUS_GLIB_LIBS PYTHON LIBXML_CFLAGS LIBXML_LIBS +THREAD_LIBS SYSTEMD_CFLAGS SYSTEMD_LIBS VALGRIND_CFLAGS VALGRIND_LIBS -XMKMF -MAN2HTML' +XMKMF' # Initialize some variables set by options. @@ -1422,8 +1441,6 @@ target=$target_alias if test "x$host_alias" != x; then if test "x$build_alias" = x; then cross_compiling=maybe - $as_echo "$as_me: WARNING: if you wanted to set the --build type, don't use --host. - If a cross compiler is detected then cross compile mode will be used" >&2 elif test "x$build_alias" != "x$host_alias"; then cross_compiling=yes fi @@ -1509,7 +1526,7 @@ if test "$ac_init_help" = "long"; then # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures dbus 1.6.8 to adapt to many kinds of systems. +\`configure' configures dbus 1.7.0 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1583,7 +1600,7 @@ fi if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of dbus 1.6.8:";; + short | recursive ) echo "Configuration of dbus 1.7.0:";; esac cat <<\_ACEOF @@ -1669,8 +1686,6 @@ Optional Packages: --with-dbus-user=<user> User for running the DBUS daemon (messagebus) --with-dbus-daemondir=dirname Directory for installing the DBUS daemon - --with-dbus-session-bus-default-address=nonce-tcp:/autolaunch:/tcp:host:port - Transport Type to be used (default: nonce-tcp:) --without-64-bit If you have to use this option, please report it as a bug --with-valgrind Add instrumentation to help valgrind to understand @@ -1680,6 +1695,12 @@ Optional Packages: Directory for systemd service files --with-dbus-test-dir=dirname path where the tests tools are available + --with-dbus-session-bus-listen-address=ADDRESS + default address for a session bus to listen on (see + configure.ac) + --with-dbus-session-bus-connect-address=ADDRESS + fallback address for a session bus client to connect + to (see configure.ac) Some influential environment variables: CC C compiler command @@ -1704,6 +1725,7 @@ Some influential environment variables: LIBXML_CFLAGS C compiler flags for LIBXML, overriding pkg-config LIBXML_LIBS linker flags for LIBXML, overriding pkg-config + THREAD_LIBS SYSTEMD_CFLAGS C compiler flags for SYSTEMD, overriding pkg-config SYSTEMD_LIBS @@ -1713,7 +1735,6 @@ Some influential environment variables: VALGRIND_LIBS linker flags for VALGRIND, overriding pkg-config XMKMF Path to xmkmf, Makefile generator for X Window System - MAN2HTML Path to man2html (optional) Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. @@ -1781,10 +1802,10 @@ fi test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -dbus configure 1.6.8 -generated by GNU Autoconf 2.68 +dbus configure 1.7.0 +generated by GNU Autoconf 2.69 -Copyright (C) 2010 Free Software Foundation, Inc. +Copyright (C) 2012 Free Software Foundation, Inc. This configure script is free software; the Free Software Foundation gives unlimited permission to copy, distribute and modify it. _ACEOF @@ -2099,7 +2120,7 @@ $as_echo "$ac_try_echo"; } >&5 test ! -s conftest.err } && test -s conftest$ac_exeext && { test "$cross_compiling" = yes || - $as_test_x conftest$ac_exeext + test -x conftest$ac_exeext }; then : ac_retval=0 else @@ -2249,7 +2270,7 @@ $as_echo "$ac_try_echo"; } >&5 test ! -s conftest.err } && test -s conftest$ac_exeext && { test "$cross_compiling" = yes || - $as_test_x conftest$ac_exeext + test -x conftest$ac_exeext }; then : ac_retval=0 else @@ -2285,7 +2306,8 @@ int main () { static int test_array [1 - 2 * !(($2) >= 0)]; -test_array [0] = 0 +test_array [0] = 0; +return test_array [0]; ; return 0; @@ -2301,7 +2323,8 @@ int main () { static int test_array [1 - 2 * !(($2) <= $ac_mid)]; -test_array [0] = 0 +test_array [0] = 0; +return test_array [0]; ; return 0; @@ -2327,7 +2350,8 @@ int main () { static int test_array [1 - 2 * !(($2) < 0)]; -test_array [0] = 0 +test_array [0] = 0; +return test_array [0]; ; return 0; @@ -2343,7 +2367,8 @@ int main () { static int test_array [1 - 2 * !(($2) >= $ac_mid)]; -test_array [0] = 0 +test_array [0] = 0; +return test_array [0]; ; return 0; @@ -2377,7 +2402,8 @@ int main () { static int test_array [1 - 2 * !(($2) <= $ac_mid)]; -test_array [0] = 0 +test_array [0] = 0; +return test_array [0]; ; return 0; @@ -2495,8 +2521,8 @@ cat >config.log <<_ACEOF This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by dbus $as_me 1.6.8, which was -generated by GNU Autoconf 2.68. Invocation command line was +It was created by dbus $as_me 1.7.0, which was +generated by GNU Autoconf 2.69. Invocation command line was $ $0 $@ @@ -2988,7 +3014,7 @@ case $as_dir/ in #(( # by default. for ac_prog in ginstall scoinst install; do for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_prog$ac_exec_ext" && $as_test_x "$as_dir/$ac_prog$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_prog$ac_exec_ext"; then if test $ac_prog = install && grep dspmsg "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then # AIX install. It has an incompatible calling convention. @@ -3157,7 +3183,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_STRIP="${ac_tool_prefix}strip" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3197,7 +3223,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_STRIP="strip" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3248,7 +3274,7 @@ do test -z "$as_dir" && as_dir=. for ac_prog in mkdir gmkdir; do for ac_exec_ext in '' $ac_executable_extensions; do - { test -f "$as_dir/$ac_prog$ac_exec_ext" && $as_test_x "$as_dir/$ac_prog$ac_exec_ext"; } || continue + as_fn_executable_p "$as_dir/$ac_prog$ac_exec_ext" || continue case `"$as_dir/$ac_prog$ac_exec_ext" --version 2>&1` in #( 'mkdir (GNU coreutils) '* | \ 'mkdir (coreutils) '* | \ @@ -3301,7 +3327,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_AWK="$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3387,7 +3413,7 @@ fi # Define the identity of the package. PACKAGE='dbus' - VERSION='1.6.8' + VERSION='1.7.0' cat >>confdefs.h <<_ACEOF @@ -3595,25 +3621,25 @@ _ACEOF # ## increment if the interface has additions, changes, removals. -LT_CURRENT=10 +LT_CURRENT=11 ## increment any time the source changes; set to ## 0 if you increment CURRENT -LT_REVISION=2 +LT_REVISION=0 ## increment if any interfaces have been added; set to 0 ## if any interfaces have been changed or removed. removal has ## precedence over adding, so set to 0 if both happened. -LT_AGE=7 +LT_AGE=8 DBUS_MAJOR_VERSION=1 -DBUS_MINOR_VERSION=6 -DBUS_MICRO_VERSION=8 -DBUS_VERSION=1.6.8 +DBUS_MINOR_VERSION=7 +DBUS_MICRO_VERSION=0 +DBUS_VERSION=1.7.0 @@ -3642,7 +3668,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_CC="${ac_tool_prefix}gcc" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3682,7 +3708,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_CC="gcc" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3735,7 +3761,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_CC="${ac_tool_prefix}cc" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3776,7 +3802,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then if test "$as_dir/$ac_word$ac_exec_ext" = "/usr/ucb/cc"; then ac_prog_rejected=yes continue @@ -3834,7 +3860,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_CC="$ac_tool_prefix$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -3878,7 +3904,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_CC="$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -4324,8 +4350,7 @@ cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include <stdarg.h> #include <stdio.h> -#include <sys/types.h> -#include <sys/stat.h> +struct stat; /* Most of the following tests are stolen from RCS 5.7's src/conf.sh. */ struct buf { int x; }; FILE * (*rcsopen) (struct buf *, struct stat *, int); @@ -4755,7 +4780,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_CXX="$ac_tool_prefix$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -4799,7 +4824,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_CXX="$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -5267,7 +5292,7 @@ do for ac_prog in grep ggrep; do for ac_exec_ext in '' $ac_executable_extensions; do ac_path_GREP="$as_dir/$ac_prog$ac_exec_ext" - { test -f "$ac_path_GREP" && $as_test_x "$ac_path_GREP"; } || continue + as_fn_executable_p "$ac_path_GREP" || continue # Check for GNU ac_path_GREP and select it if it is found. # Check for GNU $ac_path_GREP case `"$ac_path_GREP" --version 2>&1` in @@ -5333,7 +5358,7 @@ do for ac_prog in egrep; do for ac_exec_ext in '' $ac_executable_extensions; do ac_path_EGREP="$as_dir/$ac_prog$ac_exec_ext" - { test -f "$ac_path_EGREP" && $as_test_x "$ac_path_EGREP"; } || continue + as_fn_executable_p "$ac_path_EGREP" || continue # Check for GNU ac_path_EGREP and select it if it is found. # Check for GNU $ac_path_EGREP case `"$ac_path_EGREP" --version 2>&1` in @@ -5540,8 +5565,8 @@ else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ -# define __EXTENSIONS__ 1 - $ac_includes_default +# define __EXTENSIONS__ 1 + $ac_includes_default int main () { @@ -5897,7 +5922,7 @@ do for ac_prog in sed gsed; do for ac_exec_ext in '' $ac_executable_extensions; do ac_path_SED="$as_dir/$ac_prog$ac_exec_ext" - { test -f "$ac_path_SED" && $as_test_x "$ac_path_SED"; } || continue + as_fn_executable_p "$ac_path_SED" || continue # Check for GNU ac_path_SED and select it if it is found. # Check for GNU $ac_path_SED case `"$ac_path_SED" --version 2>&1` in @@ -5976,7 +6001,7 @@ do for ac_prog in fgrep; do for ac_exec_ext in '' $ac_executable_extensions; do ac_path_FGREP="$as_dir/$ac_prog$ac_exec_ext" - { test -f "$ac_path_FGREP" && $as_test_x "$ac_path_FGREP"; } || continue + as_fn_executable_p "$ac_path_FGREP" || continue # Check for GNU ac_path_FGREP and select it if it is found. # Check for GNU $ac_path_FGREP case `"$ac_path_FGREP" --version 2>&1` in @@ -6232,7 +6257,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_DUMPBIN="$ac_tool_prefix$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -6276,7 +6301,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_DUMPBIN="$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -6700,7 +6725,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_OBJDUMP="${ac_tool_prefix}objdump" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -6740,7 +6765,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_OBJDUMP="objdump" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -6866,10 +6891,6 @@ freebsd* | dragonfly*) fi ;; -gnu*) - lt_cv_deplibs_check_method=pass_all - ;; - haiku*) lt_cv_deplibs_check_method=pass_all ;; @@ -6908,11 +6929,11 @@ irix5* | irix6* | nonstopux*) ;; # This must be glibc/ELF. -linux* | k*bsd*-gnu | kopensolaris*-gnu) +linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) lt_cv_deplibs_check_method=pass_all ;; -netbsd*) +netbsd* | netbsdelf*-gnu) if echo __ELF__ | $CC -E - | $GREP __ELF__ > /dev/null; then lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|_pic\.a)$' else @@ -7046,7 +7067,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_DLLTOOL="${ac_tool_prefix}dlltool" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7086,7 +7107,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_DLLTOOL="dlltool" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7189,7 +7210,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_AR="$ac_tool_prefix$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7233,7 +7254,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_AR="$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7358,7 +7379,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_STRIP="${ac_tool_prefix}strip" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7398,7 +7419,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_STRIP="strip" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7457,7 +7478,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_RANLIB="${ac_tool_prefix}ranlib" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -7497,7 +7518,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_RANLIB="ranlib" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8146,7 +8167,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_MANIFEST_TOOL="${ac_tool_prefix}mt" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8186,7 +8207,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_MANIFEST_TOOL="mt" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8266,7 +8287,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_DSYMUTIL="${ac_tool_prefix}dsymutil" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8306,7 +8327,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_DSYMUTIL="dsymutil" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8358,7 +8379,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_NMEDIT="${ac_tool_prefix}nmedit" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8398,7 +8419,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_NMEDIT="nmedit" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8450,7 +8471,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_LIPO="${ac_tool_prefix}lipo" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8490,7 +8511,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_LIPO="lipo" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8542,7 +8563,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_OTOOL="${ac_tool_prefix}otool" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8582,7 +8603,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_OTOOL="otool" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8634,7 +8655,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_OTOOL64="${ac_tool_prefix}otool64" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -8674,7 +8695,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_OTOOL64="otool64" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -9578,7 +9599,7 @@ lt_prog_compiler_static= lt_prog_compiler_static='-non_shared' ;; - linux* | k*bsd*-gnu | kopensolaris*-gnu) + linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) case $cc_basename in # old Intel for x86_64 which still supported -KPIC. ecc*) @@ -10056,6 +10077,9 @@ $as_echo_n "checking whether the $compiler linker ($LD) supports shared librarie openbsd*) with_gnu_ld=no ;; + linux* | k*bsd*-gnu | gnu*) + link_all_deplibs=no + ;; esac ld_shlibs=yes @@ -10277,7 +10301,7 @@ _LT_EOF fi ;; - netbsd*) + netbsd* | netbsdelf*-gnu) if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then archive_cmds='$LD -Bshareable $libobjs $deplibs $linker_flags -o $lib' wlarc= @@ -10454,6 +10478,7 @@ _LT_EOF if test "$aix_use_runtimelinking" = yes; then shared_flag="$shared_flag "'${wl}-G' fi + link_all_deplibs=no else # not using gcc if test "$host_cpu" = ia64; then @@ -10907,7 +10932,7 @@ $as_echo "$lt_cv_irix_exported_symbol" >&6; } link_all_deplibs=yes ;; - netbsd*) + netbsd* | netbsdelf*-gnu) if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' # a.out else @@ -11744,17 +11769,6 @@ freebsd* | dragonfly*) esac ;; -gnu*) - version_type=linux # correct to gnu/linux during the next big refactor - need_lib_prefix=no - need_version=no - library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}' - soname_spec='${libname}${release}${shared_ext}$major' - shlibpath_var=LD_LIBRARY_PATH - shlibpath_overrides_runpath=no - hardcode_into_libs=yes - ;; - haiku*) version_type=linux # correct to gnu/linux during the next big refactor need_lib_prefix=no @@ -11871,7 +11885,7 @@ linux*oldld* | linux*aout* | linux*coff*) ;; # This must be glibc/ELF. -linux* | k*bsd*-gnu | kopensolaris*-gnu) +linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) version_type=linux # correct to gnu/linux during the next big refactor need_lib_prefix=no need_version=no @@ -11920,14 +11934,10 @@ fi # before this can be enabled. hardcode_into_libs=yes - # Add ABI-specific directories to the system library path. - sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib" - # Append ld.so.conf contents to the search path if test -f /etc/ld.so.conf; then lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \$2)); skip = 1; } { if (!skip) print \$0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[ ]/d;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '` - sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec $lt_ld_extra" - + sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra" fi # We used to test for /lib/ld.so.1 and disable shared libraries on @@ -11939,6 +11949,18 @@ fi dynamic_linker='GNU/Linux ld.so' ;; +netbsdelf*-gnu) + version_type=linux + need_lib_prefix=no + need_version=no + library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}' + soname_spec='${libname}${release}${shared_ext}$major' + shlibpath_var=LD_LIBRARY_PATH + shlibpath_overrides_runpath=no + hardcode_into_libs=yes + dynamic_linker='NetBSD ld.elf_so' + ;; + netbsd*) version_type=sunos need_lib_prefix=no @@ -13686,9 +13708,6 @@ fi ld_shlibs_CXX=yes ;; - gnu*) - ;; - haiku*) archive_cmds_CXX='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib' link_all_deplibs_CXX=yes @@ -13850,7 +13869,7 @@ fi inherit_rpath_CXX=yes ;; - linux* | k*bsd*-gnu | kopensolaris*-gnu) + linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) case $cc_basename in KCC*) # Kuck and Associates, Inc. (KAI) C++ Compiler @@ -14710,7 +14729,7 @@ lt_prog_compiler_static_CXX= ;; esac ;; - linux* | k*bsd*-gnu | kopensolaris*-gnu) + linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) case $cc_basename in KCC*) # KAI C++ Compiler @@ -14774,7 +14793,7 @@ lt_prog_compiler_static_CXX= ;; esac ;; - netbsd*) + netbsd* | netbsdelf*-gnu) ;; *qnx* | *nto*) # QNX uses GNU C++, but need to define -shared option too, otherwise @@ -15145,6 +15164,9 @@ $as_echo_n "checking whether the $compiler linker ($LD) supports shared librarie ;; esac ;; + linux* | k*bsd*-gnu | gnu*) + link_all_deplibs_CXX=no + ;; *) export_symbols_cmds_CXX='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' ;; @@ -15579,17 +15601,6 @@ freebsd* | dragonfly*) esac ;; -gnu*) - version_type=linux # correct to gnu/linux during the next big refactor - need_lib_prefix=no - need_version=no - library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}' - soname_spec='${libname}${release}${shared_ext}$major' - shlibpath_var=LD_LIBRARY_PATH - shlibpath_overrides_runpath=no - hardcode_into_libs=yes - ;; - haiku*) version_type=linux # correct to gnu/linux during the next big refactor need_lib_prefix=no @@ -15706,7 +15717,7 @@ linux*oldld* | linux*aout* | linux*coff*) ;; # This must be glibc/ELF. -linux* | k*bsd*-gnu | kopensolaris*-gnu) +linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) version_type=linux # correct to gnu/linux during the next big refactor need_lib_prefix=no need_version=no @@ -15755,14 +15766,10 @@ fi # before this can be enabled. hardcode_into_libs=yes - # Add ABI-specific directories to the system library path. - sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib" - # Append ld.so.conf contents to the search path if test -f /etc/ld.so.conf; then lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \$2)); skip = 1; } { if (!skip) print \$0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[ ]/d;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '` - sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec $lt_ld_extra" - + sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra" fi # We used to test for /lib/ld.so.1 and disable shared libraries on @@ -15774,6 +15781,18 @@ fi dynamic_linker='GNU/Linux ld.so' ;; +netbsdelf*-gnu) + version_type=linux + need_lib_prefix=no + need_version=no + library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}' + soname_spec='${libname}${release}${shared_ext}$major' + shlibpath_var=LD_LIBRARY_PATH + shlibpath_overrides_runpath=no + hardcode_into_libs=yes + dynamic_linker='NetBSD ld.elf_so' + ;; + netbsd*) version_type=sunos need_lib_prefix=no @@ -16140,7 +16159,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -16183,7 +16202,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_ac_pt_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -16254,7 +16273,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_RC="${ac_tool_prefix}windres" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -16294,7 +16313,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_RC="windres" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -16463,7 +16482,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_WINDRES="${ac_tool_prefix}windres" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -16503,7 +16522,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_ac_ct_WINDRES="windres" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -16792,14 +16811,6 @@ if test "${with_dbus_daemondir+set}" = set; then : fi -# Check whether --with-dbus_session_bus_default_address was given. -if test "${with_dbus_session_bus_default_address+set}" = set; then : - withval=$with_dbus_session_bus_default_address; with_dbus_session_bus_default_address=$withval -else - with_dbus_session_bus_default_address=nonce-tcp: -fi - - # Check whether --enable-embedded-tests was given. if test "${enable_embedded_tests+set}" = set; then : enableval=$enable_embedded_tests; @@ -16864,6 +16875,13 @@ fi # default (unless you don't have GLib), because they don't bloat the library # or binaries. + +$as_echo "#define GLIB_VERSION_MIN_REQUIRED GLIB_VERSION_2_26" >>confdefs.h + + +$as_echo "#define GLIB_VERSION_MAX_ALLOWED GLIB_VERSION_2_26" >>confdefs.h + + with_glib=yes if test "x$enable_modular_tests" != xno; then @@ -17158,7 +17176,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_PYTHON="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -17396,7 +17414,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_PYTHON="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -19302,7 +19320,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -19345,7 +19363,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_ac_pt_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -19578,15 +19596,31 @@ fi # Thread lib detection -ac_fn_c_check_func "$LINENO" "pthread_cond_timedwait" "ac_cv_func_pthread_cond_timedwait" -if test "x$ac_cv_func_pthread_cond_timedwait" = xyes; then : - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread_cond_timedwait in -lpthread" >&5 -$as_echo_n "checking for pthread_cond_timedwait in -lpthread... " >&6; } -if ${ac_cv_lib_pthread_pthread_cond_timedwait+:} false; then : + +save_libs="$LIBS" +LIBS="$LIBS $THREAD_LIBS" + +is_missing_pthread_function="is required when compiling D-Bus on Unix platforms, but is not in your libc or libpthread. Please open a bug on https://bugs.freedesktop.org/enter_bug.cgi?product=dbus with details of your platform." + +# Don't do these automatic checks if the user set THREAD_LIBS on the +# configure command-line. If they did, we assume they're right. +# +# We also don't do these checks on Windows, because you don't need magical +# linker flags to have threading support there. +if test "x$dbus_unix" = xyes && test "x$THREAD_LIBS" = x; then : + + # Mandatory pthread functions. In principle, some of these could be made + # optional if there are platforms that don't have them. + # + # Currently, we only look in -lpthread. + # In principle we might need to look in -lpthreads, -lthreads, ... + # as well - please file a bug if your platform needs this. + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing pthread_cond_timedwait" >&5 +$as_echo_n "checking for library containing pthread_cond_timedwait... " >&6; } +if ${ac_cv_search_pthread_cond_timedwait+:} false; then : $as_echo_n "(cached) " >&6 else - ac_check_lib_save_LIBS=$LIBS -LIBS="-lpthread $LIBS" + ac_func_search_save_LIBS=$LIBS cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -19605,34 +19639,219 @@ return pthread_cond_timedwait (); return 0; } _ACEOF -if ac_fn_c_try_link "$LINENO"; then : - ac_cv_lib_pthread_pthread_cond_timedwait=yes +for ac_lib in '' pthread; do + if test -z "$ac_lib"; then + ac_res="none required" + else + ac_res=-l$ac_lib + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + fi + if ac_fn_c_try_link "$LINENO"; then : + ac_cv_search_pthread_cond_timedwait=$ac_res +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext + if ${ac_cv_search_pthread_cond_timedwait+:} false; then : + break +fi +done +if ${ac_cv_search_pthread_cond_timedwait+:} false; then : + else - ac_cv_lib_pthread_pthread_cond_timedwait=no + ac_cv_search_pthread_cond_timedwait=no +fi +rm conftest.$ac_ext +LIBS=$ac_func_search_save_LIBS +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_pthread_cond_timedwait" >&5 +$as_echo "$ac_cv_search_pthread_cond_timedwait" >&6; } +ac_res=$ac_cv_search_pthread_cond_timedwait +if test "$ac_res" != no; then : + test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" + THREAD_LIBS="$LIBS" +else + as_fn_error $? "pthread_cond_timedwait $is_missing_pthread_function" "$LINENO" 5 +fi + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing pthread_mutexattr_init" >&5 +$as_echo_n "checking for library containing pthread_mutexattr_init... " >&6; } +if ${ac_cv_search_pthread_mutexattr_init+:} false; then : + $as_echo_n "(cached) " >&6 +else + ac_func_search_save_LIBS=$LIBS +cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +/* Override any GCC internal prototype to avoid an error. + Use char because int might match the return type of a GCC + builtin and then its argument prototype would still apply. */ +#ifdef __cplusplus +extern "C" +#endif +char pthread_mutexattr_init (); +int +main () +{ +return pthread_mutexattr_init (); + ; + return 0; +} +_ACEOF +for ac_lib in '' pthread; do + if test -z "$ac_lib"; then + ac_res="none required" + else + ac_res=-l$ac_lib + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + fi + if ac_fn_c_try_link "$LINENO"; then : + ac_cv_search_pthread_mutexattr_init=$ac_res fi rm -f core conftest.err conftest.$ac_objext \ - conftest$ac_exeext conftest.$ac_ext -LIBS=$ac_check_lib_save_LIBS + conftest$ac_exeext + if ${ac_cv_search_pthread_mutexattr_init+:} false; then : + break fi -{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_pthread_pthread_cond_timedwait" >&5 -$as_echo "$ac_cv_lib_pthread_pthread_cond_timedwait" >&6; } -if test "x$ac_cv_lib_pthread_pthread_cond_timedwait" = xyes; then : - THREAD_LIBS="-lpthread" +done +if ${ac_cv_search_pthread_mutexattr_init+:} false; then : + +else + ac_cv_search_pthread_mutexattr_init=no +fi +rm conftest.$ac_ext +LIBS=$ac_func_search_save_LIBS +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_pthread_mutexattr_init" >&5 +$as_echo "$ac_cv_search_pthread_mutexattr_init" >&6; } +ac_res=$ac_cv_search_pthread_mutexattr_init +if test "$ac_res" != no; then : + test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" + THREAD_LIBS="$LIBS" +else + as_fn_error $? "pthread_mutexattr_init $is_missing_pthread_function" "$LINENO" 5 fi + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing pthread_mutexattr_settype" >&5 +$as_echo_n "checking for library containing pthread_mutexattr_settype... " >&6; } +if ${ac_cv_search_pthread_mutexattr_settype+:} false; then : + $as_echo_n "(cached) " >&6 +else + ac_func_search_save_LIBS=$LIBS +cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +/* Override any GCC internal prototype to avoid an error. + Use char because int might match the return type of a GCC + builtin and then its argument prototype would still apply. */ +#ifdef __cplusplus +extern "C" +#endif +char pthread_mutexattr_settype (); +int +main () +{ +return pthread_mutexattr_settype (); + ; + return 0; +} +_ACEOF +for ac_lib in '' pthread; do + if test -z "$ac_lib"; then + ac_res="none required" + else + ac_res=-l$ac_lib + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + fi + if ac_fn_c_try_link "$LINENO"; then : + ac_cv_search_pthread_mutexattr_settype=$ac_res +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext + if ${ac_cv_search_pthread_mutexattr_settype+:} false; then : + break fi +done +if ${ac_cv_search_pthread_mutexattr_settype+:} false; then : -save_libs="$LIBS" -LIBS="$LIBS $THREAD_LIBS" -ac_fn_c_check_func "$LINENO" "pthread_condattr_setclock" "ac_cv_func_pthread_condattr_setclock" -if test "x$ac_cv_func_pthread_condattr_setclock" = xyes; then : - have_pthread_condattr_setclock=true else - have_pthread_condattr_setclock=false + ac_cv_search_pthread_mutexattr_settype=no +fi +rm conftest.$ac_ext +LIBS=$ac_func_search_save_LIBS +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_pthread_mutexattr_settype" >&5 +$as_echo "$ac_cv_search_pthread_mutexattr_settype" >&6; } +ac_res=$ac_cv_search_pthread_mutexattr_settype +if test "$ac_res" != no; then : + test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" + THREAD_LIBS="$LIBS" +else + as_fn_error $? "pthread_mutexattr_settype $is_missing_pthread_function" "$LINENO" 5 fi -if test x$have_pthread_condattr_setclock = xtrue; then - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing clock_getres" >&5 + + # Optional, for monotonic clocks. Because it's optional, this check + # is non-fatal if we don't find it. + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing pthread_condattr_setclock" >&5 +$as_echo_n "checking for library containing pthread_condattr_setclock... " >&6; } +if ${ac_cv_search_pthread_condattr_setclock+:} false; then : + $as_echo_n "(cached) " >&6 +else + ac_func_search_save_LIBS=$LIBS +cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +/* Override any GCC internal prototype to avoid an error. + Use char because int might match the return type of a GCC + builtin and then its argument prototype would still apply. */ +#ifdef __cplusplus +extern "C" +#endif +char pthread_condattr_setclock (); +int +main () +{ +return pthread_condattr_setclock (); + ; + return 0; +} +_ACEOF +for ac_lib in '' pthread; do + if test -z "$ac_lib"; then + ac_res="none required" + else + ac_res=-l$ac_lib + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + fi + if ac_fn_c_try_link "$LINENO"; then : + ac_cv_search_pthread_condattr_setclock=$ac_res +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext + if ${ac_cv_search_pthread_condattr_setclock+:} false; then : + break +fi +done +if ${ac_cv_search_pthread_condattr_setclock+:} false; then : + +else + ac_cv_search_pthread_condattr_setclock=no +fi +rm conftest.$ac_ext +LIBS=$ac_func_search_save_LIBS +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_pthread_condattr_setclock" >&5 +$as_echo "$ac_cv_search_pthread_condattr_setclock" >&6; } +ac_res=$ac_cv_search_pthread_condattr_setclock +if test "$ac_res" != no; then : + test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" + THREAD_LIBS="$LIBS" +fi + + + if test "x$ac_cv_search_pthread_condattr_setclock" != xno; then : + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing clock_getres" >&5 $as_echo_n "checking for library containing clock_getres... " >&6; } if ${ac_cv_search_clock_getres+:} false; then : $as_echo_n "(cached) " >&6 @@ -19685,12 +19904,12 @@ $as_echo "$ac_cv_search_clock_getres" >&6; } ac_res=$ac_cv_search_clock_getres if test "$ac_res" != no; then : test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" - THREAD_LIBS="$THREAD_LIBS -lrt" + THREAD_LIBS="$LIBS" fi - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for CLOCK_MONOTONIC" >&5 + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for CLOCK_MONOTONIC" >&5 $as_echo_n "checking for CLOCK_MONOTONIC... " >&6; } - cat confdefs.h - <<_ACEOF >conftest.$ac_ext + cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include <time.h> #include <pthread.h> @@ -19715,16 +19934,20 @@ else have_clock_monotonic=false fi rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext -if test x$have_clock_monotonic = xtrue; then - { $as_echo "$as_me:${as_lineno-$LINENO}: result: found" >&5 + if test x$have_clock_monotonic = xtrue; then : + + { $as_echo "$as_me:${as_lineno-$LINENO}: result: found" >&5 $as_echo "found" >&6; } $as_echo "#define HAVE_MONOTONIC_CLOCK 1" >>confdefs.h + else - { $as_echo "$as_me:${as_lineno-$LINENO}: result: not found" >&5 + { $as_echo "$as_me:${as_lineno-$LINENO}: result: not found" >&5 $as_echo "not found" >&6; } fi + +fi fi LIBS="$save_libs" @@ -20087,7 +20310,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_LAUNCHCTL="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -21718,7 +21941,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_DOXYGEN="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -21794,7 +22017,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_prog_XSLTPROC="$ac_prog" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -21847,7 +22070,7 @@ do IFS=$as_save_IFS test -z "$as_dir" && as_dir=. for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then ac_cv_path_XMLTO="$as_dir/$ac_word$ac_exec_ext" $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 break 2 @@ -21905,58 +22128,7 @@ fi { $as_echo "$as_me:${as_lineno-$LINENO}: result: $enable_xml_docs" >&5 $as_echo "$enable_xml_docs" >&6; } -# Extract the first word of "man2html", so it can be a program name with args. -set dummy man2html; ac_word=$2 -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5 -$as_echo_n "checking for $ac_word... " >&6; } -if ${ac_cv_path_MAN2HTML+:} false; then : - $as_echo_n "(cached) " >&6 -else - case $MAN2HTML in - [\\/]* | ?:[\\/]*) - ac_cv_path_MAN2HTML="$MAN2HTML" # Let the user override the test with a path. - ;; - *) - as_save_IFS=$IFS; IFS=$PATH_SEPARATOR -for as_dir in $PATH -do - IFS=$as_save_IFS - test -z "$as_dir" && as_dir=. - for ac_exec_ext in '' $ac_executable_extensions; do - if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then - ac_cv_path_MAN2HTML="$as_dir/$ac_word$ac_exec_ext" - $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 - break 2 - fi -done - done -IFS=$as_save_IFS - - ;; -esac -fi -MAN2HTML=$ac_cv_path_MAN2HTML -if test -n "$MAN2HTML"; then - { $as_echo "$as_me:${as_lineno-$LINENO}: result: $MAN2HTML" >&5 -$as_echo "$MAN2HTML" >&6; } -else - { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 -$as_echo "no" >&6; } -fi - - - - if test x$MAN2HTML != x; then - DBUS_HAVE_MAN2HTML_TRUE= - DBUS_HAVE_MAN2HTML_FALSE='#' -else - DBUS_HAVE_MAN2HTML_TRUE='#' - DBUS_HAVE_MAN2HTML_FALSE= -fi - - - if test x$enable_doxygen_docs = xyes -a x$enable_xml_docs = xyes -a \ - x$MAN2HTML != x; then + if test x$enable_doxygen_docs = xyes && test x$enable_xml_docs = xyes; then DBUS_CAN_UPLOAD_DOCS_TRUE= DBUS_CAN_UPLOAD_DOCS_FALSE='#' else @@ -22264,8 +22436,17 @@ cat >>confdefs.h <<_ACEOF _ACEOF -## system bus only listens on local domain sockets, and never -## on an abstract socket (so only root can create the socket) +## System bus only listens on local domain sockets, and never +## on an abstract socket (so only root can create the socket). +## +## This won't work on Windows. It's not meant to - the system bus is +## meaningless on Windows anyway. +## +## This has to be suitable for hard-coding in client libraries as well as +## in the dbus-daemon's configuration, so it has to be valid to listen on +## and also to connect to. If this ever changes, it'll need to be split into +## two variables, one for the listening address and one for the connecting +## address. DBUS_SYSTEM_BUS_DEFAULT_ADDRESS="unix:path=$DBUS_SYSTEM_SOCKET" @@ -22472,15 +22653,73 @@ _ACEOF -if test x$dbus_win = xyes; then - DBUS_SESSION_BUS_DEFAULT_ADDRESS="$with_dbus_session_bus_default_address" +# This must be a listening address. It doesn't necessarily need to be an +# address you can connect to - it can be something vague like +# "nonce-tcp:". +# +# The default varies by platform. + +# Check whether --with-dbus_session_bus_listen_address was given. +if test "${with_dbus_session_bus_listen_address+set}" = set; then : + withval=$with_dbus_session_bus_listen_address; with_dbus_session_bus_listen_address=$withval +else + with_dbus_session_bus_listen_address= +fi + + +if test "x$with_dbus_session_bus_listen_address" != "x"; then + # the user specified something, trust them + DBUS_SESSION_BUS_LISTEN_ADDRESS="$with_dbus_session_bus_listen_address" +elif test x$dbus_win = xyes; then + # On Windows, you can (and should) listen on autolaunch addresses, + # because autolaunching is different. + # See https://bugs.freedesktop.org/show_bug.cgi?id=38201 + DBUS_SESSION_BUS_LISTEN_ADDRESS="autolaunch:" elif test x$have_launchd = xyes; then - DBUS_SESSION_BUS_DEFAULT_ADDRESS="launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" + # Mac OS X default is to use launchd + DBUS_SESSION_BUS_LISTEN_ADDRESS="launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" +else + # The default on all other Unix platforms (notably Linux) + # is to create a randomly named socket in /tmp or similar + DBUS_SESSION_BUS_LISTEN_ADDRESS="unix:tmpdir=$DBUS_SESSION_SOCKET_DIR" +fi + + +# This must be an address you can connect to. It doesn't necessarily +# need to be an address you can listen on - it can be "autolaunch:", +# even on Unix. +# +# The default varies by platform. + +# Check whether --with-dbus_session_bus_connect_address was given. +if test "${with_dbus_session_bus_connect_address+set}" = set; then : + withval=$with_dbus_session_bus_connect_address; with_dbus_session_bus_connect_address=$withval +else + with_dbus_session_bus_connect_address= +fi + + +if test "x$with_dbus_session_bus_connect_address" != "x"; then + # the user specified something, trust them + DBUS_SESSION_BUS_CONNECT_ADDRESS="$with_dbus_session_bus_connect_address" +elif test x$dbus_win = xyes; then + # Windows autolaunching is a bit different; leaving it in its own + # branch of the conditional because the default might conceivably + # change (see #38201) + DBUS_SESSION_BUS_CONNECT_ADDRESS="autolaunch:" else - DBUS_SESSION_BUS_DEFAULT_ADDRESS="unix:tmpdir=$DBUS_SESSION_SOCKET_DIR" + # The default on all other Unix platforms (notably Linux) + # is to use auto-launching - this works a bit differently on Mac OS X + # but comes out basically the same in the end + DBUS_SESSION_BUS_CONNECT_ADDRESS="autolaunch:" fi +cat >>confdefs.h <<_ACEOF +#define DBUS_SESSION_BUS_CONNECT_ADDRESS "$DBUS_SESSION_BUS_CONNECT_ADDRESS" +_ACEOF + + # darwin needs this to initialize the environment for ac_header in crt_externs.h do : @@ -22516,7 +22755,7 @@ $as_echo "#define DBUS_ENABLE_STATS 1" >>confdefs.h fi -ac_config_files="$ac_config_files Doxyfile dbus/versioninfo.rc dbus/dbus-arch-deps.h bus/system.conf bus/session.conf bus/messagebus bus/messagebus-config bus/org.freedesktop.dbus-session.plist bus/rc.messagebus bus/dbus.service bus/dbus.socket Makefile dbus/Makefile bus/Makefile tools/Makefile test/Makefile test/name-test/Makefile doc/Makefile doc/dbus-daemon.1 dbus-1.pc dbus-1-uninstalled.pc test/data/valid-config-files/debug-allow-all.conf test/data/valid-config-files/debug-allow-all-sha1.conf test/data/valid-config-files-system/debug-allow-all-pass.conf test/data/valid-config-files-system/debug-allow-all-fail.conf test/data/valid-service-files/org.freedesktop.DBus.TestSuite.PrivServer.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteEchoService.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteForkingEchoService.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteSegfaultService.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteShellEchoServiceSuccess.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteShellEchoServiceFail.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteEchoService.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteSegfaultService.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteShellEchoServiceSuccess.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteShellEchoServiceFail.service test/data/invalid-service-files-system/org.freedesktop.DBus.TestSuiteNoExec.service test/data/invalid-service-files-system/org.freedesktop.DBus.TestSuiteNoUser.service test/data/invalid-service-files-system/org.freedesktop.DBus.TestSuiteNoService.service" +ac_config_files="$ac_config_files Doxyfile dbus/versioninfo.rc dbus/dbus-arch-deps.h bus/system.conf bus/session.conf bus/messagebus bus/messagebus-config bus/org.freedesktop.dbus-session.plist bus/rc.messagebus bus/dbus.service bus/dbus.socket Makefile dbus/Makefile bus/Makefile tools/Makefile test/Makefile test/name-test/Makefile doc/Makefile doc/dbus-cleanup-sockets.1.xml doc/dbus-daemon.1.xml doc/dbus-launch.1.xml doc/dbus-monitor.1.xml doc/dbus-send.1.xml doc/dbus-uuidgen.1.xml dbus-1.pc dbus-1-uninstalled.pc test/data/valid-config-files/debug-allow-all.conf test/data/valid-config-files/debug-allow-all-sha1.conf test/data/valid-config-files-system/debug-allow-all-pass.conf test/data/valid-config-files-system/debug-allow-all-fail.conf test/data/valid-service-files/org.freedesktop.DBus.TestSuite.PrivServer.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteEchoService.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteForkingEchoService.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteSegfaultService.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteShellEchoServiceSuccess.service test/data/valid-service-files/org.freedesktop.DBus.TestSuiteShellEchoServiceFail.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteEchoService.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteSegfaultService.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteShellEchoServiceSuccess.service test/data/valid-service-files-system/org.freedesktop.DBus.TestSuiteShellEchoServiceFail.service test/data/invalid-service-files-system/org.freedesktop.DBus.TestSuiteNoExec.service test/data/invalid-service-files-system/org.freedesktop.DBus.TestSuiteNoUser.service test/data/invalid-service-files-system/org.freedesktop.DBus.TestSuiteNoService.service" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure @@ -22740,10 +22979,6 @@ if test -z "${DBUS_XML_DOCS_ENABLED_TRUE}" && test -z "${DBUS_XML_DOCS_ENABLED_F as_fn_error $? "conditional \"DBUS_XML_DOCS_ENABLED\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 fi -if test -z "${DBUS_HAVE_MAN2HTML_TRUE}" && test -z "${DBUS_HAVE_MAN2HTML_FALSE}"; then - as_fn_error $? "conditional \"DBUS_HAVE_MAN2HTML\" was never defined. -Usually this means the macro was only invoked conditionally." "$LINENO" 5 -fi if test -z "${DBUS_CAN_UPLOAD_DOCS_TRUE}" && test -z "${DBUS_CAN_UPLOAD_DOCS_FALSE}"; then as_fn_error $? "conditional \"DBUS_CAN_UPLOAD_DOCS\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 @@ -23062,16 +23297,16 @@ if (echo >conf$$.file) 2>/dev/null; then # ... but there are two gotchas: # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail. # 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable. - # In both cases, we have to default to `cp -p'. + # In both cases, we have to default to `cp -pR'. ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe || - as_ln_s='cp -p' + as_ln_s='cp -pR' elif ln conf$$.file conf$$ 2>/dev/null; then as_ln_s=ln else - as_ln_s='cp -p' + as_ln_s='cp -pR' fi else - as_ln_s='cp -p' + as_ln_s='cp -pR' fi rm -f conf$$ conf$$.exe conf$$.dir/conf$$.file conf$$.file rmdir conf$$.dir 2>/dev/null @@ -23131,28 +23366,16 @@ else as_mkdir_p=false fi -if test -x / >/dev/null 2>&1; then - as_test_x='test -x' -else - if ls -dL / >/dev/null 2>&1; then - as_ls_L_option=L - else - as_ls_L_option= - fi - as_test_x=' - eval sh -c '\'' - if test -d "$1"; then - test -d "$1/."; - else - case $1 in #( - -*)set "./$1";; - esac; - case `ls -ld'$as_ls_L_option' "$1" 2>/dev/null` in #(( - ???[sx]*):;;*)false;;esac;fi - '\'' sh - ' -fi -as_executable_p=$as_test_x + +# as_fn_executable_p FILE +# ----------------------- +# Test if FILE is an executable regular file. +as_fn_executable_p () +{ + test -f "$1" && test -x "$1" +} # as_fn_executable_p +as_test_x='test -x' +as_executable_p=as_fn_executable_p # Sed expression to map a string onto a valid CPP name. as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'" @@ -23173,8 +23396,8 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1 # report actual input values of CONFIG_FILES etc. instead of their # values after options handling. ac_log=" -This file was extended by dbus $as_me 1.6.8, which was -generated by GNU Autoconf 2.68. Invocation command line was +This file was extended by dbus $as_me 1.7.0, which was +generated by GNU Autoconf 2.69. Invocation command line was CONFIG_FILES = $CONFIG_FILES CONFIG_HEADERS = $CONFIG_HEADERS @@ -23239,11 +23462,11 @@ _ACEOF cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`" ac_cs_version="\\ -dbus config.status 1.6.8 -configured by $0, generated by GNU Autoconf 2.68, +dbus config.status 1.7.0 +configured by $0, generated by GNU Autoconf 2.69, with options \\"\$ac_cs_config\\" -Copyright (C) 2010 Free Software Foundation, Inc. +Copyright (C) 2012 Free Software Foundation, Inc. This config.status script is free software; the Free Software Foundation gives unlimited permission to copy, distribute and modify it." @@ -23334,7 +23557,7 @@ fi _ACEOF cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 if \$ac_cs_recheck; then - set X '$SHELL' '$0' $ac_configure_args \$ac_configure_extra_args --no-create --no-recursion + set X $SHELL '$0' $ac_configure_args \$ac_configure_extra_args --no-create --no-recursion shift \$as_echo "running CONFIG_SHELL=$SHELL \$*" >&6 CONFIG_SHELL='$SHELL' @@ -23850,7 +24073,12 @@ do "test/Makefile") CONFIG_FILES="$CONFIG_FILES test/Makefile" ;; "test/name-test/Makefile") CONFIG_FILES="$CONFIG_FILES test/name-test/Makefile" ;; "doc/Makefile") CONFIG_FILES="$CONFIG_FILES doc/Makefile" ;; - "doc/dbus-daemon.1") CONFIG_FILES="$CONFIG_FILES doc/dbus-daemon.1" ;; + "doc/dbus-cleanup-sockets.1.xml") CONFIG_FILES="$CONFIG_FILES doc/dbus-cleanup-sockets.1.xml" ;; + "doc/dbus-daemon.1.xml") CONFIG_FILES="$CONFIG_FILES doc/dbus-daemon.1.xml" ;; + "doc/dbus-launch.1.xml") CONFIG_FILES="$CONFIG_FILES doc/dbus-launch.1.xml" ;; + "doc/dbus-monitor.1.xml") CONFIG_FILES="$CONFIG_FILES doc/dbus-monitor.1.xml" ;; + "doc/dbus-send.1.xml") CONFIG_FILES="$CONFIG_FILES doc/dbus-send.1.xml" ;; + "doc/dbus-uuidgen.1.xml") CONFIG_FILES="$CONFIG_FILES doc/dbus-uuidgen.1.xml" ;; "dbus-1.pc") CONFIG_FILES="$CONFIG_FILES dbus-1.pc" ;; "dbus-1-uninstalled.pc") CONFIG_FILES="$CONFIG_FILES dbus-1-uninstalled.pc" ;; "test/data/valid-config-files/debug-allow-all.conf") CONFIG_FILES="$CONFIG_FILES test/data/valid-config-files/debug-allow-all.conf" ;; @@ -25570,8 +25798,7 @@ echo " 32-bit int: ${DBUS_INT32_TYPE} 16-bit int: ${DBUS_INT16_TYPE} Doxygen: ${DOXYGEN:-not found} - xmlto: ${XMLTO:-not found} - man2html: ${MAN2HTML:-not found}" + xmlto: ${XMLTO:-not found}" echo " Rebuilding generated files: ${USE_MAINTAINER_MODE} @@ -25599,7 +25826,8 @@ echo " System bus socket: ${DBUS_SYSTEM_SOCKET} System bus address: ${DBUS_SYSTEM_BUS_DEFAULT_ADDRESS} System bus PID file: ${DBUS_SYSTEM_PID_FILE} - Session bus address: ${DBUS_SESSION_BUS_DEFAULT_ADDRESS} + Session bus listens on: ${DBUS_SESSION_BUS_LISTEN_ADDRESS} + Session clients connect to: ${DBUS_SESSION_BUS_CONNECT_ADDRESS} Console auth dir: ${DBUS_CONSOLE_AUTH_DIR} Console owner file: ${have_console_owner_file} Console owner file path: ${DBUS_CONSOLE_OWNER_FILE} diff --git a/configure.ac b/configure.ac index 24fcc9e7..4554fcea 100644 --- a/configure.ac +++ b/configure.ac @@ -2,8 +2,8 @@ dnl -*- mode: m4 -*- AC_PREREQ([2.63]) m4_define([dbus_major_version], [1]) -m4_define([dbus_minor_version], [6]) -m4_define([dbus_micro_version], [8]) +m4_define([dbus_minor_version], [7]) +m4_define([dbus_micro_version], [0]) m4_define([dbus_version], [dbus_major_version.dbus_minor_version.dbus_micro_version]) AC_INIT([dbus],[dbus_version],[https://bugs.freedesktop.org/enter_bug.cgi?product=dbus],[dbus]) @@ -33,16 +33,16 @@ AC_DEFINE_UNQUOTED(DBUS_DAEMON_NAME,"dbus-daemon",[Name of executable]) # ## increment if the interface has additions, changes, removals. -LT_CURRENT=10 +LT_CURRENT=11 ## increment any time the source changes; set to ## 0 if you increment CURRENT -LT_REVISION=2 +LT_REVISION=0 ## increment if any interfaces have been added; set to 0 ## if any interfaces have been changed or removed. removal has ## precedence over adding, so set to 0 if both happened. -LT_AGE=7 +LT_AGE=8 AC_SUBST(LT_CURRENT) AC_SUBST(LT_REVISION) @@ -169,7 +169,6 @@ AC_ARG_WITH(console-owner-file, AS_HELP_STRING([--with-console-owner-file=[filen AC_ARG_WITH(launchd-agent-dir, AS_HELP_STRING([--with-launchd-agent-dir=[dirname]],[directory to put the launchd agent (default: /Library/LaunchAgents)])) AC_ARG_WITH(dbus_user, AS_HELP_STRING([--with-dbus-user=<user>],[User for running the DBUS daemon (messagebus)])) AC_ARG_WITH(dbus_daemondir, AS_HELP_STRING([--with-dbus-daemondir=[dirname]],[Directory for installing the DBUS daemon])) -AC_ARG_WITH(dbus_session_bus_default_address, AS_HELP_STRING([--with-dbus-session-bus-default-address=[nonce-tcp:/autolaunch:/tcp:host:port]],[Transport Type to be used (default: nonce-tcp:)]),with_dbus_session_bus_default_address=$withval,with_dbus_session_bus_default_address=nonce-tcp:) AC_ARG_ENABLE([embedded-tests], AS_HELP_STRING([--enable-embedded-tests], @@ -212,6 +211,9 @@ fi # default (unless you don't have GLib), because they don't bloat the library # or binaries. +AC_DEFINE([GLIB_VERSION_MIN_REQUIRED], [GLIB_VERSION_2_26], [Ignore post-2.26 deprecations]) +AC_DEFINE([GLIB_VERSION_MAX_ALLOWED], [GLIB_VERSION_2_26], [Prevent post-2.26 APIs]) + with_glib=yes if test "x$enable_modular_tests" != xno; then @@ -953,15 +955,53 @@ AC_SUBST([XML_CFLAGS]) AC_SUBST([XML_LIBS]) # Thread lib detection -AC_CHECK_FUNC(pthread_cond_timedwait,[AC_CHECK_LIB(pthread,pthread_cond_timedwait, - [THREAD_LIBS="-lpthread"])]) +AC_ARG_VAR([THREAD_LIBS]) save_libs="$LIBS" LIBS="$LIBS $THREAD_LIBS" -AC_CHECK_FUNC(pthread_condattr_setclock,have_pthread_condattr_setclock=true,have_pthread_condattr_setclock=false) -if test x$have_pthread_condattr_setclock = xtrue; then - AC_SEARCH_LIBS([clock_getres],[rt],[THREAD_LIBS="$THREAD_LIBS -lrt"]) - AC_MSG_CHECKING([for CLOCK_MONOTONIC]) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <time.h> + +is_missing_pthread_function="is required when compiling D-Bus on Unix platforms, but is not in your libc or libpthread. Please open a bug on https://bugs.freedesktop.org/enter_bug.cgi?product=dbus with details of your platform." + +# Don't do these automatic checks if the user set THREAD_LIBS on the +# configure command-line. If they did, we assume they're right. +# +# We also don't do these checks on Windows, because you don't need magical +# linker flags to have threading support there. +AS_IF([test "x$dbus_unix" = xyes && test "x$THREAD_LIBS" = x], + [ + # Mandatory pthread functions. In principle, some of these could be made + # optional if there are platforms that don't have them. + # + # Currently, we only look in -lpthread. + # In principle we might need to look in -lpthreads, -lthreads, ... + # as well - please file a bug if your platform needs this. + AC_SEARCH_LIBS([pthread_cond_timedwait], + [pthread], + [THREAD_LIBS="$LIBS"], + [AC_MSG_ERROR([pthread_cond_timedwait $is_missing_pthread_function])], + []) + AC_SEARCH_LIBS([pthread_mutexattr_init], + [pthread], + [THREAD_LIBS="$LIBS"], + [AC_MSG_ERROR([pthread_mutexattr_init $is_missing_pthread_function])], + []) + AC_SEARCH_LIBS([pthread_mutexattr_settype], + [pthread], + [THREAD_LIBS="$LIBS"], + [AC_MSG_ERROR([pthread_mutexattr_settype $is_missing_pthread_function])], + []) + + # Optional, for monotonic clocks. Because it's optional, this check + # is non-fatal if we don't find it. + AC_SEARCH_LIBS([pthread_condattr_setclock], + [pthread], + [THREAD_LIBS="$LIBS"]) + + AS_IF([test "x$ac_cv_search_pthread_condattr_setclock" != xno], + [ + AC_SEARCH_LIBS([clock_getres], [rt], [THREAD_LIBS="$LIBS"]) + AC_MSG_CHECKING([for CLOCK_MONOTONIC]) + AC_COMPILE_IFELSE([AC_LANG_PROGRAM( +[[#include <time.h> #include <pthread.h> ]], [[ struct timespec monotonic_timer; @@ -970,15 +1010,17 @@ pthread_condattr_init (&attr); pthread_condattr_setclock (&attr, CLOCK_MONOTONIC); clock_getres (CLOCK_MONOTONIC,&monotonic_timer); ]])], -[have_clock_monotonic=true], -[have_clock_monotonic=false]) -if test x$have_clock_monotonic = xtrue; then - AC_MSG_RESULT([found]) - AC_DEFINE(HAVE_MONOTONIC_CLOCK, 1, [Define if we have CLOCK_MONOTONIC]) -else - AC_MSG_RESULT([not found]) -fi -fi + [have_clock_monotonic=true], + [have_clock_monotonic=false]) + AS_IF([test x$have_clock_monotonic = xtrue], + [ + AC_MSG_RESULT([found]) + AC_DEFINE(HAVE_MONOTONIC_CLOCK, 1, [Define if we have CLOCK_MONOTONIC]) + ], + [AC_MSG_RESULT([not found])]) + ]) dnl have pthread_condattr_setclock + ]) dnl on Unix + LIBS="$save_libs" AC_SUBST([THREAD_LIBS]) @@ -1449,13 +1491,8 @@ fi AM_CONDITIONAL(DBUS_XML_DOCS_ENABLED, test x$enable_xml_docs = xyes) AC_MSG_RESULT($enable_xml_docs) -AC_PATH_PROG([MAN2HTML], [man2html]) -AC_ARG_VAR([MAN2HTML], [Path to man2html (optional)]) -AM_CONDITIONAL(DBUS_HAVE_MAN2HTML, test x$MAN2HTML != x) - AM_CONDITIONAL(DBUS_CAN_UPLOAD_DOCS, - test x$enable_doxygen_docs = xyes -a x$enable_xml_docs = xyes -a \ - x$MAN2HTML != x) + [test x$enable_doxygen_docs = xyes && test x$enable_xml_docs = xyes]) #### Have to go $localstatedir->$prefix/var->/usr/local/var @@ -1523,8 +1560,17 @@ fi AC_SUBST(DBUS_SYSTEM_SOCKET) AC_DEFINE_UNQUOTED(DBUS_SYSTEM_SOCKET,"$DBUS_SYSTEM_SOCKET",[The name of the socket the system bus listens on by default]) -## system bus only listens on local domain sockets, and never -## on an abstract socket (so only root can create the socket) +## System bus only listens on local domain sockets, and never +## on an abstract socket (so only root can create the socket). +## +## This won't work on Windows. It's not meant to - the system bus is +## meaningless on Windows anyway. +## +## This has to be suitable for hard-coding in client libraries as well as +## in the dbus-daemon's configuration, so it has to be valid to listen on +## and also to connect to. If this ever changes, it'll need to be split into +## two variables, one for the listening address and one for the connecting +## address. DBUS_SYSTEM_BUS_DEFAULT_ADDRESS="unix:path=$DBUS_SYSTEM_SOCKET" AC_SUBST(DBUS_SYSTEM_BUS_DEFAULT_ADDRESS) AC_DEFINE_UNQUOTED(DBUS_SYSTEM_BUS_DEFAULT_ADDRESS, "$DBUS_SYSTEM_BUS_DEFAULT_ADDRESS",[The default D-Bus address of the system bus]) @@ -1668,14 +1714,64 @@ fi AC_DEFINE_UNQUOTED(DBUS_SESSION_SOCKET_DIR, "$DBUS_SESSION_SOCKET_DIR", [Where per-session bus puts its sockets]) AC_SUBST(DBUS_SESSION_SOCKET_DIR) -if test x$dbus_win = xyes; then - DBUS_SESSION_BUS_DEFAULT_ADDRESS="$with_dbus_session_bus_default_address" +# This must be a listening address. It doesn't necessarily need to be an +# address you can connect to - it can be something vague like +# "nonce-tcp:". +# +# The default varies by platform. +AC_ARG_WITH([dbus_session_bus_listen_address], + AS_HELP_STRING([--with-dbus-session-bus-listen-address=[ADDRESS]], + [default address for a session bus to listen on (see configure.ac)]), + [with_dbus_session_bus_listen_address=$withval], + [with_dbus_session_bus_listen_address=]) + +if test "x$with_dbus_session_bus_listen_address" != "x"; then + # the user specified something, trust them + DBUS_SESSION_BUS_LISTEN_ADDRESS="$with_dbus_session_bus_listen_address" +elif test x$dbus_win = xyes; then + # On Windows, you can (and should) listen on autolaunch addresses, + # because autolaunching is different. + # See https://bugs.freedesktop.org/show_bug.cgi?id=38201 + DBUS_SESSION_BUS_LISTEN_ADDRESS="autolaunch:" elif test x$have_launchd = xyes; then - DBUS_SESSION_BUS_DEFAULT_ADDRESS="launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" + # Mac OS X default is to use launchd + DBUS_SESSION_BUS_LISTEN_ADDRESS="launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" +else + # The default on all other Unix platforms (notably Linux) + # is to create a randomly named socket in /tmp or similar + DBUS_SESSION_BUS_LISTEN_ADDRESS="unix:tmpdir=$DBUS_SESSION_SOCKET_DIR" +fi +AC_SUBST([DBUS_SESSION_BUS_LISTEN_ADDRESS]) + +# This must be an address you can connect to. It doesn't necessarily +# need to be an address you can listen on - it can be "autolaunch:", +# even on Unix. +# +# The default varies by platform. +AC_ARG_WITH([dbus_session_bus_connect_address], + AS_HELP_STRING([--with-dbus-session-bus-connect-address=[ADDRESS]], + [fallback address for a session bus client to connect to (see configure.ac)]), + [with_dbus_session_bus_connect_address=$withval], + [with_dbus_session_bus_connect_address=]) + +if test "x$with_dbus_session_bus_connect_address" != "x"; then + # the user specified something, trust them + DBUS_SESSION_BUS_CONNECT_ADDRESS="$with_dbus_session_bus_connect_address" +elif test x$dbus_win = xyes; then + # Windows autolaunching is a bit different; leaving it in its own + # branch of the conditional because the default might conceivably + # change (see #38201) + DBUS_SESSION_BUS_CONNECT_ADDRESS="autolaunch:" else - DBUS_SESSION_BUS_DEFAULT_ADDRESS="unix:tmpdir=$DBUS_SESSION_SOCKET_DIR" + # The default on all other Unix platforms (notably Linux) + # is to use auto-launching - this works a bit differently on Mac OS X + # but comes out basically the same in the end + DBUS_SESSION_BUS_CONNECT_ADDRESS="autolaunch:" fi -AC_SUBST(DBUS_SESSION_BUS_DEFAULT_ADDRESS) +AC_SUBST([DBUS_SESSION_BUS_CONNECT_ADDRESS]) +AC_DEFINE_UNQUOTED([DBUS_SESSION_BUS_CONNECT_ADDRESS], + ["$DBUS_SESSION_BUS_CONNECT_ADDRESS"], + [Fallback address for session bus clients]) # darwin needs this to initialize the environment AC_CHECK_HEADERS(crt_externs.h) @@ -1717,7 +1813,12 @@ tools/Makefile test/Makefile test/name-test/Makefile doc/Makefile -doc/dbus-daemon.1 +doc/dbus-cleanup-sockets.1.xml +doc/dbus-daemon.1.xml +doc/dbus-launch.1.xml +doc/dbus-monitor.1.xml +doc/dbus-send.1.xml +doc/dbus-uuidgen.1.xml dbus-1.pc dbus-1-uninstalled.pc test/data/valid-config-files/debug-allow-all.conf @@ -1762,8 +1863,7 @@ echo " 32-bit int: ${DBUS_INT32_TYPE} 16-bit int: ${DBUS_INT16_TYPE} Doxygen: ${DOXYGEN:-not found} - xmlto: ${XMLTO:-not found} - man2html: ${MAN2HTML:-not found}" + xmlto: ${XMLTO:-not found}" echo " Rebuilding generated files: ${USE_MAINTAINER_MODE} @@ -1791,7 +1891,8 @@ echo " System bus socket: ${DBUS_SYSTEM_SOCKET} System bus address: ${DBUS_SYSTEM_BUS_DEFAULT_ADDRESS} System bus PID file: ${DBUS_SYSTEM_PID_FILE} - Session bus address: ${DBUS_SESSION_BUS_DEFAULT_ADDRESS} + Session bus listens on: ${DBUS_SESSION_BUS_LISTEN_ADDRESS} + Session clients connect to: ${DBUS_SESSION_BUS_CONNECT_ADDRESS} Console auth dir: ${DBUS_CONSOLE_AUTH_DIR} Console owner file: ${have_console_owner_file} Console owner file path: ${DBUS_CONSOLE_OWNER_FILE} diff --git a/dbus/Makefile.am b/dbus/Makefile.am index bb5cccaf..3679e3f9 100644 --- a/dbus/Makefile.am +++ b/dbus/Makefile.am @@ -308,5 +308,5 @@ clean-local: /bin/rm *.bb *.bbg *.da *.gcov .libs/*.da .libs/*.bbg || true update-systemd: - curl http://cgit.freedesktop.org/systemd/plain/src/sd-daemon.c > sd-daemon.c - curl http://cgit.freedesktop.org/systemd/plain/src/sd-daemon.h > sd-daemon.h + curl http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-daemon/sd-daemon.c > $(srcdir)/sd-daemon.c + curl http://cgit.freedesktop.org/systemd/systemd/plain/src/systemd/sd-daemon.h > $(srcdir)/sd-daemon.h diff --git a/dbus/Makefile.in b/dbus/Makefile.in index d8448a3f..322914d2 100644 --- a/dbus/Makefile.in +++ b/dbus/Makefile.in @@ -415,7 +415,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -474,7 +475,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ @@ -2304,8 +2304,8 @@ clean-local: /bin/rm *.bb *.bbg *.da *.gcov .libs/*.da .libs/*.bbg || true update-systemd: - curl http://cgit.freedesktop.org/systemd/plain/src/sd-daemon.c > sd-daemon.c - curl http://cgit.freedesktop.org/systemd/plain/src/sd-daemon.h > sd-daemon.h + curl http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-daemon/sd-daemon.c > $(srcdir)/sd-daemon.c + curl http://cgit.freedesktop.org/systemd/systemd/plain/src/systemd/sd-daemon.h > $(srcdir)/sd-daemon.h # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. diff --git a/dbus/dbus-bus.c b/dbus/dbus-bus.c index fadc3a8b..6f81c74a 100644 --- a/dbus/dbus-bus.c +++ b/dbus/dbus-bus.c @@ -192,12 +192,12 @@ init_session_address (void) if (!retval) return FALSE; - /* The DBUS_SESSION_BUS_DEFAULT_ADDRESS should have really been named - * DBUS_SESSION_BUS_FALLBACK_ADDRESS. - */ + /* We have a hard-coded (but compile-time-configurable) fallback address for + * the session bus. */ if (bus_connection_addresses[DBUS_BUS_SESSION] == NULL) bus_connection_addresses[DBUS_BUS_SESSION] = - _dbus_strdup (DBUS_SESSION_BUS_DEFAULT_ADDRESS); + _dbus_strdup (DBUS_SESSION_BUS_CONNECT_ADDRESS); + if (bus_connection_addresses[DBUS_BUS_SESSION] == NULL) return FALSE; diff --git a/dbus/dbus-internals.h b/dbus/dbus-internals.h index 8036a2ba..80376ad5 100644 --- a/dbus/dbus-internals.h +++ b/dbus/dbus-internals.h @@ -35,10 +35,6 @@ DBUS_BEGIN_DECLS -#ifndef DBUS_SESSION_BUS_DEFAULT_ADDRESS -#define DBUS_SESSION_BUS_DEFAULT_ADDRESS "autolaunch:" -#endif - void _dbus_warn (const char *format, ...) _DBUS_GNUC_PRINTF (1, 2); diff --git a/dbus/dbus-mempool.c b/dbus/dbus-mempool.c index 33aabf9c..0c3f117d 100644 --- a/dbus/dbus-mempool.c +++ b/dbus/dbus-mempool.c @@ -173,7 +173,7 @@ _dbus_mem_pool_new (int element_size, _dbus_assert ((pool->block_size % pool->element_size) == 0); - VALGRIND_CREATE_MEMPOOL (pool, 0, zero_elements) + VALGRIND_CREATE_MEMPOOL (pool, 0, zero_elements); return pool; } @@ -188,7 +188,7 @@ _dbus_mem_pool_free (DBusMemPool *pool) { DBusMemBlock *block; - VALGRIND_DESTROY_MEMPOOL (pool) + VALGRIND_DESTROY_MEMPOOL (pool); block = pool->blocks; while (block != NULL) @@ -241,7 +241,7 @@ _dbus_mem_pool_alloc (DBusMemPool *pool) pool->allocated_elements += 1; VALGRIND_MEMPOOL_ALLOC (pool, (void *) &block->elements[0], - pool->element_size) + pool->element_size); return (void*) &block->elements[0]; } else @@ -261,7 +261,7 @@ _dbus_mem_pool_alloc (DBusMemPool *pool) pool->free_elements = pool->free_elements->next; - VALGRIND_MEMPOOL_ALLOC (pool, element, pool->element_size) + VALGRIND_MEMPOOL_ALLOC (pool, element, pool->element_size); if (pool->zero_elements) memset (element, '\0', pool->element_size); @@ -329,7 +329,7 @@ _dbus_mem_pool_alloc (DBusMemPool *pool) pool->allocated_elements += 1; - VALGRIND_MEMPOOL_ALLOC (pool, element, pool->element_size) + VALGRIND_MEMPOOL_ALLOC (pool, element, pool->element_size); return element; } } @@ -347,7 +347,7 @@ dbus_bool_t _dbus_mem_pool_dealloc (DBusMemPool *pool, void *element) { - VALGRIND_MEMPOOL_FREE (pool, element) + VALGRIND_MEMPOOL_FREE (pool, element); #ifdef DBUS_BUILD_TESTS if (_dbus_disable_mem_pools ()) diff --git a/dbus/dbus-server-unix.c b/dbus/dbus-server-unix.c index 130f66ec..d9952404 100644 --- a/dbus/dbus-server-unix.c +++ b/dbus/dbus-server-unix.c @@ -149,7 +149,7 @@ _dbus_server_listen_platform_specific (DBusAddressEntry *entry, } else if (strcmp (method, "systemd") == 0) { - int n, *fds; + int i, n, *fds; DBusString address; n = _dbus_listen_systemd_sockets (&fds, error); @@ -159,27 +159,39 @@ _dbus_server_listen_platform_specific (DBusAddressEntry *entry, return DBUS_SERVER_LISTEN_DID_NOT_CONNECT; } - _dbus_string_init_const (&address, "systemd:"); + if (!_dbus_string_init (&address)) + goto systemd_oom; - *server_p = _dbus_server_new_for_socket (fds, n, &address, NULL); - if (*server_p == NULL) + for (i = 0; i < n; i++) { - int i; - - for (i = 0; i < n; i++) + if (i > 0) { - _dbus_close_socket (fds[i], NULL); + if (!_dbus_string_append (&address, ";")) + goto systemd_oom; } - dbus_free (fds); - - dbus_set_error (error, DBUS_ERROR_NO_MEMORY, NULL); - return DBUS_SERVER_LISTEN_DID_NOT_CONNECT; + if (!_dbus_append_address_from_socket (fds[i], &address, error)) + goto systemd_err; } + *server_p = _dbus_server_new_for_socket (fds, n, &address, NULL); + if (*server_p == NULL) + goto systemd_oom; + dbus_free (fds); return DBUS_SERVER_LISTEN_OK; - } + systemd_oom: + _DBUS_SET_OOM (error); + systemd_err: + for (i = 0; i < n; i++) + { + _dbus_close_socket (fds[i], NULL); + } + dbus_free (fds); + _dbus_string_free (&address); + + return DBUS_SERVER_LISTEN_DID_NOT_CONNECT; + } #ifdef DBUS_ENABLE_LAUNCHD else if (strcmp (method, "launchd") == 0) { diff --git a/dbus/dbus-spawn.c b/dbus/dbus-spawn.c index ef00801c..55a7e1e6 100644 --- a/dbus/dbus-spawn.c +++ b/dbus/dbus-spawn.c @@ -1256,7 +1256,11 @@ _dbus_spawn_async_with_babysitter (DBusBabysitter **sitter_p, _dbus_assert_not_reached ("Got to code after write_err_and_exit()"); } else if (grandchild_pid == 0) - { + { + /* Go back to ignoring SIGPIPE, since it's evil + */ + signal (SIGPIPE, SIG_IGN); + do_exec (child_err_report_pipe[WRITE_END], argv, env, diff --git a/dbus/dbus-sysdeps-pthread.c b/dbus/dbus-sysdeps-pthread.c index c60457be..439c9c62 100644 --- a/dbus/dbus-sysdeps-pthread.c +++ b/dbus/dbus-sysdeps-pthread.c @@ -36,12 +36,14 @@ #include <config.h> +#ifdef HAVE_MONOTONIC_CLOCK /* Whether we have a "monotonic" clock; i.e. a clock not affected by * changes in system time. * This is initialized once in check_monotonic_clock below. * https://bugs.freedesktop.org/show_bug.cgi?id=18121 */ static dbus_bool_t have_monotonic_clock = 0; +#endif struct DBusRMutex { pthread_mutex_t lock; /**< the lock */ diff --git a/dbus/dbus-sysdeps-unix.c b/dbus/dbus-sysdeps-unix.c index b4ecc96e..a0310592 100644 --- a/dbus/dbus-sysdeps-unix.c +++ b/dbus/dbus-sysdeps-unix.c @@ -55,6 +55,7 @@ #include <netinet/in.h> #include <netdb.h> #include <grp.h> +#include <arpa/inet.h> #ifdef HAVE_ERRNO_H #include <errno.h> @@ -3299,15 +3300,12 @@ _read_subprocess_line_argv (const char *progpath, /* set-up stdXXX */ close (result_pipe[READ_END]); close (errors_pipe[READ_END]); - close (0); /* close stdin */ - close (1); /* close stdout */ - close (2); /* close stderr */ - if (dup2 (fd, 0) == -1) + if (dup2 (fd, 0) == -1) /* setup stdin */ _exit (1); - if (dup2 (result_pipe[WRITE_END], 1) == -1) + if (dup2 (result_pipe[WRITE_END], 1) == -1) /* setup stdout */ _exit (1); - if (dup2 (errors_pipe[WRITE_END], 2) == -1) + if (dup2 (errors_pipe[WRITE_END], 2) == -1) /* setup stderr */ _exit (1); _dbus_close_all (); @@ -4160,4 +4158,71 @@ _dbus_check_setuid (void) #endif } +/** + * Read the address from the socket and append it to the string + * + * @param fd the socket + * @param address + * @param error return location for error code + */ +dbus_bool_t +_dbus_append_address_from_socket (int fd, + DBusString *address, + DBusError *error) +{ + union { + struct sockaddr sa; + struct sockaddr_storage storage; + struct sockaddr_un un; + struct sockaddr_in ipv4; + struct sockaddr_in6 ipv6; + } socket; + char hostip[INET6_ADDRSTRLEN]; + int size = sizeof (socket); + + if (getsockname (fd, &socket.sa, &size)) + goto err; + + switch (socket.sa.sa_family) + { + case AF_UNIX: + if (socket.un.sun_path[0]=='\0') + { + if (_dbus_string_append_printf (address, "unix:abstract=%s", &(socket.un.sun_path[1]))) + return TRUE; + } + else + { + if (_dbus_string_append_printf (address, "unix:path=%s", socket.un.sun_path)) + return TRUE; + } + break; + case AF_INET: + if (inet_ntop (AF_INET, &socket.ipv4.sin_addr, hostip, sizeof (hostip))) + if (_dbus_string_append_printf (address, "tcp:family=ipv4,host=%s,port=%u", + hostip, ntohs (socket.ipv4.sin_port))) + return TRUE; + break; +#ifdef AF_INET6 + case AF_INET6: + if (inet_ntop (AF_INET6, &socket.ipv6.sin6_addr, hostip, sizeof (hostip))) + if (_dbus_string_append_printf (address, "tcp:family=ipv6,host=%s,port=%u", + hostip, ntohs (socket.ipv6.sin6_port))) + return TRUE; + break; +#endif + default: + dbus_set_error (error, + _dbus_error_from_errno (EINVAL), + "Failed to read address from socket: Unknown socket type."); + return FALSE; + } + err: + dbus_set_error (error, + _dbus_error_from_errno (errno), + "Failed to open socket: %s", + _dbus_strerror (errno)); + return FALSE; +} + /* tests in dbus-sysdeps-util.c */ diff --git a/dbus/dbus-sysdeps-unix.h b/dbus/dbus-sysdeps-unix.h index 9b708967..a265b335 100644 --- a/dbus/dbus-sysdeps-unix.h +++ b/dbus/dbus-sysdeps-unix.h @@ -138,6 +138,10 @@ dbus_bool_t _dbus_parse_uid (const DBusString *uid_str, void _dbus_close_all (void); +dbus_bool_t _dbus_append_address_from_socket (int fd, + DBusString *address, + DBusError *error); + /** @} */ DBUS_END_DECLS diff --git a/dbus/dbus-sysdeps-util-unix.c b/dbus/dbus-sysdeps-util-unix.c index 76423ab8..7beab209 100644 --- a/dbus/dbus-sysdeps-util-unix.c +++ b/dbus/dbus-sysdeps-util-unix.c @@ -49,7 +49,10 @@ #include <sys/socket.h> #include <dirent.h> #include <sys/un.h> + +#ifdef HAVE_SYSLOG_H #include <syslog.h> +#endif #ifdef HAVE_SYS_SYSLIMITS_H #include <sys/syslimits.h> @@ -123,6 +126,7 @@ _dbus_become_daemon (const DBusString *pidfile, dup2 (dev_null_fd, 2); else _dbus_verbose ("keeping stderr open due to DBUS_DEBUG_OUTPUT\n"); + close (dev_null_fd); } if (!keep_umask) @@ -424,11 +428,15 @@ _dbus_request_file_descriptor_limit (unsigned int limit) void _dbus_init_system_log (void) { +#ifdef HAVE_SYSLOG_H + #if HAVE_DECL_LOG_PERROR openlog ("dbus", LOG_PID | LOG_PERROR, LOG_DAEMON); #else openlog ("dbus", LOG_PID, LOG_DAEMON); #endif + +#endif } /** @@ -464,6 +472,7 @@ _dbus_system_log (DBusSystemLogSeverity severity, const char *msg, ...) void _dbus_system_logv (DBusSystemLogSeverity severity, const char *msg, va_list args) { +#ifdef HAVE_SYSLOG_H int flags; switch (severity) { @@ -480,7 +489,10 @@ _dbus_system_logv (DBusSystemLogSeverity severity, const char *msg, va_list args return; } -#ifndef HAVE_DECL_LOG_PERROR + vsyslog (flags, msg, args); +#endif + +#if !defined(HAVE_SYSLOG_H) || !HAVE_DECL_LOG_PERROR { /* vsyslog() won't write to stderr, so we'd better do it */ va_list tmp; @@ -493,8 +505,6 @@ _dbus_system_logv (DBusSystemLogSeverity severity, const char *msg, va_list args } #endif - vsyslog (flags, msg, args); - if (severity == DBUS_SYSTEM_LOG_FATAL) exit (1); } diff --git a/dbus/dbus-sysdeps-win.c b/dbus/dbus-sysdeps-win.c index bc4951b5..5a2fb209 100644 --- a/dbus/dbus-sysdeps-win.c +++ b/dbus/dbus-sysdeps-win.c @@ -3121,8 +3121,18 @@ _dbus_atomic_dec (DBusAtomic *atomic) dbus_int32_t _dbus_atomic_get (DBusAtomic *atomic) { - /* this is what GLib does, hopefully it's right... */ - MemoryBarrier (); + /* In this situation, GLib issues a MemoryBarrier() and then returns + * atomic->value. However, mingw from mingw.org (not to be confused with + * mingw-w64 from mingw-w64.sf.net) does not have MemoryBarrier in its + * headers, so we have to get a memory barrier some other way. + * + * InterlockedIncrement is older, and is documented on MSDN to be a full + * memory barrier, so let's use that. + */ + long dummy = 0; + + InterlockedExchange (&dummy, 1); + return atomic->value; } diff --git a/dbus/dbus-sysdeps.h b/dbus/dbus-sysdeps.h index eee91608..f4b0ac97 100644 --- a/dbus/dbus-sysdeps.h +++ b/dbus/dbus-sysdeps.h @@ -278,6 +278,19 @@ dbus_int32_t _dbus_atomic_get (DBusAtomic *atomic); #define _DBUS_POLLHUP 0x0080 /** Invalid request: fd not open */ #define _DBUS_POLLNVAL 0x1000 +#elif defined(__QNX__) +/** Writing now will not block */ +#define _DBUS_POLLOUT 0x0002 +/** There is data to read */ +#define _DBUS_POLLIN 0x0005 +/** There is urgent data to read */ +#define _DBUS_POLLPRI 0x0008 +/** Error condition */ +#define _DBUS_POLLERR 0x0020 +/** Hung up */ +#define _DBUS_POLLHUP 0x0040 +/** Invalid request: fd not open */ +#define _DBUS_POLLNVAL 0x1000 #else /** There is data to read */ #define _DBUS_POLLIN 0x0001 diff --git a/dbus/dbus-valgrind-internal.h b/dbus/dbus-valgrind-internal.h index 55566ec0..6760b40d 100644 --- a/dbus/dbus-valgrind-internal.h +++ b/dbus/dbus-valgrind-internal.h @@ -32,10 +32,10 @@ # include <memcheck.h> # include <valgrind.h> #else -# define VALGRIND_CREATE_MEMPOOL(_1, _2, _3) /* nothing */ -# define VALGRIND_DESTROY_MEMPOOL(_1) /* nothing */ -# define VALGRIND_MEMPOOL_ALLOC(_1, _2, _3) /* nothing */ -# define VALGRIND_MEMPOOL_FREE(_1, _2) /* nothing */ +# define VALGRIND_CREATE_MEMPOOL(_1, _2, _3) do { } while (0) +# define VALGRIND_DESTROY_MEMPOOL(_1) do { } while (0) +# define VALGRIND_MEMPOOL_ALLOC(_1, _2, _3) do { } while (0) +# define VALGRIND_MEMPOOL_FREE(_1, _2) do { } while (0) /* Recent gcc will warn if you have a statement that's just a macro * expanding to (0), but not if you have an inline stub function that diff --git a/dbus/sd-daemon.c b/dbus/sd-daemon.c index 9c23b917..80aadf7a 100644 --- a/dbus/sd-daemon.c +++ b/dbus/sd-daemon.c @@ -32,7 +32,11 @@ #include <sys/stat.h> #include <sys/socket.h> #include <sys/un.h> +#ifdef __BIONIC__ +#include <linux/fcntl.h> +#else #include <sys/fcntl.h> +#endif #include <netinet/in.h> #include <stdlib.h> #include <errno.h> @@ -40,10 +44,28 @@ #include <string.h> #include <stdarg.h> #include <stdio.h> +#include <stddef.h> +#include <limits.h> + +#if defined(__linux__) +#include <mqueue.h> +#endif #include "sd-daemon.h" -int sd_listen_fds(int unset_environment) { +#if (__GNUC__ >= 4) +#ifdef SD_EXPORT_SYMBOLS +/* Export symbols */ +#define _sd_export_ __attribute__ ((visibility("default"))) +#else +/* Don't export the symbols */ +#define _sd_export_ __attribute__ ((visibility("hidden"))) +#endif +#else +#define _sd_export_ +#endif + +_sd_export_ int sd_listen_fds(int unset_environment) { #if defined(DISABLE_SYSTEMD) || !defined(__linux__) return 0; @@ -53,7 +75,8 @@ int sd_listen_fds(int unset_environment) { char *p = NULL; unsigned long l; - if (!(e = getenv("LISTEN_PID"))) { + e = getenv("LISTEN_PID"); + if (!e) { r = 0; goto finish; } @@ -66,7 +89,7 @@ int sd_listen_fds(int unset_environment) { goto finish; } - if (!p || *p || l <= 0) { + if (!p || p == e || *p || l <= 0) { r = -EINVAL; goto finish; } @@ -77,7 +100,8 @@ int sd_listen_fds(int unset_environment) { goto finish; } - if (!(e = getenv("LISTEN_FDS"))) { + e = getenv("LISTEN_FDS"); + if (!e) { r = 0; goto finish; } @@ -90,7 +114,7 @@ int sd_listen_fds(int unset_environment) { goto finish; } - if (!p || *p) { + if (!p || p == e || *p) { r = -EINVAL; goto finish; } @@ -98,7 +122,8 @@ int sd_listen_fds(int unset_environment) { for (fd = SD_LISTEN_FDS_START; fd < SD_LISTEN_FDS_START + (int) l; fd ++) { int flags; - if ((flags = fcntl(fd, F_GETFD)) < 0) { + flags = fcntl(fd, F_GETFD); + if (flags < 0) { r = -errno; goto finish; } @@ -124,13 +149,12 @@ finish: #endif } -int sd_is_fifo(int fd, const char *path) { +_sd_export_ int sd_is_fifo(int fd, const char *path) { struct stat st_fd; if (fd < 0) return -EINVAL; - memset(&st_fd, 0, sizeof(st_fd)); if (fstat(fd, &st_fd) < 0) return -errno; @@ -140,7 +164,6 @@ int sd_is_fifo(int fd, const char *path) { if (path) { struct stat st_path; - memset(&st_path, 0, sizeof(st_path)); if (stat(path, &st_path) < 0) { if (errno == ENOENT || errno == ENOTDIR) @@ -157,6 +180,42 @@ int sd_is_fifo(int fd, const char *path) { return 1; } +_sd_export_ int sd_is_special(int fd, const char *path) { + struct stat st_fd; + + if (fd < 0) + return -EINVAL; + + if (fstat(fd, &st_fd) < 0) + return -errno; + + if (!S_ISREG(st_fd.st_mode) && !S_ISCHR(st_fd.st_mode)) + return 0; + + if (path) { + struct stat st_path; + + if (stat(path, &st_path) < 0) { + + if (errno == ENOENT || errno == ENOTDIR) + return 0; + + return -errno; + } + + if (S_ISREG(st_fd.st_mode) && S_ISREG(st_path.st_mode)) + return + st_path.st_dev == st_fd.st_dev && + st_path.st_ino == st_fd.st_ino; + else if (S_ISCHR(st_fd.st_mode) && S_ISCHR(st_path.st_mode)) + return st_path.st_rdev == st_fd.st_rdev; + else + return 0; + } + + return 1; +} + static int sd_is_socket_internal(int fd, int type, int listening) { struct stat st_fd; @@ -208,13 +267,14 @@ union sockaddr_union { struct sockaddr_storage storage; }; -int sd_is_socket(int fd, int family, int type, int listening) { +_sd_export_ int sd_is_socket(int fd, int family, int type, int listening) { int r; if (family < 0) return -EINVAL; - if ((r = sd_is_socket_internal(fd, type, listening)) <= 0) + r = sd_is_socket_internal(fd, type, listening); + if (r <= 0) return r; if (family > 0) { @@ -236,7 +296,7 @@ int sd_is_socket(int fd, int family, int type, int listening) { return 1; } -int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port) { +_sd_export_ int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port) { union sockaddr_union sockaddr; socklen_t l; int r; @@ -244,7 +304,8 @@ int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port if (family != 0 && family != AF_INET && family != AF_INET6) return -EINVAL; - if ((r = sd_is_socket_internal(fd, type, listening)) <= 0) + r = sd_is_socket_internal(fd, type, listening); + if (r <= 0) return r; memset(&sockaddr, 0, sizeof(sockaddr)); @@ -281,12 +342,13 @@ int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port return 1; } -int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t length) { +_sd_export_ int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t length) { union sockaddr_union sockaddr; socklen_t l; int r; - if ((r = sd_is_socket_internal(fd, type, listening)) <= 0) + r = sd_is_socket_internal(fd, type, listening); + if (r <= 0) return r; memset(&sockaddr, 0, sizeof(sockaddr)); @@ -302,29 +364,66 @@ int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t return 0; if (path) { - if (length <= 0) + if (length == 0) length = strlen(path); - if (length <= 0) + if (length == 0) /* Unnamed socket */ - return l == sizeof(sa_family_t); + return l == offsetof(struct sockaddr_un, sun_path); if (path[0]) /* Normal path socket */ return - (l >= sizeof(sa_family_t) + length + 1) && + (l >= offsetof(struct sockaddr_un, sun_path) + length + 1) && memcmp(path, sockaddr.un.sun_path, length+1) == 0; else /* Abstract namespace socket */ return - (l == sizeof(sa_family_t) + length) && + (l == offsetof(struct sockaddr_un, sun_path) + length) && memcmp(path, sockaddr.un.sun_path, length) == 0; } return 1; } -int sd_notify(int unset_environment, const char *state) { +_sd_export_ int sd_is_mq(int fd, const char *path) { +#if !defined(__linux__) + return 0; +#else + struct mq_attr attr; + + if (fd < 0) + return -EINVAL; + + if (mq_getattr(fd, &attr) < 0) + return -errno; + + if (path) { + char fpath[PATH_MAX]; + struct stat a, b; + + if (path[0] != '/') + return -EINVAL; + + if (fstat(fd, &a) < 0) + return -errno; + + strncpy(stpcpy(fpath, "/dev/mqueue"), path, sizeof(fpath) - 12); + fpath[sizeof(fpath)-1] = 0; + + if (stat(fpath, &b) < 0) + return -errno; + + if (a.st_dev != b.st_dev || + a.st_ino != b.st_ino) + return 0; + } + + return 1; +#endif +} + +_sd_export_ int sd_notify(int unset_environment, const char *state) { #if defined(DISABLE_SYSTEMD) || !defined(__linux__) || !defined(SOCK_CLOEXEC) return 0; #else @@ -339,7 +438,8 @@ int sd_notify(int unset_environment, const char *state) { goto finish; } - if (!(e = getenv("NOTIFY_SOCKET"))) + e = getenv("NOTIFY_SOCKET"); + if (!e) return 0; /* Must be an abstract socket, or an absolute path */ @@ -348,7 +448,8 @@ int sd_notify(int unset_environment, const char *state) { goto finish; } - if ((fd = socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0)) < 0) { + fd = socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0); + if (fd < 0) { r = -errno; goto finish; } @@ -366,7 +467,7 @@ int sd_notify(int unset_environment, const char *state) { memset(&msghdr, 0, sizeof(msghdr)); msghdr.msg_name = &sockaddr; - msghdr.msg_namelen = sizeof(sa_family_t) + strlen(e); + msghdr.msg_namelen = offsetof(struct sockaddr_un, sun_path) + strlen(e); if (msghdr.msg_namelen > sizeof(struct sockaddr_un)) msghdr.msg_namelen = sizeof(struct sockaddr_un); @@ -392,7 +493,7 @@ finish: #endif } -int sd_notifyf(int unset_environment, const char *format, ...) { +_sd_export_ int sd_notifyf(int unset_environment, const char *format, ...) { #if defined(DISABLE_SYSTEMD) || !defined(__linux__) return 0; #else @@ -414,7 +515,7 @@ int sd_notifyf(int unset_environment, const char *format, ...) { #endif } -int sd_booted(void) { +_sd_export_ int sd_booted(void) { #if defined(DISABLE_SYSTEMD) || !defined(__linux__) return 0; #else diff --git a/dbus/sd-daemon.h b/dbus/sd-daemon.h index c68c96d2..fb7456d5 100644 --- a/dbus/sd-daemon.h +++ b/dbus/sd-daemon.h @@ -58,21 +58,21 @@ extern "C" { You may find an up-to-date version of these source files online: - http://cgit.freedesktop.org/systemd/plain/src/sd-daemon.h - http://cgit.freedesktop.org/systemd/plain/src/sd-daemon.c + http://cgit.freedesktop.org/systemd/systemd/plain/src/systemd/sd-daemon.h + http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-daemon/sd-daemon.c This should compile on non-Linux systems, too, but with the exception of the sd_is_xxx() calls all functions will become NOPs. - See sd-daemon(7) for more information. + See sd-daemon(3) for more information. */ +#ifndef _sd_printf_attr_ #if __GNUC__ >= 4 #define _sd_printf_attr_(a,b) __attribute__ ((format (printf, a, b))) -#define _sd_hidden_ __attribute__ ((visibility("hidden"))) #else #define _sd_printf_attr_(a,b) -#define _sd_hidden_ +#endif #endif /* @@ -109,7 +109,7 @@ extern "C" { See sd_listen_fds(3) for more information. */ -int sd_listen_fds(int unset_environment) _sd_hidden_; +int sd_listen_fds(int unset_environment); /* Helper call for identifying a passed file descriptor. Returns 1 if @@ -121,7 +121,19 @@ int sd_listen_fds(int unset_environment) _sd_hidden_; See sd_is_fifo(3) for more information. */ -int sd_is_fifo(int fd, const char *path) _sd_hidden_; +int sd_is_fifo(int fd, const char *path); + +/* + Helper call for identifying a passed file descriptor. Returns 1 if + the file descriptor is a special character device on the file + system stored under the specified path, 0 otherwise. + If path is NULL a path name check will not be done and the call + only verifies if the file descriptor refers to a special character. + Returns a negative errno style error code on failure. + + See sd_is_special(3) for more information. +*/ +int sd_is_special(int fd, const char *path); /* Helper call for identifying a passed file descriptor. Returns 1 if @@ -137,7 +149,7 @@ int sd_is_fifo(int fd, const char *path) _sd_hidden_; See sd_is_socket(3) for more information. */ -int sd_is_socket(int fd, int family, int type, int listening) _sd_hidden_; +int sd_is_socket(int fd, int family, int type, int listening); /* Helper call for identifying a passed file descriptor. Returns 1 if @@ -151,7 +163,7 @@ int sd_is_socket(int fd, int family, int type, int listening) _sd_hidden_; See sd_is_socket_inet(3) for more information. */ -int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port) _sd_hidden_; +int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port); /* Helper call for identifying a passed file descriptor. Returns 1 if @@ -167,17 +179,25 @@ int sd_is_socket_inet(int fd, int family, int type, int listening, uint16_t port See sd_is_socket_unix(3) for more information. */ -int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t length) _sd_hidden_; +int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t length); + +/* + Helper call for identifying a passed file descriptor. Returns 1 if + the file descriptor is a POSIX Message Queue of the specified name, + 0 otherwise. If path is NULL a message queue name check is not + done. Returns a negative errno style error code on failure. +*/ +int sd_is_mq(int fd, const char *path); /* Informs systemd about changed daemon state. This takes a number of - newline seperated environment-style variable assignments in a + newline separated environment-style variable assignments in a string. The following variables are known: READY=1 Tells systemd that daemon startup is finished (only relevant for services of Type=notify). The passed argument is a boolean "1" or "0". Since there is - little value in signalling non-readiness the only + little value in signaling non-readiness the only value daemons should send is "READY=1". STATUS=... Passes a single-line status string back to systemd @@ -197,8 +217,13 @@ int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t MAINPID=... The main pid of a daemon, in case systemd did not fork off the process itself. Example: "MAINPID=4711" + WATCHDOG=1 Tells systemd to update the watchdog timestamp. + Services using this feature should do this in + regular intervals. A watchdog framework can use the + timestamps to detect failed services. + Daemons can choose to send additional variables. However, it is - recommened to prefix variable names not listed above with X_. + recommended to prefix variable names not listed above with X_. Returns a negative errno-style error code on failure. Returns > 0 if systemd could be notified, 0 if it couldn't possibly because @@ -213,7 +238,7 @@ int sd_is_socket_unix(int fd, int type, int listening, const char *path, size_t See sd_notify(3) for more information. */ -int sd_notify(int unset_environment, const char *state) _sd_hidden_; +int sd_notify(int unset_environment, const char *state); /* Similar to sd_notify() but takes a format string. @@ -235,7 +260,7 @@ int sd_notify(int unset_environment, const char *state) _sd_hidden_; See sd_notifyf(3) for more information. */ -int sd_notifyf(int unset_environment, const char *format, ...) _sd_printf_attr_(2,3) _sd_hidden_; +int sd_notifyf(int unset_environment, const char *format, ...) _sd_printf_attr_(2,3); /* Returns > 0 if the system was booted with systemd. Returns < 0 on @@ -244,11 +269,11 @@ int sd_notifyf(int unset_environment, const char *format, ...) _sd_printf_attr_( fine. You should NOT protect them with a call to this function. Also note that this function checks whether the system, not the user session is controlled by systemd. However the functions above work - for both session and system services. + for both user and system services. See sd_booted(3) for more information. */ -int sd_booted(void) _sd_hidden_; +int sd_booted(void); #ifdef __cplusplus } diff --git a/doc/Makefile.am b/doc/Makefile.am index b2659871..35725696 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,20 +1,23 @@ apidir = @htmldir@/api -# automake normally assumes that man pages are generated files; -# these ones aren't, so we need the dist_ prefix to say that they're -# their own source code -dist_man1_MANS = \ +MAN_XML_FILES = \ + dbus-cleanup-sockets.1.xml \ + dbus-daemon.1.xml \ + dbus-launch.1.xml \ + dbus-monitor.1.xml \ + dbus-send.1.xml \ + dbus-uuidgen.1.xml \ + $(NULL) + +if DBUS_XML_DOCS_ENABLED +man1_MANS = \ dbus-cleanup-sockets.1 \ + dbus-daemon.1 \ dbus-launch.1 \ dbus-monitor.1 \ dbus-send.1 \ dbus-uuidgen.1 - -# on the other hand, this one is generated -man1_MANS = \ - dbus-daemon.1 - -MAN_IN_FILES = dbus-daemon.1.in +endif MAN_HTML_FILES = \ dbus-cleanup-sockets.1.html \ @@ -43,8 +46,7 @@ STATIC_DOCS = \ EXTRA_DIST = \ file-boilerplate.c \ doxygen_to_devhelp.xsl \ - $(STATIC_DOCS) \ - $(MAN_IN_FILES) + $(STATIC_DOCS) html_DATA = @@ -59,27 +61,22 @@ STATIC_HTML = \ dist_html_DATA += $(STATIC_HTML) -# we distribute these in the tarball so users don't necessarily need xmlto -dist_html_DATA += $(XMLTO_OUTPUT) - -XMLTO_OUTPUT= \ +XMLTO_HTML = \ dbus-faq.html \ dbus-specification.html \ dbus-test-plan.html \ - dbus-tutorial.html + dbus-tutorial.html \ + $(MAN_HTML_FILES) \ + $(NULL) if DBUS_XML_DOCS_ENABLED -dbus-specification.html: dbus-specification.xml - $(XMLTO) html-nochunks $< - -dbus-test-plan.html: dbus-test-plan.xml - $(XMLTO) html-nochunks $< +html_DATA += $(XMLTO_HTML) -dbus-tutorial.html: dbus-tutorial.xml +%.html: %.xml $(XMLTO) html-nochunks $< -dbus-faq.html: dbus-faq.xml - $(XMLTO) html-nochunks $< +%.1: %.1.xml + $(XMLTO) man $< endif if DBUS_DOXYGEN_DOCS_ENABLED @@ -115,13 +112,6 @@ uninstall-local:: rmdir $(DESTDIR)$(apidir) endif -if DBUS_HAVE_MAN2HTML -html_DATA += $(MAN_HTML_FILES) - -%.1.html: %.1 - $(AM_V_GEN)( $(MAN2HTML) < $< > $@.tmp && mv $@.tmp $@ ) -endif - if DBUS_CAN_UPLOAD_DOCS BONUS_FILES = \ $(top_srcdir)/README \ @@ -131,14 +121,15 @@ BONUS_FILES = \ $(top_srcdir)/COPYING \ $(top_srcdir)/ChangeLog -dbus-docs: $(STATIC_DOCS) $(dist_doc_DATA) $(dist_html_DATA) $(MAN_HTML_FILES) $(BONUS_FILES) doxygen.stamp +dbus-docs: $(STATIC_DOCS) $(MAN_XML_FILES) $(dist_doc_DATA) $(dist_html_DATA) $(MAN_HTML_FILES) $(BONUS_FILES) doxygen.stamp $(XMLTO_HTML) $(AM_V_at)rm -rf $@ $@.tmp $(AM_V_GEN)$(MKDIR_P) $@.tmp/api $(AM_V_at)cd $(srcdir) && cp $(STATIC_DOCS) @abs_builddir@/$@.tmp $(AM_V_at)cd $(srcdir) && cp $(dist_doc_DATA) @abs_builddir@/$@.tmp $(AM_V_at)cd $(srcdir) && cp $(STATIC_HTML) @abs_builddir@/$@.tmp - $(AM_V_at)cp $(XMLTO_OUTPUT) @abs_builddir@/$@.tmp + $(AM_V_at)cp $(XMLTO_HTML) @abs_builddir@/$@.tmp $(AM_V_at)cp $(MAN_HTML_FILES) @abs_builddir@/$@.tmp + $(AM_V_at)cp $(MAN_XML_FILES) @abs_builddir@/$@.tmp $(AM_V_at)cp $(BONUS_FILES) @abs_builddir@/$@.tmp $(AM_V_at)cp -r api/html @abs_builddir@/$@.tmp/api $(AM_V_at)mv $@.tmp $@ @@ -165,12 +156,15 @@ maintainer-upload-docs: @false endif +CLEANFILES = \ + $(man1_MANS) \ + $(MAN_XML_FILES) \ + $(XMLTO_HTML) \ + $(NULL) + clean-local: rm -f $(html_DATA) rm -rf api rm -rf dbus-docs dbus-docs.tmp rm -f *.1.html rm -f doxygen.stamp - -maintainer-clean-local: - rm -f $(XMLTO_OUTPUT) diff --git a/doc/Makefile.in b/doc/Makefile.in index 4ab0f9e6..572f8ac3 100644 --- a/doc/Makefile.in +++ b/doc/Makefile.in @@ -51,12 +51,14 @@ PRE_UNINSTALL = : POST_UNINSTALL = : build_triplet = @build@ host_triplet = @host@ -@DBUS_DOXYGEN_DOCS_ENABLED_TRUE@@DBUS_HAVE_XSLTPROC_TRUE@am__append_1 = dbus.devhelp -@DBUS_HAVE_MAN2HTML_TRUE@am__append_2 = $(MAN_HTML_FILES) +@DBUS_XML_DOCS_ENABLED_TRUE@am__append_1 = $(XMLTO_HTML) +@DBUS_DOXYGEN_DOCS_ENABLED_TRUE@@DBUS_HAVE_XSLTPROC_TRUE@am__append_2 = dbus.devhelp subdir = doc -DIST_COMMON = $(dist_doc_DATA) $(dist_html_DATA) $(dist_man1_MANS) \ - $(srcdir)/Makefile.am $(srcdir)/Makefile.in \ - $(srcdir)/dbus-daemon.1.in TODO +DIST_COMMON = $(dist_doc_DATA) $(dist_html_DATA) $(srcdir)/Makefile.am \ + $(srcdir)/Makefile.in $(srcdir)/dbus-cleanup-sockets.1.xml.in \ + $(srcdir)/dbus-daemon.1.xml.in $(srcdir)/dbus-launch.1.xml.in \ + $(srcdir)/dbus-monitor.1.xml.in $(srcdir)/dbus-send.1.xml.in \ + $(srcdir)/dbus-uuidgen.1.xml.in TODO ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/m4/as-ac-expand.m4 \ $(top_srcdir)/m4/compiler.m4 $(top_srcdir)/m4/libtool.m4 \ @@ -69,7 +71,9 @@ am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/config.h -CONFIG_CLEAN_FILES = dbus-daemon.1 +CONFIG_CLEAN_FILES = dbus-cleanup-sockets.1.xml dbus-daemon.1.xml \ + dbus-launch.1.xml dbus-monitor.1.xml dbus-send.1.xml \ + dbus-uuidgen.1.xml CONFIG_CLEAN_VPATH_FILES = AM_V_GEN = $(am__v_GEN_@AM_V@) am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@) @@ -115,7 +119,7 @@ man1dir = $(mandir)/man1 am__installdirs = "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(docdir)" \ "$(DESTDIR)$(htmldir)" "$(DESTDIR)$(htmldir)" NROFF = nroff -MANS = $(dist_man1_MANS) $(man1_MANS) +MANS = $(man1_MANS) DATA = $(dist_doc_DATA) $(dist_html_DATA) $(html_DATA) DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) ACLOCAL = @ACLOCAL@ @@ -157,7 +161,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -216,7 +221,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ @@ -327,23 +331,23 @@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ apidir = @htmldir@/api +MAN_XML_FILES = \ + dbus-cleanup-sockets.1.xml \ + dbus-daemon.1.xml \ + dbus-launch.1.xml \ + dbus-monitor.1.xml \ + dbus-send.1.xml \ + dbus-uuidgen.1.xml \ + $(NULL) -# automake normally assumes that man pages are generated files; -# these ones aren't, so we need the dist_ prefix to say that they're -# their own source code -dist_man1_MANS = \ - dbus-cleanup-sockets.1 \ - dbus-launch.1 \ - dbus-monitor.1 \ - dbus-send.1 \ - dbus-uuidgen.1 - - -# on the other hand, this one is generated -man1_MANS = \ - dbus-daemon.1 +@DBUS_XML_DOCS_ENABLED_TRUE@man1_MANS = \ +@DBUS_XML_DOCS_ENABLED_TRUE@ dbus-cleanup-sockets.1 \ +@DBUS_XML_DOCS_ENABLED_TRUE@ dbus-daemon.1 \ +@DBUS_XML_DOCS_ENABLED_TRUE@ dbus-launch.1 \ +@DBUS_XML_DOCS_ENABLED_TRUE@ dbus-monitor.1 \ +@DBUS_XML_DOCS_ENABLED_TRUE@ dbus-send.1 \ +@DBUS_XML_DOCS_ENABLED_TRUE@ dbus-uuidgen.1 -MAN_IN_FILES = dbus-daemon.1.in MAN_HTML_FILES = \ dbus-cleanup-sockets.1.html \ dbus-daemon.1.html \ @@ -371,13 +375,10 @@ STATIC_DOCS = \ EXTRA_DIST = \ file-boilerplate.c \ doxygen_to_devhelp.xsl \ - $(STATIC_DOCS) \ - $(MAN_IN_FILES) + $(STATIC_DOCS) html_DATA = $(am__append_1) $(am__append_2) - -# we distribute these in the tarball so users don't necessarily need xmlto -dist_html_DATA = $(STATIC_HTML) $(XMLTO_OUTPUT) +dist_html_DATA = $(STATIC_HTML) # diagram.png/diagram.svg aren't really HTML, but must go in the same # directory as the HTML to avoid broken links @@ -386,11 +387,13 @@ STATIC_HTML = \ diagram.svg \ $(NULL) -XMLTO_OUTPUT = \ +XMLTO_HTML = \ dbus-faq.html \ dbus-specification.html \ dbus-test-plan.html \ - dbus-tutorial.html + dbus-tutorial.html \ + $(MAN_HTML_FILES) \ + $(NULL) @DBUS_CAN_UPLOAD_DOCS_TRUE@BONUS_FILES = \ @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(top_srcdir)/README \ @@ -404,6 +407,12 @@ XMLTO_OUTPUT = \ @DBUS_CAN_UPLOAD_DOCS_TRUE@DOC_WWW_DIR = /srv/dbus.freedesktop.org/www @DBUS_CAN_UPLOAD_DOCS_TRUE@SPECIFICATION_SERVER = specifications.freedesktop.org @DBUS_CAN_UPLOAD_DOCS_TRUE@SPECIFICATION_PATH = /srv/specifications.freedesktop.org/www/dbus/1.0 +CLEANFILES = \ + $(man1_MANS) \ + $(MAN_XML_FILES) \ + $(XMLTO_HTML) \ + $(NULL) + all: all-am .SUFFIXES: @@ -437,7 +446,17 @@ $(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps) $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps) cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh $(am__aclocal_m4_deps): -dbus-daemon.1: $(top_builddir)/config.status $(srcdir)/dbus-daemon.1.in +dbus-cleanup-sockets.1.xml: $(top_builddir)/config.status $(srcdir)/dbus-cleanup-sockets.1.xml.in + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ +dbus-daemon.1.xml: $(top_builddir)/config.status $(srcdir)/dbus-daemon.1.xml.in + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ +dbus-launch.1.xml: $(top_builddir)/config.status $(srcdir)/dbus-launch.1.xml.in + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ +dbus-monitor.1.xml: $(top_builddir)/config.status $(srcdir)/dbus-monitor.1.xml.in + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ +dbus-send.1.xml: $(top_builddir)/config.status $(srcdir)/dbus-send.1.xml.in + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ +dbus-uuidgen.1.xml: $(top_builddir)/config.status $(srcdir)/dbus-uuidgen.1.xml.in cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ mostlyclean-libtool: @@ -445,9 +464,9 @@ mostlyclean-libtool: clean-libtool: -rm -rf .libs _libs -install-man1: $(dist_man1_MANS) $(man1_MANS) +install-man1: $(man1_MANS) @$(NORMAL_INSTALL) - @list1='$(dist_man1_MANS) $(man1_MANS)'; \ + @list1='$(man1_MANS)'; \ list2=''; \ test -n "$(man1dir)" \ && test -n "`echo $$list1$$list2`" \ @@ -481,7 +500,7 @@ install-man1: $(dist_man1_MANS) $(man1_MANS) uninstall-man1: @$(NORMAL_UNINSTALL) - @list='$(dist_man1_MANS) $(man1_MANS)'; test -n "$(man1dir)" || exit 0; \ + @list='$(man1_MANS)'; test -n "$(man1dir)" || exit 0; \ files=`{ for i in $$list; do echo "$$i"; done; \ } | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \ -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \ @@ -629,6 +648,7 @@ install-strip: mostlyclean-generic: clean-generic: + -test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) distclean-generic: -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) @@ -690,8 +710,7 @@ installcheck-am: maintainer-clean: maintainer-clean-am -rm -f Makefile -maintainer-clean-am: distclean-am maintainer-clean-generic \ - maintainer-clean-local +maintainer-clean-am: distclean-am maintainer-clean-generic mostlyclean: mostlyclean-am @@ -722,24 +741,18 @@ uninstall-man: uninstall-man1 install-info-am install-man install-man1 install-pdf \ install-pdf-am install-ps install-ps-am install-strip \ installcheck installcheck-am installdirs maintainer-clean \ - maintainer-clean-generic maintainer-clean-local mostlyclean \ - mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \ - uninstall uninstall-am uninstall-dist_docDATA \ - uninstall-dist_htmlDATA uninstall-htmlDATA uninstall-local \ - uninstall-man uninstall-man1 + maintainer-clean-generic mostlyclean mostlyclean-generic \ + mostlyclean-libtool pdf pdf-am ps ps-am uninstall uninstall-am \ + uninstall-dist_docDATA uninstall-dist_htmlDATA \ + uninstall-htmlDATA uninstall-local uninstall-man \ + uninstall-man1 -@DBUS_XML_DOCS_ENABLED_TRUE@dbus-specification.html: dbus-specification.xml +@DBUS_XML_DOCS_ENABLED_TRUE@%.html: %.xml @DBUS_XML_DOCS_ENABLED_TRUE@ $(XMLTO) html-nochunks $< -@DBUS_XML_DOCS_ENABLED_TRUE@dbus-test-plan.html: dbus-test-plan.xml -@DBUS_XML_DOCS_ENABLED_TRUE@ $(XMLTO) html-nochunks $< - -@DBUS_XML_DOCS_ENABLED_TRUE@dbus-tutorial.html: dbus-tutorial.xml -@DBUS_XML_DOCS_ENABLED_TRUE@ $(XMLTO) html-nochunks $< - -@DBUS_XML_DOCS_ENABLED_TRUE@dbus-faq.html: dbus-faq.xml -@DBUS_XML_DOCS_ENABLED_TRUE@ $(XMLTO) html-nochunks $< +@DBUS_XML_DOCS_ENABLED_TRUE@%.1: %.1.xml +@DBUS_XML_DOCS_ENABLED_TRUE@ $(XMLTO) man $< @DBUS_DOXYGEN_DOCS_ENABLED_TRUE@all-local:: doxygen.stamp @@ -768,17 +781,15 @@ uninstall-man: uninstall-man1 @DBUS_DOXYGEN_DOCS_ENABLED_TRUE@ rmdir --ignore-fail-on-non-empty $(DESTDIR)$(apidir) || \ @DBUS_DOXYGEN_DOCS_ENABLED_TRUE@ rmdir $(DESTDIR)$(apidir) -@DBUS_HAVE_MAN2HTML_TRUE@%.1.html: %.1 -@DBUS_HAVE_MAN2HTML_TRUE@ $(AM_V_GEN)( $(MAN2HTML) < $< > $@.tmp && mv $@.tmp $@ ) - -@DBUS_CAN_UPLOAD_DOCS_TRUE@dbus-docs: $(STATIC_DOCS) $(dist_doc_DATA) $(dist_html_DATA) $(MAN_HTML_FILES) $(BONUS_FILES) doxygen.stamp +@DBUS_CAN_UPLOAD_DOCS_TRUE@dbus-docs: $(STATIC_DOCS) $(MAN_XML_FILES) $(dist_doc_DATA) $(dist_html_DATA) $(MAN_HTML_FILES) $(BONUS_FILES) doxygen.stamp $(XMLTO_HTML) @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)rm -rf $@ $@.tmp @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_GEN)$(MKDIR_P) $@.tmp/api @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cd $(srcdir) && cp $(STATIC_DOCS) @abs_builddir@/$@.tmp @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cd $(srcdir) && cp $(dist_doc_DATA) @abs_builddir@/$@.tmp @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cd $(srcdir) && cp $(STATIC_HTML) @abs_builddir@/$@.tmp -@DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cp $(XMLTO_OUTPUT) @abs_builddir@/$@.tmp +@DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cp $(XMLTO_HTML) @abs_builddir@/$@.tmp @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cp $(MAN_HTML_FILES) @abs_builddir@/$@.tmp +@DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cp $(MAN_XML_FILES) @abs_builddir@/$@.tmp @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cp $(BONUS_FILES) @abs_builddir@/$@.tmp @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)cp -r api/html @abs_builddir@/$@.tmp/api @DBUS_CAN_UPLOAD_DOCS_TRUE@ $(AM_V_at)mv $@.tmp $@ @@ -804,9 +815,6 @@ clean-local: rm -f *.1.html rm -f doxygen.stamp -maintainer-clean-local: - rm -f $(XMLTO_OUTPUT) - # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: diff --git a/doc/dbus-cleanup-sockets.1 b/doc/dbus-cleanup-sockets.1 deleted file mode 100644 index a062d498..00000000 --- a/doc/dbus-cleanup-sockets.1 +++ /dev/null @@ -1,43 +0,0 @@ -.\" -.\" dbus\-cleanup\-sockets manual page. -.\" Copyright (C) 2003 Red Hat, Inc. -.\" -.TH dbus\-cleanup\-sockets 1 -.SH NAME -dbus\-cleanup\-sockets \- clean up leftover sockets in a directory -.SH SYNOPSIS -.PP -.B dbus\-cleanup\-sockets [DIRECTORY] - -.SH DESCRIPTION - -The \fIdbus\-cleanup\-sockets\fP command cleans up unused D\-Bus -connection sockets. See http://www.freedesktop.org/software/dbus/ for -more information about the big picture. - -.PP -If given no arguments, \fIdbus\-cleanup\-sockets\fP cleans up sockets -in the standard default socket directory for the -per\-user\-login\-session message bus; this is usually /tmp. -Optionally, you can pass a different directory on the command line. - -.PP -On Linux, this program is essentially useless, because D\-Bus defaults -to using "abstract sockets" that exist only in memory and don't have a -corresponding file in /tmp. - -.PP -On most other flavors of UNIX, it's possible for the socket files to -leak when programs using D\-Bus exit abnormally or without closing -their D\-Bus connections. Thus, it might be interesting to run -dbus\-cleanup\-sockets in a cron job to mop up any leaked sockets. -Or you can just ignore the leaked sockets, they aren't really hurting -anything, other than cluttering the output of "ls /tmp" - -.SH AUTHOR -dbus\-cleanup\-sockets was adapted by Havoc Pennington from -linc\-cleanup\-sockets written by Michael Meeks. - -.SH BUGS -Please send bug reports to the D\-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ diff --git a/doc/dbus-cleanup-sockets.1.xml.in b/doc/dbus-cleanup-sockets.1.xml.in new file mode 100644 index 00000000..6d98083d --- /dev/null +++ b/doc/dbus-cleanup-sockets.1.xml.in @@ -0,0 +1,65 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> +<refentry id='dbuscleanupsockets1'> + +<!-- dbus\-cleanup\-sockets manual page. + Copyright (C) 2003 Red Hat, Inc. --> + +<refmeta> +<refentrytitle>dbus-cleanup-sockets</refentrytitle> +<manvolnum>1</manvolnum> +<refmiscinfo class="manual">User Commands</refmiscinfo> +<refmiscinfo class="source">D-Bus</refmiscinfo> +<refmiscinfo class="version">@DBUS_VERSION@</refmiscinfo> +</refmeta> +<refnamediv> +<refname>dbus-cleanup-sockets</refname> +<refpurpose>clean up leftover sockets in a directory</refpurpose> +</refnamediv> +<!-- body begins here --> +<refsynopsisdiv id='synopsis'> +<cmdsynopsis> + <command>dbus-cleanup-sockets</command> <arg choice='opt'><replaceable>DIRECTORY</replaceable></arg> + <sbr/> +</cmdsynopsis> +</refsynopsisdiv> + + +<refsect1 id='description'><title>DESCRIPTION</title> +<para>The <command>dbus-cleanup-sockets</command> command cleans up unused D-Bus +connection sockets. See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for +more information about the big picture.</para> + + +<para>If given no arguments, <command>dbus-cleanup-sockets</command> cleans up sockets +in the standard default socket directory for the +per-user-login-session message bus; this is usually /tmp. +Optionally, you can pass a different directory on the command line.</para> + + +<para>On Linux, this program is essentially useless, because D-Bus defaults +to using "abstract sockets" that exist only in memory and don't have a +corresponding file in /tmp.</para> + + +<para>On most other flavors of UNIX, it's possible for the socket files to +leak when programs using D-Bus exit abnormally or without closing +their D-Bus connections. Thus, it might be interesting to run +dbus-cleanup-sockets in a cron job to mop up any leaked sockets. +Or you can just ignore the leaked sockets, they aren't really hurting +anything, other than cluttering the output of "ls /tmp"</para> + +</refsect1> + +<refsect1 id='author'><title>AUTHOR</title> +<para>dbus-cleanup-sockets was adapted by Havoc Pennington from +linc-cleanup-sockets written by Michael Meeks.</para> + +</refsect1> + +<refsect1 id='bugs'><title>BUGS</title> +<para>Please send bug reports to the D-Bus mailing list or bug tracker, +see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para> +</refsect1> +</refentry> diff --git a/doc/dbus-daemon.1.in b/doc/dbus-daemon.1.in deleted file mode 100644 index 53856e91..00000000 --- a/doc/dbus-daemon.1.in +++ /dev/null @@ -1,766 +0,0 @@ -.\" -.\" dbus\-daemon manual page. -.\" Copyright (C) 2003,2008 Red Hat, Inc. -.\" -.TH dbus\-daemon 1 -.SH NAME -dbus\-daemon \- Message bus daemon -.SH SYNOPSIS -.PP -.B dbus\-daemon -dbus\-daemon [\-\-version] [\-\-session] [\-\-system] [\-\-config\-file=FILE] -[\-\-print\-address[=DESCRIPTOR]] [\-\-print\-pid[=DESCRIPTOR]] [\-\-fork] - -.SH DESCRIPTION -\fIdbus\-daemon\fP is the D\-Bus message bus daemon. See -http://www.freedesktop.org/software/dbus/ for more information about -the big picture. D\-Bus is first a library that provides one\-to\-one -communication between any two applications; \fIdbus\-daemon\fP is an -application that uses this library to implement a message bus -daemon. Multiple programs connect to the message bus daemon and can -exchange messages with one another. -.PP -There are two standard message bus instances: the systemwide message bus -(installed on many systems as the "messagebus" init service) and the -per\-user\-login\-session message bus (started each time a user logs in). -\fIdbus\-daemon\fP is used for both of these instances, but with -a different configuration file. -.PP -The \-\-session option is equivalent to -"\-\-config\-file=@EXPANDED_SYSCONFDIR@/dbus\-1/session.conf" and the \-\-system -option is equivalent to -"\-\-config\-file=@EXPANDED_SYSCONFDIR@/dbus\-1/system.conf". By creating -additional configuration files and using the \-\-config\-file option, -additional special\-purpose message bus daemons could be created. -.PP -The systemwide daemon is normally launched by an init script, -standardly called simply "messagebus". -.PP -The systemwide daemon is largely used for broadcasting system events, -such as changes to the printer queue, or adding/removing devices. -.PP -The per\-session daemon is used for various interprocess communication -among desktop applications (however, it is not tied to X or the GUI -in any way). -.PP -SIGHUP will cause the D\-Bus daemon to PARTIALLY reload its -configuration file and to flush its user/group information caches. Some -configuration changes would require kicking all apps off the bus; so they will -only take effect if you restart the daemon. Policy changes should take effect -with SIGHUP. - -.SH OPTIONS -The following options are supported: -.TP -.I "\-\-config\-file=FILE" -Use the given configuration file. -.TP -.I "\-\-fork" -Force the message bus to fork and become a daemon, even if -the configuration file does not specify that it should. -In most contexts the configuration file already gets this -right, though. -.I "\-\-nofork" -Force the message bus not to fork and become a daemon, even if -the configuration file specifies that it should. -.TP -.I "\-\-print\-address[=DESCRIPTOR]" -Print the address of the message bus to standard output, or -to the given file descriptor. This is used by programs that -launch the message bus. -.TP -.I "\-\-print\-pid[=DESCRIPTOR]" -Print the process ID of the message bus to standard output, or -to the given file descriptor. This is used by programs that -launch the message bus. -.TP -.I "\-\-session" -Use the standard configuration file for the per\-login\-session message -bus. -.TP -.I "\-\-system" -Use the standard configuration file for the systemwide message bus. -.TP -.I "\-\-version" -Print the version of the daemon. -.TP -.I "\-\-introspect" -Print the introspection information for all D\-Bus internal interfaces. -.TP -.I "\-\-address[=ADDRESS]" -Set the address to listen on. This option overrides the address -configured in the configuration file. -.TP -.I "\-\-systemd\-activation" -Enable systemd\-style service activation. Only useful in conjunction -with the systemd system and session manager on Linux. -.TP -.I "\-\-nopidfile" -Don't write a PID file even if one is configured in the configuration -files. - -.SH CONFIGURATION FILE - -A message bus daemon has a configuration file that specializes it -for a particular application. For example, one configuration -file might set up the message bus to be a systemwide message bus, -while another might set it up to be a per\-user\-login\-session bus. -.PP -The configuration file also establishes resource limits, security -parameters, and so forth. -.PP -The configuration file is not part of any interoperability -specification and its backward compatibility is not guaranteed; this -document is documentation, not specification. -.PP -The standard systemwide and per\-session message bus setups are -configured in the files "@EXPANDED_SYSCONFDIR@/dbus\-1/system.conf" and -"@EXPANDED_SYSCONFDIR@/dbus\-1/session.conf". These files normally -<include> a system\-local.conf or session\-local.conf; you can put local -overrides in those files to avoid modifying the primary configuration -files. - -.PP -The configuration file is an XML document. It must have the following -doctype declaration: -.nf - - <!DOCTYPE busconfig PUBLIC "\-//freedesktop//DTD D\-Bus Bus Configuration 1.0//EN" - "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> - -.fi - -.PP -The following elements may be present in the configuration file. - -.TP -.I "<busconfig>" - -.PP -Root element. - -.TP -.I "<type>" - -.PP -The well\-known type of the message bus. Currently known values are -"system" and "session"; if other values are set, they should be -either added to the D\-Bus specification, or namespaced. The last -<type> element "wins" (previous values are ignored). This element -only controls which message bus specific environment variables are -set in activated clients. Most of the policy that distinguishes a -session bus from the system bus is controlled from the other elements -in the configuration file. - -.PP -If the well\-known type of the message bus is "session", then the -DBUS_STARTER_BUS_TYPE environment variable will be set to "session" -and the DBUS_SESSION_BUS_ADDRESS environment variable will be set -to the address of the session bus. Likewise, if the type of the -message bus is "system", then the DBUS_STARTER_BUS_TYPE environment -variable will be set to "system" and the DBUS_SESSION_BUS_ADDRESS -environment variable will be set to the address of the system bus -(which is normally well known anyway). - -.PP -Example: <type>session</type> - -.TP -.I "<include>" - -.PP -Include a file <include>filename.conf</include> at this point. If the -filename is relative, it is located relative to the configuration file -doing the including. - -.PP -<include> has an optional attribute "ignore_missing=(yes|no)" -which defaults to "no" if not provided. This attribute -controls whether it's a fatal error for the included file -to be absent. - -.TP -.I "<includedir>" - -.PP -Include all files in <includedir>foo.d</includedir> at this -point. Files in the directory are included in undefined order. -Only files ending in ".conf" are included. - -.PP -This is intended to allow extension of the system bus by particular -packages. For example, if CUPS wants to be able to send out -notification of printer queue changes, it could install a file to -@EXPANDED_SYSCONFDIR@/dbus\-1/system.d that allowed all apps to receive -this message and allowed the printer daemon user to send it. - -.TP -.I "<user>" - -.PP -The user account the daemon should run as, as either a username or a -UID. If the daemon cannot change to this UID on startup, it will exit. -If this element is not present, the daemon will not change or care -about its UID. - -.PP -The last <user> entry in the file "wins", the others are ignored. - -.PP -The user is changed after the bus has completed initialization. So -sockets etc. will be created before changing user, but no data will be -read from clients before changing user. This means that sockets -and PID files can be created in a location that requires root -privileges for writing. - -.TP -.I "<fork>" - -.PP -If present, the bus daemon becomes a real daemon (forks -into the background, etc.). This is generally used -rather than the \-\-fork command line option. - -.TP -.I "<keep_umask>" - -.PP -If present, the bus daemon keeps its original umask when forking. -This may be useful to avoid affecting the behavior of child processes. - -.TP -.I "<listen>" - -.PP -Add an address that the bus should listen on. The -address is in the standard D\-Bus format that contains -a transport name plus possible parameters/options. - -.PP -Example: <listen>unix:path=/tmp/foo</listen> - -.PP -Example: <listen>tcp:host=localhost,port=1234</listen> - -.PP -If there are multiple <listen> elements, then the bus listens -on multiple addresses. The bus will pass its address to -started services or other interested parties with -the last address given in <listen> first. That is, -apps will try to connect to the last <listen> address first. - -.PP -tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. -If a hostname resolves to multiple addresses, the server will bind -to all of them. The family=ipv4 or family=ipv6 options can be used -to force it to bind to a subset of addresses - -.PP -Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen> - -.PP -A special case is using a port number of zero (or omitting the port), -which means to choose an available port selected by the operating -system. The port number chosen can be obtained with the -\-\-print\-address command line parameter and will be present in other -cases where the server reports its own address, such as when -DBUS_SESSION_BUS_ADDRESS is set. - -.PP -Example: <listen>tcp:host=localhost,port=0</listen> - -.PP -tcp addresses also allow a bind=hostname option, which will override -the host option specifying what address to bind to, without changing -the address reported by the bus. The bind option can also take a -special name '*' to cause the bus to listen on all local address -(INADDR_ANY). The specified host should be a valid name of the local -machine or weird stuff will happen. - -.PP -Example: <listen>tcp:host=localhost,bind=*,port=0</listen> - -.TP -.I "<auth>" - -.PP -Lists permitted authorization mechanisms. If this element doesn't -exist, then all known mechanisms are allowed. If there are multiple -<auth> elements, all the listed mechanisms are allowed. The order in -which mechanisms are listed is not meaningful. - -.PP -Example: <auth>EXTERNAL</auth> - -.PP -Example: <auth>DBUS_COOKIE_SHA1</auth> - -.TP -.I "<servicedir>" - -.PP -Adds a directory to scan for .service files. Directories are -scanned starting with the last to appear in the config file -(the first .service file found that provides a particular -service will be used). - -.PP -Service files tell the bus how to automatically start a program. -They are primarily used with the per\-user\-session bus, -not the systemwide bus. - -.TP -.I "<standard_session_servicedirs/>" - -.PP -<standard_session_servicedirs/> is equivalent to specifying a series -of <servicedir/> elements for each of the data directories in the "XDG -Base Directory Specification" with the subdirectory "dbus\-1/services", -so for example "/usr/share/dbus\-1/services" would be among the -directories searched. - -.PP -The "XDG Base Directory Specification" can be found at -http://freedesktop.org/wiki/Standards/basedir\-spec if it hasn't moved, -otherwise try your favorite search engine. - -.PP -The <standard_session_servicedirs/> option is only relevant to the -per\-user\-session bus daemon defined in -@EXPANDED_SYSCONFDIR@/dbus\-1/session.conf. Putting it in any other -configuration file would probably be nonsense. - -.TP -.I "<standard_system_servicedirs/>" - -.PP -<standard_system_servicedirs/> specifies the standard system\-wide -activation directories that should be searched for service files. -This option defaults to @EXPANDED_DATADIR@/dbus\-1/system\-services. - -.PP -The <standard_system_servicedirs/> option is only relevant to the -per\-system bus daemon defined in -@EXPANDED_SYSCONFDIR@/dbus\-1/system.conf. Putting it in any other -configuration file would probably be nonsense. - -.TP -.I "<servicehelper/>" - -.PP -<servicehelper/> specifies the setuid helper that is used to launch -system daemons with an alternate user. Typically this should be -the dbus\-daemon\-launch\-helper executable in located in libexec. - -.PP -The <servicehelper/> option is only relevant to the per\-system bus daemon -defined in @EXPANDED_SYSCONFDIR@/dbus\-1/system.conf. Putting it in any other -configuration file would probably be nonsense. - -.TP -.I "<limit>" - -.PP -<limit> establishes a resource limit. For example: -.nf - <limit name="max_message_size">64</limit> - <limit name="max_completed_connections">512</limit> -.fi - -.PP -The name attribute is mandatory. -Available limit names are: -.nf - "max_incoming_bytes" : total size in bytes of messages - incoming from a single connection - "max_incoming_unix_fds" : total number of unix fds of messages - incoming from a single connection - "max_outgoing_bytes" : total size in bytes of messages - queued up for a single connection - "max_outgoing_unix_fds" : total number of unix fds of messages - queued up for a single connection - "max_message_size" : max size of a single message in - bytes - "max_message_unix_fds" : max unix fds of a single message - "service_start_timeout" : milliseconds (thousandths) until - a started service has to connect - "auth_timeout" : milliseconds (thousandths) a - connection is given to - authenticate - "max_completed_connections" : max number of authenticated connections - "max_incomplete_connections" : max number of unauthenticated - connections - "max_connections_per_user" : max number of completed connections from - the same user - "max_pending_service_starts" : max number of service launches in - progress at the same time - "max_names_per_connection" : max number of names a single - connection can own - "max_match_rules_per_connection": max number of match rules for a single - connection - "max_replies_per_connection" : max number of pending method - replies per connection - (number of calls\-in\-progress) - "reply_timeout" : milliseconds (thousandths) - until a method call times out -.fi - -.PP -The max incoming/outgoing queue sizes allow a new message to be queued -if one byte remains below the max. So you can in fact exceed the max -by max_message_size. - -.PP -max_completed_connections divided by max_connections_per_user is the -number of users that can work together to denial\-of\-service all other users by using -up all connections on the systemwide bus. - -.PP -Limits are normally only of interest on the systemwide bus, not the user session -buses. - -.TP -.I "<policy>" - -.PP -The <policy> element defines a security policy to be applied to a particular -set of connections to the bus. A policy is made up of -<allow> and <deny> elements. Policies are normally used with the systemwide bus; -they are analogous to a firewall in that they allow expected traffic -and prevent unexpected traffic. - -.PP -Currently, the system bus has a default\-deny policy for sending method calls -and owning bus names. Everything else, in particular reply messages, receive -checks, and signals has a default allow policy. - -.PP -In general, it is best to keep system services as small, targeted programs which -run in their own process and provide a single bus name. Then, all that is needed -is an <allow> rule for the "own" permission to let the process claim the bus -name, and a "send_destination" rule to allow traffic from some or all uids to -your service. - -.PP -The <policy> element has one of four attributes: -.nf - context="(default|mandatory)" - at_console="(true|false)" - user="username or userid" - group="group name or gid" -.fi - -.PP -Policies are applied to a connection as follows: -.nf - \- all context="default" policies are applied - \- all group="connection's user's group" policies are applied - in undefined order - \- all user="connection's auth user" policies are applied - in undefined order - \- all at_console="true" policies are applied - \- all at_console="false" policies are applied - \- all context="mandatory" policies are applied -.fi - -.PP -Policies applied later will override those applied earlier, -when the policies overlap. Multiple policies with the same -user/group/context are applied in the order they appear -in the config file. - -.TP -.I "<deny>" -.I "<allow>" - -.PP -A <deny> element appears below a <policy> element and prohibits some -action. The <allow> element makes an exception to previous <deny> -statements, and works just like <deny> but with the inverse meaning. - -.PP -The possible attributes of these elements are: -.nf - send_interface="interface_name" - send_member="method_or_signal_name" - send_error="error_name" - send_destination="name" - send_type="method_call" | "method_return" | "signal" | "error" - send_path="/path/name" - - receive_interface="interface_name" - receive_member="method_or_signal_name" - receive_error="error_name" - receive_sender="name" - receive_type="method_call" | "method_return" | "signal" | "error" - receive_path="/path/name" - - send_requested_reply="true" | "false" - receive_requested_reply="true" | "false" - - eavesdrop="true" | "false" - - own="name" - own_prefix="name" - user="username" - group="groupname" -.fi - -.PP -Examples: -.nf - <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/> - <deny send_destination="org.freedesktop.System"/> - <deny receive_sender="org.freedesktop.System"/> - <deny user="john"/> - <deny group="enemies"/> -.fi - -.PP -The <deny> element's attributes determine whether the deny "matches" a -particular action. If it matches, the action is denied (unless later -rules in the config file allow it). -.PP -send_destination and receive_sender rules mean that messages may not be -sent to or received from the *owner* of the given name, not that -they may not be sent *to that name*. That is, if a connection -owns services A, B, C, and sending to A is denied, sending to B or C -will not work either. -.PP -The other send_* and receive_* attributes are purely textual/by\-value -matches against the given field in the message header. -.PP -"Eavesdropping" occurs when an application receives a message that -was explicitly addressed to a name the application does not own, or -is a reply to such a message. Eavesdropping thus only applies to -messages that are addressed to services and replies to such messages -(i.e. it does not apply to signals). -.PP -For <allow>, eavesdrop="true" indicates that the rule matches even -when eavesdropping. eavesdrop="false" is the default and means that -the rule only allows messages to go to their specified recipient. -For <deny>, eavesdrop="true" indicates that the rule matches -only when eavesdropping. eavesdrop="false" is the default for <deny> -also, but here it means that the rule applies always, even when -not eavesdropping. The eavesdrop attribute can only be combined with -send and receive rules (with send_* and receive_* attributes). -.PP -The [send|receive]_requested_reply attribute works similarly to the eavesdrop -attribute. It controls whether the <deny> or <allow> matches a reply -that is expected (corresponds to a previous method call message). -This attribute only makes sense for reply messages (errors and method -returns), and is ignored for other message types. - -.PP -For <allow>, [send|receive]_requested_reply="true" is the default and indicates that -only requested replies are allowed by the -rule. [send|receive]_requested_reply="false" means that the rule allows any reply -even if unexpected. - -.PP -For <deny>, [send|receive]_requested_reply="false" is the default but indicates that -the rule matches only when the reply was not -requested. [send|receive]_requested_reply="true" indicates that the rule applies -always, regardless of pending reply state. - -.PP -user and group denials mean that the given user or group may -not connect to the message bus. - -.PP -For "name", "username", "groupname", etc. -the character "*" can be substituted, meaning "any." Complex globs -like "foo.bar.*" aren't allowed for now because they'd be work to -implement and maybe encourage sloppy security anyway. - -.PP -<allow own_prefix="a.b"/> allows you to own the name "a.b" or any -name whose first dot-separated elements are "a.b": in particular, -you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". -This is useful when services like Telepathy and ReserveDevice -define a meaning for subtrees of well-known names, such as -org.freedesktop.Telepathy.ConnectionManager.(anything) -and org.freedesktop.ReserveDevice1.(anything). - -.PP -It does not make sense to deny a user or group inside a <policy> -for a user or group; user/group denials can only be inside -context="default" or context="mandatory" policies. - -.PP -A single <deny> rule may specify combinations of attributes such as -send_destination and send_interface and send_type. In this case, the -denial applies only if both attributes match the message being denied. -e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would -deny messages with the given interface AND the given bus name. -To get an OR effect you specify multiple <deny> rules. - -.PP -You can't include both send_ and receive_ attributes on the same -rule, since "whether the message can be sent" and "whether it can be -received" are evaluated separately. - -.PP -Be careful with send_interface/receive_interface, because the -interface field in messages is optional. In particular, do NOT -specify <deny send_interface="org.foo.Bar"/>! This will cause -no\-interface messages to be blocked for all services, which is -almost certainly not what you intended. Always use rules of -the form: <deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/> - -.TP -.I "<selinux>" - -.PP -The <selinux> element contains settings related to Security Enhanced Linux. -More details below. - -.TP -.I "<associate>" - -.PP -An <associate> element appears below an <selinux> element and -creates a mapping. Right now only one kind of association is possible: -.nf - <associate own="org.freedesktop.Foobar" context="foo_t"/> -.fi - -.PP -This means that if a connection asks to own the name -"org.freedesktop.Foobar" then the source context will be the context -of the connection and the target context will be "foo_t" \- see the -short discussion of SELinux below. - -.PP -Note, the context here is the target context when requesting a name, -NOT the context of the connection owning the name. - -.PP -There's currently no way to set a default for owning any name, if -we add this syntax it will look like: -.nf - <associate own="*" context="foo_t"/> -.fi -If you find a reason this is useful, let the developers know. -Right now the default will be the security context of the bus itself. - -.PP -If two <associate> elements specify the same name, the element -appearing later in the configuration file will be used. - -.SH SELinux - -.PP -See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts: - -.IP "" 8 -Every subject (process) and object (e.g. file, socket, IPC object, -etc) in the system is assigned a collection of security attributes, -known as a security context. A security context contains all of the -security attributes associated with a particular subject or object -that are relevant to the security policy. - -.IP "" 8 -In order to better encapsulate security contexts and to provide -greater efficiency, the policy enforcement code of SELinux typically -handles security identifiers (SIDs) rather than security contexts. A -SID is an integer that is mapped by the security server to a security -context at runtime. - -.IP "" 8 -When a security decision is required, the policy enforcement code -passes a pair of SIDs (typically the SID of a subject and the SID of -an object, but sometimes a pair of subject SIDs or a pair of object -SIDs), and an object security class to the security server. The object -security class indicates the kind of object, e.g. a process, a regular -file, a directory, a TCP socket, etc. - -.IP "" 8 -Access decisions specify whether or not a permission is granted for a -given pair of SIDs and class. Each object class has a set of -associated permissions defined to control operations on objects with -that class. - -.PP -D\-Bus performs SELinux security checks in two places. - -.PP -First, any time a message is routed from one connection to another -connection, the bus daemon will check permissions with the security context of -the first connection as source, security context of the second connection -as target, object class "dbus" and requested permission "send_msg". - -.PP -If a security context is not available for a connection -(impossible when using UNIX domain sockets), then the target -context used is the context of the bus daemon itself. -There is currently no way to change this default, because we're -assuming that only UNIX domain sockets will be used to -connect to the systemwide bus. If this changes, we'll -probably add a way to set the default connection context. - -.PP -Second, any time a connection asks to own a name, -the bus daemon will check permissions with the security -context of the connection as source, the security context specified -for the name in the config file as target, object -class "dbus" and requested permission "acquire_svc". - -.PP -The security context for a bus name is specified with the -<associate> element described earlier in this document. -If a name has no security context associated in the -configuration file, the security context of the bus daemon -itself will be used. - -.SH DEBUGGING - -.PP -If you're trying to figure out where your messages are going or why -you aren't getting messages, there are several things you can try. -.PP -Remember that the system bus is heavily locked down and if you -haven't installed a security policy file to allow your message -through, it won't work. For the session bus, this is not a concern. -.PP -The simplest way to figure out what's happening on the bus is to run -the \fIdbus\-monitor\fP program, which comes with the D\-Bus -package. You can also send test messages with \fIdbus\-send\fP. These -programs have their own man pages. -.PP -If you want to know what the daemon itself is doing, you might consider -running a separate copy of the daemon to test against. This will allow you -to put the daemon under a debugger, or run it with verbose output, without -messing up your real session and system daemons. -.PP -To run a separate test copy of the daemon, for example you might open a terminal -and type: -.nf - DBUS_VERBOSE=1 dbus\-daemon \-\-session \-\-print\-address -.fi -.PP -The test daemon address will be printed when the daemon starts. You will need -to copy\-and\-paste this address and use it as the value of the -DBUS_SESSION_BUS_ADDRESS environment variable when you launch the applications -you want to test. This will cause those applications to connect to your -test bus instead of the DBUS_SESSION_BUS_ADDRESS of your real session bus. -.PP -DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D\-Bus -was compiled with verbose mode enabled. This is not recommended in -production builds due to performance impact. You may need to rebuild -D\-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE -also affects the D\-Bus library and thus applications using D\-Bus; it may -be useful to see verbose output on both the client side and from the daemon.) -.PP -If you want to get fancy, you can create a custom bus -configuration for your test bus (see the session.conf and system.conf -files that define the two default configurations for example). This -would allow you to specify a different directory for .service files, -for example. - -.SH AUTHOR -See http://www.freedesktop.org/software/dbus/doc/AUTHORS - -.SH BUGS -Please send bug reports to the D\-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ diff --git a/cmake/bus/dbus-daemon.xml b/doc/dbus-daemon.1.xml.in index f331699c..aea25144 100644 --- a/cmake/bus/dbus-daemon.xml +++ b/doc/dbus-daemon.1.xml.in @@ -1,17 +1,19 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> -<!-- lifted from troff+man by doclifter --> -<refentry id='dbus-daemon'> -<!-- --> -<!-- dbus\-daemon manual page. --> -<!-- Copyright (C) 2003 Red Hat, Inc. --> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> +<refentry id='dbusdaemon1'> + +<!-- dbus\-daemon manual page. + Copyright (C) 2003,2008 Red Hat, Inc. --> <refmeta> <refentrytitle>dbus-daemon</refentrytitle> <manvolnum>1</manvolnum> +<refmiscinfo class="manual">User Commands</refmiscinfo> +<refmiscinfo class="source">D-Bus</refmiscinfo> +<refmiscinfo class="version">@DBUS_VERSION@</refmiscinfo> </refmeta> -<refnamediv id='name'> +<refnamediv> <refname>dbus-daemon</refname> <refpurpose>Message bus daemon</refpurpose> </refnamediv> @@ -41,35 +43,29 @@ application that uses this library to implement a message bus daemon. Multiple programs connect to the message bus daemon and can exchange messages with one another.</para> - -<para>There are two standard message bus instances: the systemwide message bus -(installed on many systems as the "messagebus" init service) and the +<para>There are two standard message bus instances: the systemwide message bus +(installed on many systems as the "messagebus" init service) and the per-user-login-session message bus (started each time a user logs in). -<command>dbus-daemon</command> is used for both of these instances, but with +<command>dbus-daemon</command> is used for both of these instances, but with a different configuration file.</para> - <para>The --session option is equivalent to -"--config-file=/etc/dbus-1/session.conf" and the --system +"--config-file=@EXPANDED_SYSCONFDIR@/dbus-1/session.conf" and the --system option is equivalent to -"--config-file=/etc/dbus-1/system.conf". By creating +"--config-file=@EXPANDED_SYSCONFDIR@/dbus-1/system.conf". By creating additional configuration files and using the --config-file option, additional special-purpose message bus daemons could be created.</para> +<para>The systemwide daemon is normally launched by an init script, +standardly called simply "messagebus".</para> -<para>The systemwide daemon is normally launched by an init script, -standardly called simply "messagebus".</para> - - -<para>The systemwide daemon is largely used for broadcasting system events, +<para>The systemwide daemon is largely used for broadcasting system events, such as changes to the printer queue, or adding/removing devices.</para> - -<para>The per-session daemon is used for various interprocess communication -among desktop applications (however, it is not tied to X or the GUI +<para>The per-session daemon is used for various interprocess communication +among desktop applications (however, it is not tied to X or the GUI in any way).</para> - <para>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its configuration file and to flush its user/group information caches. Some configuration changes would require kicking all apps off the bus; so they will @@ -90,25 +86,28 @@ with SIGHUP.</para> <varlistentry> <term><option>--fork</option></term> <listitem> -<para>Force the message bus to fork and become a daemon, even if +<para>Force the message bus to fork and become a daemon, even if the configuration file does not specify that it should. In most contexts the configuration file already gets this -right, though.</para> +right, though. +<option>--nofork</option> +Force the message bus not to fork and become a daemon, even if +the configuration file specifies that it should.</para> </listitem> </varlistentry> <varlistentry> <term><option>--print-address[=DESCRIPTOR]</option></term> <listitem> -<para>Print the address of the message bus to standard output, or -to the given file descriptor. This is used by programs that +<para>Print the address of the message bus to standard output, or +to the given file descriptor. This is used by programs that launch the message bus.</para> </listitem> </varlistentry> <varlistentry> <term><option>--print-pid[=DESCRIPTOR]</option></term> <listitem> -<para>Print the process ID of the message bus to standard output, or -to the given file descriptor. This is used by programs that +<para>Print the process ID of the message bus to standard output, or +to the given file descriptor. This is used by programs that launch the message bus.</para> </listitem> </varlistentry> @@ -129,6 +128,33 @@ bus.</para> <term><option>--version</option></term> <listitem> <para>Print the version of the daemon.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--introspect</option></term> + <listitem> +<para>Print the introspection information for all D-Bus internal interfaces.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--address[=ADDRESS]</option></term> + <listitem> +<para>Set the address to listen on. This option overrides the address +configured in the configuration file.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--systemd-activation</option></term> + <listitem> +<para>Enable systemd-style service activation. Only useful in conjunction +with the systemd system and session manager on Linux.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--nopidfile</option></term> + <listitem> +<para>Don't write a PID file even if one is configured in the configuration +files.</para> </listitem> </varlistentry> @@ -137,23 +163,20 @@ bus.</para> <refsect1 id='configuration_file'><title>CONFIGURATION FILE</title> <para>A message bus daemon has a configuration file that specializes it -for a particular application. For example, one configuration -file might set up the message bus to be a systemwide message bus, +for a particular application. For example, one configuration +file might set up the message bus to be a systemwide message bus, while another might set it up to be a per-user-login-session bus.</para> - <para>The configuration file also establishes resource limits, security parameters, and so forth.</para> - <para>The configuration file is not part of any interoperability specification and its backward compatibility is not guaranteed; this document is documentation, not specification.</para> - <para>The standard systemwide and per-session message bus setups are -configured in the files "/etc/dbus-1/system.conf" and -"/etc/dbus-1/session.conf". These files normally +configured in the files "@EXPANDED_SYSCONFDIR@/dbus-1/system.conf" and +"@EXPANDED_SYSCONFDIR@/dbus-1/session.conf". These files normally <include> a system-local.conf or session-local.conf; you can put local overrides in those files to avoid modifying the primary configuration files.</para> @@ -171,43 +194,50 @@ doctype declaration:</para> <para>The following elements may be present in the configuration file.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><busconfig></emphasis></term> - <listitem> -<para></para> - </listitem> - </varlistentry> -</variablelist> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><busconfig></emphasis></para></listitem> + + +</itemizedlist> <para>Root element.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><type></emphasis></term> - <listitem> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><type></emphasis></para></listitem> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + +</itemizedlist> <para>The well-known type of the message bus. Currently known values are "system" and "session"; if other values are set, they should be either added to the D-Bus specification, or namespaced. The last -<type> element "wins" (previous values are ignored).</para> +<type> element "wins" (previous values are ignored). This element +only controls which message bus specific environment variables are +set in activated clients. Most of the policy that distinguishes a +session bus from the system bus is controlled from the other elements +in the configuration file.</para> + + +<para>If the well-known type of the message bus is "session", then the +DBUS_STARTER_BUS_TYPE environment variable will be set to "session" +and the DBUS_SESSION_BUS_ADDRESS environment variable will be set +to the address of the session bus. Likewise, if the type of the +message bus is "system", then the DBUS_STARTER_BUS_TYPE environment +variable will be set to "system" and the DBUS_SESSION_BUS_ADDRESS +environment variable will be set to the address of the system bus +(which is normally well known anyway).</para> <para>Example: <type>session</type></para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><include></emphasis></term> - <listitem> -<para></para> - </listitem> - </varlistentry> -</variablelist> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><include></emphasis></para></listitem> + + +</itemizedlist> <para>Include a file <include>filename.conf</include> at this point. If the filename is relative, it is located relative to the configuration file @@ -215,19 +245,16 @@ doing the including.</para> <para><include> has an optional attribute "ignore_missing=(yes|no)" -which defaults to "no" if not provided. This attribute -controls whether it's a fatal error for the included file +which defaults to "no" if not provided. This attribute +controls whether it's a fatal error for the included file to be absent.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><includedir></emphasis></term> - <listitem> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><includedir></emphasis></para></listitem> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + +</itemizedlist> <para>Include all files in <includedir>foo.d</includedir> at this point. Files in the directory are included in undefined order. @@ -237,18 +264,15 @@ Only files ending in ".conf" are included.</para> <para>This is intended to allow extension of the system bus by particular packages. For example, if CUPS wants to be able to send out notification of printer queue changes, it could install a file to -/etc/dbus-1/system.d that allowed all apps to receive +@EXPANDED_SYSCONFDIR@/dbus-1/system.d that allowed all apps to receive this message and allowed the printer daemon user to send it.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><user></emphasis></term> - <listitem> +<itemizedlist remap='TP'> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + <listitem><para><emphasis remap='I'><user></emphasis></para></listitem> + + +</itemizedlist> <para>The user account the daemon should run as, as either a username or a UID. If the daemon cannot change to this UID on startup, it will exit. @@ -261,97 +285,127 @@ about its UID.</para> <para>The user is changed after the bus has completed initialization. So sockets etc. will be created before changing user, but no data will be -read from clients before changing user. This means that sockets -and PID files can be created in a location that requires root +read from clients before changing user. This means that sockets +and PID files can be created in a location that requires root privileges for writing.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><fork></emphasis></term> - <listitem> -<para></para> - </listitem> - </varlistentry> -</variablelist> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><fork></emphasis></para></listitem> -<para>If present, the bus daemon becomes a real daemon (forks -into the background, etc.). This is generally used + +</itemizedlist> + +<para>If present, the bus daemon becomes a real daemon (forks +into the background, etc.). This is generally used rather than the --fork command line option.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><listen></emphasis></term> - <listitem> +<itemizedlist remap='TP'> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + <listitem><para><emphasis remap='I'><keep_umask></emphasis></para></listitem> + + +</itemizedlist> + +<para>If present, the bus daemon keeps its original umask when forking. +This may be useful to avoid affecting the behavior of child processes.</para> + +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><listen></emphasis></para></listitem> -<para>Add an address that the bus should listen on. The -address is in the standard D-Bus format that contains + +</itemizedlist> + +<para>Add an address that the bus should listen on. The +address is in the standard D-Bus format that contains a transport name plus possible parameters/options.</para> <para>Example: <listen>unix:path=/tmp/foo</listen></para> -<para>If there are multiple <listen> elements, then the bus listens -on multiple addresses. The bus will pass its address to -started services or other interested parties with -the last address given in <listen> first. That is, +<para>Example: <listen>tcp:host=localhost,port=1234</listen></para> + + +<para>If there are multiple <listen> elements, then the bus listens +on multiple addresses. The bus will pass its address to +started services or other interested parties with +the last address given in <listen> first. That is, apps will try to connect to the last <listen> address first.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><auth></emphasis></term> - <listitem> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> +<para>tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. +If a hostname resolves to multiple addresses, the server will bind +to all of them. The family=ipv4 or family=ipv6 options can be used +to force it to bind to a subset of addresses</para> + + +<para>Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen></para> + + +<para>A special case is using a port number of zero (or omitting the port), +which means to choose an available port selected by the operating +system. The port number chosen can be obtained with the +--print-address command line parameter and will be present in other +cases where the server reports its own address, such as when +DBUS_SESSION_BUS_ADDRESS is set.</para> + + +<para>Example: <listen>tcp:host=localhost,port=0</listen></para> + + +<para>tcp addresses also allow a bind=hostname option, which will override +the host option specifying what address to bind to, without changing +the address reported by the bus. The bind option can also take a +special name '*' to cause the bus to listen on all local address +(INADDR_ANY). The specified host should be a valid name of the local +machine or weird stuff will happen.</para> + + +<para>Example: <listen>tcp:host=localhost,bind=*,port=0</listen></para> + +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><auth></emphasis></para></listitem> + + +</itemizedlist> <para>Lists permitted authorization mechanisms. If this element doesn't exist, then all known mechanisms are allowed. If there are multiple <auth> elements, all the listed mechanisms are allowed. The order in which mechanisms are listed is not meaningful.</para> - + <para>Example: <auth>EXTERNAL</auth></para> <para>Example: <auth>DBUS_COOKIE_SHA1</auth></para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><servicedir></emphasis></term> - <listitem> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><servicedir></emphasis></para></listitem> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + +</itemizedlist> <para>Adds a directory to scan for .service files. Directories are -scanned starting with the last to appear in the config file -(the first .service file found that provides a particular +scanned starting with the last to appear in the config file +(the first .service file found that provides a particular service will be used).</para> <para>Service files tell the bus how to automatically start a program. -They are primarily used with the per-user-session bus, +They are primarily used with the per-user-session bus, not the systemwide bus.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><standard_session_servicedirs/></emphasis></term> - <listitem> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><standard_session_servicedirs/></emphasis></para></listitem> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + +</itemizedlist> <para><standard_session_servicedirs/> is equivalent to specifying a series of <servicedir/> elements for each of the data directories in the "XDG @@ -367,18 +421,48 @@ otherwise try your favorite search engine.</para> <para>The <standard_session_servicedirs/> option is only relevant to the per-user-session bus daemon defined in -/etc/dbus-1/session.conf. Putting it in any other +@EXPANDED_SYSCONFDIR@/dbus-1/session.conf. Putting it in any other configuration file would probably be nonsense.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><limit></emphasis></term> - <listitem> +<itemizedlist remap='TP'> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + <listitem><para><emphasis remap='I'><standard_system_servicedirs/></emphasis></para></listitem> + + +</itemizedlist> + +<para><standard_system_servicedirs/> specifies the standard system-wide +activation directories that should be searched for service files. +This option defaults to @EXPANDED_DATADIR@/dbus-1/system-services.</para> + + +<para>The <standard_system_servicedirs/> option is only relevant to the +per-system bus daemon defined in +@EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other +configuration file would probably be nonsense.</para> + +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><servicehelper/></emphasis></para></listitem> + + +</itemizedlist> + +<para><servicehelper/> specifies the setuid helper that is used to launch +system daemons with an alternate user. Typically this should be +the dbus-daemon-launch-helper executable in located in libexec.</para> + + +<para>The <servicehelper/> option is only relevant to the per-system bus daemon +defined in @EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other +configuration file would probably be nonsense.</para> + +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><limit></emphasis></para></listitem> + + +</itemizedlist> <para><limit> establishes a resource limit. For example:</para> <literallayout remap='.nf'> @@ -392,31 +476,36 @@ Available limit names are:</para> <literallayout remap='.nf'> "max_incoming_bytes" : total size in bytes of messages incoming from a single connection + "max_incoming_unix_fds" : total number of unix fds of messages + incoming from a single connection "max_outgoing_bytes" : total size in bytes of messages queued up for a single connection + "max_outgoing_unix_fds" : total number of unix fds of messages + queued up for a single connection "max_message_size" : max size of a single message in bytes - "service_start_timeout" : milliseconds (thousandths) until + "max_message_unix_fds" : max unix fds of a single message + "service_start_timeout" : milliseconds (thousandths) until a started service has to connect "auth_timeout" : milliseconds (thousandths) a connection is given to authenticate - "max_completed_connections" : max number of authenticated connections + "max_completed_connections" : max number of authenticated connections "max_incomplete_connections" : max number of unauthenticated connections "max_connections_per_user" : max number of completed connections from the same user "max_pending_service_starts" : max number of service launches in progress at the same time - "max_names_per_connection" : max number of names a single + "max_names_per_connection" : max number of names a single connection can own - "max_match_rules_per_connection": max number of match rules for a single + "max_match_rules_per_connection": max number of match rules for a single connection - "max_replies_per_connection" : max number of pending method + "max_replies_per_connection" : max number of pending method replies per connection (number of calls-in-progress) - "reply_timeout" : milliseconds (thousandths) - until a method call times out + "reply_timeout" : milliseconds (thousandths) + until a method call times out </literallayout> <!-- .fi --> @@ -430,49 +519,60 @@ number of users that can work together to denial-of-service all other users by u up all connections on the systemwide bus.</para> -<para>Limits are normally only of interest on the systemwide bus, not the user session +<para>Limits are normally only of interest on the systemwide bus, not the user session buses.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><policy></emphasis></term> - <listitem> +<itemizedlist remap='TP'> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + <listitem><para><emphasis remap='I'><policy></emphasis></para></listitem> + + +</itemizedlist> <para>The <policy> element defines a security policy to be applied to a particular set of connections to the bus. A policy is made up of <allow> and <deny> elements. Policies are normally used with the systemwide bus; -they are analogous to a firewall in that they allow expected traffic +they are analogous to a firewall in that they allow expected traffic and prevent unexpected traffic.</para> -<para>The <policy> element has one of three attributes:</para> +<para>Currently, the system bus has a default-deny policy for sending method calls +and owning bus names. Everything else, in particular reply messages, receive +checks, and signals has a default allow policy.</para> + + +<para>In general, it is best to keep system services as small, targeted programs which +run in their own process and provide a single bus name. Then, all that is needed +is an <allow> rule for the "own" permission to let the process claim the bus +name, and a "send_destination" rule to allow traffic from some or all uids to +your service.</para> + + +<para>The <policy> element has one of four attributes:</para> <literallayout remap='.nf'> context="(default|mandatory)" + at_console="(true|false)" user="username or userid" group="group name or gid" </literallayout> <!-- .fi --> -<para> -Policies are applied to a connection as follows:</para> +<para>Policies are applied to a connection as follows:</para> <literallayout remap='.nf'> - all context="default" policies are applied - all group="connection's user's group" policies are applied in undefined order - all user="connection's auth user" policies are applied in undefined order + - all at_console="true" policies are applied + - all at_console="false" policies are applied - all context="mandatory" policies are applied </literallayout> <!-- .fi --> -<para>Policies applied later will override those applied earlier, -when the policies overlap. Multiple policies with the same -user/group/context are applied in the order they appear +<para>Policies applied later will override those applied earlier, +when the policies overlap. Multiple policies with the same +user/group/context are applied in the order they appear in the config file.</para> <variablelist remap='TP'> @@ -493,16 +593,16 @@ statements, and works just like <deny> but with the inverse meaning.</para <para>The possible attributes of these elements are:</para> <literallayout remap='.nf'> send_interface="interface_name" - send_member="method_or_signal_name" - send_error="error_name" - send_destination="name" - send_type="method_call" | "method_return" | "signal" | "error" + send_member="method_or_signal_name" + send_error="error_name" + send_destination="name" + send_type="method_call" | "method_return" | "signal" | "error" send_path="/path/name" receive_interface="interface_name" - receive_member="method_or_signal_name" - receive_error="error_name" - receive_sender="name" + receive_member="method_or_signal_name" + receive_error="error_name" + receive_sender="name" receive_type="method_call" | "method_return" | "signal" | "error" receive_path="/path/name" @@ -520,9 +620,7 @@ statements, and works just like <deny> but with the inverse meaning.</para <para>Examples:</para> <literallayout remap='.nf'> - <deny send_interface="org.freedesktop.System" send_member="Reboot"/> - <deny receive_interface="org.freedesktop.System" receive_member="Reboot"/> - <deny own="org.freedesktop.System"/> + <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/> <deny send_destination="org.freedesktop.System"/> <deny receive_sender="org.freedesktop.System"/> <deny user="john"/> @@ -534,34 +632,29 @@ statements, and works just like <deny> but with the inverse meaning.</para particular action. If it matches, the action is denied (unless later rules in the config file allow it).</para> - <para>send_destination and receive_sender rules mean that messages may not be sent to or received from the *owner* of the given name, not that they may not be sent *to that name*. That is, if a connection owns services A, B, C, and sending to A is denied, sending to B or C will not work either.</para> - <para>The other send_* and receive_* attributes are purely textual/by-value matches against the given field in the message header.</para> - <para>"Eavesdropping" occurs when an application receives a message that -was explicitly addressed to a name the application does not own. -Eavesdropping thus only applies to messages that are addressed to -services (i.e. it does not apply to signals).</para> - +was explicitly addressed to a name the application does not own, or +is a reply to such a message. Eavesdropping thus only applies to +messages that are addressed to services and replies to such messages +(i.e. it does not apply to signals).</para> -<para>For <allow>, eavesdrop="true" indicates that the rule matches even -when eavesdropping. eavesdrop="false" is the default and means that +<para>For <allow>, eavesdrop="true" indicates that the rule matches even +when eavesdropping. eavesdrop="false" is the default and means that the rule only allows messages to go to their specified recipient. -For <deny>, eavesdrop="true" indicates that the rule matches +For <deny>, eavesdrop="true" indicates that the rule matches only when eavesdropping. eavesdrop="false" is the default for <deny> -also, but here it means that the rule applies always, even when +also, but here it means that the rule applies always, even when not eavesdropping. The eavesdrop attribute can only be combined with -receive rules (with receive_* attributes).</para> - - +send and receive rules (with send_* and receive_* attributes).</para> <para>The [send|receive]_requested_reply attribute works similarly to the eavesdrop attribute. It controls whether the <deny> or <allow> matches a reply @@ -582,7 +675,7 @@ requested. [send|receive]_requested_reply="true" indicates that the rule applies always, regardless of pending reply state.</para> -<para>user and group denials mean that the given user or group may +<para>user and group denials mean that the given user or group may not connect to the message bus.</para> @@ -591,6 +684,7 @@ the character "*" can be substituted, meaning "any." Complex globs like "foo.bar.*" aren't allowed for now because they'd be work to implement and maybe encourage sloppy security anyway.</para> + <para><allow own_prefix="a.b"/> allows you to own the name "a.b" or any name whose first dot-separated elements are "a.b": in particular, you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". @@ -599,6 +693,7 @@ define a meaning for subtrees of well-known names, such as org.freedesktop.Telepathy.ConnectionManager.(anything) and org.freedesktop.ReserveDevice1.(anything).</para> + <para>It does not make sense to deny a user or group inside a <policy> for a user or group; user/group denials can only be inside context="default" or context="mandatory" policies.</para> @@ -617,42 +712,40 @@ rule, since "whether the message can be sent" and "whether it can be received" are evaluated separately.</para> -<para>Be careful with send_interface/receive_interface, because the -interface field in messages is optional.</para> +<para>Be careful with send_interface/receive_interface, because the +interface field in messages is optional. In particular, do NOT +specify <deny send_interface="org.foo.Bar"/>! This will cause +no-interface messages to be blocked for all services, which is +almost certainly not what you intended. Always use rules of +the form: <deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/></para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><selinux></emphasis></term> - <listitem> +<itemizedlist remap='TP'> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + <listitem><para><emphasis remap='I'><selinux></emphasis></para></listitem> + + +</itemizedlist> <para>The <selinux> element contains settings related to Security Enhanced Linux. More details below.</para> -<variablelist remap='TP'> - <varlistentry> - <term><emphasis remap='I'><associate></emphasis></term> - <listitem> +<itemizedlist remap='TP'> + + <listitem><para><emphasis remap='I'><associate></emphasis></para></listitem> -<para></para> <!-- FIXME: blank list item --> - </listitem> - </varlistentry> -</variablelist> + +</itemizedlist> <para>An <associate> element appears below an <selinux> element and creates a mapping. Right now only one kind of association is possible:</para> <literallayout remap='.nf'> - <associate own="org.freedesktop.Foobar" context="foo_t"/> + <associate own="org.freedesktop.Foobar" context="foo_t"/> </literallayout> <!-- .fi --> <para>This means that if a connection asks to own the name "org.freedesktop.Foobar" then the source context will be the context -of the connection and the target context will be "foo_t" - see the +of the connection and the target context will be "foo_t" - see the short discussion of SELinux below.</para> @@ -663,7 +756,7 @@ NOT the context of the connection owning the name.</para> <para>There's currently no way to set a default for owning any name, if we add this syntax it will look like:</para> <literallayout remap='.nf'> - <associate own="*" context="foo_t"/> + <associate own="*" context="foo_t"/> </literallayout> <!-- .fi --> <para>If you find a reason this is useful, let the developers know. Right now the default will be the security context of the bus itself.</para> @@ -715,30 +808,75 @@ the first connection as source, security context of the second connection as target, object class "dbus" and requested permission "send_msg".</para> -<para>If a security context is not available for a connection -(impossible when using UNIX domain sockets), then the target +<para>If a security context is not available for a connection +(impossible when using UNIX domain sockets), then the target context used is the context of the bus daemon itself. -There is currently no way to change this default, because we're -assuming that only UNIX domain sockets will be used to -connect to the systemwide bus. If this changes, we'll +There is currently no way to change this default, because we're +assuming that only UNIX domain sockets will be used to +connect to the systemwide bus. If this changes, we'll probably add a way to set the default connection context.</para> -<para>Second, any time a connection asks to own a name, -the bus daemon will check permissions with the security +<para>Second, any time a connection asks to own a name, +the bus daemon will check permissions with the security context of the connection as source, the security context specified -for the name in the config file as target, object +for the name in the config file as target, object class "dbus" and requested permission "acquire_svc".</para> -<para>The security context for a bus name is specified with the +<para>The security context for a bus name is specified with the <associate> element described earlier in this document. -If a name has no security context associated in the -configuration file, the security context of the bus daemon +If a name has no security context associated in the +configuration file, the security context of the bus daemon itself will be used.</para> </refsect1> +<refsect1 id='debugging'><title>DEBUGGING</title> +<para>If you're trying to figure out where your messages are going or why +you aren't getting messages, there are several things you can try.</para> + +<para>Remember that the system bus is heavily locked down and if you +haven't installed a security policy file to allow your message +through, it won't work. For the session bus, this is not a concern.</para> + +<para>The simplest way to figure out what's happening on the bus is to run +the <emphasis remap='I'>dbus-monitor</emphasis> program, which comes with the D-Bus +package. You can also send test messages with <emphasis remap='I'>dbus-send</emphasis>. These +programs have their own man pages.</para> + +<para>If you want to know what the daemon itself is doing, you might consider +running a separate copy of the daemon to test against. This will allow you +to put the daemon under a debugger, or run it with verbose output, without +messing up your real session and system daemons.</para> + +<para>To run a separate test copy of the daemon, for example you might open a terminal +and type:</para> +<literallayout remap='.nf'> + DBUS_VERBOSE=1 dbus-daemon --session --print-address +</literallayout> <!-- .fi --> + +<para>The test daemon address will be printed when the daemon starts. You will need +to copy-and-paste this address and use it as the value of the +DBUS_SESSION_BUS_ADDRESS environment variable when you launch the applications +you want to test. This will cause those applications to connect to your +test bus instead of the DBUS_SESSION_BUS_ADDRESS of your real session bus.</para> + +<para>DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus +was compiled with verbose mode enabled. This is not recommended in +production builds due to performance impact. You may need to rebuild +D-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE +also affects the D-Bus library and thus applications using D-Bus; it may +be useful to see verbose output on both the client side and from the daemon.)</para> + +<para>If you want to get fancy, you can create a custom bus +configuration for your test bus (see the session.conf and system.conf +files that define the two default configurations for example). This +would allow you to specify a different directory for .service files, +for example.</para> + +</refsect1> + <refsect1 id='author'><title>AUTHOR</title> <para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para> @@ -749,4 +887,3 @@ itself will be used.</para> see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para> </refsect1> </refentry> - diff --git a/doc/dbus-faq.html b/doc/dbus-faq.html deleted file mode 100644 index c42e1b2f..00000000 --- a/doc/dbus-faq.html +++ /dev/null @@ -1,437 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>D-Bus FAQ</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" title="D-Bus FAQ"><div class="titlepage"><div><div><h2 class="title"><a name="index"></a>D-Bus FAQ</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:hp@pobox.com">hp@pobox.com</a>></code><br> - </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="othername">A</span> <span class="surname">Wheeler</span></h3></div></div></div><div><p class="releaseinfo">Version 0.3</p></div></div><hr></div><div class="qandaset" title="Frequently Asked Questions"><a name="faq"></a><dl><dt>1. <a href="#idp48080"> - What is D-Bus? - </a></dt><dt>2. <a href="#idp51984"> - Is D-Bus stable/finished? - </a></dt><dt>3. <a href="#idp55152"> - How is the reference implementation licensed? Can I use it in - proprietary applications? - </a></dt><dt>4. <a href="#idp59104"> - What is the difference between a bus name, and object path, - and an interface? - </a></dt><dt>5. <a href="#service"> - What is a "service"? - </a></dt><dt>6. <a href="#components"> - Is D-Bus a "component system"? - </a></dt><dt>7. <a href="#speed"> - How fast is the D-Bus reference implementation? - </a></dt><dt>8. <a href="#size"> - How large is the D-Bus reference implementation? - </a></dt><dt>9. <a href="#other-ipc"> - How does D-Bus differ from other interprocess communication - or networking protocols? - </a></dt><dt>10. <a href="#corba"> - How does D-Bus differ from CORBA? - </a></dt><dt>11. <a href="#xmlrpcsoap"> - How does D-Bus differ from XML-RPC and SOAP? - </a></dt><dt>12. <a href="#dce"> - How does D-Bus differ from DCE? - </a></dt><dt>13. <a href="#dcom"> - How does D-Bus differ from DCOM and COM? - </a></dt><dt>14. <a href="#internet-communications-engine"> - How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) - </a></dt><dt>15. <a href="#inter-client-exchange"> - How does D-Bus differ from Inter-Client Exchange (ICE)? - </a></dt><dt>16. <a href="#dcop"> - How does D-Bus differ from DCOP? - </a></dt><dt>17. <a href="#yet-more-ipc"> - How does D-Bus differ from [yet more IPC mechanisms]? - </a></dt><dt>18. <a href="#which-ipc"> - Which IPC mechanism should I use? - </a></dt><dt>19. <a href="#idp4836432"> - How can I submit a bug or patch? - </a></dt></dl><table border="0" width="100%" summary="Q and A Set"><col align="left" width="1%"><col><tbody><tr class="question" title="1."><td align="left" valign="top"><a name="idp48080"></a><a name="idp48336"></a><p><b>1.</b></p></td><td align="left" valign="top"><p> - What is D-Bus? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - This is probably best answered by reading the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> or - the introduction to the <a class="ulink" href="dbus-specification.html" target="_top">specification</a>. In - short, it is a system consisting of 1) a wire protocol for exposing a - typical object-oriented language/framework to other applications; and - 2) a bus daemon that allows applications to find and monitor one another. - Phrased differently, D-Bus is 1) an interprocess communication (IPC) system and 2) some higher-level - structure (lifecycle tracking, service activation, security policy) provided by two bus daemons, - one systemwide and one per-user-session. - </p></td></tr><tr class="question" title="2."><td align="left" valign="top"><a name="idp51984"></a><a name="idp52240"></a><p><b>2.</b></p></td><td align="left" valign="top"><p> - Is D-Bus stable/finished? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - The low-level library "libdbus" and the protocol specification are considered - ABI stable. The <a class="ulink" href="README" target="_top">README</a> - file has a discussion of the API/ABI stability guarantees. - Higher-level bindings (such as those for Qt, GLib, Python, Java, C#) each - have their own release schedules and degree of maturity, not linked to - the low-level library and bus daemon release. Check the project page for - the binding you're considering to understand that project's policies. - </p></td></tr><tr class="question" title="3."><td align="left" valign="top"><a name="idp55152"></a><a name="idp55408"></a><p><b>3.</b></p></td><td align="left" valign="top"><p> - How is the reference implementation licensed? Can I use it in - proprietary applications? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - The short answer is yes, you can use it in proprietary applications. - You should read the <a class="ulink" href="COPYING" target="_top">COPYING</a> file, which - offers you the choice of two licenses. These are the GPL and the - AFL. The GPL requires that your application be licensed under the GPL - as well. The AFL is an "X-style" or "BSD-style" license compatible - with proprietary licensing, but it does have some requirements; in - particular it prohibits you from filing a lawsuit alleging that the - D-Bus software infringes your patents <span class="emphasis"><em>while you continue to - use D-Bus</em></span>. If you're going to sue, you have to stop using - the software. Read the licenses to determine their meaning, this FAQ - entry is not intended to change the meaning or terms of the licenses. - </p></td></tr><tr class="question" title="4."><td align="left" valign="top"><a name="idp59104"></a><a name="idp59360"></a><p><b>4.</b></p></td><td align="left" valign="top"><p> - What is the difference between a bus name, and object path, - and an interface? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - If you imagine a C++ program that implements a network service, then - the bus name is the hostname of the computer running this C++ program, - the object path is a C++ object instance pointer, and an interface is - a C++ class (a pure virtual or abstract class, to be exact). - </p><p> - In Java terms, the object path is an object reference, - and an interface is a Java interface. - </p><p> - People get confused because if they write an application - with a single object instance and a single interface, - then the bus name, object path, and interface look - redundant. For example, you might have a text editor - that uses the bus name <code class="literal">org.freedesktop.TextEditor</code>, - has a global singleton object called - <code class="literal">/org/freedesktop/TextEditor</code>, and - that singleton object could implement the interface - <code class="literal">org.freedesktop.TextEditor</code>. - </p><p> - However, a text editor application could as easily own multiple bus - names (for example, <code class="literal">org.kde.KWrite</code> in addition to - generic <code class="literal">TextEditor</code>), have multiple objects (maybe - <code class="literal">/org/kde/documents/4352</code> where the number changes - according to the document), and each object could implement multiple - interfaces, such as <code class="literal">org.freedesktop.DBus.Introspectable</code>, - <code class="literal">org.freedesktop.BasicTextField</code>, - <code class="literal">org.kde.RichTextDocument</code>. - </p></td></tr><tr class="question" title="5."><td align="left" valign="top"><a name="service"></a><a name="idp3746896"></a><p><b>5.</b></p></td><td align="left" valign="top"><p> - What is a "service"? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - A service is a program that can be launched by the bus daemon - to provide some functionality to other programs. Services - are normally launched according to the bus name they will - have. - </p><p> - People often misuse the word "service" for any - bus name, but this tends to be ambiguous and confusing so is discouraged. - In the D-Bus docs we try to use "service" only when talking about - programs the bus knows how to launch, i.e. a service always has a - .service file. - </p></td></tr><tr class="question" title="6."><td align="left" valign="top"><a name="components"></a><a name="idp3750112"></a><p><b>6.</b></p></td><td align="left" valign="top"><p> - Is D-Bus a "component system"? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - It helps to keep these concepts separate in your mind: - </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> - Object/component system - </p></li><li class="listitem"><p> - GUI control/widget embedding interfaces - </p></li><li class="listitem"><p> - Interprocess communication system or wire protocol - </p></li></ol></div><p> - </p><p> - D-Bus is not a component system. "Component system" was originally - defined by COM, and was essentially a workaround for the limitations - of the C++ object system (adding introspection, runtime location of - objects, ABI guarantees, and so forth). With the C# language and CLR, - Microsoft added these features to the primary object system, leaving - COM obsolete. Similarly, Java has much less need for something like - COM than C++ did. Even QObject (from Qt) and GObject (from GLib) offer - some of the same features found in COM. - </p><p> - Component systems are not about GUI control embedding. Embedding - a spreadsheet in a word processor document is a matter of defining - some specific <span class="emphasis"><em>interfaces</em></span> that objects - can implement. These interfaces provide methods related to - GUI controls. So an object implementing those interfaces - can be embedded. - </p><p> - The word "component" just means "object with some fancy features" and - in modern languages all objects are effectively "components." - </p><p> - So components are fancy objects, and some objects are GUI controls. - </p><p> - A third, unrelated feature is interprocess communication or IPC. - D-Bus is an IPC system. Given an object (or "component" if you must), - you can expose the functionality of that object over an IPC system. - Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus. - You can use any of these IPC systems with any object/component system, - though some of them are "tuned" for specific object systems. - You can think of an IPC system primarily as a wire protocol. - </p><p> - If you combine an IPC system with a set of GUI control interfaces, - then you can have an out-of-process or dynamically-loaded GUI control. - </p><p> - Another related concept is the <em class="firstterm">plugin</em> or - <em class="firstterm">extension</em>. Generic plugin systems such as the - <a class="ulink" href="http://eclipse.org" target="_top">Eclipse</a> system are not so different - from component/object systems, though perhaps a "plugin" tends to be a - bundle of objects with a user-visible name and can be - downloaded/packaged as a unit. - </p></td></tr><tr class="question" title="7."><td align="left" valign="top"><a name="speed"></a><a name="idp28640"></a><p><b>7.</b></p></td><td align="left" valign="top"><p> - How fast is the D-Bus reference implementation? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Of course it depends a bit on what you're doing. - <a class="ulink" href="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html" target="_top"> - This mail</a> contains some benchmarking. At the time of that - benchmark, D-Bus one-to-one communication was about 2.5x slower than - simply pushing the data raw over a socket. After the recent rewrite of - the marshaling code, D-Bus is slower than that because a lot of - optimization work was lost. But it can probably be sped up again. - </p><p> - D-Bus communication with the intermediate bus daemon should be - (and as last profiled, was) about twice as slow as one-to-one - mode, because a round trip involves four socket reads/writes rather - than two socket reads/writes. - </p><p> - The overhead comes from a couple of places; part of it is simply - "abstraction penalty" (there are layers of code to support - multiple main loops, multiple transport types, security, etc.). - Probably the largest part comes from data validation - (because the reference implementation does not trust incoming data). - It would be simple to add a "no validation" mode, but probably - not a good idea all things considered. - </p><p> - Raw bandwidth isn't the only concern; D-Bus is designed to - enable asynchronous communication and avoid round trips. - This is frequently a more important performance issue - than throughput. - </p></td></tr><tr class="question" title="8."><td align="left" valign="top"><a name="size"></a><a name="idp34160"></a><p><b>8.</b></p></td><td align="left" valign="top"><p> - How large is the D-Bus reference implementation? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - A production build (with assertions, unit tests, and verbose logging - disabled) is on the order of a 150K shared library. - </p><p> - A much, much smaller implementation would be possible by omitting out - of memory handling, hardcoding a main loop (or always using blocking - I/O), skipping validation, and otherwise simplifying things. - </p></td></tr><tr class="question" title="9."><td align="left" valign="top"><a name="other-ipc"></a><a name="idp37280"></a><p><b>9.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from other interprocess communication - or networking protocols? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Keep in mind, it is not only an IPC system; it also includes - lifecycle tracking, service activation, security policy, and other - higher-level structure and assumptions. - </p><p> - The best place to start is to read the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a>, so - you have a concrete idea what D-Bus actually is. If you - understand other protocols on a wire format level, you - may also want to read the D-Bus <a class="ulink" href="dbus-specification.html" target="_top">specification</a> to see what - D-Bus looks like on a low level. - </p><p> - As the <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> and <a class="ulink" href="dbus-specification.html" target="_top">specification</a> both explain, D-Bus is tuned - for some specific use cases. Thus, it probably isn't tuned - for what you want to do, unless you are doing the things - D-Bus was designed for. Don't make the mistake of thinking - that any system involving "IPC" is the same thing. - </p><p> - The D-Bus authors would not recommend using D-Bus - for applications where it doesn't make sense. - The following questions compare D-Bus to some other - protocols primarily to help you understand D-Bus - and decide whether it's appropriate; D-Bus is neither intended - nor claimed to be the right choice for every application. - </p><p> - It should be possible to bridge D-Bus to other IPC systems, - just as D-Bus can be bridged to object systems. - </p><p> - Note: the D-Bus mailing list subscribers are <span class="emphasis"><em>very much not - interested</em></span> in debating which IPC system is the One True - System. So if you want to discuss that, please use another forum. - </p></td></tr><tr class="question" title="10."><td align="left" valign="top"><a name="corba"></a><a name="idp4762800"></a><p><b>10.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from CORBA? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - <a class="ulink" href="http://www.omg.org" target="_top">CORBA</a> is designed to support - object-oriented IPC between objects, automatically marshalling - parameters as necessary. CORBA is strongly supported by the <a class="ulink" href="http://www.omg.org" target="_top">Open Management Group (OMG)</a>, which - produces various standards and supporting documents for CORBA and has - the backing of many large organizations. There are many CORBA ORBs - available, both proprietary ORBs and free / open source software ORBs - (the latter include <a class="ulink" href="http://orbit-resource.sourceforge.net/" target="_top">ORBit</a>, <a class="ulink" href="http://www.mico.org/" target="_top">MICO</a>, and <a class="ulink" href="http://www.theaceorb.com/" target="_top">The ACE Orb (TAO)</a>). Many - organizations continue to use CORBA ORBs for various kinds of IPC. - </p><p> - Both GNOME and KDE have used CORBA and then moved away from it. KDE - had more success with a system called DCOP, and GNOME layered a system - called Bonobo on top of CORBA. Without custom extensions, CORBA does - not support many of the things one wants to do in a desktop - environment with the GNOME/KDE architecture. - </p><p> - CORBA on the other hand has a number of features of interest for - enterprise and web application development, though XML systems such as - SOAP are the latest fad. - </p><p> - Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems - work in terms of objects and methods, and have concepts such as - "oneway" calls. Only D-Bus has direct support for "signals" as in - GLib/Qt (or Java listeners, or C# delegates). - </p><p> - D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, - because CORBA is more generic and D-Bus has two specific use-cases in mind. - This makes D-Bus a bit simpler. - </p><p> - However, unlike CORBA D-Bus does <span class="emphasis"><em>not</em></span> specify the - API for the language bindings. Instead, "native" bindings adapted - specifically to the conventions of a framework such as QObject, - GObject, C#, Java, Python, etc. are encouraged. The libdbus reference - implementation is designed to be a backend for bindings of this - nature, rather than to be used directly. The rationale is that an IPC - system API should not "leak" all over a program; it should come into - play only just before data goes over the wire. As an aside, OMG is - apparently working on a simpler C++ binding for CORBA. - </p><p> - Many CORBA implementations such as ORBit are faster than the libdbus - reference implementation. One reason is that D-Bus considers data - from the other end of the connection to be untrusted and extensively - validates it. But generally speaking other priorities were placed - ahead of raw speed in the libdbus implementation. A fast D-Bus - implementation along the lines of ORBit should be possible, of course. - </p><p> - On a more trivial note, D-Bus involves substantially fewer acronyms - than CORBA. - </p></td></tr><tr class="question" title="11."><td align="left" valign="top"><a name="xmlrpcsoap"></a><a name="idm35328"></a><p><b>11.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from XML-RPC and SOAP? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - In <a class="ulink" href="http://www.w3.org/TR/SOAP/" target="_top">SOAP</a> and <a class="ulink" href="http://www.xmlrpc.com" target="_top">XML-RPC</a>, RPC calls are transformed - into an XML-based format, then sent over the wire (typically using the - HTTP protocol), where they are processed and returned. XML-RPC is the - simple protocol (its spec is only a page or two), and SOAP is the - full-featured protocol. - </p><p> - XML-RPC and SOAP impose XML parsing overhead that is normally - irrelevant in the context of the Internet, but significant for - constant fine-grained IPC among applications in a desktop session. - </p><p> - D-Bus offers persistent connections and with the bus daemon - supports lifecycle tracking of other applications connected - to the bus. With XML-RPC and SOAP, typically each method call - exists in isolation and has its own HTTP connection. - </p></td></tr><tr class="question" title="12."><td align="left" valign="top"><a name="dce"></a><a name="idp4801888"></a><p><b>12.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from DCE? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - <a class="ulink" href="http://www.opengroup.org/dce/" target="_top">Distributed Computing - Environment (DCE)</a> is an industry-standard vendor-neutral - standard that includes an IPC mechanism. <a class="ulink" href="http://www.opengroup.org/comm/press/05-01-12.htm" target="_top">The Open Group - has released an implementation as open source software</a>. DCE - is quite capable, and includes a vast amount of functionality such as - a distributed time service. As the name implies, DCE is intended for - use in a large, multi-computer distributed application. D-Bus would - not be well-suited for this. - </p></td></tr><tr class="question" title="13."><td align="left" valign="top"><a name="dcom"></a><a name="idp4806592"></a><p><b>13.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from DCOM and COM? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - Comparing D-Bus to COM is apples and oranges; - see <a class="xref" href="#components" title="6.">Q: 6</a>. - </p><p> - DCOM (distributed COM) is a Windows IPC system designed for use with - the COM object system. It's similar in some ways to DCE and CORBA. - </p></td></tr><tr class="question" title="14."><td align="left" valign="top"><a name="internet-communications-engine"></a><a name="idp4810864"></a><p><b>14.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - The <a class="ulink" href="http://www.zeroc.com/ice.html" target="_top"> Internet - Communications Engine (Ice)</a> is a powerful IPC mechanism more - on the level of SOAP or CORBA than D-Bus. Ice has a "dual-license" - business around it; i.e. you can use it under the GPL, or pay for a - proprietary license. - </p></td></tr><tr class="question" title="15."><td align="left" valign="top"><a name="inter-client-exchange"></a><a name="idp4814880"></a><p><b>15.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from Inter-Client Exchange (ICE)? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - <a class="ulink" href="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf" target="_top">ICE</a> - was developed for the X Session Management protocol (XSMP), as part of - the X Window System (X11R6.1). The idea was to allow desktop sessions - to contain nongraphical clients in addition to X clients. - </p><p> - ICE is a binary protocol designed for desktop use, and KDE's DCOP - builds on ICE. ICE is substantially simpler than D-Bus (in contrast - to most of the other IPC systems mentioned here, which are more - complex). ICE doesn't really define a mapping to objects and methods - (DCOP adds that layer). The reference implementation of ICE (libICE) - is often considered to be horrible (and horribly insecure). - </p><p> - DCOP and XSMP are the only two widely-used applications of ICE, - and both could in principle be replaced by D-Bus. (Though whether - GNOME and KDE will bother is an open question.) - </p></td></tr><tr class="question" title="16."><td align="left" valign="top"><a name="dcop"></a><a name="idp4819504"></a><p><b>16.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from DCOP? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - D-Bus is intentionally pretty similar to <a class="ulink" href="http://developer.kde.org/documentation/library/kdeqt/dcop.html" target="_top">DCOP</a>, - and can be thought of as a "DCOP the next generation" suitable for - sharing between the various open source desktop projects. - </p><p> - D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus - should not be more complex for programmers. The additional complexity - of D-Bus arises from its separation of object references vs. bus names - vs. interfaces as distinct concepts, and its support for one-to-one - connections in addition to connections over the bus. The libdbus - reference implementation has a lot of API to support multiple bindings - and main loops, and performs data validation and out-of-memory handling - in order to support secure applications such as the systemwide bus. - </p><p> - D-Bus is probably somewhat slower than DCOP due to data validation - and more "layers" in the reference implementation. A comparison - hasn't been posted to the list though. - </p><p> - At this time, KDE has not committed to using D-Bus, but there have - been discussions of KDE bridging D-Bus and DCOP, or even changing - DCOP's implementation to use D-Bus internally (so that GNOME and KDE - would end up using exactly the same bus). See the KDE mailing list - archives for some of these discussions. - </p></td></tr><tr class="question" title="17."><td align="left" valign="top"><a name="yet-more-ipc"></a><a name="idp4826496"></a><p><b>17.</b></p></td><td align="left" valign="top"><p> - How does D-Bus differ from [yet more IPC mechanisms]? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - There are countless uses of network sockets in the world. <a class="ulink" href="http://www.mbus.org/" target="_top">MBUS</a>, Sun ONC/RPC, Jabber/XMPP, - SIP, are some we can think of quickly. - </p></td></tr><tr class="question" title="18."><td align="left" valign="top"><a name="which-ipc"></a><a name="idp4830432"></a><p><b>18.</b></p></td><td align="left" valign="top"><p> - Which IPC mechanism should I use? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. - </p><p> - If you're writing an Internet or Intranet application, XML-RPC or SOAP - work for many people. These are standard, available for most - languages, simple to debug and easy to use. - </p><p> - If you're writing a desktop application for UNIX, - then D-Bus is of course our recommendation for - talking to other parts of the desktop session. - </p><p> - D-Bus is also designed for communications between system daemons and - communications between the desktop and system daemons. - </p><p> - If you're doing something complicated such as clustering, - distributed swarms, peer-to-peer, or whatever then - the authors of this FAQ don't have expertise in these - areas and you should ask someone else or try a search engine. - D-Bus is most likely a poor choice but could be appropriate - for some things. - </p><p> - Note: the D-Bus mailing list is probably not the place to - discuss which system is appropriate for your application, - though you are welcome to ask specific questions about - D-Bus <span class="emphasis"><em>after reading this FAQ, the tutorial, and - searching the list archives</em></span>. The best way - to search the list archives is probably to use - an Internet engine such as Google. On Google, - include "site:freedesktop.org" in your search. - </p></td></tr><tr class="question" title="19."><td align="left" valign="top"><a name="idp4836432"></a><a name="idp4836688"></a><p><b>19.</b></p></td><td align="left" valign="top"><p> - How can I submit a bug or patch? - </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> - The D-Bus <a class="ulink" href="http://dbus.freedesktop.org" target="_top">web site</a> - has a link to the bug tracker, which is the best place to store - patches. You can also post them to the list, especially if you want - to discuss the patch or get feedback. - </p></td></tr></tbody></table></div></div></body></html> diff --git a/doc/dbus-launch.1 b/doc/dbus-launch.1 deleted file mode 100644 index e22a3be0..00000000 --- a/doc/dbus-launch.1 +++ /dev/null @@ -1,211 +0,0 @@ -.\" -.\" dbus\-launch manual page. -.\" Copyright (C) 2003 Red Hat, Inc. -.\" -.TH dbus\-launch 1 -.SH NAME -dbus\-launch \- Utility to start a message bus from a shell script -.SH SYNOPSIS -.PP -.B dbus\-launch [\-\-version] [\-\-sh\-syntax] [\-\-csh\-syntax] [\-\-auto\-syntax] [\-\-exit\-with\-session] [\-\-autolaunch=MACHINEID] [\-\-config\-file=FILENAME] [PROGRAM] [ARGS...] - -.SH DESCRIPTION - -The \fIdbus\-launch\fP command is used to start a session bus -instance of \fIdbus\-daemon\fP from a shell script. -It would normally be called from a user's login -scripts. Unlike the daemon itself, \fIdbus\-launch\fP exits, so -backticks or the $() construct can be used to read information from -\fIdbus\-launch\fP. - -With no arguments, \fIdbus\-launch\fP will launch a session bus -instance and print the address and PID of that instance to standard -output. - -You may specify a program to be run; in this case, \fIdbus\-launch\fP -will launch a session bus instance, set the appropriate environment -variables so the specified program can find the bus, and then execute the -specified program, with the specified arguments. See below for -examples. - -If you launch a program, \fIdbus\-launch\fP will not print the -information about the new bus to standard output. - -When \fIdbus\-launch\fP prints bus information to standard output, by -default it is in a simple key\-value pairs format. However, you may -request several alternate syntaxes using the \-\-sh\-syntax, \-\-csh\-syntax, -\-\-binary\-syntax, or -\-\-auto\-syntax options. Several of these cause \fIdbus\-launch\fP to emit shell code -to set up the environment. - -With the \-\-auto\-syntax option, \fIdbus\-launch\fP looks at the value -of the SHELL environment variable to determine which shell syntax -should be used. If SHELL ends in "csh", then csh\-compatible code is -emitted; otherwise Bourne shell code is emitted. Instead of passing -\-\-auto\-syntax, you may explicitly specify a particular one by using -\-\-sh\-syntax for Bourne syntax, or \-\-csh\-syntax for csh syntax. -In scripts, it's more robust to avoid \-\-auto\-syntax and you hopefully -know which shell your script is written in. - -.PP -See http://www.freedesktop.org/software/dbus/ for more information -about D\-Bus. See also the man page for \fIdbus\-daemon\fP. - -.SH EXAMPLES - -Distributions running -.B dbus\-launch -as part of a standard X session should run -.B "dbus\-launch \-\-exit\-with\-session" -after the X server has started and become available, as a wrapper around -the "main" X client (typically a session manager or window manager), as in -these examples: - -.RS -.B "dbus\-launch \-\-exit\-with\-session gnome\-session" - -.B "dbus\-launch \-\-exit\-with\-session openbox" - -.B "dbus\-launch \-\-exit\-with\-session ~/.xsession" -.RE - -If your distribution does not do this, you can achieve similar results -by running your session or window manager in the same way in a script -run by your X session, such as -.BR ~/.xsession , -.B ~/.xinitrc -or -.BR ~/.Xclients . - -To start a D-Bus session within a text-mode session, you can run -dbus-launch in the background. For instance, in a sh-compatible shell: - -.nf - ## test for an existing bus daemon, just to be safe - if test \-z "$DBUS_SESSION_BUS_ADDRESS" ; then - ## if not found, launch a new one - eval `dbus\-launch \-\-sh\-syntax` - echo "D\-Bus per\-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" - fi -.fi -Note that in this case, dbus-launch will exit, and dbus-daemon will not be -terminated automatically on logout. - -.SH AUTOMATIC LAUNCHING - -.PP -If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use -D\-Bus, by default the process will attempt to invoke dbus\-launch with -the \-\-autolaunch option to start up a new session bus or find the -existing bus address on the X display or in a file in -~/.dbus/session\-bus/ - -.PP -Whenever an autolaunch occurs, the application that had to -start a new bus will be in its own little world; it can effectively -end up starting a whole new session if it tries to use a lot of -bus services. This can be suboptimal or even totally broken, depending -on the app and what it tries to do. - -.PP -There are two common reasons for autolaunch. One is ssh to a remote -machine. The ideal fix for that would be forwarding of -DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded. -In the meantime, you can edit the session.conf config file to -have your session bus listen on TCP, and manually set -DBUS_SESSION_BUS_ADDRESS, if you like. - -.PP -The second common reason for autolaunch is an su to another user, and -display of X applications running as the second user on the display -belonging to the first user. Perhaps the ideal fix in this case -would be to allow the second user to connect to the session bus of the -first user, just as they can connect to the first user's display. -However, a mechanism for that has not been coded. - -.PP -You can always avoid autolaunch by manually setting -DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default -address if none is set is "autolaunch:", so if any other address is -set there will be no autolaunch. You can however include autolaunch in -an explicit session bus address as a fallback, for example -DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" \- in that case if -the first address doesn't work, processes will autolaunch. (The bus -address variable contains a comma\-separated list of addresses to try.) - -.PP -The \-\-autolaunch option is considered an internal implementation -detail of libdbus, and in fact there are plans to change it. There's -no real reason to use it outside of the libdbus implementation anyhow. - -.SH OPTIONS -The following options are supported: -.TP -.I "\-\-auto\-syntax" -Choose \-\-csh\-syntax or \-\-sh\-syntax based on the SHELL environment variable. - -.I "\-\-binary\-syntax" -Write to stdout a nul\-terminated bus address, then the bus PID as a -binary integer of size sizeof(pid_t), then the bus X window ID as a -binary integer of size sizeof(long). Integers are in the machine's -byte order, not network byte order or any other canonical byte order. - -.TP -.I "\-\-close\-stderr" -Close the standard error output stream before starting the D\-Bus -daemon. This is useful if you want to capture dbus\-launch error -messages but you don't want dbus\-daemon to keep the stream open to -your application. - -.TP -.I "\-\-config\-file=FILENAME" -Pass \-\-config\-file=FILENAME to the bus daemon, instead of passing it -the \-\-session argument. See the man page for dbus\-daemon - -.TP -.I "\-\-csh\-syntax" -Emit csh compatible code to set up environment variables. - -.TP -.I "\-\-exit\-with\-session" -If this option is provided, a persistent "babysitter" process will be -created that watches stdin for HUP and tries to connect to the X -server. If this process gets a HUP on stdin or loses its X connection, -it kills the message bus daemon. - -.TP -.I "\-\-autolaunch=MACHINEID" -This option implies that \fIdbus\-launch\fP should scan for a -previously\-started session and reuse the values found there. If no -session is found, it will start a new session. The -\-\-exit\-with\-session option is implied if \-\-autolaunch is given. -This option is for the exclusive use of libdbus, you do not want to -use it manually. It may change in the future. - -.TP -.I "\-\-sh\-syntax" -Emit Bourne\-shell compatible code to set up environment variables. - -.TP -.I "\-\-version" -Print the version of dbus\-launch - -.SH NOTES - -If you run -.B "dbus\-launch myapp" -(with any other options), dbus\-daemon will -.I not -exit when -.B myapp -terminates: this is because -.B myapp -is assumed to be part of a larger session, rather than a session in its -own right. - -.SH AUTHOR -See http://www.freedesktop.org/software/dbus/doc/AUTHORS - -.SH BUGS -Please send bug reports to the D\-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ diff --git a/cmake/tools/dbus-launch.xml b/doc/dbus-launch.1.xml.in index dc34898f..fde439da 100644 --- a/cmake/tools/dbus-launch.xml +++ b/doc/dbus-launch.1.xml.in @@ -1,17 +1,19 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> -<!-- lifted from troff+man by doclifter --> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> <refentry id='dbuslaunch1'> -<!-- --> -<!-- dbus\-launch manual page. --> -<!-- Copyright (C) 2003 Red Hat, Inc. --> + +<!-- dbus\-launch manual page. + Copyright (C) 2003 Red Hat, Inc. --> <refmeta> <refentrytitle>dbus-launch</refentrytitle> <manvolnum>1</manvolnum> +<refmiscinfo class="manual">User Commands</refmiscinfo> +<refmiscinfo class="source">D-Bus</refmiscinfo> +<refmiscinfo class="version">@DBUS_VERSION@</refmiscinfo> </refmeta> -<refnamediv id='name'> +<refnamediv> <refname>dbus-launch</refname> <refpurpose>Utility to start a message bus from a shell script</refpurpose> </refnamediv> @@ -33,7 +35,7 @@ <refsect1 id='description'><title>DESCRIPTION</title> -<para>The <command>dbus-launch</command> command is used to start a session bus +<para>The <command>dbus-launch</command> command is used to start a session bus instance of <emphasis remap='I'>dbus-daemon</emphasis> from a shell script. It would normally be called from a user's login scripts. Unlike the daemon itself, <command>dbus-launch</command> exits, so @@ -41,7 +43,7 @@ backticks or the $() construct can be used to read information from <command>dbus-launch</command>.</para> <para>With no arguments, <command>dbus-launch</command> will launch a session bus -instance and print the address and pid of that instance to standard +instance and print the address and PID of that instance to standard output.</para> <para>You may specify a program to be run; in this case, <command>dbus-launch</command> @@ -54,7 +56,7 @@ examples.</para> information about the new bus to standard output.</para> <para>When <command>dbus-launch</command> prints bus information to standard output, by -default it is in a simple key-value pairs format. However, you may +default it is in a simple key-value pairs format. However, you may request several alternate syntaxes using the --sh-syntax, --csh-syntax, --binary-syntax, or --auto-syntax options. Several of these cause <command>dbus-launch</command> to emit shell code @@ -64,7 +66,7 @@ to set up the environment.</para> of the SHELL environment variable to determine which shell syntax should be used. If SHELL ends in "csh", then csh-compatible code is emitted; otherwise Bourne shell code is emitted. Instead of passing ---auto-syntax, you may explicity specify a particular one by using +--auto-syntax, you may explicitly specify a particular one by using --sh-syntax for Bourne syntax, or --csh-syntax for csh syntax. In scripts, it's more robust to avoid --auto-syntax and you hopefully know which shell your script is written in.</para> @@ -73,44 +75,60 @@ know which shell your script is written in.</para> <para>See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about D-Bus. See also the man page for <emphasis remap='I'>dbus-daemon</emphasis>.</para> +</refsect1> -<para>Here is an example of how to use <command>dbus-launch</command> with an -sh-compatible shell to start the per-session bus daemon:</para> -<literallayout remap='.nf'> +<refsect1 id='examples'><title>EXAMPLES</title> +<para>Distributions running +<command>dbus-launch</command> +as part of a standard X session should run +<emphasis remap='B'>dbus-launch --exit-with-session</emphasis> +after the X server has started and become available, as a wrapper around +the "main" X client (typically a session manager or window manager), as in +these examples:</para> - ## test for an existing bus daemon, just to be safe - if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then - ## if not found, launch a new one - eval `dbus-launch --sh-syntax --exit-with-session` - echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" - fi + <blockquote remap='RS'> +<para><emphasis remap='B'>dbus-launch --exit-with-session gnome-session</emphasis></para> -</literallayout> <!-- .fi --> -<para>You might run something like that in your login scripts.</para> +<para><emphasis remap='B'>dbus-launch --exit-with-session openbox</emphasis></para> +<para><emphasis remap='B'>dbus-launch --exit-with-session ~/.xsession</emphasis> + </para></blockquote> <!-- remap='RE' --> -<para>Another way to use <command>dbus-launch</command> is to run your main session -program, like so:</para> -<literallayout remap='.nf'> +<para>If your distribution does not do this, you can achieve similar results +by running your session or window manager in the same way in a script +run by your X session, such as +<filename>~/.xsession</filename>, +<filename>~/.xinitrc</filename> +or +<filename>~/.Xclients</filename>.</para> -dbus-launch gnome-session +<para>To start a D-Bus session within a text-mode session, you can run +dbus-launch in the background. For instance, in a sh-compatible shell:</para> +<literallayout remap='.nf'> + ## test for an existing bus daemon, just to be safe + if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then + ## if not found, launch a new one + eval `dbus-launch --sh-syntax` + echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" + fi </literallayout> <!-- .fi --> -<para>The above would likely be appropriate for ~/.xsession or ~/.Xclients.</para> +<para>Note that in this case, dbus-launch will exit, and dbus-daemon will not be +terminated automatically on logout.</para> </refsect1> <refsect1 id='automatic_launching'><title>AUTOMATIC LAUNCHING</title> <para>If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with -the --autolaunch option to start up a new session bus or find the +the --autolaunch option to start up a new session bus or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/</para> <para>Whenever an autolaunch occurs, the application that had to start a new bus will be in its own little world; it can effectively -end up starting a whole new session if it tries to use a lot of +end up starting a whole new session if it tries to use a lot of bus services. This can be suboptimal or even totally broken, depending on the app and what it tries to do.</para> @@ -118,7 +136,7 @@ on the app and what it tries to do.</para> <para>There are two common reasons for autolaunch. One is ssh to a remote machine. The ideal fix for that would be forwarding of DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded. -In the meantime, you can edit the session.conf config file to +In the meantime, you can edit the session.conf config file to have your session bus listen on TCP, and manually set DBUS_SESSION_BUS_ADDRESS, if you like.</para> @@ -176,7 +194,7 @@ your application.</para> <varlistentry> <term><option>--config-file=FILENAME</option></term> <listitem> -<para>Pass --config-file=FILENAME to the bus daemon, instead of passing it +<para>Pass --config-file=FILENAME to the bus daemon, instead of passing it the --session argument. See the man page for dbus-daemon</para> </listitem> @@ -191,7 +209,7 @@ the --session argument. See the man page for dbus-daemon</para> <varlistentry> <term><option>--exit-with-session</option></term> <listitem> -<para>If this option is provided, a persistent "babysitter" process will be +<para>If this option is provided, a persistent "babysitter" process will be created that watches stdin for HUP and tries to connect to the X server. If this process gets a HUP on stdin or loses its X connection, it kills the message bus daemon.</para> @@ -227,6 +245,20 @@ use it manually. It may change in the future.</para> </variablelist> </refsect1> +<refsect1 id='notes'><title>NOTES</title> +<para>If you run +<emphasis remap='B'>dbus-launch myapp</emphasis> +(with any other options), dbus-daemon will +<emphasis remap='I'>not</emphasis> +exit when +<emphasis remap='B'>myapp</emphasis> +terminates: this is because +<emphasis remap='B'>myapp</emphasis> +is assumed to be part of a larger session, rather than a session in its +own right.</para> + +</refsect1> + <refsect1 id='author'><title>AUTHOR</title> <para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para> @@ -237,4 +269,3 @@ use it manually. It may change in the future.</para> see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para> </refsect1> </refentry> - diff --git a/doc/dbus-monitor.1 b/doc/dbus-monitor.1 deleted file mode 100644 index 6282b9eb..00000000 --- a/doc/dbus-monitor.1 +++ /dev/null @@ -1,78 +0,0 @@ -.\" -.\" dbus\-monitor manual page. -.\" Copyright (C) 2003 Red Hat, Inc. -.\" -.TH dbus\-monitor 1 -.SH NAME -dbus\-monitor \- debug probe to print message bus messages -.SH SYNOPSIS -.PP -.B dbus\-monitor -[\-\-system | \-\-session | \-\-address ADDRESS] [\-\-profile | \-\-monitor] -[watch expressions] - -.SH DESCRIPTION - -The \fIdbus\-monitor\fP command is used to monitor messages going -through a D\-Bus message bus. See -http://www.freedesktop.org/software/dbus/ for more information about -the big picture. - -.PP -There are two well\-known message buses: the systemwide message bus -(installed on many systems as the "messagebus" service) and the -per\-user\-login\-session message bus (started each time a user logs in). -The \-\-system and \-\-session options direct \fIdbus\-monitor\fP to -monitor the system or session buses respectively. If neither is -specified, \fIdbus\-monitor\fP monitors the session bus. - -.PP -\fIdbus\-monitor\fP has two different output modes, the 'classic'\-style -monitoring mode and profiling mode. The profiling format is a compact -format with a single line per message and microsecond\-resolution timing -information. The \-\-profile and \-\-monitor options select the profiling -and monitoring output format respectively. If neither is specified, -\fIdbus\-monitor\fP uses the monitoring output format. - -.PP -In order to get \fIdbus\-monitor\fP to see the messages you are interested -in, you should specify a set of watch expressions as you would expect to -be passed to the \fIdbus_bus_add_match\fP function. - -.PP -The message bus configuration may keep \fIdbus\-monitor\fP from seeing -all messages, especially if you run the monitor as a non\-root user. - -.SH OPTIONS -.TP -.I "\-\-system" -Monitor the system message bus. -.TP -.I "\-\-session" -Monitor the session message bus. (This is the default.) -.TP -.I "\-\-address ADDRESS" -Monitor an arbitrary message bus given at ADDRESS. -.TP -.I "\-\-profile" -Use the profiling output format. -.TP -.I "\-\-monitor" -Use the monitoring output format. (This is the default.) - -.SH EXAMPLE -Here is an example of using dbus\-monitor to watch for the gnome typing -monitor to say things -.nf - - dbus\-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'" - -.fi - -.SH AUTHOR -dbus\-monitor was written by Philip Blundell. -The profiling output mode was added by Olli Salli. - -.SH BUGS -Please send bug reports to the D\-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ diff --git a/cmake/tools/dbus-monitor.xml b/doc/dbus-monitor.1.xml.in index b41cace2..af05e3aa 100644 --- a/cmake/tools/dbus-monitor.xml +++ b/doc/dbus-monitor.1.xml.in @@ -1,24 +1,26 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> -<!-- lifted from troff+man by doclifter --> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> <refentry id='dbusmonitor1'> -<!-- --> -<!-- dbus\-monitor manual page. --> -<!-- Copyright (C) 2003 Red Hat, Inc. --> + +<!-- dbus\-monitor manual page. + Copyright (C) 2003 Red Hat, Inc. --> <refmeta> <refentrytitle>dbus-monitor</refentrytitle> <manvolnum>1</manvolnum> +<refmiscinfo class="manual">User Commands</refmiscinfo> +<refmiscinfo class="source">D-Bus</refmiscinfo> +<refmiscinfo class="version">@DBUS_VERSION@</refmiscinfo> </refmeta> -<refnamediv id='name'> +<refnamediv> <refname>dbus-monitor</refname> <refpurpose>debug probe to print message bus messages</refpurpose> </refnamediv> <!-- body begins here --> <refsynopsisdiv id='synopsis'> <cmdsynopsis> - <command>dbus-monitor</command> + <command>dbus-monitor</command> <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg><arg choice='plain'>--address <replaceable>ADDRESS</replaceable></arg></group> <group choice='opt'><arg choice='plain'>--profile </arg><arg choice='plain'>--monitor </arg></group> <arg choice='opt'><arg choice='plain'><replaceable>watch</replaceable></arg><arg choice='plain'><replaceable>expressions</replaceable></arg></arg> @@ -118,4 +120,3 @@ The profiling output mode was added by Olli Salli.</para> see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para> </refsect1> </refentry> - diff --git a/doc/dbus-send.1 b/doc/dbus-send.1 deleted file mode 100644 index 131a60df..00000000 --- a/doc/dbus-send.1 +++ /dev/null @@ -1,109 +0,0 @@ -.\" -.\" dbus\-send manual page. -.\" Copyright (C) 2003 Red Hat, Inc. -.\" -.TH dbus\-send 1 -.SH NAME -dbus\-send \- Send a message to a message bus -.SH SYNOPSIS -.PP -.B dbus\-send -[\fB\-\-system\fP | \fB\-\-session\fP] -[\fB\-\-dest=\fINAME\fP] -[\fB\-\-print\-reply\fP[\fB=literal\fP]] -[\fB\-\-reply\-timeout=\fIMSEC\fP] -[\fB\-\-type=\fITYPE\fP] -\fIOBJECT_PATH\fP \fIINTERFACE\fB.\fIMEMBER\fP [\fICONTENTS\fP ...] - -.SH DESCRIPTION - -The \fIdbus\-send\fP command is used to send a message to a D\-Bus message -bus. See http://www.freedesktop.org/software/dbus/ for more -information about the big picture. - -.PP -There are two well\-known message buses: the systemwide message bus -(installed on many systems as the "messagebus" service) and the -per\-user\-login\-session message bus (started each time a user logs in). -The \fB\-\-system\fP and \fB\-\-session\fP options direct -\fBdbus\-send\fP to send messages to the system or session buses respectively. -If neither is specified, \fBdbus\-send\fP sends to the session bus. - -.PP -Nearly all uses of \fBdbus\-send\fP must provide the \fB\-\-dest\fP argument -which is the name of a connection on the bus to send the message to. If -\fB\-\-dest\fP is omitted, no destination is set. - -.PP -The object path and the name of the message to send must always be -specified. Following arguments, if any, are the message contents -(message arguments). These are given as type\-specified values and -may include containers (arrays, dicts, and variants) as described below. - -.nf -<contents> ::= <item> | <container> [ <item> | <container>...] -<item> ::= <type>:<value> -<container> ::= <array> | <dict> | <variant> -<array> ::= array:<type>:<value>[,<value>...] -<dict> ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...] -<variant> ::= variant:<type>:<value> -<type> ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath -.fi - -D\-Bus supports more types than these, but \fBdbus\-send\fP currently -does not. Also, \fBdbus\-send\fP does not permit empty containers -or nested containers (e.g. arrays of variants). - -.PP -Here is an example invocation: -.nf - - dbus\-send \-\-dest=org.freedesktop.ExampleName \\ - /org/freedesktop/sample/object/name \\ - org.freedesktop.ExampleInterface.ExampleMethod \\ - int32:47 string:'hello world' double:65.32 \\ - array:string:"1st item","next item","last item" \\ - dict:string:int32:"one",1,"two",2,"three",3 \\ - variant:int32:\-8 \\ - objpath:/org/freedesktop/sample/object/name - -.fi - -Note that the interface is separated from a method or signal -name by a dot, though in the actual protocol the interface -and the interface member are separate fields. - -.SH OPTIONS -The following options are supported: -.TP -.BI \-\-dest= NAME -Specify the name of the connection to receive the message. -.TP -.B "\-\-print\-reply" -Block for a reply to the message sent, and print any reply received -in a human-readable form. -.TP -.B "\-\-print\-reply=literal" -Block for a reply to the message sent, and print the body of the -reply. If the reply is an object path or a string, it is printed -literally, with no punctuation, escape characters etc. -.TP -.BI \-\-reply\-timeout= MSEC -Wait for a reply for up to \fIMSEC\fP milliseconds. -The default is implementation\(hydefined, typically 25 seconds. -.TP -.B "\-\-system" -Send to the system message bus. -.TP -.B "\-\-session" -Send to the session message bus. (This is the default.) -.TP -.BI \-\-type= TYPE -Specify \fBmethod_call\fP or \fBsignal\fP (defaults to "\fBsignal\fP"). - -.SH AUTHOR -dbus\-send was written by Philip Blundell. - -.SH BUGS -Please send bug reports to the D\-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ diff --git a/cmake/tools/dbus-send.xml b/doc/dbus-send.1.xml.in index 7fefc03e..78f1374b 100644 --- a/cmake/tools/dbus-send.xml +++ b/doc/dbus-send.1.xml.in @@ -1,34 +1,34 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> -<!-- lifted from troff+man by doclifter --> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> <refentry id='dbussend1'> -<!-- --> -<!-- dbus\-send manual page. --> -<!-- Copyright (C) 2003 Red Hat, Inc. --> + +<!-- dbus\-send manual page. + Copyright (C) 2003 Red Hat, Inc. --> <refmeta> <refentrytitle>dbus-send</refentrytitle> <manvolnum>1</manvolnum> +<refmiscinfo class="manual">User Commands</refmiscinfo> +<refmiscinfo class="source">D-Bus</refmiscinfo> +<refmiscinfo class="version">@DBUS_VERSION@</refmiscinfo> </refmeta> -<refnamediv id='name'> +<refnamediv> <refname>dbus-send</refname> <refpurpose>Send a message to a message bus</refpurpose> </refnamediv> <!-- body begins here --> <refsynopsisdiv id='synopsis'> <cmdsynopsis> - <command>dbus-send</command> + <command>dbus-send</command> <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg></group> <arg choice='opt'>--dest=<replaceable>NAME</replaceable></arg> - <arg choice='opt'>--print-reply </arg> + <arg choice='opt'><arg choice='plain'>--print-reply </arg><arg choice='opt'><replaceable>=literal</replaceable></arg></arg> + <arg choice='opt'>--reply-timeout=<replaceable>MSEC</replaceable></arg> <arg choice='opt'>--type=<replaceable>TYPE</replaceable></arg> - <arg choice='plain'><replaceable><destination</replaceable></arg> - <arg choice='plain'><replaceable>object</replaceable></arg> - <arg choice='plain'><replaceable>path></replaceable></arg> - <arg choice='plain'><replaceable><message</replaceable></arg> - <arg choice='plain'><replaceable>name></replaceable></arg> - <arg choice='opt' rep='repeat'><replaceable>contents</replaceable></arg> + <arg choice='plain'><replaceable>OBJECT_PATH</replaceable></arg> + <arg choice='plain'><replaceable>INTERFACE.MEMBER</replaceable></arg> + <arg choice='opt' rep='repeat'><replaceable>CONTENTS</replaceable></arg> <sbr/> </cmdsynopsis> </refsynopsisdiv> @@ -36,33 +36,33 @@ <refsect1 id='description'><title>DESCRIPTION</title> <para>The <command>dbus-send</command> command is used to send a message to a D-Bus message -bus. See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more +bus. See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about the big picture.</para> -<para>There are two well-known message buses: the systemwide message bus -(installed on many systems as the "messagebus" service) and the +<para>There are two well-known message buses: the systemwide message bus +(installed on many systems as the "messagebus" service) and the per-user-login-session message bus (started each time a user logs in). -The --system and --session options direct <command>dbus-send</command> to send -messages to the system or session buses respectively. If neither is -specified, <command>dbus-send</command> sends to the session bus.</para> +The <option>--system</option> and <option>--session</option> options direct +<command>dbus-send</command> to send messages to the system or session buses respectively. +If neither is specified, <command>dbus-send</command> sends to the session bus.</para> -<para>Nearly all uses of <command>dbus-send</command> must provide the --dest argument +<para>Nearly all uses of <command>dbus-send</command> must provide the <option>--dest</option> argument which is the name of a connection on the bus to send the message to. If ---dest is omitted, no destination is set.</para> +<option>--dest</option> is omitted, no destination is set.</para> <para>The object path and the name of the message to send must always be specified. Following arguments, if any, are the message contents -(message arguments). These are given as type-specified values and +(message arguments). These are given as type-specified values and may include containers (arrays, dicts, and variants) as described below.</para> <literallayout remap='.nf'> <contents> ::= <item> | <container> [ <item> | <container>...] <item> ::= <type>:<value> <container> ::= <array> | <dict> | <variant> -<array> ::= array:<type>:<value>[,<value>...] +<array> ::= array:<type>:<value>[,<value>...] <dict> ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...] <variant> ::= variant:<type>:<value> <type> ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath @@ -76,18 +76,18 @@ or nested containers (e.g. arrays of variants).</para> <para>Here is an example invocation:</para> <literallayout remap='.nf'> - dbus-send --dest=org.freedesktop.ExampleName \ - /org/freedesktop/sample/object/name \ - org.freedesktop.ExampleInterface.ExampleMethod \ - int32:47 string:'hello world' double:65.32 \ - array:string:"1st item","next item","last item" \ - dict:string:int32:"one",1,"two",2,"three",3 \ - variant:int32:-8 \ - objpath:/org/freedesktop/sample/object/name + dbus-send --dest=org.freedesktop.ExampleName \ + /org/freedesktop/sample/object/name \ + org.freedesktop.ExampleInterface.ExampleMethod \ + int32:47 string:'hello world' double:65.32 \ + array:string:"1st item","next item","last item" \ + dict:string:int32:"one",1,"two",2,"three",3 \ + variant:int32:-8 \ + objpath:/org/freedesktop/sample/object/name </literallayout> <!-- .fi --> -<para>Note that the interface is separated from a method or signal +<para>Note that the interface is separated from a method or signal name by a dot, though in the actual protocol the interface and the interface member are separate fields.</para> @@ -97,7 +97,7 @@ and the interface member are separate fields.</para> <para>The following options are supported:</para> <variablelist remap='TP'> <varlistentry> - <term><option>--dest=NAME</option></term> + <term><option>--dest=</option><replaceable>NAME</replaceable></term> <listitem> <para>Specify the name of the connection to receive the message.</para> </listitem> @@ -105,7 +105,23 @@ and the interface member are separate fields.</para> <varlistentry> <term><option>--print-reply</option></term> <listitem> -<para>Block for a reply to the message sent, and print any reply received.</para> +<para>Block for a reply to the message sent, and print any reply received +in a human-readable form.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--print-reply=literal</option></term> + <listitem> +<para>Block for a reply to the message sent, and print the body of the +reply. If the reply is an object path or a string, it is printed +literally, with no punctuation, escape characters etc.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><option>--reply-timeout=</option><replaceable>MSEC</replaceable></term> + <listitem> +<para>Wait for a reply for up to <emphasis remap='I'>MSEC</emphasis> milliseconds. +The default is implementation‐defined, typically 25 seconds.</para> </listitem> </varlistentry> <varlistentry> @@ -121,9 +137,9 @@ and the interface member are separate fields.</para> </listitem> </varlistentry> <varlistentry> - <term><option>--type=TYPE</option></term> + <term><option>--type=</option><replaceable>TYPE</replaceable></term> <listitem> -<para>Specify "method_call" or "signal" (defaults to "signal").</para> +<para>Specify <emphasis remap='B'>method_call</emphasis> or <emphasis remap='B'>signal</emphasis> (defaults to "<emphasis remap='B'>signal</emphasis>").</para> </listitem> </varlistentry> @@ -140,4 +156,3 @@ and the interface member are separate fields.</para> see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para> </refsect1> </refentry> - diff --git a/doc/dbus-specification.html b/doc/dbus-specification.html deleted file mode 100644 index f42243fc..00000000 --- a/doc/dbus-specification.html +++ /dev/null @@ -1,2898 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>D-Bus Specification</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" title="D-Bus Specification"><div class="titlepage"><div><div><h2 class="title"><a name="index"></a>D-Bus Specification</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:hp@pobox.com">hp@pobox.com</a>></code><br> - </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">Anders</span> <span class="surname">Carlsson</span></h3><div class="affiliation"><span class="orgname">CodeFactory AB<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:andersca@codefactory.se">andersca@codefactory.se</a>></code><br> - </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">Alexander</span> <span class="surname">Larsson</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:alexl@redhat.com">alexl@redhat.com</a>></code><br> - </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">Sven</span> <span class="surname">Herzberg</span></h3><div class="affiliation"><span class="orgname">Imendio AB<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:sven@imendio.com">sven@imendio.com</a>></code><br> - </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">Simon</span> <span class="surname">McVittie</span></h3><div class="affiliation"><span class="orgname">Collabora Ltd.<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a>></code><br> - </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="surname">Zeuthen</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:davidz@redhat.com">davidz@redhat.com</a>></code><br> - </p></div></div></div></div></div><div><p class="releaseinfo">Version 0.19</p></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision current</td><td align="left"><a class="ulink" href="http://cgit.freedesktop.org/dbus/dbus/log/doc/dbus-specification.xml" target="_top">commit log</a></td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.19</td><td align="left">20 February 2012</td><td align="left">smcv/lp</td></tr><tr><td align="left" colspan="3">formally define unique connection names and well-known - bus names; document best practices for interface, bus, member and - error names, and object paths; document the search path for session - and system services on Unix; document the systemd transport</td></tr><tr><td align="left">Revision 0.18</td><td align="left">29 July 2011</td><td align="left">smcv</td></tr><tr><td align="left" colspan="3">define eavesdropping, unicast, broadcast; add eavesdrop - match keyword; promote type system to a top-level section</td></tr><tr><td align="left">Revision 0.17</td><td align="left">1 June 2011</td><td align="left">smcv/davidz</td></tr><tr><td align="left" colspan="3">define ObjectManager; reserve extra pseudo-type-codes used - by GVariant</td></tr><tr><td align="left">Revision 0.16</td><td align="left">11 April 2011</td><td align="left"></td></tr><tr><td align="left" colspan="3">add path_namespace, arg0namespace; argNpath matches object - paths</td></tr><tr><td align="left">Revision 0.15</td><td align="left">3 November 2010</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.14</td><td align="left">12 May 2010</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.13</td><td align="left">23 Dezember 2009</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.12</td><td align="left">7 November, 2006</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.11</td><td align="left">6 February 2005</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.10</td><td align="left">28 January 2005</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.9</td><td align="left">7 Januar 2005</td><td align="left"></td></tr><tr><td align="left" colspan="3"></td></tr><tr><td align="left">Revision 0.8</td><td align="left">06 September 2003</td><td align="left"></td></tr><tr><td align="left" colspan="3">First released document.</td></tr></table></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#introduction">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#stability">Protocol and Specification Stability</a></span></dt></dl></dd><dt><span class="sect1"><a href="#type-system">Type System</a></span></dt><dd><dl><dt><span class="sect2"><a href="#message-protocol-signatures">Type Signatures</a></span></dt><dt><span class="sect2"><a href="#message-protocol-marshaling">Marshaling (Wire Format)</a></span></dt></dl></dd><dt><span class="sect1"><a href="#message-protocol">Message Protocol</a></span></dt><dd><dl><dt><span class="sect2"><a href="#message-protocol-messages">Message Format</a></span></dt><dt><span class="sect2"><a href="#message-protocol-names">Valid Names</a></span></dt><dt><span class="sect2"><a href="#message-protocol-types">Message Types</a></span></dt><dt><span class="sect2"><a href="#message-protocol-handling-invalid">Invalid Protocol and Spec Extensions</a></span></dt></dl></dd><dt><span class="sect1"><a href="#auth-protocol">Authentication Protocol</a></span></dt><dd><dl><dt><span class="sect2"><a href="#auth-protocol-overview">Protocol Overview</a></span></dt><dt><span class="sect2"><a href="#auth-nul-byte">Special credentials-passing nul byte</a></span></dt><dt><span class="sect2"><a href="#auth-command-auth">AUTH command</a></span></dt><dt><span class="sect2"><a href="#auth-command-cancel">CANCEL Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-data">DATA Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-begin">BEGIN Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-rejected">REJECTED Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-ok">OK Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-error">ERROR Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-negotiate-unix-fd">NEGOTIATE_UNIX_FD Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-agree-unix-fd">AGREE_UNIX_FD Command</a></span></dt><dt><span class="sect2"><a href="#auth-command-future">Future Extensions</a></span></dt><dt><span class="sect2"><a href="#auth-examples">Authentication examples</a></span></dt><dt><span class="sect2"><a href="#auth-states">Authentication state diagrams</a></span></dt><dt><span class="sect2"><a href="#auth-mechanisms">Authentication mechanisms</a></span></dt></dl></dd><dt><span class="sect1"><a href="#addresses">Server Addresses</a></span></dt><dt><span class="sect1"><a href="#transports">Transports</a></span></dt><dd><dl><dt><span class="sect2"><a href="#transports-unix-domain-sockets">Unix Domain Sockets</a></span></dt><dt><span class="sect2"><a href="#transports-launchd">launchd</a></span></dt><dt><span class="sect2"><a href="#transports-systemd">systemd</a></span></dt><dt><span class="sect2"><a href="#transports-tcp-sockets">TCP Sockets</a></span></dt><dt><span class="sect2"><a href="#transports-nonce-tcp-sockets">Nonce-secured TCP Sockets</a></span></dt><dt><span class="sect2"><a href="#transports-exec">Executed Subprocesses on Unix</a></span></dt></dl></dd><dt><span class="sect1"><a href="#meta-transports">Meta Transports</a></span></dt><dd><dl><dt><span class="sect2"><a href="#meta-transports-autolaunch">Autolaunch</a></span></dt></dl></dd><dt><span class="sect1"><a href="#uuids">UUIDs</a></span></dt><dt><span class="sect1"><a href="#standard-interfaces">Standard Interfaces</a></span></dt><dd><dl><dt><span class="sect2"><a href="#standard-interfaces-peer"><code class="literal">org.freedesktop.DBus.Peer</code></a></span></dt><dt><span class="sect2"><a href="#standard-interfaces-introspectable"><code class="literal">org.freedesktop.DBus.Introspectable</code></a></span></dt><dt><span class="sect2"><a href="#standard-interfaces-properties"><code class="literal">org.freedesktop.DBus.Properties</code></a></span></dt><dt><span class="sect2"><a href="#standard-interfaces-objectmanager"><code class="literal">org.freedesktop.DBus.ObjectManager</code></a></span></dt></dl></dd><dt><span class="sect1"><a href="#introspection-format">Introspection Data Format</a></span></dt><dt><span class="sect1"><a href="#message-bus">Message Bus Specification</a></span></dt><dd><dl><dt><span class="sect2"><a href="#message-bus-overview">Message Bus Overview</a></span></dt><dt><span class="sect2"><a href="#message-bus-names">Message Bus Names</a></span></dt><dt><span class="sect2"><a href="#message-bus-routing">Message Bus Message Routing</a></span></dt><dt><span class="sect2"><a href="#message-bus-starting-services">Message Bus Starting Services</a></span></dt><dt><span class="sect2"><a href="#message-bus-types">Well-known Message Bus Instances</a></span></dt><dt><span class="sect2"><a href="#message-bus-messages">Message Bus Messages</a></span></dt></dl></dd><dt><span class="glossary"><a href="#idp5904720">Glossary</a></span></dt></dl></div><div class="sect1" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="introduction"></a>Introduction</h2></div></div></div><p> - D-Bus is a system for low-latency, low-overhead, easy to use - interprocess communication (IPC). In more detail: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - D-Bus is <span class="emphasis"><em>low-latency</em></span> because it is designed - to avoid round trips and allow asynchronous operation, much like - the X protocol. - </p></li><li class="listitem"><p> - D-Bus is <span class="emphasis"><em>low-overhead</em></span> because it uses a - binary protocol, and does not have to convert to and from a text - format such as XML. Because D-Bus is intended for potentially - high-resolution same-machine IPC, not primarily for Internet IPC, - this is an interesting optimization. - </p></li><li class="listitem"><p> - D-Bus is <span class="emphasis"><em>easy to use</em></span> because it works in terms - of <em class="firstterm">messages</em> rather than byte streams, and - automatically handles a lot of the hard IPC issues. Also, the D-Bus - library is designed to be wrapped in a way that lets developers use - their framework's existing object/type system, rather than learning - a new one specifically for IPC. - </p></li></ul></div><p> - </p><p> - The base D-Bus protocol is a one-to-one (peer-to-peer or client-server) - protocol, specified in <a class="xref" href="#message-protocol" title="Message Protocol">the section called “Message Protocol”</a>. That is, it is - a system for one application to talk to a single other - application. However, the primary intended application of the protocol is the - D-Bus <em class="firstterm">message bus</em>, specified in <a class="xref" href="#message-bus" title="Message Bus Specification">the section called “Message Bus Specification”</a>. The message bus is a special application that - accepts connections from multiple other applications, and forwards - messages among them. - </p><p> - Uses of D-Bus include notification of system changes (notification of when - a camera is plugged in to a computer, or a new version of some software - has been installed), or desktop interoperability, for example a file - monitoring service or a configuration service. - </p><p> - D-Bus is designed for two specific use cases: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - A "system bus" for notifications from the system to user sessions, - and to allow the system to request input from user sessions. - </p></li><li class="listitem"><p> - A "session bus" used to implement desktop environments such as - GNOME and KDE. - </p></li></ul></div><p> - D-Bus is not intended to be a generic IPC system for any possible - application, and intentionally omits many features found in other - IPC systems for this reason. - </p><p> - At the same time, the bus daemons offer a number of features not found in - other IPC systems, such as single-owner "bus names" (similar to X - selections), on-demand startup of services, and security policies. - In many ways, these features are the primary motivation for developing - D-Bus; other systems would have sufficed if IPC were the only goal. - </p><p> - D-Bus may turn out to be useful in unanticipated applications, but future - versions of this spec and the reference implementation probably will not - incorporate features that interfere with the core use cases. - </p><p> - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. However, the - document could use a serious audit to be sure it makes sense to do - so. Also, they are not capitalized. - </p><div class="sect2" title="Protocol and Specification Stability"><div class="titlepage"><div><div><h3 class="title"><a name="stability"></a>Protocol and Specification Stability</h3></div></div></div><p> - The D-Bus protocol is frozen (only compatible extensions are allowed) as - of November 8, 2006. However, this specification could still use a fair - bit of work to make interoperable reimplementation possible without - reference to the D-Bus reference implementation. Thus, this - specification is not marked 1.0. To mark it 1.0, we'd like to see - someone invest significant effort in clarifying the specification - language, and growing the specification to cover more aspects of the - reference implementation's behavior. - </p><p> - Until this work is complete, any attempt to reimplement D-Bus will - probably require looking at the reference implementation and/or asking - questions on the D-Bus mailing list about intended behavior. - Questions on the list are very welcome. - </p><p> - Nonetheless, this document should be a useful starting point and is - to our knowledge accurate, though incomplete. - </p></div></div><div class="sect1" title="Type System"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="type-system"></a>Type System</h2></div></div></div><p> - D-Bus has a type system, in which values of various types can be - serialized into a sequence of bytes referred to as the - <em class="firstterm">wire format</em> in a standard way. - Converting a value from some other representation into the wire - format is called <em class="firstterm">marshaling</em> and converting - it back from the wire format is <em class="firstterm">unmarshaling</em>. - </p><div class="sect2" title="Type Signatures"><div class="titlepage"><div><div><h3 class="title"><a name="message-protocol-signatures"></a>Type Signatures</h3></div></div></div><p> - The D-Bus protocol does not include type tags in the marshaled data; a - block of marshaled values must have a known <em class="firstterm">type - signature</em>. The type signature is made up of <em class="firstterm">type - codes</em>. A type code is an ASCII character representing the - type of a value. Because ASCII characters are used, the type signature - will always form a valid ASCII string. A simple string compare - determines whether two type signatures are equivalent. - </p><p> - As a simple example, the type code for 32-bit integer (<code class="literal">INT32</code>) is - the ASCII character 'i'. So the signature for a block of values - containing a single <code class="literal">INT32</code> would be: - </p><pre class="programlisting"> - "i" - </pre><p> - A block of values containing two <code class="literal">INT32</code> would have this signature: - </p><pre class="programlisting"> - "ii" - </pre><p> - </p><p> - All <em class="firstterm">basic</em> types work like - <code class="literal">INT32</code> in this example. To marshal and unmarshal - basic types, you simply read one value from the data - block corresponding to each type code in the signature. - In addition to basic types, there are four <em class="firstterm">container</em> - types: <code class="literal">STRUCT</code>, <code class="literal">ARRAY</code>, <code class="literal">VARIANT</code>, - and <code class="literal">DICT_ENTRY</code>. - </p><p> - <code class="literal">STRUCT</code> has a type code, ASCII character 'r', but this type - code does not appear in signatures. Instead, ASCII characters - '(' and ')' are used to mark the beginning and end of the struct. - So for example, a struct containing two integers would have this - signature: - </p><pre class="programlisting"> - "(ii)" - </pre><p> - Structs can be nested, so for example a struct containing - an integer and another struct: - </p><pre class="programlisting"> - "(i(ii))" - </pre><p> - The value block storing that struct would contain three integers; the - type signature allows you to distinguish "(i(ii))" from "((ii)i)" or - "(iii)" or "iii". - </p><p> - The <code class="literal">STRUCT</code> type code 'r' is not currently used in the D-Bus protocol, - but is useful in code that implements the protocol. This type code - is specified to allow such code to interoperate in non-protocol contexts. - </p><p> - Empty structures are not allowed; there must be at least one - type code between the parentheses. - </p><p> - <code class="literal">ARRAY</code> has ASCII character 'a' as type code. The array type code must be - followed by a <em class="firstterm">single complete type</em>. The single - complete type following the array is the type of each array element. So - the simple example is: - </p><pre class="programlisting"> - "ai" - </pre><p> - which is an array of 32-bit integers. But an array can be of any type, - such as this array-of-struct-with-two-int32-fields: - </p><pre class="programlisting"> - "a(ii)" - </pre><p> - Or this array of array of integer: - </p><pre class="programlisting"> - "aai" - </pre><p> - </p><p> - The phrase <em class="firstterm">single complete type</em> deserves some - definition. A single complete type is a basic type code, a variant type code, - an array with its element type, or a struct with its fields. - So the following signatures are not single complete types: - </p><pre class="programlisting"> - "aa" - </pre><p> - </p><pre class="programlisting"> - "(ii" - </pre><p> - </p><pre class="programlisting"> - "ii)" - </pre><p> - And the following signatures contain multiple complete types: - </p><pre class="programlisting"> - "ii" - </pre><p> - </p><pre class="programlisting"> - "aiai" - </pre><p> - </p><pre class="programlisting"> - "(ii)(ii)" - </pre><p> - Note however that a single complete type may <span class="emphasis"><em>contain</em></span> - multiple other single complete types. - </p><p> - <code class="literal">VARIANT</code> has ASCII character 'v' as its type code. A marshaled value of - type <code class="literal">VARIANT</code> will have the signature of a single complete type as part - of the <span class="emphasis"><em>value</em></span>. This signature will be followed by a - marshaled value of that type. - </p><p> - A <code class="literal">DICT_ENTRY</code> works exactly like a struct, but rather - than parentheses it uses curly braces, and it has more restrictions. - The restrictions are: it occurs only as an array element type; it has - exactly two single complete types inside the curly braces; the first - single complete type (the "key") must be a basic type rather than a - container type. Implementations must not accept dict entries outside of - arrays, must not accept dict entries with zero, one, or more than two - fields, and must not accept dict entries with non-basic-typed keys. A - dict entry is always a key-value pair. - </p><p> - The first field in the <code class="literal">DICT_ENTRY</code> is always the key. - A message is considered corrupt if the same key occurs twice in the same - array of <code class="literal">DICT_ENTRY</code>. However, for performance reasons - implementations are not required to reject dicts with duplicate keys. - </p><p> - In most languages, an array of dict entry would be represented as a - map, hash table, or dict object. - </p><p> - The following table summarizes the D-Bus types. - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional Name</th><th>Code</th><th>Description</th></tr></thead><tbody><tr><td><code class="literal">INVALID</code></td><td>0 (ASCII NUL)</td><td>Not a valid type code, used to terminate signatures</td></tr><tr><td><code class="literal">BYTE</code></td><td>121 (ASCII 'y')</td><td>8-bit unsigned integer</td></tr><tr><td><code class="literal">BOOLEAN</code></td><td>98 (ASCII 'b')</td><td>Boolean value, 0 is <code class="literal">FALSE</code> and 1 is <code class="literal">TRUE</code>. Everything else is invalid.</td></tr><tr><td><code class="literal">INT16</code></td><td>110 (ASCII 'n')</td><td>16-bit signed integer</td></tr><tr><td><code class="literal">UINT16</code></td><td>113 (ASCII 'q')</td><td>16-bit unsigned integer</td></tr><tr><td><code class="literal">INT32</code></td><td>105 (ASCII 'i')</td><td>32-bit signed integer</td></tr><tr><td><code class="literal">UINT32</code></td><td>117 (ASCII 'u')</td><td>32-bit unsigned integer</td></tr><tr><td><code class="literal">INT64</code></td><td>120 (ASCII 'x')</td><td>64-bit signed integer</td></tr><tr><td><code class="literal">UINT64</code></td><td>116 (ASCII 't')</td><td>64-bit unsigned integer</td></tr><tr><td><code class="literal">DOUBLE</code></td><td>100 (ASCII 'd')</td><td>IEEE 754 double</td></tr><tr><td><code class="literal">STRING</code></td><td>115 (ASCII 's')</td><td>UTF-8 string (<span class="emphasis"><em>must</em></span> be valid UTF-8). Must be nul terminated and contain no other nul bytes.</td></tr><tr><td><code class="literal">OBJECT_PATH</code></td><td>111 (ASCII 'o')</td><td>Name of an object instance</td></tr><tr><td><code class="literal">SIGNATURE</code></td><td>103 (ASCII 'g')</td><td>A type signature</td></tr><tr><td><code class="literal">ARRAY</code></td><td>97 (ASCII 'a')</td><td>Array</td></tr><tr><td><code class="literal">STRUCT</code></td><td>114 (ASCII 'r'), 40 (ASCII '('), 41 (ASCII ')')</td><td>Struct; type code 114 'r' is reserved for use in - bindings and implementations to represent the general - concept of a struct, and must not appear in signatures - used on D-Bus.</td></tr><tr><td><code class="literal">VARIANT</code></td><td>118 (ASCII 'v') </td><td>Variant type (the type of the value is part of the value itself)</td></tr><tr><td><code class="literal">DICT_ENTRY</code></td><td>101 (ASCII 'e'), 123 (ASCII '{'), 125 (ASCII '}') </td><td>Entry in a dict or map (array of key-value pairs). - Type code 101 'e' is reserved for use in bindings and - implementations to represent the general concept of a - dict or dict-entry, and must not appear in signatures - used on D-Bus.</td></tr><tr><td><code class="literal">UNIX_FD</code></td><td>104 (ASCII 'h')</td><td>Unix file descriptor</td></tr><tr><td>(reserved)</td><td>109 (ASCII 'm')</td><td>Reserved for <a class="ulink" href="https://bugs.freedesktop.org/show_bug.cgi?id=27857" target="_top">a - 'maybe' type compatible with the one in GVariant</a>, - and must not appear in signatures used on D-Bus until - specified here</td></tr><tr><td>(reserved)</td><td>42 (ASCII '*')</td><td>Reserved for use in bindings/implementations to - represent any <em class="firstterm">single complete type</em>, - and must not appear in signatures used on D-Bus.</td></tr><tr><td>(reserved)</td><td>63 (ASCII '?')</td><td>Reserved for use in bindings/implementations to - represent any <em class="firstterm">basic type</em>, and must - not appear in signatures used on D-Bus.</td></tr><tr><td>(reserved)</td><td>64 (ASCII '@'), 38 (ASCII '&'), - 94 (ASCII '^')</td><td>Reserved for internal use by bindings/implementations, - and must not appear in signatures used on D-Bus. - GVariant uses these type-codes to encode calling - conventions.</td></tr></tbody></table></div><p> - </p></div><div class="sect2" title="Marshaling (Wire Format)"><div class="titlepage"><div><div><h3 class="title"><a name="message-protocol-marshaling"></a>Marshaling (Wire Format)</h3></div></div></div><p> - Given a type signature, a block of bytes can be converted into typed - values. This section describes the format of the block of bytes. Byte - order and alignment issues are handled uniformly for all D-Bus types. - </p><p> - A block of bytes has an associated byte order. The byte order - has to be discovered in some way; for D-Bus messages, the - byte order is part of the message header as described in - <a class="xref" href="#message-protocol-messages" title="Message Format">the section called “Message Format”</a>. For now, assume - that the byte order is known to be either little endian or big - endian. - </p><p> - Each value in a block of bytes is aligned "naturally," for example - 4-byte values are aligned to a 4-byte boundary, and 8-byte values to an - 8-byte boundary. To properly align a value, <em class="firstterm">alignment - padding</em> may be necessary. The alignment padding must always - be the minimum required padding to properly align the following value; - and it must always be made up of nul bytes. The alignment padding must - not be left uninitialized (it can't contain garbage), and more padding - than required must not be used. - </p><p> - Given all this, the types are marshaled on the wire as follows: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional Name</th><th>Encoding</th><th>Alignment</th></tr></thead><tbody><tr><td><code class="literal">INVALID</code></td><td>Not applicable; cannot be marshaled.</td><td>N/A</td></tr><tr><td><code class="literal">BYTE</code></td><td>A single 8-bit byte.</td><td>1</td></tr><tr><td><code class="literal">BOOLEAN</code></td><td>As for <code class="literal">UINT32</code>, but only 0 and 1 are valid values.</td><td>4</td></tr><tr><td><code class="literal">INT16</code></td><td>16-bit signed integer in the message's byte order.</td><td>2</td></tr><tr><td><code class="literal">UINT16</code></td><td>16-bit unsigned integer in the message's byte order.</td><td>2</td></tr><tr><td><code class="literal">INT32</code></td><td>32-bit signed integer in the message's byte order.</td><td>4</td></tr><tr><td><code class="literal">UINT32</code></td><td>32-bit unsigned integer in the message's byte order.</td><td>4</td></tr><tr><td><code class="literal">INT64</code></td><td>64-bit signed integer in the message's byte order.</td><td>8</td></tr><tr><td><code class="literal">UINT64</code></td><td>64-bit unsigned integer in the message's byte order.</td><td>8</td></tr><tr><td><code class="literal">DOUBLE</code></td><td>64-bit IEEE 754 double in the message's byte order.</td><td>8</td></tr><tr><td><code class="literal">STRING</code></td><td>A <code class="literal">UINT32</code> indicating the string's - length in bytes excluding its terminating nul, followed by - non-nul string data of the given length, followed by a terminating nul - byte. - </td><td> - 4 (for the length) - </td></tr><tr><td><code class="literal">OBJECT_PATH</code></td><td>Exactly the same as <code class="literal">STRING</code> except the - content must be a valid object path (see below). - </td><td> - 4 (for the length) - </td></tr><tr><td><code class="literal">SIGNATURE</code></td><td>The same as <code class="literal">STRING</code> except the length is a single - byte (thus signatures have a maximum length of 255) - and the content must be a valid signature (see below). - </td><td> - 1 - </td></tr><tr><td><code class="literal">ARRAY</code></td><td> - A <code class="literal">UINT32</code> giving the length of the array data in bytes, followed by - alignment padding to the alignment boundary of the array element type, - followed by each array element. The array length is from the - end of the alignment padding to the end of the last element, - i.e. it does not include the padding after the length, - or any padding after the last element. - Arrays have a maximum length defined to be 2 to the 26th power or - 67108864. Implementations must not send or accept arrays exceeding this - length. - </td><td> - 4 (for the length) - </td></tr><tr><td><code class="literal">STRUCT</code></td><td> - A struct must start on an 8-byte boundary regardless of the - type of the struct fields. The struct value consists of each - field marshaled in sequence starting from that 8-byte - alignment boundary. - </td><td> - 8 - </td></tr><tr><td><code class="literal">VARIANT</code></td><td> - A variant type has a marshaled - <code class="literal">SIGNATURE</code> followed by a marshaled - value with the type given in the signature. Unlike - a message signature, the variant signature can - contain only a single complete type. So "i", "ai" - or "(ii)" is OK, but "ii" is not. Use of variants may not - cause a total message depth to be larger than 64, including - other container types such as structures. - </td><td> - 1 (alignment of the signature) - </td></tr><tr><td><code class="literal">DICT_ENTRY</code></td><td> - Identical to STRUCT. - </td><td> - 8 - </td></tr><tr><td><code class="literal">UNIX_FD</code></td><td>32-bit unsigned integer in the message's byte - order. The actual file descriptors need to be - transferred out-of-band via some platform specific - mechanism. On the wire, values of this type store the index to the - file descriptor in the array of file descriptors that - accompany the message.</td><td>4</td></tr></tbody></table></div><p> - </p><div class="sect3" title="Valid Object Paths"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-marshaling-object-path"></a>Valid Object Paths</h4></div></div></div><p> - An object path is a name used to refer to an object instance. - Conceptually, each participant in a D-Bus message exchange may have - any number of object instances (think of C++ or Java objects) and each - such instance will have a path. Like a filesystem, the object - instances in an application form a hierarchical tree. - </p><p> - The following rules define a valid object path. Implementations must - not send or accept messages with invalid object paths. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The path may be of any length. - </p></li><li class="listitem"><p> - The path must begin with an ASCII '/' (integer 47) character, - and must consist of elements separated by slash characters. - </p></li><li class="listitem"><p> - Each element must only contain the ASCII characters - "[A-Z][a-z][0-9]_" - </p></li><li class="listitem"><p> - No element may be the empty string. - </p></li><li class="listitem"><p> - Multiple '/' characters cannot occur in sequence. - </p></li><li class="listitem"><p> - A trailing '/' character is not allowed unless the - path is the root path (a single '/' character). - </p></li></ul></div><p> - </p><p> - Object paths are often namespaced by starting with a reversed - domain name and containing an interface version number, in the - same way as - <a class="link" href="#message-protocol-names-interface" title="Interface names">interface - names</a> and - <a class="link" href="#message-protocol-names-bus" title="Bus names">well-known - bus names</a>. - This makes it possible to implement more than one service, or - more than one version of a service, in the same process, - even if the services share a connection but cannot otherwise - co-operate (for instance, if they are implemented by different - plugins). - </p><p> - For instance, if the owner of <code class="literal">example.com</code> is - developing a D-Bus API for a music player, they might use the - hierarchy of object paths that start with - <code class="literal">/com/example/MusicPlayer1</code> for its objects. - </p></div><div class="sect3" title="Valid Signatures"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-marshaling-signature"></a>Valid Signatures</h4></div></div></div><p> - An implementation must not send or accept invalid signatures. - Valid signatures will conform to the following rules: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The signature ends with a nul byte. - </p></li><li class="listitem"><p> - The signature is a list of single complete types. - Arrays must have element types, and structs must - have both open and close parentheses. - </p></li><li class="listitem"><p> - Only type codes and open and close parentheses are - allowed in the signature. The <code class="literal">STRUCT</code> type code - is not allowed in signatures, because parentheses - are used instead. - </p></li><li class="listitem"><p> - The maximum depth of container type nesting is 32 array type - codes and 32 open parentheses. This implies that the maximum - total depth of recursion is 64, for an "array of array of array - of ... struct of struct of struct of ..." where there are 32 - array and 32 struct. - </p></li><li class="listitem"><p> - The maximum length of a signature is 255. - </p></li><li class="listitem"><p> - Signatures must be nul-terminated. - </p></li></ul></div><p> - </p></div></div></div><div class="sect1" title="Message Protocol"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="message-protocol"></a>Message Protocol</h2></div></div></div><p> - A <em class="firstterm">message</em> consists of a - <em class="firstterm">header</em> and a <em class="firstterm">body</em>. If you - think of a message as a package, the header is the address, and the body - contains the package contents. The message delivery system uses the header - information to figure out where to send the message and how to interpret - it; the recipient interprets the body of the message. - </p><p> - The body of the message is made up of zero or more - <em class="firstterm">arguments</em>, which are typed values, such as an - integer or a byte array. - </p><p> - Both header and body use the D-Bus <a class="link" href="#type-system" title="Type System">type - system</a> and format for serializing data. - </p><div class="sect2" title="Message Format"><div class="titlepage"><div><div><h3 class="title"><a name="message-protocol-messages"></a>Message Format</h3></div></div></div><p> - A message consists of a header and a body. The header is a block of - values with a fixed signature and meaning. The body is a separate block - of values, with a signature specified in the header. - </p><p> - The length of the header must be a multiple of 8, allowing the body to - begin on an 8-byte boundary when storing the entire message in a single - buffer. If the header does not naturally end on an 8-byte boundary - up to 7 bytes of nul-initialized alignment padding must be added. - </p><p> - The message body need not end on an 8-byte boundary. - </p><p> - The maximum length of a message, including header, header alignment padding, - and body is 2 to the 27th power or 134217728. Implementations must not - send or accept messages exceeding this size. - </p><p> - The signature of the header is: - </p><pre class="programlisting"> - "yyyyuua(yv)" - </pre><p> - Written out more readably, this is: - </p><pre class="programlisting"> - BYTE, BYTE, BYTE, BYTE, UINT32, UINT32, ARRAY of STRUCT of (BYTE,VARIANT) - </pre><p> - </p><p> - These values have the following meanings: - </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><thead><tr><th>Value</th><th>Description</th></tr></thead><tbody><tr><td>1st <code class="literal">BYTE</code></td><td>Endianness flag; ASCII 'l' for little-endian - or ASCII 'B' for big-endian. Both header and body are - in this endianness.</td></tr><tr><td>2nd <code class="literal">BYTE</code></td><td><em class="firstterm">Message type</em>. Unknown types must be ignored. - Currently-defined types are described below. - </td></tr><tr><td>3rd <code class="literal">BYTE</code></td><td>Bitwise OR of flags. Unknown flags - must be ignored. Currently-defined flags are described below. - </td></tr><tr><td>4th <code class="literal">BYTE</code></td><td>Major protocol version of the sending application. If - the major protocol version of the receiving application does not - match, the applications will not be able to communicate and the - D-Bus connection must be disconnected. The major protocol - version for this version of the specification is 1. - </td></tr><tr><td>1st <code class="literal">UINT32</code></td><td>Length in bytes of the message body, starting - from the end of the header. The header ends after - its alignment padding to an 8-boundary. - </td></tr><tr><td>2nd <code class="literal">UINT32</code></td><td>The serial of this message, used as a cookie - by the sender to identify the reply corresponding - to this request. This must not be zero. - </td></tr><tr><td><code class="literal">ARRAY</code> of <code class="literal">STRUCT</code> of (<code class="literal">BYTE</code>,<code class="literal">VARIANT</code>)</td><td>An array of zero or more <em class="firstterm">header - fields</em> where the byte is the field code, and the - variant is the field value. The message type determines - which fields are required. - </td></tr></tbody></table></div><p> - </p><p> - <em class="firstterm">Message types</em> that can appear in the second byte - of the header are: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional name</th><th>Decimal value</th><th>Description</th></tr></thead><tbody><tr><td><code class="literal">INVALID</code></td><td>0</td><td>This is an invalid type.</td></tr><tr><td><code class="literal">METHOD_CALL</code></td><td>1</td><td>Method call.</td></tr><tr><td><code class="literal">METHOD_RETURN</code></td><td>2</td><td>Method reply with returned data.</td></tr><tr><td><code class="literal">ERROR</code></td><td>3</td><td>Error reply. If the first argument exists and is a - string, it is an error message.</td></tr><tr><td><code class="literal">SIGNAL</code></td><td>4</td><td>Signal emission.</td></tr></tbody></table></div><p> - </p><p> - Flags that can appear in the third byte of the header: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional name</th><th>Hex value</th><th>Description</th></tr></thead><tbody><tr><td><code class="literal">NO_REPLY_EXPECTED</code></td><td>0x1</td><td>This message does not expect method return replies or - error replies; the reply can be omitted as an - optimization. However, it is compliant with this specification - to return the reply despite this flag and the only harm - from doing so is extra network traffic. - </td></tr><tr><td><code class="literal">NO_AUTO_START</code></td><td>0x2</td><td>The bus must not launch an owner - for the destination name in response to this message. - </td></tr></tbody></table></div><p> - </p><div class="sect3" title="Header Fields"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-header-fields"></a>Header Fields</h4></div></div></div><p> - The array at the end of the header contains <em class="firstterm">header - fields</em>, where each field is a 1-byte field code followed - by a field value. A header must contain the required header fields for - its message type, and zero or more of any optional header - fields. Future versions of this protocol specification may add new - fields. Implementations must ignore fields they do not - understand. Implementations must not invent their own header fields; - only changes to this specification may introduce new header fields. - </p><p> - Again, if an implementation sees a header field code that it does not - expect, it must ignore that field, as it will be part of a new - (but compatible) version of this specification. This also applies - to known header fields appearing in unexpected messages, for - example: if a signal has a reply serial it must be ignored - even though it has no meaning as of this version of the spec. - </p><p> - However, implementations must not send or accept known header fields - with the wrong type stored in the field value. So for example a - message with an <code class="literal">INTERFACE</code> field of type - <code class="literal">UINT32</code> would be considered corrupt. - </p><p> - Here are the currently-defined header fields: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col><col><col></colgroup><thead><tr><th>Conventional Name</th><th>Decimal Code</th><th>Type</th><th>Required In</th><th>Description</th></tr></thead><tbody><tr><td><code class="literal">INVALID</code></td><td>0</td><td>N/A</td><td>not allowed</td><td>Not a valid field name (error if it appears in a message)</td></tr><tr><td><code class="literal">PATH</code></td><td>1</td><td><code class="literal">OBJECT_PATH</code></td><td><code class="literal">METHOD_CALL</code>, <code class="literal">SIGNAL</code></td><td>The object to send a call to, - or the object a signal is emitted from. - The special path - <code class="literal">/org/freedesktop/DBus/Local</code> is reserved; - implementations should not send messages with this path, - and the reference implementation of the bus daemon will - disconnect any application that attempts to do so. - </td></tr><tr><td><code class="literal">INTERFACE</code></td><td>2</td><td><code class="literal">STRING</code></td><td><code class="literal">SIGNAL</code></td><td> - The interface to invoke a method call on, or - that a signal is emitted from. Optional for - method calls, required for signals. - The special interface - <code class="literal">org.freedesktop.DBus.Local</code> is reserved; - implementations should not send messages with this - interface, and the reference implementation of the bus - daemon will disconnect any application that attempts to - do so. - </td></tr><tr><td><code class="literal">MEMBER</code></td><td>3</td><td><code class="literal">STRING</code></td><td><code class="literal">METHOD_CALL</code>, <code class="literal">SIGNAL</code></td><td>The member, either the method name or signal name.</td></tr><tr><td><code class="literal">ERROR_NAME</code></td><td>4</td><td><code class="literal">STRING</code></td><td><code class="literal">ERROR</code></td><td>The name of the error that occurred, for errors</td></tr><tr><td><code class="literal">REPLY_SERIAL</code></td><td>5</td><td><code class="literal">UINT32</code></td><td><code class="literal">ERROR</code>, <code class="literal">METHOD_RETURN</code></td><td>The serial number of the message this message is a reply - to. (The serial number is the second <code class="literal">UINT32</code> in the header.)</td></tr><tr><td><code class="literal">DESTINATION</code></td><td>6</td><td><code class="literal">STRING</code></td><td>optional</td><td>The name of the connection this message is intended for. - Only used in combination with the message bus, see - <a class="xref" href="#message-bus" title="Message Bus Specification">the section called “Message Bus Specification”</a>.</td></tr><tr><td><code class="literal">SENDER</code></td><td>7</td><td><code class="literal">STRING</code></td><td>optional</td><td>Unique name of the sending connection. - The message bus fills in this field so it is reliable; the field is - only meaningful in combination with the message bus.</td></tr><tr><td><code class="literal">SIGNATURE</code></td><td>8</td><td><code class="literal">SIGNATURE</code></td><td>optional</td><td>The signature of the message body. - If omitted, it is assumed to be the - empty signature "" (i.e. the body must be 0-length).</td></tr><tr><td><code class="literal">UNIX_FDS</code></td><td>9</td><td><code class="literal">UINT32</code></td><td>optional</td><td>The number of Unix file descriptors that - accompany the message. If omitted, it is assumed - that no Unix file descriptors accompany the - message. The actual file descriptors need to be - transferred via platform specific mechanism - out-of-band. They must be sent at the same time as - part of the message itself. They may not be sent - before the first byte of the message itself is - transferred or after the last byte of the message - itself.</td></tr></tbody></table></div><p> - </p></div></div><div class="sect2" title="Valid Names"><div class="titlepage"><div><div><h3 class="title"><a name="message-protocol-names"></a>Valid Names</h3></div></div></div><p> - The various names in D-Bus messages have some restrictions. - </p><p> - There is a <em class="firstterm">maximum name length</em> - of 255 which applies to bus names, interfaces, and members. - </p><div class="sect3" title="Interface names"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-names-interface"></a>Interface names</h4></div></div></div><p> - Interfaces have names with type <code class="literal">STRING</code>, meaning that - they must be valid UTF-8. However, there are also some - additional restrictions that apply to interface names - specifically: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Interface names are composed of 1 or more elements separated by - a period ('.') character. All elements must contain at least - one character. - </p></li><li class="listitem"><p>Each element must only contain the ASCII characters - "[A-Z][a-z][0-9]_" and must not begin with a digit. - </p></li><li class="listitem"><p>Interface names must contain at least one '.' (period) - character (and thus at least two elements). - </p></li><li class="listitem"><p>Interface names must not begin with a '.' (period) character.</p></li><li class="listitem"><p>Interface names must not exceed the maximum name length.</p></li></ul></div><p> - </p><p> - Interface names should start with the reversed DNS domain name of - the author of the interface (in lower-case), like interface names - in Java. It is conventional for the rest of the interface name - to consist of words run together, with initial capital letters - on all words ("CamelCase"). Several levels of hierarchy can be used. - It is also a good idea to include the major version of the interface - in the name, and increment it if incompatible changes are made; - this way, a single object can implement several versions of an - interface in parallel, if necessary. - </p><p> - For instance, if the owner of <code class="literal">example.com</code> is - developing a D-Bus API for a music player, they might define - interfaces called <code class="literal">com.example.MusicPlayer1</code>, - <code class="literal">com.example.MusicPlayer1.Track</code> and - <code class="literal">com.example.MusicPlayer1.Seekable</code>. - </p><p> - D-Bus does not distinguish between the concepts that would be - called classes and interfaces in Java: either can be identified on - D-Bus by an interface name. - </p></div><div class="sect3" title="Bus names"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-names-bus"></a>Bus names</h4></div></div></div><p> - Connections have one or more bus names associated with them. - A connection has exactly one bus name that is a <em class="firstterm">unique - connection name</em>. The unique connection name remains - with the connection for its entire lifetime. - A bus name is of type <code class="literal">STRING</code>, - meaning that it must be valid UTF-8. However, there are also - some additional restrictions that apply to bus names - specifically: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Bus names that start with a colon (':') - character are unique connection names. Other bus names - are called <em class="firstterm">well-known bus names</em>. - </p></li><li class="listitem"><p>Bus names are composed of 1 or more elements separated by - a period ('.') character. All elements must contain at least - one character. - </p></li><li class="listitem"><p>Each element must only contain the ASCII characters - "[A-Z][a-z][0-9]_-". Only elements that are part of a unique - connection name may begin with a digit, elements in - other bus names must not begin with a digit. - </p></li><li class="listitem"><p>Bus names must contain at least one '.' (period) - character (and thus at least two elements). - </p></li><li class="listitem"><p>Bus names must not begin with a '.' (period) character.</p></li><li class="listitem"><p>Bus names must not exceed the maximum name length.</p></li></ul></div><p> - </p><p> - Note that the hyphen ('-') character is allowed in bus names but - not in interface names. - </p><p> - Like <a class="link" href="#message-protocol-names-interface" title="Interface names">interface - names</a>, well-known bus names should start with the - reversed DNS domain name of the author of the interface (in - lower-case), and it is conventional for the rest of the well-known - bus name to consist of words run together, with initial - capital letters. As with interface names, including a version - number in well-known bus names is a good idea; it's possible to - have the well-known bus name for more than one version - simultaneously if backwards compatibility is required. - </p><p> - If a well-known bus name implies the presence of a "main" interface, - that "main" interface is often given the same name as - the well-known bus name, and situated at the corresponding object - path. For instance, if the owner of <code class="literal">example.com</code> - is developing a D-Bus API for a music player, they might define - that any application that takes the well-known name - <code class="literal">com.example.MusicPlayer1</code> should have an object - at the object path <code class="literal">/com/example/MusicPlayer1</code> - which implements the interface - <code class="literal">com.example.MusicPlayer1</code>. - </p></div><div class="sect3" title="Member names"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-names-member"></a>Member names</h4></div></div></div><p> - Member (i.e. method or signal) names: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Must only contain the ASCII characters - "[A-Z][a-z][0-9]_" and may not begin with a - digit.</p></li><li class="listitem"><p>Must not contain the '.' (period) character.</p></li><li class="listitem"><p>Must not exceed the maximum name length.</p></li><li class="listitem"><p>Must be at least 1 byte in length.</p></li></ul></div><p> - </p><p> - It is conventional for member names on D-Bus to consist of - capitalized words with no punctuation ("camel-case"). - Method names should usually be verbs, such as - <code class="literal">GetItems</code>, and signal names should usually be - a description of an event, such as <code class="literal">ItemsChanged</code>. - </p></div><div class="sect3" title="Error names"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-names-error"></a>Error names</h4></div></div></div><p> - Error names have the same restrictions as interface names. - </p><p> - Error names have the same naming conventions as interface - names, and often contain <code class="literal">.Error.</code>; for instance, - the owner of <code class="literal">example.com</code> might define the - errors <code class="literal">com.example.MusicPlayer.Error.FileNotFound</code> - and <code class="literal">com.example.MusicPlayer.Error.OutOfMemory</code>. - The errors defined by D-Bus itself, such as - <code class="literal">org.freedesktop.DBus.Error.Failed</code>, follow a - similar pattern. - </p></div></div><div class="sect2" title="Message Types"><div class="titlepage"><div><div><h3 class="title"><a name="message-protocol-types"></a>Message Types</h3></div></div></div><p> - Each of the message types (<code class="literal">METHOD_CALL</code>, <code class="literal">METHOD_RETURN</code>, <code class="literal">ERROR</code>, and - <code class="literal">SIGNAL</code>) has its own expected usage conventions and header fields. - This section describes these conventions. - </p><div class="sect3" title="Method Calls"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-types-method"></a>Method Calls</h4></div></div></div><p> - Some messages invoke an operation on a remote object. These are - called method call messages and have the type tag <code class="literal">METHOD_CALL</code>. Such - messages map naturally to methods on objects in a typical program. - </p><p> - A method call message is required to have a <code class="literal">MEMBER</code> header field - indicating the name of the method. Optionally, the message has an - <code class="literal">INTERFACE</code> field giving the interface the method is a part of. In the - absence of an <code class="literal">INTERFACE</code> field, if two interfaces on the same object have - a method with the same name, it is undefined which of the two methods - will be invoked. Implementations may also choose to return an error in - this ambiguous case. However, if a method name is unique - implementations must not require an interface field. - </p><p> - Method call messages also include a <code class="literal">PATH</code> field - indicating the object to invoke the method on. If the call is passing - through a message bus, the message will also have a - <code class="literal">DESTINATION</code> field giving the name of the connection - to receive the message. - </p><p> - When an application handles a method call message, it is required to - return a reply. The reply is identified by a <code class="literal">REPLY_SERIAL</code> header field - indicating the serial number of the <code class="literal">METHOD_CALL</code> being replied to. The - reply can have one of two types; either <code class="literal">METHOD_RETURN</code> or <code class="literal">ERROR</code>. - </p><p> - If the reply has type <code class="literal">METHOD_RETURN</code>, the arguments to the reply message - are the return value(s) or "out parameters" of the method call. - If the reply has type <code class="literal">ERROR</code>, then an "exception" has been thrown, - and the call fails; no return value will be provided. It makes - no sense to send multiple replies to the same method call. - </p><p> - Even if a method call has no return values, a <code class="literal">METHOD_RETURN</code> - reply is required, so the caller will know the method - was successfully processed. - </p><p> - The <code class="literal">METHOD_RETURN</code> or <code class="literal">ERROR</code> reply message must have the <code class="literal">REPLY_SERIAL</code> - header field. - </p><p> - If a <code class="literal">METHOD_CALL</code> message has the flag <code class="literal">NO_REPLY_EXPECTED</code>, - then as an optimization the application receiving the method - call may choose to omit the reply message (regardless of - whether the reply would have been <code class="literal">METHOD_RETURN</code> or <code class="literal">ERROR</code>). - However, it is also acceptable to ignore the <code class="literal">NO_REPLY_EXPECTED</code> - flag and reply anyway. - </p><p> - Unless a message has the flag <code class="literal">NO_AUTO_START</code>, if the - destination name does not exist then a program to own the destination - name will be started before the message is delivered. The message - will be held until the new program is successfully started or has - failed to start; in case of failure, an error will be returned. This - flag is only relevant in the context of a message bus, it is ignored - during one-to-one communication with no intermediate bus. - </p><div class="sect4" title="Mapping method calls to native APIs"><div class="titlepage"><div><div><h5 class="title"><a name="message-protocol-types-method-apis"></a>Mapping method calls to native APIs</h5></div></div></div><p> - APIs for D-Bus may map method calls to a method call in a specific - programming language, such as C++, or may map a method call written - in an IDL to a D-Bus message. - </p><p> - In APIs of this nature, arguments to a method are often termed "in" - (which implies sent in the <code class="literal">METHOD_CALL</code>), or "out" (which implies - returned in the <code class="literal">METHOD_RETURN</code>). Some APIs such as CORBA also have - "inout" arguments, which are both sent and received, i.e. the caller - passes in a value which is modified. Mapped to D-Bus, an "inout" - argument is equivalent to an "in" argument, followed by an "out" - argument. You can't pass things "by reference" over the wire, so - "inout" is purely an illusion of the in-process API. - </p><p> - Given a method with zero or one return values, followed by zero or more - arguments, where each argument may be "in", "out", or "inout", the - caller constructs a message by appending each "in" or "inout" argument, - in order. "out" arguments are not represented in the caller's message. - </p><p> - The recipient constructs a reply by appending first the return value - if any, then each "out" or "inout" argument, in order. - "in" arguments are not represented in the reply message. - </p><p> - Error replies are normally mapped to exceptions in languages that have - exceptions. - </p><p> - In converting from native APIs to D-Bus, it is perhaps nice to - map D-Bus naming conventions ("FooBar") to native conventions - such as "fooBar" or "foo_bar" automatically. This is OK - as long as you can say that the native API is one that - was specifically written for D-Bus. It makes the most sense - when writing object implementations that will be exported - over the bus. Object proxies used to invoke remote D-Bus - objects probably need the ability to call any D-Bus method, - and thus a magic name mapping like this could be a problem. - </p><p> - This specification doesn't require anything of native API bindings; - the preceding is only a suggested convention for consistency - among bindings. - </p></div></div><div class="sect3" title="Signal Emission"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-types-signal"></a>Signal Emission</h4></div></div></div><p> - Unlike method calls, signal emissions have no replies. - A signal emission is simply a single message of type <code class="literal">SIGNAL</code>. - It must have three header fields: <code class="literal">PATH</code> giving the object - the signal was emitted from, plus <code class="literal">INTERFACE</code> and <code class="literal">MEMBER</code> giving - the fully-qualified name of the signal. The <code class="literal">INTERFACE</code> header is required - for signals, though it is optional for method calls. - </p></div><div class="sect3" title="Errors"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-types-errors"></a>Errors</h4></div></div></div><p> - Messages of type <code class="literal">ERROR</code> are most commonly replies - to a <code class="literal">METHOD_CALL</code>, but may be returned in reply - to any kind of message. The message bus for example - will return an <code class="literal">ERROR</code> in reply to a signal emission if - the bus does not have enough memory to send the signal. - </p><p> - An <code class="literal">ERROR</code> may have any arguments, but if the first - argument is a <code class="literal">STRING</code>, it must be an error message. - The error message may be logged or shown to the user - in some way. - </p></div><div class="sect3" title="Notation in this document"><div class="titlepage"><div><div><h4 class="title"><a name="message-protocol-types-notation"></a>Notation in this document</h4></div></div></div><p> - This document uses a simple pseudo-IDL to describe particular method - calls and signals. Here is an example of a method call: - </p><pre class="programlisting"> - org.freedesktop.DBus.StartServiceByName (in STRING name, in UINT32 flags, - out UINT32 resultcode) - </pre><p> - This means <code class="literal">INTERFACE</code> = org.freedesktop.DBus, <code class="literal">MEMBER</code> = StartServiceByName, - <code class="literal">METHOD_CALL</code> arguments are <code class="literal">STRING</code> and <code class="literal">UINT32</code>, <code class="literal">METHOD_RETURN</code> argument - is <code class="literal">UINT32</code>. Remember that the <code class="literal">MEMBER</code> field can't contain any '.' (period) - characters so it's known that the last part of the name in - the "IDL" is the member name. - </p><p> - In C++ that might end up looking like this: - </p><pre class="programlisting"> - unsigned int org::freedesktop::DBus::StartServiceByName (const char *name, - unsigned int flags); - </pre><p> - or equally valid, the return value could be done as an argument: - </p><pre class="programlisting"> - void org::freedesktop::DBus::StartServiceByName (const char *name, - unsigned int flags, - unsigned int *resultcode); - </pre><p> - It's really up to the API designer how they want to make - this look. You could design an API where the namespace wasn't used - in C++, using STL or Qt, using varargs, or whatever you wanted. - </p><p> - Signals are written as follows: - </p><pre class="programlisting"> - org.freedesktop.DBus.NameLost (STRING name) - </pre><p> - Signals don't specify "in" vs. "out" because only - a single direction is possible. - </p><p> - It isn't especially encouraged to use this lame pseudo-IDL in actual - API implementations; you might use the native notation for the - language you're using, or you might use COM or CORBA IDL, for example. - </p></div></div><div class="sect2" title="Invalid Protocol and Spec Extensions"><div class="titlepage"><div><div><h3 class="title"><a name="message-protocol-handling-invalid"></a>Invalid Protocol and Spec Extensions</h3></div></div></div><p> - For security reasons, the D-Bus protocol should be strictly parsed and - validated, with the exception of defined extension points. Any invalid - protocol or spec violations should result in immediately dropping the - connection without notice to the other end. Exceptions should be - carefully considered, e.g. an exception may be warranted for a - well-understood idiosyncrasy of a widely-deployed implementation. In - cases where the other end of a connection is 100% trusted and known to - be friendly, skipping validation for performance reasons could also make - sense in certain cases. - </p><p> - Generally speaking violations of the "must" requirements in this spec - should be considered possible attempts to exploit security, and violations - of the "should" suggestions should be considered legitimate (though perhaps - they should generate an error in some cases). - </p><p> - The following extension points are built in to D-Bus on purpose and must - not be treated as invalid protocol. The extension points are intended - for use by future versions of this spec, they are not intended for third - parties. At the moment, the only way a third party could extend D-Bus - without breaking interoperability would be to introduce a way to negotiate new - feature support as part of the auth protocol, using EXTENSION_-prefixed - commands. There is not yet a standard way to negotiate features. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - In the authentication protocol (see <a class="xref" href="#auth-protocol" title="Authentication Protocol">the section called “Authentication Protocol”</a>) unknown - commands result in an ERROR rather than a disconnect. This enables - future extensions to the protocol. Commands starting with EXTENSION_ are - reserved for third parties. - </p></li><li class="listitem"><p> - The authentication protocol supports pluggable auth mechanisms. - </p></li><li class="listitem"><p> - The address format (see <a class="xref" href="#addresses" title="Server Addresses">the section called “Server Addresses”</a>) supports new - kinds of transport. - </p></li><li class="listitem"><p> - Messages with an unknown type (something other than - <code class="literal">METHOD_CALL</code>, <code class="literal">METHOD_RETURN</code>, - <code class="literal">ERROR</code>, <code class="literal">SIGNAL</code>) are ignored. - Unknown-type messages must still be well-formed in the same way - as the known messages, however. They still have the normal - header and body. - </p></li><li class="listitem"><p> - Header fields with an unknown or unexpected field code must be ignored, - though again they must still be well-formed. - </p></li><li class="listitem"><p> - New standard interfaces (with new methods and signals) can of course be added. - </p></li></ul></div><p> - </p></div></div><div class="sect1" title="Authentication Protocol"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="auth-protocol"></a>Authentication Protocol</h2></div></div></div><p> - Before the flow of messages begins, two applications must - authenticate. A simple plain-text protocol is used for - authentication; this protocol is a SASL profile, and maps fairly - directly from the SASL specification. The message encoding is - NOT used here, only plain text messages. - </p><p> - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - </p><div class="sect2" title="Protocol Overview"><div class="titlepage"><div><div><h3 class="title"><a name="auth-protocol-overview"></a>Protocol Overview</h3></div></div></div><p> - The protocol is a line-based protocol, where each line ends with - \r\n. Each line begins with an all-caps ASCII command name containing - only the character range [A-Z_], a space, then any arguments for the - command, then the \r\n ending the line. The protocol is - case-sensitive. All bytes must be in the ASCII character set. - - Commands from the client to the server are as follows: - - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>AUTH [mechanism] [initial-response]</p></li><li class="listitem"><p>CANCEL</p></li><li class="listitem"><p>BEGIN</p></li><li class="listitem"><p>DATA <data in hex encoding></p></li><li class="listitem"><p>ERROR [human-readable error explanation]</p></li><li class="listitem"><p>NEGOTIATE_UNIX_FD</p></li></ul></div><p> - - From server to client are as follows: - - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>REJECTED <space-separated list of mechanism names></p></li><li class="listitem"><p>OK <GUID in hex></p></li><li class="listitem"><p>DATA <data in hex encoding></p></li><li class="listitem"><p>ERROR</p></li><li class="listitem"><p>AGREE_UNIX_FD</p></li></ul></div><p> - </p><p> - Unofficial extensions to the command set must begin with the letters - "EXTENSION_", to avoid conflicts with future official commands. - For example, "EXTENSION_COM_MYDOMAIN_DO_STUFF". - </p></div><div class="sect2" title="Special credentials-passing nul byte"><div class="titlepage"><div><div><h3 class="title"><a name="auth-nul-byte"></a>Special credentials-passing nul byte</h3></div></div></div><p> - Immediately after connecting to the server, the client must send a - single nul byte. This byte may be accompanied by credentials - information on some operating systems that use sendmsg() with - SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain - sockets. However, the nul byte must be sent even on other kinds of - socket, and even on operating systems that do not require a byte to be - sent in order to transmit credentials. The text protocol described in - this document begins after the single nul byte. If the first byte - received from the client is not a nul byte, the server may disconnect - that client. - </p><p> - A nul byte in any context other than the initial byte is an error; - the protocol is ASCII-only. - </p><p> - The credentials sent along with the nul byte may be used with the - SASL mechanism EXTERNAL. - </p></div><div class="sect2" title="AUTH command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-auth"></a>AUTH command</h3></div></div></div><p> - If an AUTH command has no arguments, it is a request to list - available mechanisms. The server must respond with a REJECTED - command listing the mechanisms it understands, or with an error. - </p><p> - If an AUTH command specifies a mechanism, and the server supports - said mechanism, the server should begin exchanging SASL - challenge-response data with the client using DATA commands. - </p><p> - If the server does not support the mechanism given in the AUTH - command, it must send either a REJECTED command listing the mechanisms - it does support, or an error. - </p><p> - If the [initial-response] argument is provided, it is intended for use - with mechanisms that have no initial challenge (or an empty initial - challenge), as if it were the argument to an initial DATA command. If - the selected mechanism has an initial challenge and [initial-response] - was provided, the server should reject authentication by sending - REJECTED. - </p><p> - If authentication succeeds after exchanging DATA commands, - an OK command must be sent to the client. - </p><p> - The first octet received by the server after the \r\n of the BEGIN - command from the client must be the first octet of the - authenticated/encrypted stream of D-Bus messages. - </p><p> - If BEGIN is received by the server, the first octet received - by the client after the \r\n of the OK command must be the - first octet of the authenticated/encrypted stream of D-Bus - messages. - </p></div><div class="sect2" title="CANCEL Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-cancel"></a>CANCEL Command</h3></div></div></div><p> - At any time up to sending the BEGIN command, the client may send a - CANCEL command. On receiving the CANCEL command, the server must - send a REJECTED command and abort the current authentication - exchange. - </p></div><div class="sect2" title="DATA Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-data"></a>DATA Command</h3></div></div></div><p> - The DATA command may come from either client or server, and simply - contains a hex-encoded block of data to be interpreted - according to the SASL mechanism in use. - </p><p> - Some SASL mechanisms support sending an "empty string"; - FIXME we need some way to do this. - </p></div><div class="sect2" title="BEGIN Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-begin"></a>BEGIN Command</h3></div></div></div><p> - The BEGIN command acknowledges that the client has received an - OK command from the server, and that the stream of messages - is about to begin. - </p><p> - The first octet received by the server after the \r\n of the BEGIN - command from the client must be the first octet of the - authenticated/encrypted stream of D-Bus messages. - </p></div><div class="sect2" title="REJECTED Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-rejected"></a>REJECTED Command</h3></div></div></div><p> - The REJECTED command indicates that the current authentication - exchange has failed, and further exchange of DATA is inappropriate. - The client would normally try another mechanism, or try providing - different responses to challenges. - </p><p> - Optionally, the REJECTED command has a space-separated list of - available auth mechanisms as arguments. If a server ever provides - a list of supported mechanisms, it must provide the same list - each time it sends a REJECTED message. Clients are free to - ignore all lists received after the first. - </p></div><div class="sect2" title="OK Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-ok"></a>OK Command</h3></div></div></div><p> - The OK command indicates that the client has been - authenticated. The client may now proceed with negotiating - Unix file descriptor passing. To do that it shall send - NEGOTIATE_UNIX_FD to the server. - </p><p> - Otherwise, the client must respond to the OK command by - sending a BEGIN command, followed by its stream of messages, - or by disconnecting. The server must not accept additional - commands using this protocol after the BEGIN command has been - received. Further communication will be a stream of D-Bus - messages (optionally encrypted, as negotiated) rather than - this protocol. - </p><p> - If a client sends BEGIN the first octet received by the client - after the \r\n of the OK command must be the first octet of - the authenticated/encrypted stream of D-Bus messages. - </p><p> - The OK command has one argument, which is the GUID of the server. - See <a class="xref" href="#addresses" title="Server Addresses">the section called “Server Addresses”</a> for more on server GUIDs. - </p></div><div class="sect2" title="ERROR Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-error"></a>ERROR Command</h3></div></div></div><p> - The ERROR command indicates that either server or client did not - know a command, does not accept the given command in the current - context, or did not understand the arguments to the command. This - allows the protocol to be extended; a client or server can send a - command present or permitted only in new protocol versions, and if - an ERROR is received instead of an appropriate response, fall back - to using some other technique. - </p><p> - If an ERROR is sent, the server or client that sent the - error must continue as if the command causing the ERROR had never been - received. However, the the server or client receiving the error - should try something other than whatever caused the error; - if only canceling/rejecting the authentication. - </p><p> - If the D-Bus protocol changes incompatibly at some future time, - applications implementing the new protocol would probably be able to - check for support of the new protocol by sending a new command and - receiving an ERROR from applications that don't understand it. Thus the - ERROR feature of the auth protocol is an escape hatch that lets us - negotiate extensions or changes to the D-Bus protocol in the future. - </p></div><div class="sect2" title="NEGOTIATE_UNIX_FD Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-negotiate-unix-fd"></a>NEGOTIATE_UNIX_FD Command</h3></div></div></div><p> - The NEGOTIATE_UNIX_FD command indicates that the client - supports Unix file descriptor passing. This command may only - be sent after the connection is authenticated, i.e. after OK - was received by the client. This command may only be sent on - transports that support Unix file descriptor passing. - </p><p> - On receiving NEGOTIATE_UNIX_FD the server must respond with - either AGREE_UNIX_FD or ERROR. It shall respond the former if - the transport chosen supports Unix file descriptor passing and - the server supports this feature. It shall respond the latter - if the transport does not support Unix file descriptor - passing, the server does not support this feature, or the - server decides not to enable file descriptor passing due to - security or other reasons. - </p></div><div class="sect2" title="AGREE_UNIX_FD Command"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-agree-unix-fd"></a>AGREE_UNIX_FD Command</h3></div></div></div><p> - The AGREE_UNIX_FD command indicates that the server supports - Unix file descriptor passing. This command may only be sent - after the connection is authenticated, and the client sent - NEGOTIATE_UNIX_FD to enable Unix file descriptor passing. This - command may only be sent on transports that support Unix file - descriptor passing. - </p><p> - On receiving AGREE_UNIX_FD the client must respond with BEGIN, - followed by its stream of messages, or by disconnecting. The - server must not accept additional commands using this protocol - after the BEGIN command has been received. Further - communication will be a stream of D-Bus messages (optionally - encrypted, as negotiated) rather than this protocol. - </p></div><div class="sect2" title="Future Extensions"><div class="titlepage"><div><div><h3 class="title"><a name="auth-command-future"></a>Future Extensions</h3></div></div></div><p> - Future extensions to the authentication and negotiation - protocol are possible. For that new commands may be - introduced. If a client or server receives an unknown command - it shall respond with ERROR and not consider this fatal. New - commands may be introduced both before, and after - authentication, i.e. both before and after the OK command. - </p></div><div class="sect2" title="Authentication examples"><div class="titlepage"><div><div><h3 class="title"><a name="auth-examples"></a>Authentication examples</h3></div></div></div><p> - </p><div class="figure"><a name="idp5181008"></a><p class="title"><b>Figure 1. Example of successful magic cookie authentication</b></p><div class="figure-contents"><pre class="programlisting"> - (MAGIC_COOKIE is a made up mechanism) - - C: AUTH MAGIC_COOKIE 3138363935333137393635383634 - S: OK 1234deadbeef - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5182832"></a><p class="title"><b>Figure 2. Example of finding out mechanisms then picking one</b></p><div class="figure-contents"><pre class="programlisting"> - C: AUTH - S: REJECTED KERBEROS_V4 SKEY - C: AUTH SKEY 7ab83f32ee - S: DATA 8799cabb2ea93e - C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f - S: OK 1234deadbeef - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5184736"></a><p class="title"><b>Figure 3. Example of client sends unknown command then falls back to regular auth</b></p><div class="figure-contents"><pre class="programlisting"> - C: FOOBAR - S: ERROR - C: AUTH MAGIC_COOKIE 3736343435313230333039 - S: OK 1234deadbeef - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5186624"></a><p class="title"><b>Figure 4. Example of server doesn't support initial auth mechanism</b></p><div class="figure-contents"><pre class="programlisting"> - C: AUTH MAGIC_COOKIE 3736343435313230333039 - S: REJECTED KERBEROS_V4 SKEY - C: AUTH SKEY 7ab83f32ee - S: DATA 8799cabb2ea93e - C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f - S: OK 1234deadbeef - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5188640"></a><p class="title"><b>Figure 5. Example of wrong password or the like followed by successful retry</b></p><div class="figure-contents"><pre class="programlisting"> - C: AUTH MAGIC_COOKIE 3736343435313230333039 - S: REJECTED KERBEROS_V4 SKEY - C: AUTH SKEY 7ab83f32ee - S: DATA 8799cabb2ea93e - C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f - S: REJECTED - C: AUTH SKEY 7ab83f32ee - S: DATA 8799cabb2ea93e - C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f - S: OK 1234deadbeef - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5190816"></a><p class="title"><b>Figure 6. Example of skey cancelled and restarted</b></p><div class="figure-contents"><pre class="programlisting"> - C: AUTH MAGIC_COOKIE 3736343435313230333039 - S: REJECTED KERBEROS_V4 SKEY - C: AUTH SKEY 7ab83f32ee - S: DATA 8799cabb2ea93e - C: CANCEL - S: REJECTED - C: AUTH SKEY 7ab83f32ee - S: DATA 8799cabb2ea93e - C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f - S: OK 1234deadbeef - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5192880"></a><p class="title"><b>Figure 7. Example of successful magic cookie authentication with successful negotiation of Unix FD passing</b></p><div class="figure-contents"><pre class="programlisting"> - (MAGIC_COOKIE is a made up mechanism) - - C: AUTH MAGIC_COOKIE 3138363935333137393635383634 - S: OK 1234deadbeef - C: NEGOTIATE_UNIX_FD - S: AGREE_UNIX_FD - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p><div class="figure"><a name="idp5194880"></a><p class="title"><b>Figure 8. Example of successful magic cookie authentication with unsuccessful negotiation of Unix FD passing</b></p><div class="figure-contents"><pre class="programlisting"> - (MAGIC_COOKIE is a made up mechanism) - - C: AUTH MAGIC_COOKIE 3138363935333137393635383634 - S: OK 1234deadbeef - C: NEGOTIATE_UNIX_FD - S: ERROR - C: BEGIN - </pre></div></div><p><br class="figure-break"> - </p></div><div class="sect2" title="Authentication state diagrams"><div class="titlepage"><div><div><h3 class="title"><a name="auth-states"></a>Authentication state diagrams</h3></div></div></div><p> - This section documents the auth protocol in terms of - a state machine for the client and the server. This is - probably the most robust way to implement the protocol. - </p><div class="sect3" title="Client states"><div class="titlepage"><div><div><h4 class="title"><a name="auth-states-client"></a>Client states</h4></div></div></div><p> - To more precisely describe the interaction between the - protocol state machine and the authentication mechanisms the - following notation is used: MECH(CHALL) means that the - server challenge CHALL was fed to the mechanism MECH, which - returns one of - - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - CONTINUE(RESP) means continue the auth conversation - and send RESP as the response to the server; - </p></li><li class="listitem"><p> - OK(RESP) means that after sending RESP to the server - the client side of the auth conversation is finished - and the server should return "OK"; - </p></li><li class="listitem"><p> - ERROR means that CHALL was invalid and could not be - processed. - </p></li></ul></div><p> - - Both RESP and CHALL may be empty. - </p><p> - The Client starts by getting an initial response from the - default mechanism and sends AUTH MECH RESP, or AUTH MECH if - the mechanism did not provide an initial response. If the - mechanism returns CONTINUE, the client starts in state - <span class="emphasis"><em>WaitingForData</em></span>, if the mechanism - returns OK the client starts in state - <span class="emphasis"><em>WaitingForOK</em></span>. - </p><p> - The client should keep track of available mechanisms and - which it mechanisms it has already attempted. This list is - used to decide which AUTH command to send. When the list is - exhausted, the client should give up and close the - connection. - </p><p title="WaitingForData"><b><span class="emphasis"><em>WaitingForData</em></span>. </b> - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Receive DATA CHALL - </p><table border="0" summary="Simple list" class="simplelist"><tr><td> - MECH(CHALL) returns CONTINUE(RESP) → send - DATA RESP, goto - <span class="emphasis"><em>WaitingForData</em></span> - </td></tr><tr><td> - MECH(CHALL) returns OK(RESP) → send DATA - RESP, goto <span class="emphasis"><em>WaitingForOK</em></span> - </td></tr><tr><td> - MECH(CHALL) returns ERROR → send ERROR - [msg], goto <span class="emphasis"><em>WaitingForData</em></span> - </td></tr></table><p> - </p></li><li class="listitem"><p> - Receive REJECTED [mechs] → - send AUTH [next mech], goto - WaitingForData or <span class="emphasis"><em>WaitingForOK</em></span> - </p></li><li class="listitem"><p> - Receive ERROR → send - CANCEL, goto - <span class="emphasis"><em>WaitingForReject</em></span> - </p></li><li class="listitem"><p> - Receive OK → send - BEGIN, terminate auth - conversation, authenticated - </p></li><li class="listitem"><p> - Receive anything else → send - ERROR, goto - <span class="emphasis"><em>WaitingForData</em></span> - </p></li></ul></div><p title="WaitingForData"> - </p><p title="WaitingForOK"><b><span class="emphasis"><em>WaitingForOK</em></span>. </b> - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Receive OK → send BEGIN, terminate auth - conversation, <span class="emphasis"><em>authenticated</em></span> - </p></li><li class="listitem"><p> - Receive REJECT [mechs] → send AUTH [next mech], - goto <span class="emphasis"><em>WaitingForData</em></span> or - <span class="emphasis"><em>WaitingForOK</em></span> - </p></li><li class="listitem"><p> - Receive DATA → send CANCEL, goto - <span class="emphasis"><em>WaitingForReject</em></span> - </p></li><li class="listitem"><p> - Receive ERROR → send CANCEL, goto - <span class="emphasis"><em>WaitingForReject</em></span> - </p></li><li class="listitem"><p> - Receive anything else → send ERROR, goto - <span class="emphasis"><em>WaitingForOK</em></span> - </p></li></ul></div><p title="WaitingForOK"> - </p><p title="WaitingForReject"><b><span class="emphasis"><em>WaitingForReject</em></span>. </b> - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Receive REJECT [mechs] → send AUTH [next mech], - goto <span class="emphasis"><em>WaitingForData</em></span> or - <span class="emphasis"><em>WaitingForOK</em></span> - </p></li><li class="listitem"><p> - Receive anything else → terminate auth - conversation, disconnect - </p></li></ul></div><p title="WaitingForReject"> - </p></div><div class="sect3" title="Server states"><div class="titlepage"><div><div><h4 class="title"><a name="auth-states-server"></a>Server states</h4></div></div></div><p> - For the server MECH(RESP) means that the client response - RESP was fed to the the mechanism MECH, which returns one of - - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - CONTINUE(CHALL) means continue the auth conversation and - send CHALL as the challenge to the client; - </p></li><li class="listitem"><p> - OK means that the client has been successfully - authenticated; - </p></li><li class="listitem"><p> - REJECT means that the client failed to authenticate or - there was an error in RESP. - </p></li></ul></div><p> - - The server starts out in state - <span class="emphasis"><em>WaitingForAuth</em></span>. If the client is - rejected too many times the server must disconnect the - client. - </p><p title="WaitingForAuth"><b><span class="emphasis"><em>WaitingForAuth</em></span>. </b> - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Receive AUTH → send REJECTED [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li><li class="listitem"><p> - Receive AUTH MECH RESP - - </p><table border="0" summary="Simple list" class="simplelist"><tr><td> - MECH not valid mechanism → send REJECTED - [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </td></tr><tr><td> - MECH(RESP) returns CONTINUE(CHALL) → send - DATA CHALL, goto - <span class="emphasis"><em>WaitingForData</em></span> - </td></tr><tr><td> - MECH(RESP) returns OK → send OK, goto - <span class="emphasis"><em>WaitingForBegin</em></span> - </td></tr><tr><td> - MECH(RESP) returns REJECT → send REJECTED - [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </td></tr></table><p> - </p></li><li class="listitem"><p> - Receive BEGIN → terminate - auth conversation, disconnect - </p></li><li class="listitem"><p> - Receive ERROR → send REJECTED [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li><li class="listitem"><p> - Receive anything else → send - ERROR, goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li></ul></div><p title="WaitingForAuth"> - </p><p title="WaitingForData"><b><span class="emphasis"><em>WaitingForData</em></span>. </b> - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Receive DATA RESP - </p><table border="0" summary="Simple list" class="simplelist"><tr><td> - MECH(RESP) returns CONTINUE(CHALL) → send - DATA CHALL, goto - <span class="emphasis"><em>WaitingForData</em></span> - </td></tr><tr><td> - MECH(RESP) returns OK → send OK, goto - <span class="emphasis"><em>WaitingForBegin</em></span> - </td></tr><tr><td> - MECH(RESP) returns REJECT → send REJECTED - [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </td></tr></table><p> - </p></li><li class="listitem"><p> - Receive BEGIN → terminate auth conversation, - disconnect - </p></li><li class="listitem"><p> - Receive CANCEL → send REJECTED [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li><li class="listitem"><p> - Receive ERROR → send REJECTED [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li><li class="listitem"><p> - Receive anything else → send ERROR, goto - <span class="emphasis"><em>WaitingForData</em></span> - </p></li></ul></div><p title="WaitingForData"> - </p><p title="WaitingForBegin"><b><span class="emphasis"><em>WaitingForBegin</em></span>. </b> - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Receive BEGIN → terminate auth conversation, - client authenticated - </p></li><li class="listitem"><p> - Receive CANCEL → send REJECTED [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li><li class="listitem"><p> - Receive ERROR → send REJECTED [mechs], goto - <span class="emphasis"><em>WaitingForAuth</em></span> - </p></li><li class="listitem"><p> - Receive anything else → send ERROR, goto - <span class="emphasis"><em>WaitingForBegin</em></span> - </p></li></ul></div><p title="WaitingForBegin"> - </p></div></div><div class="sect2" title="Authentication mechanisms"><div class="titlepage"><div><div><h3 class="title"><a name="auth-mechanisms"></a>Authentication mechanisms</h3></div></div></div><p> - This section describes some new authentication mechanisms. - D-Bus also allows any standard SASL mechanism of course. - </p><div class="sect3" title="DBUS_COOKIE_SHA1"><div class="titlepage"><div><div><h4 class="title"><a name="auth-mechanisms-sha"></a>DBUS_COOKIE_SHA1</h4></div></div></div><p> - The DBUS_COOKIE_SHA1 mechanism is designed to establish that a client - has the ability to read a private file owned by the user being - authenticated. If the client can prove that it has access to a secret - cookie stored in this file, then the client is authenticated. - Thus the security of DBUS_COOKIE_SHA1 depends on a secure home - directory. - </p><p> - Throughout this description, "hex encoding" must output the digits - from a to f in lower-case; the digits A to F must not be used - in the DBUS_COOKIE_SHA1 mechanism. - </p><p> - Authentication proceeds as follows: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The client sends the username it would like to authenticate - as, hex-encoded. - </p></li><li class="listitem"><p> - The server sends the name of its "cookie context" (see below); a - space character; the integer ID of the secret cookie the client - must demonstrate knowledge of; a space character; then a - randomly-generated challenge string, all of this hex-encoded into - one, single string. - </p></li><li class="listitem"><p> - The client locates the cookie and generates its own - randomly-generated challenge string. The client then concatenates - the server's decoded challenge, a ":" character, its own challenge, - another ":" character, and the cookie. It computes the SHA-1 hash - of this composite string as a hex digest. It concatenates the - client's challenge string, a space character, and the SHA-1 hex - digest, hex-encodes the result and sends it back to the server. - </p></li><li class="listitem"><p> - The server generates the same concatenated string used by the - client and computes its SHA-1 hash. It compares the hash with - the hash received from the client; if the two hashes match, the - client is authenticated. - </p></li></ul></div><p> - </p><p> - Each server has a "cookie context," which is a name that identifies a - set of cookies that apply to that server. A sample context might be - "org_freedesktop_session_bus". Context names must be valid ASCII, - nonzero length, and may not contain the characters slash ("/"), - backslash ("\"), space (" "), newline ("\n"), carriage return ("\r"), - tab ("\t"), or period ("."). There is a default context, - "org_freedesktop_general" that's used by servers that do not specify - otherwise. - </p><p> - Cookies are stored in a user's home directory, in the directory - <code class="filename">~/.dbus-keyrings/</code>. This directory must - not be readable or writable by other users. If it is, - clients and servers must ignore it. The directory - contains cookie files named after the cookie context. - </p><p> - A cookie file contains one cookie per line. Each line - has three space-separated fields: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The cookie ID number, which must be a non-negative integer and - may not be used twice in the same file. - </p></li><li class="listitem"><p> - The cookie's creation time, in UNIX seconds-since-the-epoch - format. - </p></li><li class="listitem"><p> - The cookie itself, a hex-encoded random block of bytes. The cookie - may be of any length, though obviously security increases - as the length increases. - </p></li></ul></div><p> - </p><p> - Only server processes modify the cookie file. - They must do so with this procedure: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Create a lockfile name by appending ".lock" to the name of the - cookie file. The server should attempt to create this file - using <code class="literal">O_CREAT | O_EXCL</code>. If file creation - fails, the lock fails. Servers should retry for a reasonable - period of time, then they may choose to delete an existing lock - to keep users from having to manually delete a stale - lock. <sup>[<a name="idp5281040" href="#ftn.idp5281040" class="footnote">1</a>]</sup> - </p></li><li class="listitem"><p> - Once the lockfile has been created, the server loads the cookie - file. It should then delete any cookies that are old (the - timeout can be fairly short), or more than a reasonable - time in the future (so that cookies never accidentally - become permanent, if the clock was set far into the future - at some point). If no recent keys remain, the - server may generate a new key. - </p></li><li class="listitem"><p> - The pruned and possibly added-to cookie file - must be resaved atomically (using a temporary - file which is rename()'d). - </p></li><li class="listitem"><p> - The lock must be dropped by deleting the lockfile. - </p></li></ul></div><p> - </p><p> - Clients need not lock the file in order to load it, - because servers are required to save the file atomically. - </p></div></div></div><div class="sect1" title="Server Addresses"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="addresses"></a>Server Addresses</h2></div></div></div><p> - Server addresses consist of a transport name followed by a colon, and - then an optional, comma-separated list of keys and values in the form key=value. - Each value is escaped. - </p><p> - For example: - </p><pre class="programlisting">unix:path=/tmp/dbus-test</pre><p> - Which is the address to a unix socket with the path /tmp/dbus-test. - </p><p> - Value escaping is similar to URI escaping but simpler. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The set of optionally-escaped bytes is: - <code class="literal">[0-9A-Za-z_-/.\]</code>. To escape, each - <span class="emphasis"><em>byte</em></span> (note, not character) which is not in the - set of optionally-escaped bytes must be replaced with an ASCII - percent (<code class="literal">%</code>) and the value of the byte in hex. - The hex value must always be two digits, even if the first digit is - zero. The optionally-escaped bytes may be escaped if desired. - </p></li><li class="listitem"><p> - To unescape, append each byte in the value; if a byte is an ASCII - percent (<code class="literal">%</code>) character then append the following - hex value instead. It is an error if a <code class="literal">%</code> byte - does not have two hex digits following. It is an error if a - non-optionally-escaped byte is seen unescaped. - </p></li></ul></div><p> - The set of optionally-escaped bytes is intended to preserve address - readability and convenience. - </p><p> - A server may specify a key-value pair with the key <code class="literal">guid</code> - and the value a hex-encoded 16-byte sequence. <a class="xref" href="#uuids" title="UUIDs">the section called “UUIDs”</a> - describes the format of the <code class="literal">guid</code> field. If present, - this UUID may be used to distinguish one server address from another. A - server should use a different UUID for each address it listens on. For - example, if a message bus daemon offers both UNIX domain socket and TCP - connections, but treats clients the same regardless of how they connect, - those two connections are equivalent post-connection but should have - distinct UUIDs to distinguish the kinds of connection. - </p><p> - The intent of the address UUID feature is to allow a client to avoid - opening multiple identical connections to the same server, by allowing the - client to check whether an address corresponds to an already-existing - connection. Comparing two addresses is insufficient, because addresses - can be recycled by distinct servers, and equivalent addresses may look - different if simply compared as strings (for example, the host in a TCP - address can be given as an IP address or as a hostname). - </p><p> - Note that the address key is <code class="literal">guid</code> even though the - rest of the API and documentation says "UUID," for historical reasons. - </p><p> - [FIXME clarify if attempting to connect to each is a requirement - or just a suggestion] - When connecting to a server, multiple server addresses can be - separated by a semi-colon. The library will then try to connect - to the first address and if that fails, it'll try to connect to - the next one specified, and so forth. For example - </p><pre class="programlisting">unix:path=/tmp/dbus-test;unix:path=/tmp/dbus-test2</pre><p> - </p></div><div class="sect1" title="Transports"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="transports"></a>Transports</h2></div></div></div><p> - [FIXME we need to specify in detail each transport and its possible arguments] - - Current transports include: unix domain sockets (including - abstract namespace on linux), launchd, systemd, TCP/IP, an executed subprocess and a debug/testing transport - using in-process pipes. Future possible transports include one that - tunnels over X11 protocol. - </p><div class="sect2" title="Unix Domain Sockets"><div class="titlepage"><div><div><h3 class="title"><a name="transports-unix-domain-sockets"></a>Unix Domain Sockets</h3></div></div></div><p> - Unix domain sockets can be either paths in the file system or on Linux - kernels, they can be abstract which are similar to paths but - do not show up in the file system. - </p><p> - When a socket is opened by the D-Bus library it truncates the path - name right before the first trailing Nul byte. This is true for both - normal paths and abstract paths. Note that this is a departure from - previous versions of D-Bus that would create sockets with a fixed - length path name. Names which were shorter than the fixed length - would be padded by Nul bytes. - </p><p> - Unix domain sockets are not available on Windows. - </p><div class="sect3" title="Server Address Format"><div class="titlepage"><div><div><h4 class="title"><a name="transports-unix-domain-sockets-addresses"></a>Server Address Format</h4></div></div></div><p> - Unix domain socket addresses are identified by the "unix:" prefix - and support the following key/value pairs: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values</th><th>Description</th></tr></thead><tbody><tr><td>path</td><td>(path)</td><td>path of the unix domain socket. If set, the "tmpdir" and "abstract" key must not be set.</td></tr><tr><td>tmpdir</td><td>(path)</td><td>temporary directory in which a socket file with a random file name starting with 'dbus-' will be created by the server. This key can only be used in server addresses, not in client addresses. If set, the "path" and "abstract" key must not be set.</td></tr><tr><td>abstract</td><td>(string)</td><td>unique string (path) in the abstract namespace. If set, the "path" or "tempdir" key must not be set.</td></tr></tbody></table></div></div></div><div class="sect2" title="launchd"><div class="titlepage"><div><div><h3 class="title"><a name="transports-launchd"></a>launchd</h3></div></div></div><p> - launchd is an open-source server management system that replaces init, inetd - and cron on Apple Mac OS X versions 10.4 and above. It provides a common session - bus address for each user and deprecates the X11-enabled D-Bus launcher on OSX. - </p><p> - launchd allocates a socket and provides it with the unix path through the - DBUS_LAUNCHD_SESSION_BUS_SOCKET variable in launchd's environment. Every process - spawned by launchd (or dbus-daemon, if it was started by launchd) can access - it through its environment. - Other processes can query for the launchd socket by executing: - $ launchctl getenv DBUS_LAUNCHD_SESSION_BUS_SOCKET - This is normally done by the D-Bus client library so doesn't have to be done - manually. - </p><p> - launchd is not available on Microsoft Windows. - </p><div class="sect3" title="Server Address Format"><div class="titlepage"><div><div><h4 class="title"><a name="transports-launchd-addresses"></a>Server Address Format</h4></div></div></div><p> - launchd addresses are identified by the "launchd:" prefix - and support the following key/value pairs: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values</th><th>Description</th></tr></thead><tbody><tr><td>env</td><td>(environment variable)</td><td>path of the unix domain socket for the launchd created dbus-daemon.</td></tr></tbody></table></div></div></div><div class="sect2" title="systemd"><div class="titlepage"><div><div><h3 class="title"><a name="transports-systemd"></a>systemd</h3></div></div></div><p> - systemd is an open-source server management system that - replaces init and inetd on newer Linux systems. It supports - socket activation. The D-Bus systemd transport is used to acquire - socket activation file descriptors from systemd and use them - as D-Bus transport when the current process is spawned by - socket activation from it. - </p><p> - The systemd transport accepts only one or more Unix domain or - TCP streams sockets passed in via socket activation. - </p><p> - The systemd transport is not available on non-Linux operating systems. - </p><p> - The systemd transport defines no parameter keys. - </p></div><div class="sect2" title="TCP Sockets"><div class="titlepage"><div><div><h3 class="title"><a name="transports-tcp-sockets"></a>TCP Sockets</h3></div></div></div><p> - The tcp transport provides TCP/IP based connections between clients - located on the same or different hosts. - </p><p> - Using tcp transport without any additional secure authentification mechanismus - over a network is unsecure. - </p><p> - Windows notes: Because of the tcp stack on Windows does not provide sending - credentials over a tcp connection, the EXTERNAL authentification - mechanismus does not work. - </p><div class="sect3" title="Server Address Format"><div class="titlepage"><div><div><h4 class="title"><a name="transports-tcp-sockets-addresses"></a>Server Address Format</h4></div></div></div><p> - TCP/IP socket addresses are identified by the "tcp:" prefix - and support the following key/value pairs: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values</th><th>Description</th></tr></thead><tbody><tr><td>host</td><td>(string)</td><td>dns name or ip address</td></tr><tr><td>port</td><td>(number)</td><td>The tcp port the server will open. A zero value let the server - choose a free port provided from the underlaying operating system. - libdbus is able to retrieve the real used port from the server. - </td></tr><tr><td>family</td><td>(string)</td><td>If set, provide the type of socket family either "ipv4" or "ipv6". If unset, the family is unspecified.</td></tr></tbody></table></div></div></div><div class="sect2" title="Nonce-secured TCP Sockets"><div class="titlepage"><div><div><h3 class="title"><a name="transports-nonce-tcp-sockets"></a>Nonce-secured TCP Sockets</h3></div></div></div><p> - The nonce-tcp transport provides a secured TCP transport, using a - simple authentication mechanism to ensure that only clients with read - access to a certain location in the filesystem can connect to the server. - The server writes a secret, the nonce, to a file and an incoming client - connection is only accepted if the client sends the nonce right after - the connect. The nonce mechanism requires no setup and is orthogonal to - the higher-level authentication mechanisms described in the - Authentication section. - </p><p> - On start, the server generates a random 16 byte nonce and writes it - to a file in the user's temporary directory. The nonce file location - is published as part of the server's D-Bus address using the - "noncefile" key-value pair. - - After an accept, the server reads 16 bytes from the socket. If the - read bytes do not match the nonce stored in the nonce file, the - server MUST immediately drop the connection. - If the nonce match the received byte sequence, the client is accepted - and the transport behaves like an unsecured tcp transport. - </p><p> - After a successful connect to the server socket, the client MUST read - the nonce from the file published by the server via the noncefile= - key-value pair and send it over the socket. After that, the - transport behaves like an unsecured tcp transport. - </p><div class="sect3" title="Server Address Format"><div class="titlepage"><div><div><h4 class="title"><a name="transports-nonce-tcp-sockets-addresses"></a>Server Address Format</h4></div></div></div><p> - Nonce TCP/IP socket addresses uses the "nonce-tcp:" prefix - and support the following key/value pairs: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values</th><th>Description</th></tr></thead><tbody><tr><td>host</td><td>(string)</td><td>dns name or ip address</td></tr><tr><td>port</td><td>(number)</td><td>The tcp port the server will open. A zero value let the server - choose a free port provided from the underlaying operating system. - libdbus is able to retrieve the real used port from the server. - </td></tr><tr><td>family</td><td>(string)</td><td>If set, provide the type of socket family either "ipv4" or "ipv6". If unset, the family is unspecified.</td></tr><tr><td>noncefile</td><td>(path)</td><td>file location containing the secret</td></tr></tbody></table></div></div></div><div class="sect2" title="Executed Subprocesses on Unix"><div class="titlepage"><div><div><h3 class="title"><a name="transports-exec"></a>Executed Subprocesses on Unix</h3></div></div></div><p> - This transport forks off a process and connects its standard - input and standard output with an anonymous Unix domain - socket. This socket is then used for communication by the - transport. This transport may be used to use out-of-process - forwarder programs as basis for the D-Bus protocol. - </p><p> - The forked process will inherit the standard error output and - process group from the parent process. - </p><p> - Executed subprocesses are not available on Windows. - </p><div class="sect3" title="Server Address Format"><div class="titlepage"><div><div><h4 class="title"><a name="transports-exec-addresses"></a>Server Address Format</h4></div></div></div><p> - Executed subprocess addresses are identified by the "unixexec:" prefix - and support the following key/value pairs: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values</th><th>Description</th></tr></thead><tbody><tr><td>path</td><td>(path)</td><td>Path of the binary to execute, either an absolute - path or a binary name that is searched for in the default - search path of the OS. This corresponds to the first - argument of execlp(). This key is mandatory.</td></tr><tr><td>argv0</td><td>(string)</td><td>The program name to use when executing the - binary. If omitted the same value as specified for path= - will be used. This corresponds to the second argument of - execlp().</td></tr><tr><td>argv1, argv2, ...</td><td>(string)</td><td>Arguments to pass to the binary. This corresponds - to the third and later arguments of execlp(). If a - specific argvX is not specified no further argvY for Y > X - are taken into account.</td></tr></tbody></table></div></div></div></div><div class="sect1" title="Meta Transports"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="meta-transports"></a>Meta Transports</h2></div></div></div><p> - Meta transports are a kind of transport with special enhancements or - behavior. Currently available meta transports include: autolaunch - </p><div class="sect2" title="Autolaunch"><div class="titlepage"><div><div><h3 class="title"><a name="meta-transports-autolaunch"></a>Autolaunch</h3></div></div></div><p>The autolaunch transport provides a way for dbus clients to autodetect - a running dbus session bus and to autolaunch a session bus if not present. - </p><div class="sect3" title="Server Address Format"><div class="titlepage"><div><div><h4 class="title"><a name="meta-transports-autolaunch-addresses"></a>Server Address Format</h4></div></div></div><p> - Autolaunch addresses uses the "autolaunch:" prefix and support the - following key/value pairs: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values</th><th>Description</th></tr></thead><tbody><tr><td>scope</td><td>(string)</td><td>scope of autolaunch (Windows only) - <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - "*install-path" - limit session bus to dbus installation path. - The dbus installation path is determined from the location of - the shared dbus library. If the library is located in a 'bin' - subdirectory the installation root is the directory above, - otherwise the directory where the library lives is taken as - installation root. - </p><pre class="programlisting"> - <install-root>/bin/[lib]dbus-1.dll - <install-root>/[lib]dbus-1.dll - </pre><p> - </p></li><li class="listitem"><p> - "*user" - limit session bus to the recent user. - </p></li><li class="listitem"><p> - other values - specify dedicated session bus like "release", - "debug" or other - </p></li></ul></div> - </td></tr></tbody></table></div></div><div class="sect3" title="Windows implementation"><div class="titlepage"><div><div><h4 class="title"><a name="meta-transports-autolaunch-windows-implementation"></a>Windows implementation</h4></div></div></div><p> - On start, the server opens a platform specific transport, creates a mutex - and a shared memory section containing the related session bus address. - This mutex will be inspected by the dbus client library to detect a - running dbus session bus. The access to the mutex and the shared memory - section are protected by global locks. - </p><p> - In the recent implementation the autolaunch transport uses a tcp transport - on localhost with a port choosen from the operating system. This detail may - change in the future. - </p><p> - Disclaimer: The recent implementation is in an early state and may not - work in all cirumstances and/or may have security issues. Because of this - the implementation is not documentated yet. - </p></div></div></div><div class="sect1" title="UUIDs"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="uuids"></a>UUIDs</h2></div></div></div><p> - A working D-Bus implementation uses universally-unique IDs in two places. - First, each server address has a UUID identifying the address, - as described in <a class="xref" href="#addresses" title="Server Addresses">the section called “Server Addresses”</a>. Second, each operating - system kernel instance running a D-Bus client or server has a UUID - identifying that kernel, retrieved by invoking the method - org.freedesktop.DBus.Peer.GetMachineId() (see <a class="xref" href="#standard-interfaces-peer" title="org.freedesktop.DBus.Peer">the section called “<code class="literal">org.freedesktop.DBus.Peer</code>”</a>). - </p><p> - The term "UUID" in this document is intended literally, i.e. an - identifier that is universally unique. It is not intended to refer to - RFC4122, and in fact the D-Bus UUID is not compatible with that RFC. - </p><p> - The UUID must contain 128 bits of data and be hex-encoded. The - hex-encoded string may not contain hyphens or other non-hex-digit - characters, and it must be exactly 32 characters long. To generate a - UUID, the current reference implementation concatenates 96 bits of random - data followed by the 32-bit time in seconds since the UNIX epoch (in big - endian byte order). - </p><p> - It would also be acceptable and probably better to simply generate 128 - bits of random data, as long as the random number generator is of high - quality. The timestamp could conceivably help if the random bits are not - very random. With a quality random number generator, collisions are - extremely unlikely even with only 96 bits, so it's somewhat academic. - </p><p> - Implementations should, however, stick to random data for the first 96 bits - of the UUID. - </p></div><div class="sect1" title="Standard Interfaces"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="standard-interfaces"></a>Standard Interfaces</h2></div></div></div><p> - See <a class="xref" href="#message-protocol-types-notation" title="Notation in this document">the section called “Notation in this document”</a> for details on - the notation used in this section. There are some standard interfaces - that may be useful across various D-Bus applications. - </p><div class="sect2" title="org.freedesktop.DBus.Peer"><div class="titlepage"><div><div><h3 class="title"><a name="standard-interfaces-peer"></a><code class="literal">org.freedesktop.DBus.Peer</code></h3></div></div></div><p> - The <code class="literal">org.freedesktop.DBus.Peer</code> interface - has two methods: - </p><pre class="programlisting"> - org.freedesktop.DBus.Peer.Ping () - org.freedesktop.DBus.Peer.GetMachineId (out STRING machine_uuid) - </pre><p> - </p><p> - On receipt of the <code class="literal">METHOD_CALL</code> message - <code class="literal">org.freedesktop.DBus.Peer.Ping</code>, an application should do - nothing other than reply with a <code class="literal">METHOD_RETURN</code> as - usual. It does not matter which object path a ping is sent to. The - reference implementation handles this method automatically. - </p><p> - On receipt of the <code class="literal">METHOD_CALL</code> message - <code class="literal">org.freedesktop.DBus.Peer.GetMachineId</code>, an application should - reply with a <code class="literal">METHOD_RETURN</code> containing a hex-encoded - UUID representing the identity of the machine the process is running on. - This UUID must be the same for all processes on a single system at least - until that system next reboots. It should be the same across reboots - if possible, but this is not always possible to implement and is not - guaranteed. - It does not matter which object path a GetMachineId is sent to. The - reference implementation handles this method automatically. - </p><p> - The UUID is intended to be per-instance-of-the-operating-system, so may represent - a virtual machine running on a hypervisor, rather than a physical machine. - Basically if two processes see the same UUID, they should also see the same - shared memory, UNIX domain sockets, process IDs, and other features that require - a running OS kernel in common between the processes. - </p><p> - The UUID is often used where other programs might use a hostname. Hostnames - can change without rebooting, however, or just be "localhost" - so the UUID - is more robust. - </p><p> - <a class="xref" href="#uuids" title="UUIDs">the section called “UUIDs”</a> explains the format of the UUID. - </p></div><div class="sect2" title="org.freedesktop.DBus.Introspectable"><div class="titlepage"><div><div><h3 class="title"><a name="standard-interfaces-introspectable"></a><code class="literal">org.freedesktop.DBus.Introspectable</code></h3></div></div></div><p> - This interface has one method: - </p><pre class="programlisting"> - org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data) - </pre><p> - </p><p> - Objects instances may implement - <code class="literal">Introspect</code> which returns an XML description of - the object, including its interfaces (with signals and methods), objects - below it in the object path tree, and its properties. - </p><p> - <a class="xref" href="#introspection-format" title="Introspection Data Format">the section called “Introspection Data Format”</a> describes the format of this XML string. - </p></div><div class="sect2" title="org.freedesktop.DBus.Properties"><div class="titlepage"><div><div><h3 class="title"><a name="standard-interfaces-properties"></a><code class="literal">org.freedesktop.DBus.Properties</code></h3></div></div></div><p> - Many native APIs will have a concept of object <em class="firstterm">properties</em> - or <em class="firstterm">attributes</em>. These can be exposed via the - <code class="literal">org.freedesktop.DBus.Properties</code> interface. - </p><p> - </p><pre class="programlisting"> - org.freedesktop.DBus.Properties.Get (in STRING interface_name, - in STRING property_name, - out VARIANT value); - org.freedesktop.DBus.Properties.Set (in STRING interface_name, - in STRING property_name, - in VARIANT value); - org.freedesktop.DBus.Properties.GetAll (in STRING interface_name, - out DICT<STRING,VARIANT> props); - </pre><p> - </p><p> - It is conventional to give D-Bus properties names consisting of - capitalized words without punctuation ("CamelCase"), like - <a class="link" href="#message-protocol-names-member" title="Member names">member names</a>. - For instance, the GObject property - <code class="literal">connection-status</code> or the Qt property - <code class="literal">connectionStatus</code> could be represented on D-Bus - as <code class="literal">ConnectionStatus</code>. - </p><p> - Strictly speaking, D-Bus property names are not required to follow - the same naming restrictions as member names, but D-Bus property - names that would not be valid member names (in particular, - GObject-style dash-separated property names) can cause interoperability - problems and should be avoided. - </p><p> - The available properties and whether they are writable can be determined - by calling <code class="literal">org.freedesktop.DBus.Introspectable.Introspect</code>, - see <a class="xref" href="#standard-interfaces-introspectable" title="org.freedesktop.DBus.Introspectable">the section called “<code class="literal">org.freedesktop.DBus.Introspectable</code>”</a>. - </p><p> - An empty string may be provided for the interface name; in this case, - if there are multiple properties on an object with the same name, - the results are undefined (picking one by according to an arbitrary - deterministic rule, or returning an error, are the reasonable - possibilities). - </p><p> - If one or more properties change on an object, the - <code class="literal">org.freedesktop.DBus.Properties.PropertiesChanged</code> - signal may be emitted (this signal was added in 0.14): - </p><p> - </p><pre class="programlisting"> - org.freedesktop.DBus.Properties.PropertiesChanged (STRING interface_name, - DICT<STRING,VARIANT> changed_properties, - ARRAY<STRING> invalidated_properties); - </pre><p> - </p><p> - where <code class="literal">changed_properties</code> is a dictionary - containing the changed properties with the new values and - <code class="literal">invalidated_properties</code> is an array of - properties that changed but the value is not conveyed. - </p><p> - Whether the <code class="literal">PropertiesChanged</code> signal is - supported can be determined by calling - <code class="literal">org.freedesktop.DBus.Introspectable.Introspect</code>. Note - that the signal may be supported for an object but it may - differ how whether and how it is used on a per-property basis - (for e.g. performance or security reasons). Each property (or - the parent interface) must be annotated with the - <code class="literal">org.freedesktop.DBus.Property.EmitsChangedSignal</code> - annotation to convey this (usually the default value - <code class="literal">true</code> is sufficient meaning that the - annotation does not need to be used). See <a class="xref" href="#introspection-format" title="Introspection Data Format">the section called “Introspection Data Format”</a> for details on this - annotation. - </p></div><div class="sect2" title="org.freedesktop.DBus.ObjectManager"><div class="titlepage"><div><div><h3 class="title"><a name="standard-interfaces-objectmanager"></a><code class="literal">org.freedesktop.DBus.ObjectManager</code></h3></div></div></div><p> - An API can optionally make use of this interface for one or - more sub-trees of objects. The root of each sub-tree implements - this interface so other applications can get all objects, - interfaces and properties in a single method call. It is - appropriate to use this interface if users of the tree of - objects are expected to be interested in all interfaces of all - objects in the tree; a more granular API should be used if - users of the objects are expected to be interested in a small - subset of the objects, a small subset of their interfaces, or - both. - </p><p> - The method that applications can use to get all objects and - properties is <code class="literal">GetManagedObjects</code>: - </p><p> - </p><pre class="programlisting"> - org.freedesktop.DBus.ObjectManager.GetManagedObjects (out DICT<OBJPATH,DICT<STRING,DICT<STRING,VARIANT>>> objpath_interfaces_and_properties); - </pre><p> - </p><p> - The return value of this method is a dict whose keys are - object paths. All returned object paths are children of the - object path implementing this interface, i.e. their object - paths start with the ObjectManager's object path plus '/'. - </p><p> - Each value is a dict whose keys are interfaces names. Each - value in this inner dict is the same dict that would be - returned by the <a class="link" href="#standard-interfaces-properties" title="org.freedesktop.DBus.Properties">org.freedesktop.DBus.Properties.GetAll()</a> - method for that combination of object path and interface. If - an interface has no properties, the empty dict is returned. - </p><p> - Changes are emitted using the following two signals: - </p><p> - </p><pre class="programlisting"> - org.freedesktop.DBus.ObjectManager.InterfacesAdded (OBJPATH object_path, - DICT<STRING,DICT<STRING,VARIANT>> interfaces_and_properties); - org.freedesktop.DBus.ObjectManager.InterfacesRemoved (OBJPATH object_path, - ARRAY<STRING> interfaces); - </pre><p> - </p><p> - The <code class="literal">InterfacesAdded</code> signal is emitted when - either a new object is added or when an existing object gains - one or more interfaces. The - <code class="literal">InterfacesRemoved</code> signal is emitted - whenever an object is removed or it loses one or more - interfaces. The second parameter of the - <code class="literal">InterfacesAdded</code> signal contains a dict with - the interfaces and properties (if any) that have been added to - the given object path. Similarly, the second parameter of the - <code class="literal">InterfacesRemoved</code> signal contains an array - of the interfaces that were removed. Note that changes on - properties on existing interfaces are not reported using this - interface - an application should also monitor the existing <a class="link" href="#standard-interfaces-properties" title="org.freedesktop.DBus.Properties">PropertiesChanged</a> - signal on each object. - </p><p> - Applications SHOULD NOT export objects that are children of an - object (directly or otherwise) implementing this interface but - which are not returned in the reply from the - <code class="literal">GetManagedObjects()</code> method of this - interface on the given object. - </p><p> - The intent of the <code class="literal">ObjectManager</code> interface - is to make it easy to write a robust client - implementation. The trivial client implementation only needs - to make two method calls: - </p><p> - </p><pre class="programlisting"> - org.freedesktop.DBus.AddMatch (bus_proxy, - "type='signal',name='org.example.App',path_namespace='/org/example/App'"); - objects = org.freedesktop.DBus.ObjectManager.GetManagedObjects (app_proxy); - </pre><p> - </p><p> - on the message bus and the remote application's - <code class="literal">ObjectManager</code>, respectively. Whenever a new - remote object is created (or an existing object gains a new - interface), the <code class="literal">InterfacesAdded</code> signal is - emitted, and since this signal contains all properties for the - interfaces, no calls to the - <code class="literal">org.freedesktop.Properties</code> interface on the - remote object are needed. Additionally, since the initial - <code class="literal">AddMatch()</code> rule already includes signal - messages from the newly created child object, no new - <code class="literal">AddMatch()</code> call is needed. - </p><p> - <span class="emphasis"><em> - The <code class="literal">org.freedesktop.DBus.ObjectManager</code> - interface was added in version 0.17 of the D-Bus - specification. - </em></span> - </p></div></div><div class="sect1" title="Introspection Data Format"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="introspection-format"></a>Introspection Data Format</h2></div></div></div><p> - As described in <a class="xref" href="#standard-interfaces-introspectable" title="org.freedesktop.DBus.Introspectable">the section called “<code class="literal">org.freedesktop.DBus.Introspectable</code>”</a>, - objects may be introspected at runtime, returning an XML string - that describes the object. The same XML format may be used in - other contexts as well, for example as an "IDL" for generating - static language bindings. - </p><p> - Here is an example of introspection data: - </p><pre class="programlisting"> - <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" - "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> - <node name="/org/freedesktop/sample_object"> - <interface name="org.freedesktop.SampleInterface"> - <method name="Frobate"> - <arg name="foo" type="i" direction="in"/> - <arg name="bar" type="s" direction="out"/> - <arg name="baz" type="a{us}" direction="out"/> - <annotation name="org.freedesktop.DBus.Deprecated" value="true"/> - </method> - <method name="Bazify"> - <arg name="bar" type="(iiu)" direction="in"/> - <arg name="bar" type="v" direction="out"/> - </method> - <method name="Mogrify"> - <arg name="bar" type="(iiav)" direction="in"/> - </method> - <signal name="Changed"> - <arg name="new_value" type="b"/> - </signal> - <property name="Bar" type="y" access="readwrite"/> - </interface> - <node name="child_of_sample_object"/> - <node name="another_child_of_sample_object"/> - </node> - </pre><p> - </p><p> - A more formal DTD and spec needs writing, but here are some quick notes. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Only the root <node> element can omit the node name, as it's - known to be the object that was introspected. If the root - <node> does have a name attribute, it must be an absolute - object path. If child <node> have object paths, they must be - relative. - </p></li><li class="listitem"><p> - If a child <node> has any sub-elements, then they - must represent a complete introspection of the child. - If a child <node> is empty, then it may or may - not have sub-elements; the child must be introspected - in order to find out. The intent is that if an object - knows that its children are "fast" to introspect - it can go ahead and return their information, but - otherwise it can omit it. - </p></li><li class="listitem"><p> - The direction element on <arg> may be omitted, - in which case it defaults to "in" for method calls - and "out" for signals. Signals only allow "out" - so while direction may be specified, it's pointless. - </p></li><li class="listitem"><p> - The possible directions are "in" and "out", - unlike CORBA there is no "inout" - </p></li><li class="listitem"><p> - The possible property access flags are - "readwrite", "read", and "write" - </p></li><li class="listitem"><p> - Multiple interfaces can of course be listed for - one <node>. - </p></li><li class="listitem"><p> - The "name" attribute on arguments is optional. - </p></li></ul></div><p> - </p><p> - Method, interface, property, and signal elements may have - "annotations", which are generic key/value pairs of metadata. - They are similar conceptually to Java's annotations and C# attributes. - Well-known annotations: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Name</th><th>Values (separated by ,)</th><th>Description</th></tr></thead><tbody><tr><td>org.freedesktop.DBus.Deprecated</td><td>true,false</td><td>Whether or not the entity is deprecated; defaults to false</td></tr><tr><td>org.freedesktop.DBus.GLib.CSymbol</td><td>(string)</td><td>The C symbol; may be used for methods and interfaces</td></tr><tr><td>org.freedesktop.DBus.Method.NoReply</td><td>true,false</td><td>If set, don't expect a reply to the method call; defaults to false.</td></tr><tr><td>org.freedesktop.DBus.Property.EmitsChangedSignal</td><td>true,invalidates,false</td><td> - <p> - If set to <code class="literal">false</code>, the - <code class="literal">org.freedesktop.DBus.Properties.PropertiesChanged</code> - signal, see <a class="xref" href="#standard-interfaces-properties" title="org.freedesktop.DBus.Properties">the section called “<code class="literal">org.freedesktop.DBus.Properties</code>”</a> is not - guaranteed to be emitted if the property changes. - </p> - <p> - If set to <code class="literal">invalidates</code> the signal - is emitted but the value is not included in the - signal. - </p> - <p> - If set to <code class="literal">true</code> the signal is - emitted with the value included. - </p> - <p> - The value for the annotation defaults to - <code class="literal">true</code> if the enclosing interface - element does not specify the annotation. Otherwise it - defaults to the value specified in the enclosing - interface element. - </p> - </td></tr></tbody></table></div></div><div class="sect1" title="Message Bus Specification"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="message-bus"></a>Message Bus Specification</h2></div></div></div><div class="sect2" title="Message Bus Overview"><div class="titlepage"><div><div><h3 class="title"><a name="message-bus-overview"></a>Message Bus Overview</h3></div></div></div><p> - The message bus accepts connections from one or more applications. - Once connected, applications can exchange messages with other - applications that are also connected to the bus. - </p><p> - In order to route messages among connections, the message bus keeps a - mapping from names to connections. Each connection has one - unique-for-the-lifetime-of-the-bus name automatically assigned. - Applications may request additional names for a connection. Additional - names are usually "well-known names" such as - "org.freedesktop.TextEditor". When a name is bound to a connection, - that connection is said to <em class="firstterm">own</em> the name. - </p><p> - The bus itself owns a special name, <code class="literal">org.freedesktop.DBus</code>. - This name routes messages to the bus, allowing applications to make - administrative requests. For example, applications can ask the bus - to assign a name to a connection. - </p><p> - Each name may have <em class="firstterm">queued owners</em>. When an - application requests a name for a connection and the name is already in - use, the bus will optionally add the connection to a queue waiting for - the name. If the current owner of the name disconnects or releases - the name, the next connection in the queue will become the new owner. - </p><p> - This feature causes the right thing to happen if you start two text - editors for example; the first one may request "org.freedesktop.TextEditor", - and the second will be queued as a possible owner of that name. When - the first exits, the second will take over. - </p><p> - Applications may send <em class="firstterm">unicast messages</em> to - a specific recipient or to the message bus itself, or - <em class="firstterm">broadcast messages</em> to all interested recipients. - See <a class="xref" href="#message-bus-routing" title="Message Bus Message Routing">the section called “Message Bus Message Routing”</a> for details. - </p></div><div class="sect2" title="Message Bus Names"><div class="titlepage"><div><div><h3 class="title"><a name="message-bus-names"></a>Message Bus Names</h3></div></div></div><p> - Each connection has at least one name, assigned at connection time and - returned in response to the - <code class="literal">org.freedesktop.DBus.Hello</code> method call. This - automatically-assigned name is called the connection's <em class="firstterm">unique - name</em>. Unique names are never reused for two different - connections to the same bus. - </p><p> - Ownership of a unique name is a prerequisite for interaction with - the message bus. It logically follows that the unique name is always - the first name that an application comes to own, and the last - one that it loses ownership of. - </p><p> - Unique connection names must begin with the character ':' (ASCII colon - character); bus names that are not unique names must not begin - with this character. (The bus must reject any attempt by an application - to manually request a name beginning with ':'.) This restriction - categorically prevents "spoofing"; messages sent to a unique name - will always go to the expected connection. - </p><p> - When a connection is closed, all the names that it owns are deleted (or - transferred to the next connection in the queue if any). - </p><p> - A connection can request additional names to be associated with it using - the <code class="literal">org.freedesktop.DBus.RequestName</code> message. <a class="xref" href="#message-protocol-names-bus" title="Bus names">the section called “Bus names”</a> describes the format of a valid - name. These names can be released again using the - <code class="literal">org.freedesktop.DBus.ReleaseName</code> message. - </p><div class="sect3" title="org.freedesktop.DBus.RequestName"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-request-name"></a><code class="literal">org.freedesktop.DBus.RequestName</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - UINT32 RequestName (in STRING name, in UINT32 flags) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name to request</td></tr><tr><td>1</td><td>UINT32</td><td>Flags</td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>UINT32</td><td>Return value</td></tr></tbody></table></div><p> - </p><p> - This method call should be sent to - <code class="literal">org.freedesktop.DBus</code> and asks the message bus to - assign the given name to the method caller. Each name maintains a - queue of possible owners, where the head of the queue is the primary - or current owner of the name. Each potential owner in the queue - maintains the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and - DBUS_NAME_FLAG_DO_NOT_QUEUE settings from its latest RequestName - call. When RequestName is invoked the following occurs: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - If the method caller is currently the primary owner of the name, - the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and DBUS_NAME_FLAG_DO_NOT_QUEUE - values are updated with the values from the new RequestName call, - and nothing further happens. - </p></li><li class="listitem"><p> - If the current primary owner (head of the queue) has - DBUS_NAME_FLAG_ALLOW_REPLACEMENT set, and the RequestName - invocation has the DBUS_NAME_FLAG_REPLACE_EXISTING flag, then - the caller of RequestName replaces the current primary owner at - the head of the queue and the current primary owner moves to the - second position in the queue. If the caller of RequestName was - in the queue previously its flags are updated with the values from - the new RequestName in addition to moving it to the head of the queue. - </p></li><li class="listitem"><p> - If replacement is not possible, and the method caller is - currently in the queue but not the primary owner, its flags are - updated with the values from the new RequestName call. - </p></li><li class="listitem"><p> - If replacement is not possible, and the method caller is - currently not in the queue, the method caller is appended to the - queue. - </p></li><li class="listitem"><p> - If any connection in the queue has DBUS_NAME_FLAG_DO_NOT_QUEUE - set and is not the primary owner, it is removed from the - queue. This can apply to the previous primary owner (if it - was replaced) or the method caller (if it updated the - DBUS_NAME_FLAG_DO_NOT_QUEUE flag while still stuck in the - queue, or if it was just added to the queue with that flag set). - </p></li></ul></div><p> - </p><p> - Note that DBUS_NAME_FLAG_REPLACE_EXISTING results in "jumping the - queue," even if another application already in the queue had specified - DBUS_NAME_FLAG_REPLACE_EXISTING. This comes up if a primary owner - that does not allow replacement goes away, and the next primary owner - does allow replacement. In this case, queued items that specified - DBUS_NAME_FLAG_REPLACE_EXISTING <span class="emphasis"><em>do not</em></span> - automatically replace the new primary owner. In other words, - DBUS_NAME_FLAG_REPLACE_EXISTING is not saved, it is only used at the - time RequestName is called. This is deliberate to avoid an infinite loop - anytime two applications are both DBUS_NAME_FLAG_ALLOW_REPLACEMENT - and DBUS_NAME_FLAG_REPLACE_EXISTING. - </p><p> - The flags argument contains any of the following values logically ORed - together: - - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional Name</th><th>Value</th><th>Description</th></tr></thead><tbody><tr><td>DBUS_NAME_FLAG_ALLOW_REPLACEMENT</td><td>0x1</td><td> - - If an application A specifies this flag and succeeds in - becoming the owner of the name, and another application B - later calls RequestName with the - DBUS_NAME_FLAG_REPLACE_EXISTING flag, then application A - will lose ownership and receive a - <code class="literal">org.freedesktop.DBus.NameLost</code> signal, and - application B will become the new owner. If DBUS_NAME_FLAG_ALLOW_REPLACEMENT - is not specified by application A, or DBUS_NAME_FLAG_REPLACE_EXISTING - is not specified by application B, then application B will not replace - application A as the owner. - - </td></tr><tr><td>DBUS_NAME_FLAG_REPLACE_EXISTING</td><td>0x2</td><td> - - Try to replace the current owner if there is one. If this - flag is not set the application will only become the owner of - the name if there is no current owner. If this flag is set, - the application will replace the current owner if - the current owner specified DBUS_NAME_FLAG_ALLOW_REPLACEMENT. - - </td></tr><tr><td>DBUS_NAME_FLAG_DO_NOT_QUEUE</td><td>0x4</td><td> - - Without this flag, if an application requests a name that is - already owned, the application will be placed in a queue to - own the name when the current owner gives it up. If this - flag is given, the application will not be placed in the - queue, the request for the name will simply fail. This flag - also affects behavior when an application is replaced as - name owner; by default the application moves back into the - waiting queue, unless this flag was provided when the application - became the name owner. - - </td></tr></tbody></table></div><p> - - The return code can be one of the following values: - - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional Name</th><th>Value</th><th>Description</th></tr></thead><tbody><tr><td>DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER</td><td>1</td><td>The caller is now the primary owner of - the name, replacing any previous owner. Either the name had no - owner before, or the caller specified - DBUS_NAME_FLAG_REPLACE_EXISTING and the current owner specified - DBUS_NAME_FLAG_ALLOW_REPLACEMENT.</td></tr><tr><td>DBUS_REQUEST_NAME_REPLY_IN_QUEUE</td><td>2</td><td>The name already had an owner, - DBUS_NAME_FLAG_DO_NOT_QUEUE was not specified, and either - the current owner did not specify - DBUS_NAME_FLAG_ALLOW_REPLACEMENT or the requesting - application did not specify DBUS_NAME_FLAG_REPLACE_EXISTING. - </td></tr><tr><td>DBUS_REQUEST_NAME_REPLY_EXISTS</td><td>3</td><td>The name already has an owner, - DBUS_NAME_FLAG_DO_NOT_QUEUE was specified, and either - DBUS_NAME_FLAG_ALLOW_REPLACEMENT was not specified by the - current owner, or DBUS_NAME_FLAG_REPLACE_EXISTING was not - specified by the requesting application.</td></tr><tr><td>DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER</td><td>4</td><td>The application trying to request ownership of a name is already the owner of it.</td></tr></tbody></table></div><p> - </p></div><div class="sect3" title="org.freedesktop.DBus.ReleaseName"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-release-name"></a><code class="literal">org.freedesktop.DBus.ReleaseName</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - UINT32 ReleaseName (in STRING name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name to release</td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>UINT32</td><td>Return value</td></tr></tbody></table></div><p> - </p><p> - This method call should be sent to - <code class="literal">org.freedesktop.DBus</code> and asks the message bus to - release the method caller's claim to the given name. If the caller is - the primary owner, a new primary owner will be selected from the - queue if any other owners are waiting. If the caller is waiting in - the queue for the name, the caller will removed from the queue and - will not be made an owner of the name if it later becomes available. - If there are no other owners in the queue for the name, it will be - removed from the bus entirely. - - The return code can be one of the following values: - - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Conventional Name</th><th>Value</th><th>Description</th></tr></thead><tbody><tr><td>DBUS_RELEASE_NAME_REPLY_RELEASED</td><td>1</td><td>The caller has released his claim on - the given name. Either the caller was the primary owner of - the name, and the name is now unused or taken by somebody - waiting in the queue for the name, or the caller was waiting - in the queue for the name and has now been removed from the - queue.</td></tr><tr><td>DBUS_RELEASE_NAME_REPLY_NON_EXISTENT</td><td>2</td><td>The given name does not exist on this bus.</td></tr><tr><td>DBUS_RELEASE_NAME_REPLY_NOT_OWNER</td><td>3</td><td>The caller was not the primary owner of this name, - and was also not waiting in the queue to own this name.</td></tr></tbody></table></div><p> - </p></div><div class="sect3" title="org.freedesktop.DBus.ListQueuedOwners"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-list-queued-owners"></a><code class="literal">org.freedesktop.DBus.ListQueuedOwners</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - ARRAY of STRING ListQueuedOwners (in STRING name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>The well-known bus name to query, such as - <code class="literal">com.example.cappuccino</code></td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>ARRAY of STRING</td><td>The unique bus names of connections currently queued - for the name</td></tr></tbody></table></div><p> - </p><p> - This method call should be sent to - <code class="literal">org.freedesktop.DBus</code> and lists the connections - currently queued for a bus name (see - <a class="xref" href="#term-queued-owner" title="Queued Name Owner">Queued Name Owner</a>). - </p></div></div><div class="sect2" title="Message Bus Message Routing"><div class="titlepage"><div><div><h3 class="title"><a name="message-bus-routing"></a>Message Bus Message Routing</h3></div></div></div><p> - Messages may have a <code class="literal">DESTINATION</code> field (see <a class="xref" href="#message-protocol-header-fields" title="Header Fields">the section called “Header Fields”</a>), resulting in a - <em class="firstterm">unicast message</em>. If the - <code class="literal">DESTINATION</code> field is present, it specifies a message - recipient by name. Method calls and replies normally specify this field. - The message bus must send messages (of any type) with the - <code class="literal">DESTINATION</code> field set to the specified recipient, - regardless of whether the recipient has set up a match rule matching - the message. - </p><p> - When the message bus receives a signal, if the - <code class="literal">DESTINATION</code> field is absent, it is considered to - be a <em class="firstterm">broadcast signal</em>, and is sent to all - applications with <em class="firstterm">message matching rules</em> that - match the message. Most signal messages are broadcasts. - </p><p> - Unicast signal messages (those with a <code class="literal">DESTINATION</code> - field) are not commonly used, but they are treated like any unicast - message: they are delivered to the specified receipient, - regardless of its match rules. One use for unicast signals is to - avoid a race condition in which a signal is emitted before the intended - recipient can call <a class="xref" href="#bus-messages-add-match" title="org.freedesktop.DBus.AddMatch">the section called “<code class="literal">org.freedesktop.DBus.AddMatch</code>”</a> to - receive that signal: if the signal is sent directly to that recipient - using a unicast message, it does not need to add a match rule at all, - and there is no race condition. Another use for unicast signals, - on message buses whose security policy prevents eavesdropping, is to - send sensitive information which should only be visible to one - recipient. - </p><p> - When the message bus receives a method call, if the - <code class="literal">DESTINATION</code> field is absent, the call is taken to be - a standard one-to-one message and interpreted by the message bus - itself. For example, sending an - <code class="literal">org.freedesktop.DBus.Peer.Ping</code> message with no - <code class="literal">DESTINATION</code> will cause the message bus itself to - reply to the ping immediately; the message bus will not make this - message visible to other applications. - </p><p> - Continuing the <code class="literal">org.freedesktop.DBus.Peer.Ping</code> example, if - the ping message were sent with a <code class="literal">DESTINATION</code> name of - <code class="literal">com.yoyodyne.Screensaver</code>, then the ping would be - forwarded, and the Yoyodyne Corporation screensaver application would be - expected to reply to the ping. - </p><p> - Message bus implementations may impose a security policy which - prevents certain messages from being sent or received. - When a message cannot be sent or received due to a security - policy, the message bus should send an error reply, unless the - original message had the <code class="literal">NO_REPLY</code> flag. - </p><div class="sect3" title="Eavesdropping"><div class="titlepage"><div><div><h4 class="title"><a name="message-bus-routing-eavesdropping"></a>Eavesdropping</h4></div></div></div><p> - Receiving a unicast message whose <code class="literal">DESTINATION</code> - indicates a different recipient is called - <em class="firstterm">eavesdropping</em>. On a message bus which acts as - a security boundary (like the standard system bus), the security - policy should usually prevent eavesdropping, since unicast messages - are normally kept private and may contain security-sensitive - information. - </p><p> - Eavesdropping is mainly useful for debugging tools, such as - the <code class="literal">dbus-monitor</code> tool in the reference - implementation of D-Bus. Tools which eavesdrop on the message bus - should be careful to avoid sending a reply or error in response to - messages intended for a different client. - </p><p> - Clients may attempt to eavesdrop by adding match rules - (see <a class="xref" href="#message-bus-routing-match-rules" title="Match Rules">the section called “Match Rules”</a>) containing - the <code class="literal">eavesdrop='true'</code> match. If the message bus' - security policy does not allow eavesdropping, the match rule can - still be added, but will not have any practical effect. For - compatibility with older message bus implementations, if adding such - a match rule results in an error reply, the client may fall back to - adding the same rule with the <code class="literal">eavesdrop</code> match - omitted. - </p></div><div class="sect3" title="Match Rules"><div class="titlepage"><div><div><h4 class="title"><a name="message-bus-routing-match-rules"></a>Match Rules</h4></div></div></div><p> - An important part of the message bus routing protocol is match - rules. Match rules describe the messages that should be sent to a - client, based on the contents of the message. Broadcast signals - are only sent to clients which have a suitable match rule: this - avoids waking up client processes to deal with signals that are - not relevant to that client. - </p><p> - Messages that list a client as their <code class="literal">DESTINATION</code> - do not need to match the client's match rules, and are sent to that - client regardless. As a result, match rules are mainly used to - receive a subset of broadcast signals. - </p><p> - Match rules can also be used for eavesdropping - (see <a class="xref" href="#message-bus-routing-eavesdropping" title="Eavesdropping">the section called “Eavesdropping”</a>), - if the security policy of the message bus allows it. - </p><p> - Match rules are added using the AddMatch bus method - (see <a class="xref" href="#bus-messages-add-match" title="org.freedesktop.DBus.AddMatch">the section called “<code class="literal">org.freedesktop.DBus.AddMatch</code>”</a>). Rules are - specified as a string of comma separated key/value pairs. - Excluding a key from the rule indicates a wildcard match. - For instance excluding the the member from a match rule but - adding a sender would let all messages from that sender through. - An example of a complete rule would be - "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='Foo',path='/bar/foo',destination=':452345.34',arg2='bar'" - </p><p> - The following table describes the keys that can be used to create - a match rule: - The following table summarizes the D-Bus types. - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Key</th><th>Possible Values</th><th>Description</th></tr></thead><tbody><tr><td><code class="literal">type</code></td><td>'signal', 'method_call', 'method_return', 'error'</td><td>Match on the message type. An example of a type match is type='signal'</td></tr><tr><td><code class="literal">sender</code></td><td>A bus or unique name (see <a class="xref" href="#term-bus-name" title="Bus Name">Bus Name</a> - and <a class="xref" href="#term-unique-name" title="Unique Connection Name">Unique Connection Name</a> respectively) - </td><td>Match messages sent by a particular sender. An example of a sender match - is sender='org.freedesktop.Hal'</td></tr><tr><td><code class="literal">interface</code></td><td>An interface name (see <a class="xref" href="#message-protocol-names-interface" title="Interface names">the section called “Interface names”</a>)</td><td>Match messages sent over or to a particular interface. An example of an - interface match is interface='org.freedesktop.Hal.Manager'. - If a message omits the interface header, it must not match any rule - that specifies this key.</td></tr><tr><td><code class="literal">member</code></td><td>Any valid method or signal name</td><td>Matches messages which have the give method or signal name. An example of - a member match is member='NameOwnerChanged'</td></tr><tr><td><code class="literal">path</code></td><td>An object path (see <a class="xref" href="#message-protocol-marshaling-object-path" title="Valid Object Paths">the section called “Valid Object Paths”</a>)</td><td>Matches messages which are sent from or to the given object. An example of a - path match is path='/org/freedesktop/Hal/Manager'</td></tr><tr><td><code class="literal">path_namespace</code></td><td>An object path</td><td> - <p> - Matches messages which are sent from or to an - object for which the object path is either the - given value, or that value followed by one or - more path components. - </p> - - <p> - For example, - <code class="literal">path_namespace='/com/example/foo'</code> - would match signals sent by - <code class="literal">/com/example/foo</code> - or by - <code class="literal">/com/example/foo/bar</code>, - but not by - <code class="literal">/com/example/foobar</code>. - </p> - - <p> - Using both <code class="literal">path</code> and - <code class="literal">path_namespace</code> in the same match - rule is not allowed. - </p> - - <p> - <span class="emphasis"><em> - This match key was added in version 0.16 of the - D-Bus specification and implemented by the bus - daemon in dbus 1.5.0 and later. - </em></span> - </p> - </td></tr><tr><td><code class="literal">destination</code></td><td>A unique name (see <a class="xref" href="#term-unique-name" title="Unique Connection Name">Unique Connection Name</a>)</td><td>Matches messages which are being sent to the given unique name. An - example of a destination match is destination=':1.0'</td></tr><tr><td><code class="literal">arg[0, 1, 2, 3, ...]</code></td><td>Any string</td><td>Arg matches are special and are used for further restricting the - match based on the arguments in the body of a message. Only arguments of type - STRING can be matched in this way. An example of an argument match - would be arg3='Foo'. Only argument indexes from 0 to 63 should be - accepted.</td></tr><tr><td><code class="literal">arg[0, 1, 2, 3, ...]path</code></td><td>Any string</td><td> - <p>Argument path matches provide a specialised form of wildcard matching for - path-like namespaces. They can match arguments whose type is either STRING or - OBJECT_PATH. As with normal argument matches, - if the argument is exactly equal to the string given in the match - rule then the rule is satisfied. Additionally, there is also a - match when either the string given in the match rule or the - appropriate message argument ends with '/' and is a prefix of the - other. An example argument path match is arg0path='/aa/bb/'. This - would match messages with first arguments of '/', '/aa/', - '/aa/bb/', '/aa/bb/cc/' and '/aa/bb/cc'. It would not match - messages with first arguments of '/aa/b', '/aa' or even '/aa/bb'.</p> - - <p>This is intended for monitoring “directories” in file system-like - hierarchies, as used in the <em class="citetitle">dconf</em> configuration - system. An application interested in all nodes in a particular hierarchy would - monitor <code class="literal">arg0path='/ca/example/foo/'</code>. Then the service could - emit a signal with zeroth argument <code class="literal">"/ca/example/foo/bar"</code> to - represent a modification to the “bar” property, or a signal with zeroth - argument <code class="literal">"/ca/example/"</code> to represent atomic modification of - many properties within that directory, and the interested application would be - notified in both cases.</p> - <p> - <span class="emphasis"><em> - This match key was added in version 0.12 of the - D-Bus specification, implemented for STRING - arguments by the bus daemon in dbus 1.2.0 and later, - and implemented for OBJECT_PATH arguments in dbus 1.5.0 - and later. - </em></span> - </p> - </td></tr><tr><td><code class="literal">arg0namespace</code></td><td>Like a bus name, except that the string is not - required to contain a '.' (period)</td><td> - <p>Match messages whose first argument is of type STRING, and is a bus name - or interface name within the specified namespace. This is primarily intended - for watching name owner changes for a group of related bus names, rather than - for a single name or all name changes.</p> - - <p>Because every valid interface name is also a valid - bus name, this can also be used for messages whose - first argument is an interface name.</p> - - <p>For example, the match rule - <code class="literal">member='NameOwnerChanged',arg0namespace='com.example.backend'</code> - matches name owner changes for bus names such as - <code class="literal">com.example.backend.foo</code>, - <code class="literal">com.example.backend.foo.bar</code>, and - <code class="literal">com.example.backend</code> itself.</p> - - <p>See also <a class="xref" href="#bus-messages-name-owner-changed" title="org.freedesktop.DBus.NameOwnerChanged">the section called “<code class="literal">org.freedesktop.DBus.NameOwnerChanged</code>”</a>.</p> - <p> - <span class="emphasis"><em> - This match key was added in version 0.16 of the - D-Bus specification and implemented by the bus - daemon in dbus 1.5.0 and later. - </em></span> - </p> - </td></tr><tr><td><code class="literal">eavesdrop</code></td><td><code class="literal">'true'</code>, <code class="literal">'false'</code></td><td>Since D-Bus 1.5.6, match rules do not - match messages which have a <code class="literal">DESTINATION</code> - field unless the match rule specifically - requests this - (see <a class="xref" href="#message-bus-routing-eavesdropping" title="Eavesdropping">the section called “Eavesdropping”</a>) - by specifying <code class="literal">eavesdrop='true'</code> - in the match rule. <code class="literal">eavesdrop='false'</code> - restores the default behaviour. Messages are - delivered to their <code class="literal">DESTINATION</code> - regardless of match rules, so this match does not - affect normal delivery of unicast messages. - If the message bus has a security policy which forbids - eavesdropping, this match may still be used without error, - but will not have any practical effect. - In older versions of D-Bus, this match was not allowed - in match rules, and all match rules behaved as if - <code class="literal">eavesdrop='true'</code> had been used. - </td></tr></tbody></table></div><p> - </p></div></div><div class="sect2" title="Message Bus Starting Services"><div class="titlepage"><div><div><h3 class="title"><a name="message-bus-starting-services"></a>Message Bus Starting Services</h3></div></div></div><p> - The message bus can start applications on behalf of other applications. - In CORBA terms, this would be called <em class="firstterm">activation</em>. - An application that can be started in this way is called a - <em class="firstterm">service</em>. - </p><p> - With D-Bus, starting a service is normally done by name. That is, - applications ask the message bus to start some program that will own a - well-known name, such as <code class="literal">org.freedesktop.TextEditor</code>. - This implies a contract documented along with the name - <code class="literal">org.freedesktop.TextEditor</code> for which objects - the owner of that name will provide, and what interfaces those - objects will have. - </p><p> - To find an executable corresponding to a particular name, the bus daemon - looks for <em class="firstterm">service description files</em>. Service - description files define a mapping from names to executables. Different - kinds of message bus will look for these files in different places, see - <a class="xref" href="#message-bus-types" title="Well-known Message Bus Instances">the section called “Well-known Message Bus Instances”</a>. - </p><p> - Service description files have the ".service" file - extension. The message bus will only load service description files - ending with .service; all other files will be ignored. The file format - is similar to that of <a class="ulink" href="http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html" target="_top">desktop - entries</a>. All service description files must be in UTF-8 - encoding. To ensure that there will be no name collisions, service files - must be namespaced using the same mechanism as messages and service - names. - </p><p> - [FIXME the file format should be much better specified than "similar to - .desktop entries" esp. since desktop entries are already - badly-specified. ;-)] - These sections from the specification apply to service files as well: - - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>General syntax</p></li><li class="listitem"><p>Comment format</p></li></ul></div><p> - - </p><div class="figure"><a name="idp5671872"></a><p class="title"><b>Figure 9. Example service description file</b></p><div class="figure-contents"><pre class="programlisting"> - # Sample service description file - [D-BUS Service] - Names=org.freedesktop.ConfigurationDatabase;org.gnome.GConf; - Exec=/usr/libexec/gconfd-2 - </pre></div></div><p><br class="figure-break"> - </p><p> - When an application asks to start a service by name, the bus daemon tries to - find a service that will own that name. It then tries to spawn the - executable associated with it. If this fails, it will report an - error. [FIXME what happens if two .service files offer the same service; - what kind of error is reported, should we have a way for the client to - choose one?] - </p><p> - The executable launched will have the environment variable - <code class="literal">DBUS_STARTER_ADDRESS</code> set to the address of the - message bus so it can connect and request the appropriate names. - </p><p> - The executable being launched may want to know whether the message bus - starting it is one of the well-known message buses (see <a class="xref" href="#message-bus-types" title="Well-known Message Bus Instances">the section called “Well-known Message Bus Instances”</a>). To facilitate this, the bus must also set - the <code class="literal">DBUS_STARTER_BUS_TYPE</code> environment variable if it is one - of the well-known buses. The currently-defined values for this variable - are <code class="literal">system</code> for the systemwide message bus, - and <code class="literal">session</code> for the per-login-session message - bus. The new executable must still connect to the address given - in <code class="literal">DBUS_STARTER_ADDRESS</code>, but may assume that the - resulting connection is to the well-known bus. - </p><p> - [FIXME there should be a timeout somewhere, either specified - in the .service file, by the client, or just a global value - and if the client being activated fails to connect within that - timeout, an error should be sent back.] - </p><div class="sect3" title="Message Bus Service Scope"><div class="titlepage"><div><div><h4 class="title"><a name="message-bus-starting-services-scope"></a>Message Bus Service Scope</h4></div></div></div><p> - The "scope" of a service is its "per-", such as per-session, - per-machine, per-home-directory, or per-display. The reference - implementation doesn't yet support starting services in a different - scope from the message bus itself. So e.g. if you start a service - on the session bus its scope is per-session. - </p><p> - We could add an optional scope to a bus name. For example, for - per-(display,session pair), we could have a unique ID for each display - generated automatically at login and set on screen 0 by executing a - special "set display ID" binary. The ID would be stored in a - <code class="literal">_DBUS_DISPLAY_ID</code> property and would be a string of - random bytes. This ID would then be used to scope names. - Starting/locating a service could be done by ID-name pair rather than - only by name. - </p><p> - Contrast this with a per-display scope. To achieve that, we would - want a single bus spanning all sessions using a given display. - So we might set a <code class="literal">_DBUS_DISPLAY_BUS_ADDRESS</code> - property on screen 0 of the display, pointing to this bus. - </p></div></div><div class="sect2" title="Well-known Message Bus Instances"><div class="titlepage"><div><div><h3 class="title"><a name="message-bus-types"></a>Well-known Message Bus Instances</h3></div></div></div><p> - Two standard message bus instances are defined here, along with how - to locate them and where their service files live. - </p><div class="sect3" title="Login session message bus"><div class="titlepage"><div><div><h4 class="title"><a name="message-bus-types-login"></a>Login session message bus</h4></div></div></div><p> - Each time a user logs in, a <em class="firstterm">login session message - bus</em> may be started. All applications in the user's login - session may interact with one another using this message bus. - </p><p> - The address of the login session message bus is given - in the <code class="literal">DBUS_SESSION_BUS_ADDRESS</code> environment - variable. If that variable is not set, applications may - also try to read the address from the X Window System root - window property <code class="literal">_DBUS_SESSION_BUS_ADDRESS</code>. - The root window property must have type <code class="literal">STRING</code>. - The environment variable should have precedence over the - root window property. - </p><p>The address of the login session message bus is given in the - <code class="literal">DBUS_SESSION_BUS_ADDRESS</code> environment variable. If - DBUS_SESSION_BUS_ADDRESS is not set, or if it's set to the string - "autolaunch:", the system should use platform-specific methods of - locating a running D-Bus session server, or starting one if a running - instance cannot be found. Note that this mechanism is not recommended - for attempting to determine if a daemon is running. It is inherently - racy to attempt to make this determination, since the bus daemon may - be started just before or just after the determination is made. - Therefore, it is recommended that applications do not try to make this - determination for their functionality purposes, and instead they - should attempt to start the server.</p><div class="sect4" title="X Windowing System"><div class="titlepage"><div><div><h5 class="title"><a name="message-bus-types-login-x-windows"></a>X Windowing System</h5></div></div></div><p> - For the X Windowing System, the application must locate the - window owner of the selection represented by the atom formed by - concatenating: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>the literal string "_DBUS_SESSION_BUS_SELECTION_"</p></li><li class="listitem"><p>the current user's username</p></li><li class="listitem"><p>the literal character '_' (underscore)</p></li><li class="listitem"><p>the machine's ID</p></li></ul></div><p> - </p><p> - The following properties are defined for the window that owns - this X selection: - </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><tbody><tr><td> - <p>Atom</p> - </td><td> - <p>meaning</p> - </td></tr><tr><td> - <p>_DBUS_SESSION_BUS_ADDRESS</p> - </td><td> - <p>the actual address of the server socket</p> - </td></tr><tr><td> - <p>_DBUS_SESSION_BUS_PID</p> - </td><td> - <p>the PID of the server process</p> - </td></tr></tbody></table></div><p> - </p><p> - At least the _DBUS_SESSION_BUS_ADDRESS property MUST be - present in this window. - </p><p> - If the X selection cannot be located or if reading the - properties from the window fails, the implementation MUST conclude - that there is no D-Bus server running and proceed to start a new - server. (See below on concurrency issues) - </p><p> - Failure to connect to the D-Bus server address thus obtained - MUST be treated as a fatal connection error and should be reported - to the application. - </p><p> - As an alternative, an implementation MAY find the information - in the following file located in the current user's home directory, - in subdirectory .dbus/session-bus/: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>the machine's ID</p></li><li class="listitem"><p>the literal character '-' (dash)</p></li><li class="listitem"><p>the X display without the screen number, with the - following prefixes removed, if present: ":", "localhost:" - ."localhost.localdomain:". That is, a display of - "localhost:10.0" produces just the number "10"</p></li></ul></div><p> - </p><p> - The contents of this file NAME=value assignment pairs and - lines starting with # are comments (no comments are allowed - otherwise). The following variable names are defined: - </p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><tbody><tr><td> - <p>Variable</p> - </td><td> - <p>meaning</p> - </td></tr><tr><td> - <p>DBUS_SESSION_BUS_ADDRESS</p> - </td><td> - <p>the actual address of the server socket</p> - </td></tr><tr><td> - <p>DBUS_SESSION_BUS_PID</p> - </td><td> - <p>the PID of the server process</p> - </td></tr><tr><td> - <p>DBUS_SESSION_BUS_WINDOWID</p> - </td><td> - <p>the window ID</p> - </td></tr></tbody></table></div><p> - </p><p> - At least the DBUS_SESSION_BUS_ADDRESS variable MUST be present - in this file. - </p><p> - Failure to open this file MUST be interpreted as absence of a - running server. Therefore, the implementation MUST proceed to - attempting to launch a new bus server if the file cannot be - opened. - </p><p> - However, success in opening this file MUST NOT lead to the - conclusion that the server is running. Thus, a failure to connect to - the bus address obtained by the alternative method MUST NOT be - considered a fatal error. If the connection cannot be established, - the implementation MUST proceed to check the X selection settings or - to start the server on its own. - </p><p> - If the implementation concludes that the D-Bus server is not - running it MUST attempt to start a new server and it MUST also - ensure that the daemon started as an effect of the "autolaunch" - mechanism provides the lookup mechanisms described above, so - subsequent calls can locate the newly started server. The - implementation MUST also ensure that if two or more concurrent - initiations happen, only one server remains running and all other - initiations are able to obtain the address of this server and - connect to it. In other words, the implementation MUST ensure that - the X selection is not present when it attempts to set it, without - allowing another process to set the selection between the - verification and the setting (e.g., by using XGrabServer / - XungrabServer). - </p></div><div class="sect4"><div class="titlepage"><div><div><h5 class="title"><a name="idp5724640"></a></h5></div></div></div><p> - On Unix systems, the session bus should search for .service files - in <code class="literal">$XDG_DATA_DIRS/dbus-1/services</code> as defined - by the - <a class="ulink" href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html" target="_top">XDG Base Directory Specification</a>. - Implementations may also search additional locations, which - should be searched with lower priority than anything in - XDG_DATA_HOME, XDG_DATA_DIRS or their respective defaults; - for example, the reference implementation also - looks in <code class="literal">${datadir}/dbus-1/services</code> as - set at compile time. - </p><p> - As described in the XDG Base Directory Specification, software - packages should install their session .service files to their - configured <code class="literal">${datadir}/dbus-1/services</code>, - where <code class="literal">${datadir}</code> is as defined by the GNU - coding standards. System administrators or users can arrange - for these service files to be read by setting XDG_DATA_DIRS or by - symlinking them into the default locations. - </p></div></div><div class="sect3" title="System message bus"><div class="titlepage"><div><div><h4 class="title"><a name="message-bus-types-system"></a>System message bus</h4></div></div></div><p> - A computer may have a <em class="firstterm">system message bus</em>, - accessible to all applications on the system. This message bus may be - used to broadcast system events, such as adding new hardware devices, - changes in the printer queue, and so forth. - </p><p> - The address of the system message bus is given - in the <code class="literal">DBUS_SYSTEM_BUS_ADDRESS</code> environment - variable. If that variable is not set, applications should try - to connect to the well-known address - <code class="literal">unix:path=/var/run/dbus/system_bus_socket</code>. - <sup>[<a name="idp5733888" href="#ftn.idp5733888" class="footnote">2</a>]</sup> - </p><p> - On Unix systems, the system bus should default to searching - for .service files in - <code class="literal">/usr/local/share/dbus-1/system-services</code>, - <code class="literal">/usr/share/dbus-1/system-services</code> and - <code class="literal">/lib/dbus-1/system-services</code>, with that order - of precedence. It may also search other implementation-specific - locations, but should not vary these locations based on environment - variables. - <sup>[<a name="idp5738096" href="#ftn.idp5738096" class="footnote">3</a>]</sup> - </p><p> - Software packages should install their system .service - files to their configured - <code class="literal">${datadir}/dbus-1/system-services</code>, - where <code class="literal">${datadir}</code> is as defined by the GNU - coding standards. System administrators can arrange - for these service files to be read by editing the system bus' - configuration file or by symlinking them into the default - locations. - </p></div></div><div class="sect2" title="Message Bus Messages"><div class="titlepage"><div><div><h3 class="title"><a name="message-bus-messages"></a>Message Bus Messages</h3></div></div></div><p> - The special message bus name <code class="literal">org.freedesktop.DBus</code> - responds to a number of additional messages. - </p><div class="sect3" title="org.freedesktop.DBus.Hello"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-hello"></a><code class="literal">org.freedesktop.DBus.Hello</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - STRING Hello () - </pre><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Unique name assigned to the connection</td></tr></tbody></table></div><p> - </p><p> - Before an application is able to send messages to other applications - it must send the <code class="literal">org.freedesktop.DBus.Hello</code> message - to the message bus to obtain a unique name. If an application without - a unique name tries to send a message to another application, or a - message to the message bus itself that isn't the - <code class="literal">org.freedesktop.DBus.Hello</code> message, it will be - disconnected from the bus. - </p><p> - There is no corresponding "disconnect" request; if a client wishes to - disconnect from the bus, it simply closes the socket (or other - communication channel). - </p></div><div class="sect3" title="org.freedesktop.DBus.ListNames"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-list-names"></a><code class="literal">org.freedesktop.DBus.ListNames</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - ARRAY of STRING ListNames () - </pre><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>ARRAY of STRING</td><td>Array of strings where each string is a bus name</td></tr></tbody></table></div><p> - </p><p> - Returns a list of all currently-owned names on the bus. - </p></div><div class="sect3" title="org.freedesktop.DBus.ListActivatableNames"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-list-activatable-names"></a><code class="literal">org.freedesktop.DBus.ListActivatableNames</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - ARRAY of STRING ListActivatableNames () - </pre><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>ARRAY of STRING</td><td>Array of strings where each string is a bus name</td></tr></tbody></table></div><p> - </p><p> - Returns a list of all names that can be activated on the bus. - </p></div><div class="sect3" title="org.freedesktop.DBus.NameHasOwner"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-name-exists"></a><code class="literal">org.freedesktop.DBus.NameHasOwner</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - BOOLEAN NameHasOwner (in STRING name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name to check</td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>BOOLEAN</td><td>Return value, true if the name exists</td></tr></tbody></table></div><p> - </p><p> - Checks if the specified name exists (currently has an owner). - </p></div><div class="sect3" title="org.freedesktop.DBus.NameOwnerChanged"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-name-owner-changed"></a><code class="literal">org.freedesktop.DBus.NameOwnerChanged</code></h4></div></div></div><p> - This is a signal: - </p><pre class="programlisting"> - NameOwnerChanged (STRING name, STRING old_owner, STRING new_owner) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name with a new owner</td></tr><tr><td>1</td><td>STRING</td><td>Old owner or empty string if none</td></tr><tr><td>2</td><td>STRING</td><td>New owner or empty string if none</td></tr></tbody></table></div><p> - </p><p> - This signal indicates that the owner of a name has changed. - It's also the signal to use to detect the appearance of - new names on the bus. - </p></div><div class="sect3" title="org.freedesktop.DBus.NameLost"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-name-lost"></a><code class="literal">org.freedesktop.DBus.NameLost</code></h4></div></div></div><p> - This is a signal: - </p><pre class="programlisting"> - NameLost (STRING name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name which was lost</td></tr></tbody></table></div><p> - </p><p> - This signal is sent to a specific application when it loses - ownership of a name. - </p></div><div class="sect3" title="org.freedesktop.DBus.NameAcquired"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-name-acquired"></a><code class="literal">org.freedesktop.DBus.NameAcquired</code></h4></div></div></div><p> - This is a signal: - </p><pre class="programlisting"> - NameAcquired (STRING name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name which was acquired</td></tr></tbody></table></div><p> - </p><p> - This signal is sent to a specific application when it gains - ownership of a name. - </p></div><div class="sect3" title="org.freedesktop.DBus.StartServiceByName"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-start-service-by-name"></a><code class="literal">org.freedesktop.DBus.StartServiceByName</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - UINT32 StartServiceByName (in STRING name, in UINT32 flags) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name of the service to start</td></tr><tr><td>1</td><td>UINT32</td><td>Flags (currently not used)</td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>UINT32</td><td>Return value</td></tr></tbody></table></div><p> - Tries to launch the executable associated with a name. For more information, see <a class="xref" href="#message-bus-starting-services" title="Message Bus Starting Services">the section called “Message Bus Starting Services”</a>. - - </p><p> - The return value can be one of the following values: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Identifier</th><th>Value</th><th>Description</th></tr></thead><tbody><tr><td>DBUS_START_REPLY_SUCCESS</td><td>1</td><td>The service was successfully started.</td></tr><tr><td>DBUS_START_REPLY_ALREADY_RUNNING</td><td>2</td><td>A connection already owns the given name.</td></tr></tbody></table></div><p> - </p></div><div class="sect3" title="org.freedesktop.DBus.UpdateActivationEnvironment"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-update-activation-environment"></a><code class="literal">org.freedesktop.DBus.UpdateActivationEnvironment</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - UpdateActivationEnvironment (in ARRAY of DICT<STRING,STRING> environment) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>ARRAY of DICT<STRING,STRING></td><td>Environment to add or update</td></tr></tbody></table></div><p> - Normally, session bus activated services inherit the environment of the bus daemon. This method adds to or modifies that environment when activating services. - </p><p> - Some bus instances, such as the standard system bus, may disable access to this method for some or all callers. - </p><p> - Note, both the environment variable names and values must be valid UTF-8. There's no way to update the activation environment with data that is invalid UTF-8. - </p></div><div class="sect3" title="org.freedesktop.DBus.GetNameOwner"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-get-name-owner"></a><code class="literal">org.freedesktop.DBus.GetNameOwner</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - STRING GetNameOwner (in STRING name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Name to get the owner of</td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Return value, a unique connection name</td></tr></tbody></table></div><p> - Returns the unique connection name of the primary owner of the name - given. If the requested name doesn't have an owner, returns a - <code class="literal">org.freedesktop.DBus.Error.NameHasNoOwner</code> error. - </p></div><div class="sect3" title="org.freedesktop.DBus.GetConnectionUnixUser"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-get-connection-unix-user"></a><code class="literal">org.freedesktop.DBus.GetConnectionUnixUser</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - UINT32 GetConnectionUnixUser (in STRING bus_name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Unique or well-known bus name of the connection to - query, such as <code class="literal">:12.34</code> or - <code class="literal">com.example.tea</code></td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>UINT32</td><td>Unix user ID</td></tr></tbody></table></div><p> - Returns the Unix user ID of the process connected to the server. If - unable to determine it (for instance, because the process is not on the - same machine as the bus daemon), an error is returned. - </p></div><div class="sect3" title="org.freedesktop.DBus.GetConnectionUnixProcessID"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-get-connection-unix-process-id"></a><code class="literal">org.freedesktop.DBus.GetConnectionUnixProcessID</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - UINT32 GetConnectionUnixProcessID (in STRING bus_name) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Unique or well-known bus name of the connection to - query, such as <code class="literal">:12.34</code> or - <code class="literal">com.example.tea</code></td></tr></tbody></table></div><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>UINT32</td><td>Unix process id</td></tr></tbody></table></div><p> - Returns the Unix process ID of the process connected to the server. If - unable to determine it (for instance, because the process is not on the - same machine as the bus daemon), an error is returned. - </p></div><div class="sect3" title="org.freedesktop.DBus.AddMatch"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-add-match"></a><code class="literal">org.freedesktop.DBus.AddMatch</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - AddMatch (in STRING rule) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Match rule to add to the connection</td></tr></tbody></table></div><p> - Adds a match rule to match messages going through the message bus (see <a class="xref" href="#message-bus-routing-match-rules" title="Match Rules">the section called “Match Rules”</a>). - If the bus does not have enough resources the <code class="literal">org.freedesktop.DBus.Error.OOM</code> - error is returned. - </p></div><div class="sect3" title="org.freedesktop.DBus.RemoveMatch"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-remove-match"></a><code class="literal">org.freedesktop.DBus.RemoveMatch</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - RemoveMatch (in STRING rule) - </pre><p> - Message arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Match rule to remove from the connection</td></tr></tbody></table></div><p> - Removes the first rule that matches (see <a class="xref" href="#message-bus-routing-match-rules" title="Match Rules">the section called “Match Rules”</a>). - If the rule is not found the <code class="literal">org.freedesktop.DBus.Error.MatchRuleNotFound</code> - error is returned. - </p></div><div class="sect3" title="org.freedesktop.DBus.GetId"><div class="titlepage"><div><div><h4 class="title"><a name="bus-messages-get-id"></a><code class="literal">org.freedesktop.DBus.GetId</code></h4></div></div></div><p> - As a method: - </p><pre class="programlisting"> - GetId (out STRING id) - </pre><p> - Reply arguments: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Argument</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>0</td><td>STRING</td><td>Unique ID identifying the bus daemon</td></tr></tbody></table></div><p> - Gets the unique ID of the bus. The unique ID here is shared among all addresses the - bus daemon is listening on (TCP, UNIX domain socket, etc.) and its format is described in - <a class="xref" href="#uuids" title="UUIDs">the section called “UUIDs”</a>. Each address the bus is listening on also has its own unique - ID, as described in <a class="xref" href="#addresses" title="Server Addresses">the section called “Server Addresses”</a>. The per-bus and per-address IDs are not related. - There is also a per-machine ID, described in <a class="xref" href="#standard-interfaces-peer" title="org.freedesktop.DBus.Peer">the section called “<code class="literal">org.freedesktop.DBus.Peer</code>”</a> and returned - by org.freedesktop.DBus.Peer.GetMachineId(). - For a desktop session bus, the bus ID can be used as a way to uniquely identify a user's session. - </p></div></div></div><div class="glossary" title="Glossary"><div class="titlepage"><div><div><h2 class="title"><a name="idp5904720"></a>Glossary</h2></div></div></div><p> - This glossary defines some of the terms used in this specification. - </p><dl><dt><a name="term-bus-name"></a>Bus Name</dt><dd><p> - The message bus maintains an association between names and - connections. (Normally, there's one connection per application.) A - bus name is simply an identifier used to locate connections. For - example, the hypothetical <code class="literal">com.yoyodyne.Screensaver</code> - name might be used to send a message to a screensaver from Yoyodyne - Corporation. An application is said to <em class="firstterm">own</em> a - name if the message bus has associated the application's connection - with the name. Names may also have <em class="firstterm">queued - owners</em> (see <a class="xref" href="#term-queued-owner" title="Queued Name Owner">Queued Name Owner</a>). - The bus assigns a unique name to each connection, - see <a class="xref" href="#term-unique-name" title="Unique Connection Name">Unique Connection Name</a>. Other names - can be thought of as "well-known names" and are - used to find applications that offer specific functionality. - </p><p> - See <a class="xref" href="#message-protocol-names-bus" title="Bus names">the section called “Bus names”</a> for details of - the syntax and naming conventions for bus names. - </p></dd><dt><a name="term-message"></a>Message</dt><dd><p> - A message is the atomic unit of communication via the D-Bus - protocol. It consists of a <em class="firstterm">header</em> and a - <em class="firstterm">body</em>; the body is made up of - <em class="firstterm">arguments</em>. - </p></dd><dt><a name="term-message-bus"></a>Message Bus</dt><dd><p> - The message bus is a special application that forwards - or routes messages between a group of applications - connected to the message bus. It also manages - <em class="firstterm">names</em> used for routing - messages. - </p></dd><dt><a name="term-name"></a>Name</dt><dd><p> - See <a class="xref" href="#term-bus-name" title="Bus Name">Bus Name</a>. "Name" may - also be used to refer to some of the other names - in D-Bus, such as interface names. - </p></dd><dt><a name="namespace"></a>Namespace</dt><dd><p> - Used to prevent collisions when defining new interfaces, bus names - etc. The convention used is the same one Java uses for defining - classes: a reversed domain name. - See <a class="xref" href="#message-protocol-names-bus" title="Bus names">the section called “Bus names”</a>, - <a class="xref" href="#message-protocol-names-interface" title="Interface names">the section called “Interface names”</a>, - <a class="xref" href="#message-protocol-names-error" title="Error names">the section called “Error names”</a>, - <a class="xref" href="#message-protocol-marshaling-object-path" title="Valid Object Paths">the section called “Valid Object Paths”</a>. - </p></dd><dt><a name="term-object"></a>Object</dt><dd><p> - Each application contains <em class="firstterm">objects</em>, which have - <em class="firstterm">interfaces</em> and - <em class="firstterm">methods</em>. Objects are referred to by a name, - called a <em class="firstterm">path</em>. - </p></dd><dt><a name="one-to-one"></a>One-to-One</dt><dd><p> - An application talking directly to another application, without going - through a message bus. One-to-one connections may be "peer to peer" or - "client to server." The D-Bus protocol has no concept of client - vs. server after a connection has authenticated; the flow of messages - is symmetrical (full duplex). - </p></dd><dt><a name="term-path"></a>Path</dt><dd><p> - Object references (object names) in D-Bus are organized into a - filesystem-style hierarchy, so each object is named by a path. As in - LDAP, there's no difference between "files" and "directories"; a path - can refer to an object, while still having child objects below it. - </p></dd><dt><a name="term-queued-owner"></a>Queued Name Owner</dt><dd><p> - Each bus name has a primary owner; messages sent to the name go to the - primary owner. However, certain names also maintain a queue of - secondary owners "waiting in the wings." If the primary owner releases - the name, then the first secondary owner in the queue automatically - becomes the new owner of the name. - </p></dd><dt><a name="term-service"></a>Service</dt><dd><p> - A service is an executable that can be launched by the bus daemon. - Services normally guarantee some particular features, for example they - may guarantee that they will request a specific name such as - "org.freedesktop.Screensaver", have a singleton object - "/org/freedesktop/Application", and that object will implement the - interface "org.freedesktop.ScreensaverControl". - </p></dd><dt><a name="term-service-description-files"></a>Service Description Files</dt><dd><p> - ".service files" tell the bus about service applications that can be - launched (see <a class="xref" href="#term-service" title="Service">Service</a>). Most importantly they - provide a mapping from bus names to services that will request those - names when they start up. - </p></dd><dt><a name="term-unique-name"></a>Unique Connection Name</dt><dd><p> - The special name automatically assigned to each connection by the - message bus. This name will never change owner, and will be unique - (never reused during the lifetime of the message bus). - It will begin with a ':' character. - </p></dd></dl></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a id="ftn.idp5281040" href="#idp5281040" class="para">1</a>] </sup>Lockfiles are used instead of real file - locking <code class="literal">fcntl()</code> because real locking - implementations are still flaky on network - filesystems.</p></div><div class="footnote"><p><sup>[<a id="ftn.idp5733888" href="#idp5733888" class="para">2</a>] </sup> - The D-Bus reference implementation actually honors the - <code class="literal">$(localstatedir)</code> configure option - for this address, on both client and server side. - </p></div><div class="footnote"><p><sup>[<a id="ftn.idp5738096" href="#idp5738096" class="para">3</a>] </sup> - The system bus is security-sensitive and is typically executed - by an init system with a clean environment. Its launch helper - process is particularly security-sensitive, and specifically - clears its own environment. - </p></div></div></div></body></html> diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index d806b8ea..8d348489 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -6,8 +6,8 @@ <article id="index"> <articleinfo> <title>D-Bus Specification</title> - <releaseinfo>Version 0.19</releaseinfo> - <date>2012-02-21</date> + <releaseinfo>Version 0.20</releaseinfo> + <date>2013-02-22</date> <authorgroup> <author> <firstname>Havoc</firstname> @@ -72,10 +72,11 @@ </authorgroup> <revhistory> <revision> - <revnumber>current</revnumber> - <date><ulink url='http://cgit.freedesktop.org/dbus/dbus/log/doc/dbus-specification.xml'>commit log</ulink></date> - <authorinitials></authorinitials> - <revremark></revremark> + <revnumber>0.20</revnumber> + <date>22 February 2013 (<ulink url='http://cgit.freedesktop.org/dbus/dbus/log/doc/dbus-specification.xml'>commit log</ulink>)</date> + <authorinitials>smcv, walters</authorinitials> + <revremark>reorganise for clarity, remove false claims about + basic types, mention /o/fd/DBus</revremark> </revision> <revision> <revnumber>0.19</revnumber> @@ -292,17 +293,68 @@ it back from the wire format is <firstterm>unmarshaling</firstterm>. </para> - <sect2 id="message-protocol-signatures"> - <title>Type Signatures</title> + <para> + The D-Bus protocol does not include type tags in the marshaled data; a + block of marshaled values must have a known <firstterm>type + signature</firstterm>. The type signature is made up of zero or more + <firstterm id="term-single-complete-type">single complete + types</firstterm>, each made up of one or more + <firstterm>type codes</firstterm>. + </para> + + <para> + A type code is an ASCII character representing the + type of a value. Because ASCII characters are used, the type signature + will always form a valid ASCII string. A simple string compare + determines whether two type signatures are equivalent. + </para> + + <para> + A single complete type is a sequence of type codes that fully describes + one type: either a basic type, or a single fully-described container type. + A single complete type is a basic type code, a variant type code, + an array with its element type, or a struct with its fields (all of which + are defined below). So the following signatures are not single complete + types: + <programlisting> + "aa" + </programlisting> + <programlisting> + "(ii" + </programlisting> + <programlisting> + "ii)" + </programlisting> + And the following signatures contain multiple complete types: + <programlisting> + "ii" + </programlisting> + <programlisting> + "aiai" + </programlisting> + <programlisting> + "(ii)(ii)" + </programlisting> + Note however that a single complete type may <emphasis>contain</emphasis> + multiple other single complete types, by containing a struct or dict + entry. + </para> + + <sect2 id="basic-types"> + <title>Basic types</title> <para> - The D-Bus protocol does not include type tags in the marshaled data; a - block of marshaled values must have a known <firstterm>type - signature</firstterm>. The type signature is made up of <firstterm>type - codes</firstterm>. A type code is an ASCII character representing the - type of a value. Because ASCII characters are used, the type signature - will always form a valid ASCII string. A simple string compare - determines whether two type signatures are equivalent. + The simplest type codes are the <firstterm id="term-basic-type">basic + types</firstterm>, which are the types whose structure is entirely + defined by their 1-character type code. Basic types consist of + fixed types and string-like types. + </para> + + <para> + The <firstterm id="term-fixed-type">fixed types</firstterm> + are basic types whose values have a fixed length, namely BYTE, + BOOLEAN, DOUBLE, UNIX_FD, and signed or unsigned integers of length + 16, 32 or 64 bits. </para> <para> @@ -319,10 +371,260 @@ </para> <para> - All <firstterm>basic</firstterm> types work like - <literal>INT32</literal> in this example. To marshal and unmarshal - basic types, you simply read one value from the data - block corresponding to each type code in the signature. + The characteristics of the fixed types are listed in this table. + + <informaltable> + <tgroup cols="3"> + <thead> + <row> + <entry>Conventional name</entry> + <entry>ASCII type-code</entry> + <entry>Encoding</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>BYTE</literal></entry> + <entry><literal>y</literal> (121)</entry> + <entry>Unsigned 8-bit integer</entry> + </row> + <row> + <entry><literal>BOOLEAN</literal></entry> + <entry><literal>b</literal> (98)</entry> + <entry>Boolean value: 0 is false, 1 is true, any other value + allowed by the marshalling format is invalid</entry> + </row> + <row> + <entry><literal>INT16</literal></entry> + <entry><literal>n</literal> (110)</entry> + <entry>Signed (two's complement) 16-bit integer</entry> + </row> + <row> + <entry><literal>UINT16</literal></entry> + <entry><literal>q</literal> (113)</entry> + <entry>Unsigned 16-bit integer</entry> + </row> + <row> + <entry><literal>INT32</literal></entry> + <entry><literal>i</literal> (105)</entry> + <entry>Signed (two's complement) 32-bit integer</entry> + </row> + <row> + <entry><literal>UINT32</literal></entry> + <entry><literal>u</literal> (117)</entry> + <entry>Unsigned 32-bit integer</entry> + </row> + <row> + <entry><literal>INT64</literal></entry> + <entry><literal>x</literal> (120)</entry> + <entry>Signed (two's complement) 64-bit integer + (mnemonic: x and t are the first characters in "sixty" not + already used for something more common)</entry> + </row> + <row> + <entry><literal>UINT64</literal></entry> + <entry><literal>t</literal> (116)</entry> + <entry>Unsigned 64-bit integer</entry> + </row> + <row> + <entry><literal>DOUBLE</literal></entry> + <entry><literal>d</literal> (100)</entry> + <entry>IEEE 754 double-precision floating point</entry> + </row> + <row> + <entry><literal>UNIX_FD</literal></entry> + <entry><literal>h</literal> (104)</entry> + <entry>Unsigned 32-bit integer representing an index into an + out-of-band array of file descriptors, transferred via some + platform-specific mechanism (mnemonic: h for handle)</entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + + <para> + The <firstterm id="term-string-like-type">string-like types</firstterm> + are basic types with a variable length. The value of any string-like + type is conceptually 0 or more Unicode codepoints encoded in UTF-8, + none of which may be U+0000. The UTF-8 text must be validated + strictly: in particular, it must not contain overlong sequences, + noncharacters such as U+FFFE, or codepoints above U+10FFFF. + </para> + + <para> + The marshalling formats for the string-like types all end with a + single zero (NUL) byte, but that byte is not considered to be part of + the text. + </para> + + <para> + The characteristics of the string-like types are listed in this table. + + <informaltable> + <tgroup cols="3"> + <thead> + <row> + <entry>Conventional name</entry> + <entry>ASCII type-code</entry> + <entry>Validity constraints</entry> + </row> + </thead> + <tbody> + <row> + <entry><literal>STRING</literal></entry> + <entry><literal>s</literal> (115)</entry> + <entry>No extra constraints</entry> + </row> + <row> + <entry><literal>OBJECT_PATH</literal></entry> + <entry><literal>o</literal> (111)</entry> + <entry>Must be + <link linkend="message-protocol-marshaling-object-path">a + syntactically valid object path</link></entry> + </row> + <row> + <entry><literal>SIGNATURE</literal></entry> + <entry><literal>g</literal> (103)</entry> + <entry>Zero or more + <firstterm linkend="term-single-complete-type">single + complete types</firstterm></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + + <sect3 id="message-protocol-marshaling-object-path"> + <title>Valid Object Paths</title> + + <para> + An object path is a name used to refer to an object instance. + Conceptually, each participant in a D-Bus message exchange may have + any number of object instances (think of C++ or Java objects) and each + such instance will have a path. Like a filesystem, the object + instances in an application form a hierarchical tree. + </para> + + <para> + Object paths are often namespaced by starting with a reversed + domain name and containing an interface version number, in the + same way as + <link linkend="message-protocol-names-interface">interface + names</link> and + <link linkend="message-protocol-names-bus">well-known + bus names</link>. + This makes it possible to implement more than one service, or + more than one version of a service, in the same process, + even if the services share a connection but cannot otherwise + co-operate (for instance, if they are implemented by different + plugins). + </para> + + <para> + For instance, if the owner of <literal>example.com</literal> is + developing a D-Bus API for a music player, they might use the + hierarchy of object paths that start with + <literal>/com/example/MusicPlayer1</literal> for its objects. + </para> + + <para> + The following rules define a valid object path. Implementations must + not send or accept messages with invalid object paths. + <itemizedlist> + <listitem> + <para> + The path may be of any length. + </para> + </listitem> + <listitem> + <para> + The path must begin with an ASCII '/' (integer 47) character, + and must consist of elements separated by slash characters. + </para> + </listitem> + <listitem> + <para> + Each element must only contain the ASCII characters + "[A-Z][a-z][0-9]_" + </para> + </listitem> + <listitem> + <para> + No element may be the empty string. + </para> + </listitem> + <listitem> + <para> + Multiple '/' characters cannot occur in sequence. + </para> + </listitem> + <listitem> + <para> + A trailing '/' character is not allowed unless the + path is the root path (a single '/' character). + </para> + </listitem> + </itemizedlist> + </para> + + </sect3> + + <sect3 id="message-protocol-marshaling-signature"> + <title>Valid Signatures</title> + <para> + An implementation must not send or accept invalid signatures. + Valid signatures will conform to the following rules: + <itemizedlist> + <listitem> + <para> + The signature is a list of single complete types. + Arrays must have element types, and structs must + have both open and close parentheses. + </para> + </listitem> + <listitem> + <para> + Only type codes, open and close parentheses, and open and + close curly brackets are allowed in the signature. The + <literal>STRUCT</literal> type code + is not allowed in signatures, because parentheses + are used instead. Similarly, the + <literal>DICT_ENTRY</literal> type code is not allowed in + signatures, because curly brackets are used instead. + </para> + </listitem> + <listitem> + <para> + The maximum depth of container type nesting is 32 array type + codes and 32 open parentheses. This implies that the maximum + total depth of recursion is 64, for an "array of array of array + of ... struct of struct of struct of ..." where there are 32 + array and 32 struct. + </para> + </listitem> + <listitem> + <para> + The maximum length of a signature is 255. + </para> + </listitem> + </itemizedlist> + </para> + + <para> + When signatures appear in messages, the marshalling format + guarantees that they will be followed by a nul byte (which can + be interpreted as either C-style string termination or the INVALID + type-code), but this is not conceptually part of the signature. + </para> + </sect3> + + </sect2> + + <sect2 id="container-types"> + <title>Container types</title> + + <para> In addition to basic types, there are four <firstterm>container</firstterm> types: <literal>STRUCT</literal>, <literal>ARRAY</literal>, <literal>VARIANT</literal>, and <literal>DICT_ENTRY</literal>. @@ -378,34 +680,6 @@ </para> <para> - The phrase <firstterm>single complete type</firstterm> deserves some - definition. A single complete type is a basic type code, a variant type code, - an array with its element type, or a struct with its fields. - So the following signatures are not single complete types: - <programlisting> - "aa" - </programlisting> - <programlisting> - "(ii" - </programlisting> - <programlisting> - "ii)" - </programlisting> - And the following signatures contain multiple complete types: - <programlisting> - "ii" - </programlisting> - <programlisting> - "aiai" - </programlisting> - <programlisting> - "(ii)(ii)" - </programlisting> - Note however that a single complete type may <emphasis>contain</emphasis> - multiple other single complete types. - </para> - - <para> <literal>VARIANT</literal> has ASCII character 'v' as its type code. A marshaled value of type <literal>VARIANT</literal> will have the signature of a single complete type as part of the <emphasis>value</emphasis>. This signature will be followed by a @@ -413,6 +687,14 @@ </para> <para> + Unlike a message signature, the variant signature can + contain only a single complete type. So "i", "ai" + or "(ii)" is OK, but "ii" is not. Use of variants may not + cause a total message depth to be larger than 64, including + other container types such as structures. + </para> + + <para> A <literal>DICT_ENTRY</literal> works exactly like a struct, but rather than parentheses it uses curly braces, and it has more restrictions. The restrictions are: it occurs only as an array element type; it has @@ -435,6 +717,10 @@ In most languages, an array of dict entry would be represented as a map, hash table, or dict object. </para> + </sect2> + + <sect2> + <title>Summary of types</title> <para> The following table summarizes the D-Bus types. @@ -566,9 +852,21 @@ </para> </sect2> + </sect1> - <sect2 id="message-protocol-marshaling"> - <title>Marshaling (Wire Format)</title> + <sect1 id="message-protocol-marshaling"> + <title>Marshaling (Wire Format)</title> + + <para> + D-Bus defines a marshalling format for its type system, which is + used in D-Bus messages. This is not the only possible marshalling + format for the type system: for instance, GVariant (part of GLib) + re-uses the D-Bus type system but implements an alternative marshalling + format. + </para> + + <sect2> + <title>Byte order and alignment</title> <para> Given a type signature, a block of bytes can be converted into typed @@ -577,11 +875,11 @@ </para> <para> - A block of bytes has an associated byte order. The byte order - has to be discovered in some way; for D-Bus messages, the - byte order is part of the message header as described in - <xref linkend="message-protocol-messages"/>. For now, assume - that the byte order is known to be either little endian or big + A block of bytes has an associated byte order. The byte order + has to be discovered in some way; for D-Bus messages, the + byte order is part of the message header as described in + <xref linkend="message-protocol-messages"/>. For now, assume + that the byte order is known to be either little endian or big endian. </para> @@ -597,6 +895,95 @@ </para> <para> + As an exception to natural alignment, <literal>STRUCT</literal> and + <literal>DICT_ENTRY</literal> values are always aligned to an 8-byte + boundary, regardless of the alignments of their contents. + </para> + </sect2> + + <sect2> + <title>Marshalling basic types</title> + + <para> + To marshal and unmarshal fixed types, you simply read one value + from the data block corresponding to each type code in the signature. + All signed integer values are encoded in two's complement, DOUBLE + values are IEEE 754 double-precision floating-point, and BOOLEAN + values are encoded in 32 bits (of which only the least significant + bit is used). + </para> + + <para> + The string-like types are all marshalled as a + fixed-length unsigned integer <varname>n</varname> giving the + length of the variable part, followed by <varname>n</varname> + nonzero bytes of UTF-8 text, followed by a single zero (nul) byte + which is not considered to be part of the text. The alignment + of the string-like type is the same as the alignment of + <varname>n</varname>. + </para> + + <para> + For the STRING and OBJECT_PATH types, <varname>n</varname> is + encoded in 4 bytes, leading to 4-byte alignment. + For the SIGNATURE type, <varname>n</varname> is encoded as a single + byte. As a result, alignment padding is never required before a + SIGNATURE. + </para> + </sect2> + + <sect2> + <title>Marshalling containers</title> + + <para> + Arrays are marshalled as a <literal>UINT32</literal> + <varname>n</varname> giving the length of the array data in bytes, + followed by alignment padding to the alignment boundary of the array + element type, followed by the <varname>n</varname> bytes of the + array elements marshalled in sequence. <varname>n</varname> does not + include the padding after the length, or any padding after the + last element. + </para> + + <para> + For instance, if the current position in the message is a multiple + of 8 bytes and the byte-order is big-endian, an array containing only + the 64-bit integer 5 would be marshalled as: + + <screen> +00 00 00 08 <lineannotation>8 bytes of data</lineannotation> +00 00 00 00 <lineannotation>padding to 8-byte boundary</lineannotation> +00 00 00 00 00 00 00 05 <lineannotation>first element = 5</lineannotation> + </screen> + </para> + + <para> + Arrays have a maximum length defined to be 2 to the 26th power or + 67108864. Implementations must not send or accept arrays exceeding this + length. + </para> + + <para> + Structs and dict entries are marshalled in the same way as their + contents, but their alignment is always to an 8-byte boundary, + even if their contents would normally be less strictly aligned. + </para> + + <para> + Variants are marshalled as the <literal>SIGNATURE</literal> of + the contents (which must be a single complete type), followed by a + marshalled value with the type given by that signature. The + variant has the same 1-byte alignment as the signature, which means + that alignment padding before a variant is never needed. + Use of variants may not cause a total message depth to be larger + than 64, including other container types such as structures. + </para> + </sect2> + + <sect2> + <title>Summary of D-Bus marshalling</title> + + <para> Given all this, the types are marshaled on the wire as follows: <informaltable> <tgroup cols="3"> @@ -661,7 +1048,7 @@ </row><row> <entry><literal>OBJECT_PATH</literal></entry> <entry>Exactly the same as <literal>STRING</literal> except the - content must be a valid object path (see below). + content must be a valid object path (see above). </entry> <entry> 4 (for the length) @@ -670,7 +1057,7 @@ <entry><literal>SIGNATURE</literal></entry> <entry>The same as <literal>STRING</literal> except the length is a single byte (thus signatures have a maximum length of 255) - and the content must be a valid signature (see below). + and the content must be a valid signature (see above). </entry> <entry> 1 @@ -679,14 +1066,8 @@ <entry><literal>ARRAY</literal></entry> <entry> A <literal>UINT32</literal> giving the length of the array data in bytes, followed by - alignment padding to the alignment boundary of the array element type, - followed by each array element. The array length is from the - end of the alignment padding to the end of the last element, - i.e. it does not include the padding after the length, - or any padding after the last element. - Arrays have a maximum length defined to be 2 to the 26th power or - 67108864. Implementations must not send or accept arrays exceeding this - length. + alignment padding to the alignment boundary of the array element type, + followed by each array element. </entry> <entry> 4 (for the length) @@ -705,14 +1086,9 @@ </row><row> <entry><literal>VARIANT</literal></entry> <entry> - A variant type has a marshaled - <literal>SIGNATURE</literal> followed by a marshaled - value with the type given in the signature. Unlike - a message signature, the variant signature can - contain only a single complete type. So "i", "ai" - or "(ii)" is OK, but "ii" is not. Use of variants may not - cause a total message depth to be larger than 64, including - other container types such as structures. + The marshaled <literal>SIGNATURE</literal> of a single + complete type, followed by a marshaled value with the type + given in the signature. </entry> <entry> 1 (alignment of the signature) @@ -739,130 +1115,7 @@ </tgroup> </informaltable> </para> - - <sect3 id="message-protocol-marshaling-object-path"> - <title>Valid Object Paths</title> - - <para> - An object path is a name used to refer to an object instance. - Conceptually, each participant in a D-Bus message exchange may have - any number of object instances (think of C++ or Java objects) and each - such instance will have a path. Like a filesystem, the object - instances in an application form a hierarchical tree. - </para> - - <para> - The following rules define a valid object path. Implementations must - not send or accept messages with invalid object paths. - <itemizedlist> - <listitem> - <para> - The path may be of any length. - </para> - </listitem> - <listitem> - <para> - The path must begin with an ASCII '/' (integer 47) character, - and must consist of elements separated by slash characters. - </para> - </listitem> - <listitem> - <para> - Each element must only contain the ASCII characters - "[A-Z][a-z][0-9]_" - </para> - </listitem> - <listitem> - <para> - No element may be the empty string. - </para> - </listitem> - <listitem> - <para> - Multiple '/' characters cannot occur in sequence. - </para> - </listitem> - <listitem> - <para> - A trailing '/' character is not allowed unless the - path is the root path (a single '/' character). - </para> - </listitem> - </itemizedlist> - </para> - - <para> - Object paths are often namespaced by starting with a reversed - domain name and containing an interface version number, in the - same way as - <link linkend="message-protocol-names-interface">interface - names</link> and - <link linkend="message-protocol-names-bus">well-known - bus names</link>. - This makes it possible to implement more than one service, or - more than one version of a service, in the same process, - even if the services share a connection but cannot otherwise - co-operate (for instance, if they are implemented by different - plugins). - </para> - - <para> - For instance, if the owner of <literal>example.com</literal> is - developing a D-Bus API for a music player, they might use the - hierarchy of object paths that start with - <literal>/com/example/MusicPlayer1</literal> for its objects. - </para> - </sect3> - <sect3 id="message-protocol-marshaling-signature"> - <title>Valid Signatures</title> - <para> - An implementation must not send or accept invalid signatures. - Valid signatures will conform to the following rules: - <itemizedlist> - <listitem> - <para> - The signature ends with a nul byte. - </para> - </listitem> - <listitem> - <para> - The signature is a list of single complete types. - Arrays must have element types, and structs must - have both open and close parentheses. - </para> - </listitem> - <listitem> - <para> - Only type codes and open and close parentheses are - allowed in the signature. The <literal>STRUCT</literal> type code - is not allowed in signatures, because parentheses - are used instead. - </para> - </listitem> - <listitem> - <para> - The maximum depth of container type nesting is 32 array type - codes and 32 open parentheses. This implies that the maximum - total depth of recursion is 64, for an "array of array of array - of ... struct of struct of struct of ..." where there are 32 - array and 32 struct. - </para> - </listitem> - <listitem> - <para> - The maximum length of a signature is 255. - </para> - </listitem> - <listitem> - <para> - Signatures must be nul-terminated. - </para> - </listitem> - </itemizedlist> - </para> - </sect3> - </sect2> </sect1> @@ -2174,7 +2427,7 @@ </listitem> <listitem> <para> - Receive REJECT [mechs] → send AUTH [next mech], + Receive REJECTED [mechs] → send AUTH [next mech], goto <emphasis>WaitingForData</emphasis> or <emphasis>WaitingForOK</emphasis> </para> @@ -2210,7 +2463,7 @@ <itemizedlist> <listitem> <para> - Receive REJECT [mechs] → send AUTH [next mech], + Receive REJECTED [mechs] → send AUTH [next mech], goto <emphasis>WaitingForData</emphasis> or <emphasis>WaitingForOK</emphasis> </para> @@ -2252,7 +2505,7 @@ <listitem> <para> - REJECT means that the client failed to authenticate or + REJECTED means that the client failed to authenticate or there was an error in RESP. </para> </listitem> @@ -2299,7 +2552,7 @@ </member> <member> - MECH(RESP) returns REJECT → send REJECTED + MECH(RESP) returns REJECTED → send REJECTED [mechs], goto <emphasis>WaitingForAuth</emphasis> </member> @@ -2353,7 +2606,7 @@ </member> <member> - MECH(RESP) returns REJECT → send REJECTED + MECH(RESP) returns REJECTED → send REJECTED [mechs], goto <emphasis>WaitingForAuth</emphasis> </member> @@ -3553,10 +3806,13 @@ that connection is said to <firstterm>own</firstterm> the name. </para> <para> - The bus itself owns a special name, <literal>org.freedesktop.DBus</literal>. - This name routes messages to the bus, allowing applications to make - administrative requests. For example, applications can ask the bus - to assign a name to a connection. + The bus itself owns a special name, + <literal>org.freedesktop.DBus</literal>, with an object + located at <literal>/org/freedesktop/DBus</literal> that + implements the <literal>org.freedesktop.DBus</literal> + interface. This service allows applications to make + administrative requests of the bus itself. For example, + applications can ask the bus to assign a name to a connection. </para> <para> Each name may have <firstterm>queued owners</firstterm>. When an diff --git a/doc/dbus-test-plan.html b/doc/dbus-test-plan.html deleted file mode 100644 index 377a3bf2..00000000 --- a/doc/dbus-test-plan.html +++ /dev/null @@ -1,141 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>D-Bus Test Plan</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" title="D-Bus Test Plan"><div class="titlepage"><div><div><h2 class="title"><a name="index"></a>D-Bus Test Plan</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Anders</span> <span class="surname">Carlsson</span></h3><div class="affiliation"><span class="orgname">CodeFactory AB<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:andersca@codefactory.se">andersca@codefactory.se</a>></code></p></div></div></div></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#introduction">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#importance-of-testing">The importance of testing</a></span></dt></dl></dd><dt><span class="sect1"><a href="#client-library">Testing the D-Bus client library</a></span></dt><dd><dl><dt><span class="sect2"><a href="#data-structures">Data Structures</a></span></dt><dt><span class="sect2"><a href="#message-loader">Message loader</a></span></dt><dt><span class="sect2"><a href="#authentication">Authentication</a></span></dt></dl></dd><dt><span class="sect1"><a href="#daemon">Testing the D-Bus bus daemon</a></span></dt><dd><dl><dt><span class="sect2"><a href="#debug-transport">The debug transport</a></span></dt><dt><span class="sect2"><a href="#bus-test">The bus-test program</a></span></dt></dl></dd><dt><span class="sect1"><a href="#other-tests">Other tests</a></span></dt><dd><dl><dt><span class="sect2"><a href="#oom-robustness">Out-Of-Memory robustness</a></span></dt><dt><span class="sect2"><a href="#leaks-and-other-stuff">Memory leaks and code robustness</a></span></dt></dl></dd></dl></div><div class="sect1" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="introduction"></a>Introduction</h2></div></div></div><p> - This document tries to explain the details of the test plan for D-Bus - </p><div class="sect2" title="The importance of testing"><div class="titlepage"><div><div><h3 class="title"><a name="importance-of-testing"></a>The importance of testing</h3></div></div></div><p> - As with any big library or program, testing is important. It - can help find bugs and regressions and make the code better - overall. - </p><p> - D-Bus is a large and complex piece of software (about 25,000 - lines of code for the client library, and 2,500 lines of code - for the bus daemon) and it's therefore important to try to make sure - that all parts of the software is functioning correctly. - </p><p> - D-Bus can be built with support for testing by passing - <code class="literal">--enable-tests</code>. to the configure script. It - is recommended that production systems build without testing - since that reduces the D-Bus client library size. - </p></div></div><div class="sect1" title="Testing the D-Bus client library"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="client-library"></a>Testing the D-Bus client library</h2></div></div></div><p> - The tests for the client library consist of the dbus-test - program which is a unit test for all aspects of the client - library. Whenever a bug in the client library is found and - fixed, a test is added to make sure that the bug won't occur again. - </p><div class="sect2" title="Data Structures"><div class="titlepage"><div><div><h3 class="title"><a name="data-structures"></a>Data Structures</h3></div></div></div><p> - The D-Bus client library consists of some data structures that - are used internally; a linked list class, a hashtable class and - a string class. All aspects of those are tested by dbus-test. - </p></div><div class="sect2" title="Message loader"><div class="titlepage"><div><div><h3 class="title"><a name="message-loader"></a>Message loader</h3></div></div></div><p> - The message loader is the part of D-Bus that takes messages in - raw character form and parses them, turning them into DBusMessages. - </p><p> - This is one of the parts of D-Bus that - <span class="emphasis"><em>must</em></span> be absolutely bug-free and - robust. The message loader should be able to handle invalid - and incomplete messages without crashing. Not doing so is a - serious issue and can easily result in D-Bus being exploitable - to DoS attacks. - </p><p> - To solve these problems, there is a testing feature called the - Message Builder. The message builder can take a serialized - message in string-form and convert it into a raw character - string which can then be loaded by the message loader. - </p><div class="figure"><a name="idp56320"></a><p class="title"><b>Figure 1. Example of a message in string form</b></p><div class="figure-contents"><pre class="programlisting"> - # Standard org.freedesktop.DBus.Hello message - - VALID_HEADER - FIELD_NAME name - TYPE STRING - STRING 'org.freedesktop.DBus.Hello' - FIELD_NAME srvc - TYPE STRING - STRING 'org.freedesktop.DBus' - ALIGN 8 - END_LENGTH Header - START_LENGTH Body - END_LENGTH Body - </pre></div></div><br class="figure-break"><p> - The file format of messages in string form is documented in - the D-Bus Reference Manual. - </p><p> - The message test part of dbus-test is using the message - builder to build different kinds of messages, both valid, - invalid, and invalid ones, to make sure that the loader won't - crash or leak memory of any of those, and that the loader - knows if a message is valid or not. - </p><p> - There is also a test program called - <code class="literal">break-loader</code> that loads a message in - string-form into raw character form using the message - builder. It then randomly changes the message, it can for - example replace single bytes of data or modify the length of - the message. This is to simulate network errors. The - break-loader program saves all the messages leading to errors - so it can easily be run for a long period of time. - </p></div><div class="sect2" title="Authentication"><div class="titlepage"><div><div><h3 class="title"><a name="authentication"></a>Authentication</h3></div></div></div><p> - For testing authentication, there is a testing feature that - can read authentication sequences from a file and play them - back to a dummy server and client to make sure that - authentication is working according to the specification. - </p><div class="figure"><a name="idp63008"></a><p class="title"><b>Figure 2. Example of an authentication script</b></p><div class="figure-contents"><pre class="programlisting"> - ## this tests a successful auth of type EXTERNAL - - SERVER - SEND 'AUTH EXTERNAL USERNAME_HEX' - EXPECT_COMMAND OK - EXPECT_STATE WAITING_FOR_INPUT - SEND 'BEGIN' - EXPECT_STATE AUTHENTICATED - </pre></div></div><br class="figure-break"></div></div><div class="sect1" title="Testing the D-Bus bus daemon"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="daemon"></a>Testing the D-Bus bus daemon</h2></div></div></div><p> - Since the D-Bus bus daemon is using the D-Bus client library it - will benefit from all tests done on the client library, but - there is still the issue of testing client-server communication. - This is more complicated since it it may require another process - running. - </p><div class="sect2" title="The debug transport"><div class="titlepage"><div><div><h3 class="title"><a name="debug-transport"></a>The debug transport</h3></div></div></div><p> - In D-Bus, a <span class="emphasis"><em>transport</em></span> is a class that - handles sending and receiving raw data over a certain - medium. The transport that is used most in D-Bus is the UNIX - transport with sends and recevies data over a UNIX socket. A - transport that tunnels data through X11 client messages is - also under development. - </p><p> - The D-Bus debug transport is a specialized transport that - works in-process. This means that a client and server that - exists in the same process can talk to eachother without using - a socket. - </p></div><div class="sect2" title="The bus-test program"><div class="titlepage"><div><div><h3 class="title"><a name="bus-test"></a>The bus-test program</h3></div></div></div><p> - The bus-test program is a program that is used to test various - parts of the D-Bus bus daemon; robustness and that it conforms - to the specifications. - </p><p> - The test program has the necessary code from the bus daemon - linked in, and it uses the debug transport for - communication. This means that the bus daemon code can be - tested without the real bus actually running, which makes - testing easier. - </p><p> - The bus-test program should test all major features of the - bus, such as service registration, notification when things - occurs and message matching. - </p></div></div><div class="sect1" title="Other tests"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="other-tests"></a>Other tests</h2></div></div></div><div class="sect2" title="Out-Of-Memory robustness"><div class="titlepage"><div><div><h3 class="title"><a name="oom-robustness"></a>Out-Of-Memory robustness</h3></div></div></div><p> - Since D-Bus should be able to be used in embedded devices, and - also as a system service, it should be able to cope with - low-memory situations without exiting or crashing. - </p><p> - In practice, this means that both the client and server code - must be able to handle dbus_malloc returning NULL. - </p><p> - To test this, two environment variables - exist. <code class="literal">DBUS_MALLOC_FAIL_NTH</code> will make every - nth call to dbus_malloc return NULL, and - <code class="literal">DBUS_MALLOC_FAIL_GREATER_THAN</code> will make any - dbus_malloc call with a request for more than the specified - number of bytes fail. - </p></div><div class="sect2" title="Memory leaks and code robustness"><div class="titlepage"><div><div><h3 class="title"><a name="leaks-and-other-stuff"></a>Memory leaks and code robustness</h3></div></div></div><p> - Naturally there are some things that tests can't be written - for, for example things like memory leaks and out-of-bounds - memory reading or writing. - </p><p> - Luckily there exists good tools for catching such errors. One - free good tool is <a class="ulink" href="http://devel-home.kde.org/~sewardj/" target="_top">Valgrind</a>, which runs the program in a - virtual CPU which makes catching errors easy. All test programs can be run under Valgrind, - </p></div></div></div></body></html> diff --git a/doc/dbus-tutorial.html b/doc/dbus-tutorial.html deleted file mode 100644 index 37ab2eac..00000000 --- a/doc/dbus-tutorial.html +++ /dev/null @@ -1,991 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>D-Bus Tutorial</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" title="D-Bus Tutorial"><div class="titlepage"><div><div><h2 class="title"><a name="index"></a>D-Bus Tutorial</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:hp@pobox.com">hp@pobox.com</a>></code></p></div></div></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="surname">Wheeler</span></h3></div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="surname">Palmieri</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:johnp@redhat.com">johnp@redhat.com</a>></code></p></div></div></div><div class="author"><h3 class="author"><span class="firstname">Colin</span> <span class="surname">Walters</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><code class="email"><<a class="email" href="mailto:walters@redhat.com">walters@redhat.com</a>></code></p></div></div></div></div></div><div><p class="releaseinfo">Version 0.5.0</p></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#meta">Tutorial Work In Progress</a></span></dt><dt><span class="sect1"><a href="#whatis">What is D-Bus?</a></span></dt><dd><dl><dt><span class="sect2"><a href="#uses">D-Bus applications</a></span></dt></dl></dd><dt><span class="sect1"><a href="#concepts">Concepts</a></span></dt><dd><dl><dt><span class="sect2"><a href="#objects">Native Objects and Object Paths</a></span></dt><dt><span class="sect2"><a href="#members">Methods and Signals</a></span></dt><dt><span class="sect2"><a href="#interfaces">Interfaces</a></span></dt><dt><span class="sect2"><a href="#proxies">Proxies</a></span></dt><dt><span class="sect2"><a href="#bus-names">Bus Names</a></span></dt><dt><span class="sect2"><a href="#addresses">Addresses</a></span></dt><dt><span class="sect2"><a href="#bigpicture">Big Conceptual Picture</a></span></dt><dt><span class="sect2"><a href="#messages">Messages - Behind the Scenes</a></span></dt><dt><span class="sect2"><a href="#callprocedure">Calling a Method - Behind the Scenes</a></span></dt><dt><span class="sect2"><a href="#signalprocedure">Emitting a Signal - Behind the Scenes</a></span></dt><dt><span class="sect2"><a href="#introspection">Introspection</a></span></dt></dl></dd><dt><span class="sect1"><a href="#glib-client">GLib API: Using Remote Objects</a></span></dt><dd><dl><dt><span class="sect2"><a href="#glib-typemappings">D-Bus - GLib type mappings</a></span></dt><dt><span class="sect2"><a href="#sample-program-1">A sample program</a></span></dt><dt><span class="sect2"><a href="#glib-program-setup">Program initalization</a></span></dt><dt><span class="sect2"><a href="#glib-method-invocation">Understanding method invocation</a></span></dt><dt><span class="sect2"><a href="#glib-signal-connection">Connecting to object signals</a></span></dt><dt><span class="sect2"><a href="#glib-error-handling">Error handling and remote exceptions</a></span></dt><dt><span class="sect2"><a href="#glib-more-examples">More examples of method invocation</a></span></dt><dt><span class="sect2"><a href="#glib-generated-bindings">Generated Bindings</a></span></dt></dl></dd><dt><span class="sect1"><a href="#glib-server">GLib API: Implementing Objects</a></span></dt><dd><dl><dt><span class="sect2"><a href="#glib-annotations">Server-side Annotations</a></span></dt></dl></dd><dt><span class="sect1"><a href="#python-client">Python API</a></span></dt><dt><span class="sect1"><a href="#qt-client">Qt API: Using Remote Objects</a></span></dt><dt><span class="sect1"><a href="#qt-server">Qt API: Implementing Objects</a></span></dt></dl></div><div class="sect1" title="Tutorial Work In Progress"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="meta"></a>Tutorial Work In Progress</h2></div></div></div><p> - This tutorial is not complete; it probably contains some useful information, but - also has plenty of gaps. Right now, you'll also need to refer to the D-Bus specification, - Doxygen reference documentation, and look at some examples of how other apps use D-Bus. - </p><p> - Enhancing the tutorial is definitely encouraged - send your patches or suggestions to the - mailing list. If you create a D-Bus binding, please add a section to the tutorial for your - binding, if only a short section with a couple of examples. - </p></div><div class="sect1" title="What is D-Bus?"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="whatis"></a>What is D-Bus?</h2></div></div></div><p> - D-Bus is a system for <em class="firstterm">interprocess communication</em> - (IPC). Architecturally, it has several layers: - - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - A library, <em class="firstterm">libdbus</em>, that allows two - applications to connect to each other and exchange messages. - </p></li><li class="listitem"><p> - A <em class="firstterm">message bus daemon</em> executable, built on - libdbus, that multiple applications can connect to. The daemon can - route messages from one application to zero or more other - applications. - </p></li><li class="listitem"><p> - <em class="firstterm">Wrapper libraries</em> or <em class="firstterm">bindings</em> - based on particular application frameworks. For example, libdbus-glib and - libdbus-qt. There are also bindings to languages such as - Python. These wrapper libraries are the API most people should use, - as they simplify the details of D-Bus programming. libdbus is - intended to be a low-level backend for the higher level bindings. - Much of the libdbus API is only useful for binding implementation. - </p></li></ul></div><p> - </p><p> - libdbus only supports one-to-one connections, just like a raw network - socket. However, rather than sending byte streams over the connection, you - send <em class="firstterm">messages</em>. Messages have a header identifying - the kind of message, and a body containing a data payload. libdbus also - abstracts the exact transport used (sockets vs. whatever else), and - handles details such as authentication. - </p><p> - The message bus daemon forms the hub of a wheel. Each spoke of the wheel - is a one-to-one connection to an application using libdbus. An - application sends a message to the bus daemon over its spoke, and the bus - daemon forwards the message to other connected applications as - appropriate. Think of the daemon as a router. - </p><p> - The bus daemon has multiple instances on a typical computer. The - first instance is a machine-global singleton, that is, a system daemon - similar to sendmail or Apache. This instance has heavy security - restrictions on what messages it will accept, and is used for systemwide - communication. The other instances are created one per user login session. - These instances allow applications in the user's session to communicate - with one another. - </p><p> - The systemwide and per-user daemons are separate. Normal within-session - IPC does not involve the systemwide message bus process and vice versa. - </p><div class="sect2" title="D-Bus applications"><div class="titlepage"><div><div><h3 class="title"><a name="uses"></a>D-Bus applications</h3></div></div></div><p> - There are many, many technologies in the world that have "Inter-process - communication" or "networking" in their stated purpose: <a class="ulink" href="http://www.omg.org" target="_top">CORBA</a>, <a class="ulink" href="http://www.opengroup.org/dce/" target="_top">DCE</a>, <a class="ulink" href="http://www.microsoft.com/com/" target="_top">DCOM</a>, <a class="ulink" href="http://developer.kde.org/documentation/library/kdeqt/dcop.html" target="_top">DCOP</a>, <a class="ulink" href="http://www.xmlrpc.com" target="_top">XML-RPC</a>, <a class="ulink" href="http://www.w3.org/TR/SOAP/" target="_top">SOAP</a>, <a class="ulink" href="http://www.mbus.org/" target="_top">MBUS</a>, <a class="ulink" href="http://www.zeroc.com/ice.html" target="_top">Internet Communications Engine (ICE)</a>, - and probably hundreds more. - Each of these is tailored for particular kinds of application. - D-Bus is designed for two specific cases: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Communication between desktop applications in the same desktop - session; to allow integration of the desktop session as a whole, - and address issues of process lifecycle (when do desktop components - start and stop running). - </p></li><li class="listitem"><p> - Communication between the desktop session and the operating system, - where the operating system would typically include the kernel - and any system daemons or processes. - </p></li></ul></div><p> - </p><p> - For the within-desktop-session use case, the GNOME and KDE desktops - have significant previous experience with different IPC solutions - such as CORBA and DCOP. D-Bus is built on that experience and - carefully tailored to meet the needs of these desktop projects - in particular. D-Bus may or may not be appropriate for other - applications; the FAQ has some comparisons to other IPC systems. - </p><p> - The problem solved by the systemwide or communication-with-the-OS case - is explained well by the following text from the Linux Hotplug project: - </p><div class="blockquote"><blockquote class="blockquote"><p> - A gap in current Linux support is that policies with any sort of - dynamic "interact with user" component aren't currently - supported. For example, that's often needed the first time a network - adapter or printer is connected, and to determine appropriate places - to mount disk drives. It would seem that such actions could be - supported for any case where a responsible human can be identified: - single user workstations, or any system which is remotely - administered. - </p><p> - This is a classic "remote sysadmin" problem, where in this case - hotplugging needs to deliver an event from one security domain - (operating system kernel, in this case) to another (desktop for - logged-in user, or remote sysadmin). Any effective response must go - the other way: the remote domain taking some action that lets the - kernel expose the desired device capabilities. (The action can often - be taken asynchronously, for example letting new hardware be idle - until a meeting finishes.) At this writing, Linux doesn't have - widely adopted solutions to such problems. However, the new D-Bus - work may begin to solve that problem. - </p></blockquote></div><p> - </p><p> - D-Bus may happen to be useful for purposes other than the one it was - designed for. Its general properties that distinguish it from - other forms of IPC are: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Binary protocol designed to be used asynchronously - (similar in spirit to the X Window System protocol). - </p></li><li class="listitem"><p> - Stateful, reliable connections held open over time. - </p></li><li class="listitem"><p> - The message bus is a daemon, not a "swarm" or - distributed architecture. - </p></li><li class="listitem"><p> - Many implementation and deployment issues are specified rather - than left ambiguous/configurable/pluggable. - </p></li><li class="listitem"><p> - Semantics are similar to the existing DCOP system, allowing - KDE to adopt it more easily. - </p></li><li class="listitem"><p> - Security features to support the systemwide mode of the - message bus. - </p></li></ul></div><p> - </p></div></div><div class="sect1" title="Concepts"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="concepts"></a>Concepts</h2></div></div></div><p> - Some basic concepts apply no matter what application framework you're - using to write a D-Bus application. The exact code you write will be - different for GLib vs. Qt vs. Python applications, however. - </p><p> - Here is a diagram (<a class="ulink" href="diagram.png" target="_top">png</a> <a class="ulink" href="diagram.svg" target="_top">svg</a>) that may help you visualize the concepts - that follow. - </p><div class="sect2" title="Native Objects and Object Paths"><div class="titlepage"><div><div><h3 class="title"><a name="objects"></a>Native Objects and Object Paths</h3></div></div></div><p> - Your programming framework probably defines what an "object" is like; - usually with a base class. For example: java.lang.Object, GObject, QObject, - python's base Object, or whatever. Let's call this a <em class="firstterm">native object</em>. - </p><p> - The low-level D-Bus protocol, and corresponding libdbus API, does not care about native objects. - However, it provides a concept called an - <em class="firstterm">object path</em>. The idea of an object path is that - higher-level bindings can name native object instances, and allow remote applications - to refer to them. - </p><p> - The object path - looks like a filesystem path, for example an object could be - named <code class="literal">/org/kde/kspread/sheets/3/cells/4/5</code>. - Human-readable paths are nice, but you are free to create an - object named <code class="literal">/com/mycompany/c5yo817y0c1y1c5b</code> - if it makes sense for your application. - </p><p> - Namespacing object paths is smart, by starting them with the components - of a domain name you own (e.g. <code class="literal">/org/kde</code>). This - keeps different code modules in the same process from stepping - on one another's toes. - </p></div><div class="sect2" title="Methods and Signals"><div class="titlepage"><div><div><h3 class="title"><a name="members"></a>Methods and Signals</h3></div></div></div><p> - Each object has <em class="firstterm">members</em>; the two kinds of member - are <em class="firstterm">methods</em> and - <em class="firstterm">signals</em>. Methods are operations that can be - invoked on an object, with optional input (aka arguments or "in - parameters") and output (aka return values or "out parameters"). - Signals are broadcasts from the object to any interested observers - of the object; signals may contain a data payload. - </p><p> - Both methods and signals are referred to by name, such as - "Frobate" or "OnClicked". - </p></div><div class="sect2" title="Interfaces"><div class="titlepage"><div><div><h3 class="title"><a name="interfaces"></a>Interfaces</h3></div></div></div><p> - Each object supports one or more <em class="firstterm">interfaces</em>. - Think of an interface as a named group of methods and signals, - just as it is in GLib or Qt or Java. Interfaces define the - <span class="emphasis"><em>type</em></span> of an object instance. - </p><p> - DBus identifies interfaces with a simple namespaced string, - something like <code class="literal">org.freedesktop.Introspectable</code>. - Most bindings will map these interface names directly to - the appropriate programming language construct, for example - to Java interfaces or C++ pure virtual classes. - </p></div><div class="sect2" title="Proxies"><div class="titlepage"><div><div><h3 class="title"><a name="proxies"></a>Proxies</h3></div></div></div><p> - A <em class="firstterm">proxy object</em> is a convenient native object created to - represent a remote object in another process. The low-level DBus API involves manually creating - a method call message, sending it, then manually receiving and processing - the method reply message. Higher-level bindings provide proxies as an alternative. - Proxies look like a normal native object; but when you invoke a method on the proxy - object, the binding converts it into a DBus method call message, waits for the reply - message, unpacks the return value, and returns it from the native method.. - </p><p> - In pseudocode, programming without proxies might look like this: - </p><pre class="programlisting"> - Message message = new Message("/remote/object/path", "MethodName", arg1, arg2); - Connection connection = getBusConnection(); - connection.send(message); - Message reply = connection.waitForReply(message); - if (reply.isError()) { - - } else { - Object returnValue = reply.getReturnValue(); - } - </pre><p> - </p><p> - Programming with proxies might look like this: - </p><pre class="programlisting"> - Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path"); - Object returnValue = proxy.MethodName(arg1, arg2); - </pre><p> - </p></div><div class="sect2" title="Bus Names"><div class="titlepage"><div><div><h3 class="title"><a name="bus-names"></a>Bus Names</h3></div></div></div><p> - When each application connects to the bus daemon, the daemon immediately - assigns it a name, called the <em class="firstterm">unique connection name</em>. - A unique name begins with a ':' (colon) character. These names are never - reused during the lifetime of the bus daemon - that is, you know - a given name will always refer to the same application. - An example of a unique name might be - <code class="literal">:34-907</code>. The numbers after the colon have - no meaning other than their uniqueness. - </p><p> - When a name is mapped - to a particular application's connection, that application is said to - <em class="firstterm">own</em> that name. - </p><p> - Applications may ask to own additional <em class="firstterm">well-known - names</em>. For example, you could write a specification to - define a name called <code class="literal">com.mycompany.TextEditor</code>. - Your definition could specify that to own this name, an application - should have an object at the path - <code class="literal">/com/mycompany/TextFileManager</code> supporting the - interface <code class="literal">org.freedesktop.FileHandler</code>. - </p><p> - Applications could then send messages to this bus name, - object, and interface to execute method calls. - </p><p> - You could think of the unique names as IP addresses, and the - well-known names as domain names. So - <code class="literal">com.mycompany.TextEditor</code> might map to something like - <code class="literal">:34-907</code> just as <code class="literal">mycompany.com</code> maps - to something like <code class="literal">192.168.0.5</code>. - </p><p> - Names have a second important use, other than routing messages. They - are used to track lifecycle. When an application exits (or crashes), its - connection to the message bus will be closed by the operating system - kernel. The message bus then sends out notification messages telling - remaining applications that the application's names have lost their - owner. By tracking these notifications, your application can reliably - monitor the lifetime of other applications. - </p><p> - Bus names can also be used to coordinate single-instance applications. - If you want to be sure only one - <code class="literal">com.mycompany.TextEditor</code> application is running for - example, have the text editor application exit if the bus name already - has an owner. - </p></div><div class="sect2" title="Addresses"><div class="titlepage"><div><div><h3 class="title"><a name="addresses"></a>Addresses</h3></div></div></div><p> - Applications using D-Bus are either servers or clients. A server - listens for incoming connections; a client connects to a server. Once - the connection is established, it is a symmetric flow of messages; the - client-server distinction only matters when setting up the - connection. - </p><p> - If you're using the bus daemon, as you probably are, your application - will be a client of the bus daemon. That is, the bus daemon listens - for connections and your application initiates a connection to the bus - daemon. - </p><p> - A D-Bus <em class="firstterm">address</em> specifies where a server will - listen, and where a client will connect. For example, the address - <code class="literal">unix:path=/tmp/abcdef</code> specifies that the server will - listen on a UNIX domain socket at the path - <code class="literal">/tmp/abcdef</code> and the client will connect to that - socket. An address can also specify TCP/IP sockets, or any other - transport defined in future iterations of the D-Bus specification. - </p><p> - When using D-Bus with a message bus daemon, - libdbus automatically discovers the address of the per-session bus - daemon by reading an environment variable. It discovers the - systemwide bus daemon by checking a well-known UNIX domain socket path - (though you can override this address with an environment variable). - </p><p> - If you're using D-Bus without a bus daemon, it's up to you to - define which application will be the server and which will be - the client, and specify a mechanism for them to agree on - the server's address. This is an unusual case. - </p></div><div class="sect2" title="Big Conceptual Picture"><div class="titlepage"><div><div><h3 class="title"><a name="bigpicture"></a>Big Conceptual Picture</h3></div></div></div><p> - Pulling all these concepts together, to specify a particular - method call on a particular object instance, a number of - nested components have to be named: - </p><pre class="programlisting"> - Address -> [Bus Name] -> Path -> Interface -> Method - </pre><p> - The bus name is in brackets to indicate that it's optional -- you only - provide a name to route the method call to the right application - when using the bus daemon. If you have a direct connection to another - application, bus names aren't used; there's no bus daemon. - </p><p> - The interface is also optional, primarily for historical - reasons; DCOP does not require specifying the interface, - instead simply forbidding duplicate method names - on the same object instance. D-Bus will thus let you - omit the interface, but if your method name is ambiguous - it is undefined which method will be invoked. - </p></div><div class="sect2" title="Messages - Behind the Scenes"><div class="titlepage"><div><div><h3 class="title"><a name="messages"></a>Messages - Behind the Scenes</h3></div></div></div><p> - D-Bus works by sending messages between processes. If you're using - a sufficiently high-level binding, you may never work with messages directly. - </p><p> - There are 4 message types: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Method call messages ask to invoke a method - on an object. - </p></li><li class="listitem"><p> - Method return messages return the results - of invoking a method. - </p></li><li class="listitem"><p> - Error messages return an exception caused by - invoking a method. - </p></li><li class="listitem"><p> - Signal messages are notifications that a given signal - has been emitted (that an event has occurred). - You could also think of these as "event" messages. - </p></li></ul></div><p> - </p><p> - A method call maps very simply to messages: you send a method call - message, and receive either a method return message or an error message - in reply. - </p><p> - Each message has a <em class="firstterm">header</em>, including <em class="firstterm">fields</em>, - and a <em class="firstterm">body</em>, including <em class="firstterm">arguments</em>. You can think - of the header as the routing information for the message, and the body as the payload. - Header fields might include the sender bus name, destination bus name, method or signal name, - and so forth. One of the header fields is a <em class="firstterm">type signature</em> describing the - values found in the body. For example, the letter "i" means "32-bit integer" so the signature - "ii" means the payload has two 32-bit integers. - </p></div><div class="sect2" title="Calling a Method - Behind the Scenes"><div class="titlepage"><div><div><h3 class="title"><a name="callprocedure"></a>Calling a Method - Behind the Scenes</h3></div></div></div><p> - A method call in DBus consists of two messages; a method call message sent from process A to process B, - and a matching method reply message sent from process B to process A. Both the call and the reply messages - are routed through the bus daemon. The caller includes a different serial number in each call message, and the - reply message includes this number to allow the caller to match replies to calls. - </p><p> - The call message will contain any arguments to the method. - The reply message may indicate an error, or may contain data returned by the method. - </p><p> - A method invocation in DBus happens as follows: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The language binding may provide a proxy, such that invoking a method on - an in-process object invokes a method on a remote object in another process. If so, the - application calls a method on the proxy, and the proxy - constructs a method call message to send to the remote process. - </p></li><li class="listitem"><p> - For more low-level APIs, the application may construct a method call message itself, without - using a proxy. - </p></li><li class="listitem"><p> - In either case, the method call message contains: a bus name belonging to the remote process; the name of the method; - the arguments to the method; an object path inside the remote process; and optionally the name of the - interface that specifies the method. - </p></li><li class="listitem"><p> - The method call message is sent to the bus daemon. - </p></li><li class="listitem"><p> - The bus daemon looks at the destination bus name. If a process owns that name, - the bus daemon forwards the method call to that process. Otherwise, the bus daemon - creates an error message and sends it back as the reply to the method call message. - </p></li><li class="listitem"><p> - The receiving process unpacks the method call message. In a simple low-level API situation, it - may immediately run the method and send a method reply message to the bus daemon. - When using a high-level binding API, the binding might examine the object path, interface, - and method name, and convert the method call message into an invocation of a method on - a native object (GObject, java.lang.Object, QObject, etc.), then convert the return - value from the native method into a method reply message. - </p></li><li class="listitem"><p> - The bus daemon receives the method reply message and sends it to the process that - made the method call. - </p></li><li class="listitem"><p> - The process that made the method call looks at the method reply and makes use of any - return values included in the reply. The reply may also indicate that an error occurred. - When using a binding, the method reply message may be converted into the return value of - of a proxy method, or into an exception. - </p></li></ul></div><p> - </p><p> - The bus daemon never reorders messages. That is, if you send two method call messages to the same recipient, - they will be received in the order they were sent. The recipient is not required to reply to the calls - in order, however; for example, it may process each method call in a separate thread, and return reply messages - in an undefined order depending on when the threads complete. Method calls have a unique serial - number used by the method caller to match reply messages to call messages. - </p></div><div class="sect2" title="Emitting a Signal - Behind the Scenes"><div class="titlepage"><div><div><h3 class="title"><a name="signalprocedure"></a>Emitting a Signal - Behind the Scenes</h3></div></div></div><p> - A signal in DBus consists of a single message, sent by one process to any number of other processes. - That is, a signal is a unidirectional broadcast. The signal may contain arguments (a data payload), but - because it is a broadcast, it never has a "return value." Contrast this with a method call - (see <a class="xref" href="#callprocedure" title="Calling a Method - Behind the Scenes">the section called “Calling a Method - Behind the Scenes”</a>) where the method call message has a matching method reply message. - </p><p> - The emitter (aka sender) of a signal has no knowledge of the signal recipients. Recipients register - with the bus daemon to receive signals based on "match rules" - these rules would typically include the sender and - the signal name. The bus daemon sends each signal only to recipients who have expressed interest in that - signal. - </p><p> - A signal in DBus happens as follows: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - A signal message is created and sent to the bus daemon. When using the low-level API this may be - done manually, with certain bindings it may be done for you by the binding when a native object - emits a native signal or event. - </p></li><li class="listitem"><p> - The signal message contains the name of the interface that specifies the signal; - the name of the signal; the bus name of the process sending the signal; and - any arguments - </p></li><li class="listitem"><p> - Any process on the message bus can register "match rules" indicating which signals it - is interested in. The bus has a list of registered match rules. - </p></li><li class="listitem"><p> - The bus daemon examines the signal and determines which processes are interested in it. - It sends the signal message to these processes. - </p></li><li class="listitem"><p> - Each process receiving the signal decides what to do with it; if using a binding, - the binding may choose to emit a native signal on a proxy object. If using the - low-level API, the process may just look at the signal sender and name and decide - what to do based on that. - </p></li></ul></div><p> - </p></div><div class="sect2" title="Introspection"><div class="titlepage"><div><div><h3 class="title"><a name="introspection"></a>Introspection</h3></div></div></div><p> - D-Bus objects may support the interface <code class="literal">org.freedesktop.DBus.Introspectable</code>. - This interface has one method <code class="literal">Introspect</code> which takes no arguments and returns - an XML string. The XML string describes the interfaces, methods, and signals of the object. - See the D-Bus specification for more details on this introspection format. - </p></div></div><div class="sect1" title="GLib API: Using Remote Objects"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="glib-client"></a>GLib API: Using Remote Objects</h2></div></div></div><p> - The GLib binding is defined in the header file - <code class="literal"><dbus/dbus-glib.h></code>. - </p><div class="sect2" title="D-Bus - GLib type mappings"><div class="titlepage"><div><div><h3 class="title"><a name="glib-typemappings"></a>D-Bus - GLib type mappings</h3></div></div></div><p> - The heart of the GLib bindings for D-Bus is the mapping it - provides between D-Bus "type signatures" and GLib types - (<code class="literal">GType</code>). The D-Bus type system is composed of - a number of "basic" types, along with several "container" types. - </p><div class="sect3" title="Basic type mappings"><div class="titlepage"><div><div><h4 class="title"><a name="glib-basic-typemappings"></a>Basic type mappings</h4></div></div></div><p> - Below is a list of the basic types, along with their associated - mapping to a <code class="literal">GType</code>. - </p><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th>D-Bus basic type</th><th>GType</th><th>Free function</th><th>Notes</th></tr></thead><tbody><tr><td><code class="literal">BYTE</code></td><td><code class="literal">G_TYPE_UCHAR</code></td><td> </td><td> </td></tr><tr><td><code class="literal">BOOLEAN</code></td><td><code class="literal">G_TYPE_BOOLEAN</code></td><td> </td><td> </td></tr><tr><td><code class="literal">INT16</code></td><td><code class="literal">G_TYPE_INT</code></td><td> </td><td>Will be changed to a <code class="literal">G_TYPE_INT16</code> once GLib has it</td></tr><tr><td><code class="literal">UINT16</code></td><td><code class="literal">G_TYPE_UINT</code></td><td> </td><td>Will be changed to a <code class="literal">G_TYPE_UINT16</code> once GLib has it</td></tr><tr><td><code class="literal">INT32</code></td><td><code class="literal">G_TYPE_INT</code></td><td> </td><td>Will be changed to a <code class="literal">G_TYPE_INT32</code> once GLib has it</td></tr><tr><td><code class="literal">UINT32</code></td><td><code class="literal">G_TYPE_UINT</code></td><td> </td><td>Will be changed to a <code class="literal">G_TYPE_UINT32</code> once GLib has it</td></tr><tr><td><code class="literal">INT64</code></td><td><code class="literal">G_TYPE_GINT64</code></td><td> </td><td> </td></tr><tr><td><code class="literal">UINT64</code></td><td><code class="literal">G_TYPE_GUINT64</code></td><td> </td><td> </td></tr><tr><td><code class="literal">DOUBLE</code></td><td><code class="literal">G_TYPE_DOUBLE</code></td><td> </td><td> </td></tr><tr><td><code class="literal">STRING</code></td><td><code class="literal">G_TYPE_STRING</code></td><td><code class="literal">g_free</code></td><td> </td></tr><tr><td><code class="literal">OBJECT_PATH</code></td><td><code class="literal">DBUS_TYPE_G_PROXY</code></td><td><code class="literal">g_object_unref</code></td><td>The returned proxy does not have an interface set; use <code class="literal">dbus_g_proxy_set_interface</code> to invoke methods</td></tr></tbody></table></div><p> - As you can see, the basic mapping is fairly straightforward. - </p></div><div class="sect3" title="Container type mappings"><div class="titlepage"><div><div><h4 class="title"><a name="glib-container-typemappings"></a>Container type mappings</h4></div></div></div><p> - The D-Bus type system also has a number of "container" - types, such as <code class="literal">DBUS_TYPE_ARRAY</code> and - <code class="literal">DBUS_TYPE_STRUCT</code>. The D-Bus type system - is fully recursive, so one can for example have an array of - array of strings (i.e. type signature - <code class="literal">aas</code>). - </p><p> - However, not all of these types are in common use; for - example, at the time of this writing the author knows of no - one using <code class="literal">DBUS_TYPE_STRUCT</code>, or a - <code class="literal">DBUS_TYPE_ARRAY</code> containing any non-basic - type. The approach the GLib bindings take is pragmatic; try - to map the most common types in the most obvious way, and - let using less common and more complex types be less - "natural". - </p><p> - First, D-Bus type signatures which have an "obvious" - corresponding built-in GLib type are mapped using that type: - </p><div class="informaltable"><table border="1"><colgroup><col><col><col><col><col><col></colgroup><thead><tr><th>D-Bus type signature</th><th>Description</th><th>GType</th><th>C typedef</th><th>Free function</th><th>Notes</th></tr></thead><tbody><tr><td><code class="literal">as</code></td><td>Array of strings</td><td><code class="literal">G_TYPE_STRV</code></td><td><code class="literal">char **</code></td><td><code class="literal">g_strfreev</code></td><td> </td></tr><tr><td><code class="literal">v</code></td><td>Generic value container</td><td><code class="literal">G_TYPE_VALUE</code></td><td><code class="literal">GValue *</code></td><td><code class="literal">g_value_unset</code></td><td>The calling conventions for values expect that method callers have allocated return values; see below.</td></tr></tbody></table></div><p> - </p><p> - The next most common recursive type signatures are arrays of - basic values. The most obvious mapping for arrays of basic - types is a <code class="literal">GArray</code>. Now, GLib does not - provide a builtin <code class="literal">GType</code> for - <code class="literal">GArray</code>. However, we actually need more than - that - we need a "parameterized" type which includes the - contained type. Why we need this we will see below. - </p><p> - The approach taken is to create these types in the D-Bus GLib - bindings; however, there is nothing D-Bus specific about them. - In the future, we hope to include such "fundamental" types in GLib - itself. - </p><div class="informaltable"><table border="1"><colgroup><col><col><col><col><col><col></colgroup><thead><tr><th>D-Bus type signature</th><th>Description</th><th>GType</th><th>C typedef</th><th>Free function</th><th>Notes</th></tr></thead><tbody><tr><td><code class="literal">ay</code></td><td>Array of bytes</td><td><code class="literal">DBUS_TYPE_G_BYTE_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr><tr><td><code class="literal">au</code></td><td>Array of uint</td><td><code class="literal">DBUS_TYPE_G_UINT_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr><tr><td><code class="literal">ai</code></td><td>Array of int</td><td><code class="literal">DBUS_TYPE_G_INT_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr><tr><td><code class="literal">ax</code></td><td>Array of int64</td><td><code class="literal">DBUS_TYPE_G_INT64_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr><tr><td><code class="literal">at</code></td><td>Array of uint64</td><td><code class="literal">DBUS_TYPE_G_UINT64_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr><tr><td><code class="literal">ad</code></td><td>Array of double</td><td><code class="literal">DBUS_TYPE_G_DOUBLE_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr><tr><td><code class="literal">ab</code></td><td>Array of boolean</td><td><code class="literal">DBUS_TYPE_G_BOOLEAN_ARRAY</code></td><td><code class="literal">GArray *</code></td><td>g_array_free</td><td> </td></tr></tbody></table></div><p> - </p><p> - D-Bus also includes a special type DBUS_TYPE_DICT_ENTRY which - is only valid in arrays. It's intended to be mapped to a "dictionary" - type by bindings. The obvious GLib mapping here is GHashTable. Again, - however, there is no builtin <code class="literal">GType</code> for a GHashTable. - Moreover, just like for arrays, we need a parameterized type so that - the bindings can communiate which types are contained in the hash table. - </p><p> - At present, only strings are supported. Work is in progress to - include more types. - </p><div class="informaltable"><table border="1"><colgroup><col><col><col><col><col><col></colgroup><thead><tr><th>D-Bus type signature</th><th>Description</th><th>GType</th><th>C typedef</th><th>Free function</th><th>Notes</th></tr></thead><tbody><tr><td><code class="literal">a{ss}</code></td><td>Dictionary mapping strings to strings</td><td><code class="literal">DBUS_TYPE_G_STRING_STRING_HASHTABLE</code></td><td><code class="literal">GHashTable *</code></td><td>g_hash_table_destroy</td><td> </td></tr></tbody></table></div><p> - </p></div><div class="sect3" title="Arbitrarily recursive type mappings"><div class="titlepage"><div><div><h4 class="title"><a name="glib-generic-typemappings"></a>Arbitrarily recursive type mappings</h4></div></div></div><p> - Finally, it is possible users will want to write or invoke D-Bus - methods which have arbitrarily complex type signatures not - directly supported by these bindings. For this case, we have a - <code class="literal">DBusGValue</code> which acts as a kind of special - variant value which may be iterated over manually. The - <code class="literal">GType</code> associated is - <code class="literal">DBUS_TYPE_G_VALUE</code>. - </p><p> - TODO insert usage of <code class="literal">DBUS_TYPE_G_VALUE</code> here. - </p></div></div><div class="sect2" title="A sample program"><div class="titlepage"><div><div><h3 class="title"><a name="sample-program-1"></a>A sample program</h3></div></div></div><p>Here is a D-Bus program using the GLib bindings. -</p><pre class="programlisting"> -int -main (int argc, char **argv) -{ - DBusGConnection *connection; - GError *error; - DBusGProxy *proxy; - char **name_list; - char **name_list_ptr; - - g_type_init (); - - error = NULL; - connection = dbus_g_bus_get (DBUS_BUS_SESSION, - &error); - if (connection == NULL) - { - g_printerr ("Failed to open connection to bus: %s\n", - error->message); - g_error_free (error); - exit (1); - } - - /* Create a proxy object for the "bus driver" (name "org.freedesktop.DBus") */ - - proxy = dbus_g_proxy_new_for_name (connection, - DBUS_SERVICE_DBUS, - DBUS_PATH_DBUS, - DBUS_INTERFACE_DBUS); - - /* Call ListNames method, wait for reply */ - error = NULL; - if (!dbus_g_proxy_call (proxy, "ListNames", &error, G_TYPE_INVALID, - G_TYPE_STRV, &name_list, G_TYPE_INVALID)) - { - /* Just do demonstrate remote exceptions versus regular GError */ - if (error->domain == DBUS_GERROR && error->code == DBUS_GERROR_REMOTE_EXCEPTION) - g_printerr ("Caught remote method exception %s: %s", - dbus_g_error_get_name (error), - error->message); - else - g_printerr ("Error: %s\n", error->message); - g_error_free (error); - exit (1); - } - - /* Print the results */ - - g_print ("Names on the message bus:\n"); - - for (name_list_ptr = name_list; *name_list_ptr; name_list_ptr++) - { - g_print (" %s\n", *name_list_ptr); - } - g_strfreev (name_list); - - g_object_unref (proxy); - - return 0; -} -</pre><p> - </p></div><div class="sect2" title="Program initalization"><div class="titlepage"><div><div><h3 class="title"><a name="glib-program-setup"></a>Program initalization</h3></div></div></div><p> - A connection to the bus is acquired using - <code class="literal">dbus_g_bus_get</code>. Next, a proxy - is created for the object "/org/freedesktop/DBus" with - interface <code class="literal">org.freedesktop.DBus</code> - on the service <code class="literal">org.freedesktop.DBus</code>. - This is a proxy for the message bus itself. - </p></div><div class="sect2" title="Understanding method invocation"><div class="titlepage"><div><div><h3 class="title"><a name="glib-method-invocation"></a>Understanding method invocation</h3></div></div></div><p> - You have a number of choices for method invocation. First, as - used above, <code class="literal">dbus_g_proxy_call</code> sends a - method call to the remote object, and blocks until a reply is - recieved. The outgoing arguments are specified in the varargs - array, terminated with <code class="literal">G_TYPE_INVALID</code>. - Next, pointers to return values are specified, followed again - by <code class="literal">G_TYPE_INVALID</code>. - </p><p> - To invoke a method asynchronously, use - <code class="literal">dbus_g_proxy_begin_call</code>. This returns a - <code class="literal">DBusGPendingCall</code> object; you may then set a - notification function using - <code class="literal">dbus_g_pending_call_set_notify</code>. - </p></div><div class="sect2" title="Connecting to object signals"><div class="titlepage"><div><div><h3 class="title"><a name="glib-signal-connection"></a>Connecting to object signals</h3></div></div></div><p> - You may connect to signals using - <code class="literal">dbus_g_proxy_add_signal</code> and - <code class="literal">dbus_g_proxy_connect_signal</code>. You must - invoke <code class="literal">dbus_g_proxy_add_signal</code> to specify - the signature of your signal handlers; you may then invoke - <code class="literal">dbus_g_proxy_connect_signal</code> multiple times. - </p><p> - Note that it will often be the case that there is no builtin - marshaller for the type signature of a remote signal. In that - case, you must generate a marshaller yourself by using - <span class="application">glib-genmarshal</span>, and then register - it using <code class="literal">dbus_g_object_register_marshaller</code>. - </p></div><div class="sect2" title="Error handling and remote exceptions"><div class="titlepage"><div><div><h3 class="title"><a name="glib-error-handling"></a>Error handling and remote exceptions</h3></div></div></div><p> - All of the GLib binding methods such as - <code class="literal">dbus_g_proxy_end_call</code> return a - <code class="literal">GError</code>. This <code class="literal">GError</code> can - represent two different things: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - An internal D-Bus error, such as an out-of-memory - condition, an I/O error, or a network timeout. Errors - generated by the D-Bus library itself have the domain - <code class="literal">DBUS_GERROR</code>, and a corresponding code - such as <code class="literal">DBUS_GERROR_NO_MEMORY</code>. It will - not be typical for applications to handle these errors - specifically. - </p></li><li class="listitem"><p> - A remote D-Bus exception, thrown by the peer, bus, or - service. D-Bus remote exceptions have both a textual - "name" and a "message". The GLib bindings store this - information in the <code class="literal">GError</code>, but some - special rules apply. - </p><p> - The set error will have the domain - <code class="literal">DBUS_GERROR</code> as above, and will also - have the code - <code class="literal">DBUS_GERROR_REMOTE_EXCEPTION</code>. In order - to access the remote exception name, you must use a - special accessor, such as - <code class="literal">dbus_g_error_has_name</code> or - <code class="literal">dbus_g_error_get_name</code>. The remote - exception detailed message is accessible via the regular - GError <code class="literal">message</code> member. - </p></li></ul></div><p> - </p></div><div class="sect2" title="More examples of method invocation"><div class="titlepage"><div><div><h3 class="title"><a name="glib-more-examples"></a>More examples of method invocation</h3></div></div></div><div class="sect3" title="Sending an integer and string, receiving an array of bytes"><div class="titlepage"><div><div><h4 class="title"><a name="glib-sending-stuff"></a>Sending an integer and string, receiving an array of bytes</h4></div></div></div><p> -</p><pre class="programlisting"> - GArray *arr; - - error = NULL; - if (!dbus_g_proxy_call (proxy, "Foobar", &error, - G_TYPE_INT, 42, G_TYPE_STRING, "hello", - G_TYPE_INVALID, - DBUS_TYPE_G_UCHAR_ARRAY, &arr, G_TYPE_INVALID)) - { - /* Handle error */ - } - g_assert (arr != NULL); - printf ("got back %u values", arr->len); -</pre><p> - </p></div><div class="sect3" title="Sending a GHashTable"><div class="titlepage"><div><div><h4 class="title"><a name="glib-sending-hash"></a>Sending a GHashTable</h4></div></div></div><p> -</p><pre class="programlisting"> - GHashTable *hash = g_hash_table_new (g_str_hash, g_str_equal); - guint32 ret; - - g_hash_table_insert (hash, "foo", "bar"); - g_hash_table_insert (hash, "baz", "whee"); - - error = NULL; - if (!dbus_g_proxy_call (proxy, "HashSize", &error, - DBUS_TYPE_G_STRING_STRING_HASH, hash, G_TYPE_INVALID, - G_TYPE_UINT, &ret, G_TYPE_INVALID)) - { - /* Handle error */ - } - g_assert (ret == 2); - g_hash_table_destroy (hash); -</pre><p> - </p></div><div class="sect3" title="Receiving a boolean and a string"><div class="titlepage"><div><div><h4 class="title"><a name="glib-receiving-bool-int"></a>Receiving a boolean and a string</h4></div></div></div><p> -</p><pre class="programlisting"> - gboolean boolret; - char *strret; - - error = NULL; - if (!dbus_g_proxy_call (proxy, "GetStuff", &error, - G_TYPE_INVALID, - G_TYPE_BOOLEAN, &boolret, - G_TYPE_STRING, &strret, - G_TYPE_INVALID)) - { - /* Handle error */ - } - printf ("%s %s", boolret ? "TRUE" : "FALSE", strret); - g_free (strret); -</pre><p> - </p></div><div class="sect3" title="Sending two arrays of strings"><div class="titlepage"><div><div><h4 class="title"><a name="glib-sending-str-arrays"></a>Sending two arrays of strings</h4></div></div></div><p> -</p><pre class="programlisting"> - /* NULL terminate */ - char *strs_static[] = {"foo", "bar", "baz", NULL}; - /* Take pointer to array; cannot pass array directly */ - char **strs_static_p = strs_static; - char **strs_dynamic; - - strs_dynamic = g_new (char *, 4); - strs_dynamic[0] = g_strdup ("hello"); - strs_dynamic[1] = g_strdup ("world"); - strs_dynamic[2] = g_strdup ("!"); - /* NULL terminate */ - strs_dynamic[3] = NULL; - - error = NULL; - if (!dbus_g_proxy_call (proxy, "TwoStrArrays", &error, - G_TYPE_STRV, strs_static_p, - G_TYPE_STRV, strs_dynamic, - G_TYPE_INVALID, - G_TYPE_INVALID)) - { - /* Handle error */ - } - g_strfreev (strs_dynamic); -</pre><p> - </p></div><div class="sect3" title="Sending a boolean, receiving an array of strings"><div class="titlepage"><div><div><h4 class="title"><a name="glib-getting-str-array"></a>Sending a boolean, receiving an array of strings</h4></div></div></div><p> -</p><pre class="programlisting"> - char **strs; - char **strs_p; - gboolean blah; - - error = NULL; - blah = TRUE; - if (!dbus_g_proxy_call (proxy, "GetStrs", &error, - G_TYPE_BOOLEAN, blah, - G_TYPE_INVALID, - G_TYPE_STRV, &strs, - G_TYPE_INVALID)) - { - /* Handle error */ - } - for (strs_p = strs; *strs_p; strs_p++) - printf ("got string: \"%s\"", *strs_p); - g_strfreev (strs); -</pre><p> - </p></div><div class="sect3" title="Sending a variant"><div class="titlepage"><div><div><h4 class="title"><a name="glib-sending-variant"></a>Sending a variant</h4></div></div></div><p> -</p><pre class="programlisting"> - GValue val = {0, }; - - g_value_init (&val, G_TYPE_STRING); - g_value_set_string (&val, "hello world"); - - error = NULL; - if (!dbus_g_proxy_call (proxy, "SendVariant", &error, - G_TYPE_VALUE, &val, G_TYPE_INVALID, - G_TYPE_INVALID)) - { - /* Handle error */ - } - g_assert (ret == 2); - g_value_unset (&val); -</pre><p> - </p></div><div class="sect3" title="Receiving a variant"><div class="titlepage"><div><div><h4 class="title"><a name="glib-receiving-variant"></a>Receiving a variant</h4></div></div></div><p> -</p><pre class="programlisting"> - GValue val = {0, }; - - error = NULL; - if (!dbus_g_proxy_call (proxy, "GetVariant", &error, G_TYPE_INVALID, - G_TYPE_VALUE, &val, G_TYPE_INVALID)) - { - /* Handle error */ - } - if (G_VALUE_TYPE (&val) == G_TYPE_STRING) - printf ("%s\n", g_value_get_string (&val)); - else if (G_VALUE_TYPE (&val) == G_TYPE_INT) - printf ("%d\n", g_value_get_int (&val)); - else - ... - g_value_unset (&val); -</pre><p> - </p></div></div><div class="sect2" title="Generated Bindings"><div class="titlepage"><div><div><h3 class="title"><a name="glib-generated-bindings"></a>Generated Bindings</h3></div></div></div><p> - By using the Introspection XML files, convenient client-side bindings - can be automatically created to ease the use of a remote DBus object. - </p><p> - Here is a sample XML file which describes an object that exposes - one method, named <code class="literal">ManyArgs</code>. - </p><pre class="programlisting"> -<?xml version="1.0" encoding="UTF-8" ?> -<node name="/com/example/MyObject"> - <interface name="com.example.MyObject"> - <method name="ManyArgs"> - <arg type="u" name="x" direction="in" /> - <arg type="s" name="str" direction="in" /> - <arg type="d" name="trouble" direction="in" /> - <arg type="d" name="d_ret" direction="out" /> - <arg type="s" name="str_ret" direction="out" /> - </method> - </interface> -</node> -</pre><p> - </p><p> - Run <code class="literal">dbus-binding-tool --mode=glib-client - <em class="replaceable"><code>FILENAME</code></em> > - <em class="replaceable"><code>HEADER_NAME</code></em></code> to generate the header - file. For example: <span class="command"><strong>dbus-binding-tool --mode=glib-client - my-object.xml > my-object-bindings.h</strong></span>. This will generate - inline functions with the following prototypes: - </p><pre class="programlisting"> -/* This is a blocking call */ -gboolean -com_example_MyObject_many_args (DBusGProxy *proxy, const guint IN_x, - const char * IN_str, const gdouble IN_trouble, - gdouble* OUT_d_ret, char ** OUT_str_ret, - GError **error); - -/* This is a non-blocking call */ -DBusGProxyCall* -com_example_MyObject_many_args_async (DBusGProxy *proxy, const guint IN_x, - const char * IN_str, const gdouble IN_trouble, - com_example_MyObject_many_args_reply callback, - gpointer userdata); - -/* This is the typedef for the non-blocking callback */ -typedef void -(*com_example_MyObject_many_args_reply) -(DBusGProxy *proxy, gdouble OUT_d_ret, char * OUT_str_ret, - GError *error, gpointer userdata); -</pre><p> - The first argument in all functions is a <code class="literal">DBusGProxy - *</code>, which you should create with the usual - <code class="literal">dbus_g_proxy_new_*</code> functions. Following that are the - "in" arguments, and then either the "out" arguments and a - <code class="literal">GError *</code> for the synchronous (blocking) function, or - callback and user data arguments for the asynchronous (non-blocking) - function. The callback in the asynchronous function passes the - <code class="literal">DBusGProxy *</code>, the returned "out" arguments, an - <code class="literal">GError *</code> which is set if there was an error otherwise - <code class="literal">NULL</code>, and the user data. - </p><p> - As with the server-side bindings support (see <a class="xref" href="#glib-server" title="GLib API: Implementing Objects">the section called “GLib API: Implementing Objects”</a>), the exact behaviour of the client-side - bindings can be manipulated using "annotations". Currently the only - annotation used by the client bindings is - <code class="literal">org.freedesktop.DBus.GLib.NoReply</code>, which sets the - flag indicating that the client isn't expecting a reply to the method - call, so a reply shouldn't be sent. This is often used to speed up - rapid method calls where there are no "out" arguments, and not knowing - if the method succeeded is an acceptable compromise to half the traffic - on the bus. - </p></div></div><div class="sect1" title="GLib API: Implementing Objects"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="glib-server"></a>GLib API: Implementing Objects</h2></div></div></div><p> - At the moment, to expose a GObject via D-Bus, you must - write XML by hand which describes the methods exported - by the object. In the future, this manual step will - be obviated by the upcoming GLib introspection support. - </p><p> - Here is a sample XML file which describes an object that exposes - one method, named <code class="literal">ManyArgs</code>. -</p><pre class="programlisting"> -<?xml version="1.0" encoding="UTF-8" ?> - -<node name="/com/example/MyObject"> - - <interface name="com.example.MyObject"> - <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="my_object"/> - <method name="ManyArgs"> - <!-- This is optional, and in this case is redunundant --> - <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="my_object_many_args"/> - <arg type="u" name="x" direction="in" /> - <arg type="s" name="str" direction="in" /> - <arg type="d" name="trouble" direction="in" /> - <arg type="d" name="d_ret" direction="out" /> - <arg type="s" name="str_ret" direction="out" /> - </method> - </interface> -</node> -</pre><p> - </p><p> - This XML is in the same format as the D-Bus introspection XML - format. Except we must include an "annotation" which give the C - symbols corresponding to the object implementation prefix - (<code class="literal">my_object</code>). In addition, if particular - methods symbol names deviate from C convention - (i.e. <code class="literal">ManyArgs</code> -> - <code class="literal">many_args</code>), you may specify an annotation - giving the C symbol. - </p><p> - Once you have written this XML, run <code class="literal">dbus-binding-tool --mode=glib-server <em class="replaceable"><code>FILENAME</code></em> > <em class="replaceable"><code>HEADER_NAME</code></em>.</code> to - generate a header file. For example: <span class="command"><strong>dbus-binding-tool --mode=glib-server my-object.xml > my-object-glue.h</strong></span>. - </p><p> - Next, include the generated header in your program, and invoke - <code class="literal">dbus_g_object_class_install_info</code> in the class - initializer, passing the object class and "object info" included in the - header. For example: - </p><pre class="programlisting"> - dbus_g_object_type_install_info (COM_FOO_TYPE_MY_OBJECT, &com_foo_my_object_info); - </pre><p> - This should be done exactly once per object class. - </p><p> - To actually implement the method, just define a C function named e.g. - <code class="literal">my_object_many_args</code> in the same file as the info - header is included. At the moment, it is required that this function - conform to the following rules: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The function must return a value of type <code class="literal">gboolean</code>; - <code class="literal">TRUE</code> on success, and <code class="literal">FALSE</code> - otherwise. - </p></li><li class="listitem"><p> - The first parameter is a pointer to an instance of the object. - </p></li><li class="listitem"><p> - Following the object instance pointer are the method - input values. - </p></li><li class="listitem"><p> - Following the input values are pointers to return values. - </p></li><li class="listitem"><p> - The final parameter must be a <code class="literal">GError **</code>. - If the function returns <code class="literal">FALSE</code> for an - error, the error parameter must be initalized with - <code class="literal">g_set_error</code>. - </p></li></ul></div><p> - </p><p> - Finally, you can export an object using <code class="literal">dbus_g_connection_register_g_object</code>. For example: - </p><pre class="programlisting"> - dbus_g_connection_register_g_object (connection, - "/com/foo/MyObject", - obj); - </pre><p> - </p><div class="sect2" title="Server-side Annotations"><div class="titlepage"><div><div><h3 class="title"><a name="glib-annotations"></a>Server-side Annotations</h3></div></div></div><p> - There are several annotations that are used when generating the - server-side bindings. The most common annotation is - <code class="literal">org.freedesktop.DBus.GLib.CSymbol</code> but there are other - annotations which are often useful. - </p><div class="variablelist"><dl><dt><span class="term"><code class="literal">org.freedesktop.DBus.GLib.CSymbol</code></span></dt><dd><p> - This annotation is used to specify the C symbol names for - the various types (interface, method, etc), if it differs from the - name DBus generates. - </p></dd><dt><span class="term"><code class="literal">org.freedesktop.DBus.GLib.Async</code></span></dt><dd><p> - This annotation marks the method implementation as an - asynchronous function, which doesn't return a response straight - away but will send the response at some later point to complete - the call. This is used to implement non-blocking services where - method calls can take time. - </p><p> - When a method is asynchronous, the function prototype is - different. It is required that the function conform to the - following rules: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - The function must return a value of type <code class="literal">gboolean</code>; - <code class="literal">TRUE</code> on success, and <code class="literal">FALSE</code> - otherwise. TODO: the return value is currently ignored. - </p></li><li class="listitem"><p> - The first parameter is a pointer to an instance of the object. - </p></li><li class="listitem"><p> - Following the object instance pointer are the method - input values. - </p></li><li class="listitem"><p> - The final parameter must be a - <code class="literal">DBusGMethodInvocation *</code>. This is used - when sending the response message back to the client, by - calling <code class="literal">dbus_g_method_return</code> or - <code class="literal">dbus_g_method_return_error</code>. - </p></li></ul></div><p> - </p></dd><dt><span class="term"><code class="literal">org.freedesktop.DBus.GLib.Const</code></span></dt><dd><p>This attribute can only be applied to "out" - <code class="literal"><arg></code> nodes, and specifies that the - parameter isn't being copied when returned. For example, this - turns a 's' argument from a <code class="literal">char **</code> to a - <code class="literal">const char **</code>, and results in the argument not - being freed by DBus after the message is sent. - </p></dd><dt><span class="term"><code class="literal">org.freedesktop.DBus.GLib.ReturnVal</code></span></dt><dd><p> - This attribute can only be applied to "out" - <code class="literal"><arg></code> nodes, and alters the expected - function signature. It currently can be set to two values: - <code class="literal">""</code> or <code class="literal">"error"</code>. The - argument marked with this attribute is not returned via a - pointer argument, but by the function's return value. If the - attribute's value is the empty string, the <code class="literal">GError - *</code> argument is also omitted so there is no standard way - to return an error value. This is very useful for interfacing - with existing code, as it is possible to match existing APIs. - If the attribute's value is <code class="literal">"error"</code>, then the - final argument is a <code class="literal">GError *</code> as usual. - </p><p> - Some examples to demonstrate the usage. This introspection XML: - </p><pre class="programlisting"> -<method name="Increment"> - <arg type="u" name="x" /> - <arg type="u" direction="out" /> -</method> - </pre><p> - Expects the following function declaration: - </p><pre class="programlisting"> -gboolean -my_object_increment (MyObject *obj, gint32 x, gint32 *ret, GError **error); - </pre><p> - </p><p> - This introspection XML: - </p><pre class="programlisting"> -<method name="IncrementRetval"> - <arg type="u" name="x" /> - <arg type="u" direction="out" > - <annotation name="org.freedesktop.DBus.GLib.ReturnVal" value=""/> - </arg> -</method> - </pre><p> - Expects the following function declaration: - </p><pre class="programlisting"> -gint32 -my_object_increment_retval (MyObject *obj, gint32 x) - </pre><p> - </p><p> - This introspection XML: - </p><pre class="programlisting"> -<method name="IncrementRetvalError"> - <arg type="u" name="x" /> - <arg type="u" direction="out" > - <annotation name="org.freedesktop.DBus.GLib.ReturnVal" value="error"/> - </arg> -</method> - </pre><p> - Expects the following function declaration: - </p><pre class="programlisting"> -gint32 -my_object_increment_retval_error (MyObject *obj, gint32 x, GError **error) - </pre><p> - </p></dd></dl></div><p> - </p></div></div><div class="sect1" title="Python API"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="python-client"></a>Python API</h2></div></div></div><p> - The Python API, dbus-python, is now documented separately in - <a class="ulink" href="http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html" target="_top">the dbus-python tutorial</a> (also available in doc/tutorial.txt, - and doc/tutorial.html if built with python-docutils, in the dbus-python - source distribution). - </p></div><div class="sect1" title="Qt API: Using Remote Objects"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="qt-client"></a>Qt API: Using Remote Objects</h2></div></div></div><p> - - The Qt bindings are not yet documented. - - </p></div><div class="sect1" title="Qt API: Implementing Objects"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="qt-server"></a>Qt API: Implementing Objects</h2></div></div></div><p> - The Qt bindings are not yet documented. - </p></div></div></body></html> diff --git a/doc/dbus-uuidgen.1 b/doc/dbus-uuidgen.1 deleted file mode 100644 index 8ed8dd20..00000000 --- a/doc/dbus-uuidgen.1 +++ /dev/null @@ -1,89 +0,0 @@ -.\" -.\" dbus\-uuidgen manual page. -.\" Copyright (C) 2006 Red Hat, Inc. -.\" -.TH dbus\-uuidgen 1 -.SH NAME -dbus\-uuidgen \- Utility to generate UUIDs -.SH SYNOPSIS -.PP -.B dbus\-uuidgen [\-\-version] [\-\-ensure[=FILENAME]] [\-\-get[=FILENAME]] - -.SH DESCRIPTION - -The \fIdbus\-uuidgen\fP command generates or reads a universally unique ID. - -.PP -Note that the D\-Bus UUID has no relationship to RFC 4122 and does not generate -UUIDs compatible with that spec. Many systems have a separate command -for that (often called "uuidgen"). - -.PP -See http://www.freedesktop.org/software/dbus/ for more information -about D\-Bus. - -.PP -The primary usage of \fIdbus\-uuidgen\fP is to run in the post\-install -script of a D\-Bus package like this: -.nf - dbus\-uuidgen \-\-ensure -.fi - -.PP -This will ensure that /var/lib/dbus/machine\-id exists and has the uuid in it. -It won't overwrite an existing uuid, since this id should remain fixed -for a single machine until the next reboot at least. - -.PP -The important properties of the machine UUID are that 1) it remains -unchanged until the next reboot and 2) it is different for any two -running instances of the OS kernel. That is, if two processes see the -same UUID, they should also see the same shared memory, UNIX domain -sockets, local X displays, localhost.localdomain resolution, process -IDs, and so forth. - -.PP -If you run \fIdbus\-uuidgen\fP with no options it just prints a new uuid made -up out of thin air. - -.PP -If you run it with \-\-get, it prints the machine UUID by default, or -the UUID in the specified file if you specify a file. - -.PP -If you try to change an existing machine\-id on a running system, it will -probably result in bad things happening. Don't try to change this file. Also, -don't make it the same on two different systems; it needs to be different -anytime there are two different kernels running. - -.PP -The UUID should be different on two different virtual machines, -because there are two different kernels. - -.SH OPTIONS -The following options are supported: -.TP -.I "\-\-get[=FILENAME]" -If a filename is not given, defaults to localstatedir/lib/dbus/machine\-id -(localstatedir is usually /var). If this file exists and is valid, the -uuid in the file is printed on stdout. Otherwise, the command exits -with a nonzero status. - -.TP -.I "\-\-ensure[=FILENAME]" -If a filename is not given, defaults to localstatedir/lib/dbus/machine\-id -(localstatedir is usually /var). If this file exists then it will be -validated, and a failure code returned if it contains the wrong thing. -If the file does not exist, it will be created with a new uuid in it. -On success, prints no output. - -.TP -.I "\-\-version" -Print the version of dbus\-uuidgen - -.SH AUTHOR -See http://www.freedesktop.org/software/dbus/doc/AUTHORS - -.SH BUGS -Please send bug reports to the D\-Bus mailing list or bug tracker, -see http://www.freedesktop.org/software/dbus/ diff --git a/doc/dbus-uuidgen.1.xml.in b/doc/dbus-uuidgen.1.xml.in new file mode 100644 index 00000000..fbd26812 --- /dev/null +++ b/doc/dbus-uuidgen.1.xml.in @@ -0,0 +1,126 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"> +<refentry id='dbusuuidgen1'> + +<!-- dbus\-uuidgen manual page. + Copyright (C) 2006 Red Hat, Inc. --> + +<refmeta> +<refentrytitle>dbus-uuidgen</refentrytitle> +<manvolnum>1</manvolnum> +<refmiscinfo class="manual">User Commands</refmiscinfo> +<refmiscinfo class="source">D-Bus</refmiscinfo> +<refmiscinfo class="version">@DBUS_VERSION@</refmiscinfo> +</refmeta> +<refnamediv> +<refname>dbus-uuidgen</refname> +<refpurpose>Utility to generate UUIDs</refpurpose> +</refnamediv> +<!-- body begins here --> +<refsynopsisdiv id='synopsis'> +<cmdsynopsis> + <command>dbus-uuidgen</command> <arg choice='opt'>--version </arg> + <arg choice='opt'><arg choice='plain'>--ensure </arg><arg choice='opt'><replaceable>=FILENAME</replaceable></arg></arg> + <arg choice='opt'><arg choice='plain'>--get </arg><arg choice='opt'><replaceable>=FILENAME</replaceable></arg></arg> + <sbr/> +</cmdsynopsis> +</refsynopsisdiv> + + +<refsect1 id='description'><title>DESCRIPTION</title> +<para>The <command>dbus-uuidgen</command> command generates or reads a universally unique ID.</para> + + +<para>Note that the D-Bus UUID has no relationship to RFC 4122 and does not generate +UUIDs compatible with that spec. Many systems have a separate command +for that (often called "uuidgen").</para> + + +<para>See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information +about D-Bus.</para> + + +<para>The primary usage of <command>dbus-uuidgen</command> is to run in the post-install +script of a D-Bus package like this:</para> +<literallayout remap='.nf'> + dbus-uuidgen --ensure +</literallayout> <!-- .fi --> + + +<para>This will ensure that /var/lib/dbus/machine-id exists and has the uuid in it. +It won't overwrite an existing uuid, since this id should remain fixed +for a single machine until the next reboot at least.</para> + + +<para>The important properties of the machine UUID are that 1) it remains +unchanged until the next reboot and 2) it is different for any two +running instances of the OS kernel. That is, if two processes see the +same UUID, they should also see the same shared memory, UNIX domain +sockets, local X displays, localhost.localdomain resolution, process +IDs, and so forth.</para> + + +<para>If you run <command>dbus-uuidgen</command> with no options it just prints a new uuid made +up out of thin air.</para> + + +<para>If you run it with --get, it prints the machine UUID by default, or +the UUID in the specified file if you specify a file.</para> + + +<para>If you try to change an existing machine-id on a running system, it will +probably result in bad things happening. Don't try to change this file. Also, +don't make it the same on two different systems; it needs to be different +anytime there are two different kernels running.</para> + + +<para>The UUID should be different on two different virtual machines, +because there are two different kernels.</para> + +</refsect1> + +<refsect1 id='options'><title>OPTIONS</title> +<para>The following options are supported:</para> +<variablelist remap='TP'> + <varlistentry> + <term><option>--get[=FILENAME]</option></term> + <listitem> +<para>If a filename is not given, defaults to localstatedir/lib/dbus/machine-id +(localstatedir is usually /var). If this file exists and is valid, the +uuid in the file is printed on stdout. Otherwise, the command exits +with a nonzero status.</para> + + </listitem> + </varlistentry> + <varlistentry> + <term><option>--ensure[=FILENAME]</option></term> + <listitem> +<para>If a filename is not given, defaults to localstatedir/lib/dbus/machine-id +(localstatedir is usually /var). If this file exists then it will be +validated, and a failure code returned if it contains the wrong thing. +If the file does not exist, it will be created with a new uuid in it. +On success, prints no output.</para> + + </listitem> + </varlistentry> + <varlistentry> + <term><option>--version</option></term> + <listitem> +<para>Print the version of dbus-uuidgen</para> + + </listitem> + </varlistentry> +</variablelist> +</refsect1> + +<refsect1 id='author'><title>AUTHOR</title> +<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para> + +</refsect1> + +<refsect1 id='bugs'><title>BUGS</title> +<para>Please send bug reports to the D-Bus mailing list or bug tracker, +see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para> +</refsect1> +</refentry> @@ -70,7 +70,7 @@ # compiler: $LTCC # compiler flags: $LTCFLAGS # linker: $LD (gnu? $with_gnu_ld) -# $progname: (GNU libtool) 2.4.2 +# $progname: (GNU libtool) 2.4.2 Debian-2.4.2-1.1 # automake: $automake_version # autoconf: $autoconf_version # @@ -80,7 +80,7 @@ PROGRAM=libtool PACKAGE=libtool -VERSION=2.4.2 +VERSION="2.4.2 Debian-2.4.2-1.1" TIMESTAMP="" package_revision=1.3337 @@ -6124,7 +6124,10 @@ func_mode_link () case $pass in dlopen) libs="$dlfiles" ;; dlpreopen) libs="$dlprefiles" ;; - link) libs="$deplibs %DEPLIBS% $dependency_libs" ;; + link) + libs="$deplibs %DEPLIBS%" + test "X$link_all_deplibs" != Xno && libs="$libs $dependency_libs" + ;; esac fi if test "$linkmode,$pass" = "lib,dlpreopen"; then @@ -6444,19 +6447,19 @@ func_mode_link () # It is a libtool convenience library, so add in its objects. func_append convenience " $ladir/$objdir/$old_library" func_append old_convenience " $ladir/$objdir/$old_library" + tmp_libs= + for deplib in $dependency_libs; do + deplibs="$deplib $deplibs" + if $opt_preserve_dup_deps ; then + case "$tmp_libs " in + *" $deplib "*) func_append specialdeplibs " $deplib" ;; + esac + fi + func_append tmp_libs " $deplib" + done elif test "$linkmode" != prog && test "$linkmode" != lib; then func_fatal_error "\`$lib' is not a convenience library" fi - tmp_libs= - for deplib in $dependency_libs; do - deplibs="$deplib $deplibs" - if $opt_preserve_dup_deps ; then - case "$tmp_libs " in - *" $deplib "*) func_append specialdeplibs " $deplib" ;; - esac - fi - func_append tmp_libs " $deplib" - done continue fi # $pass = conv @@ -7349,6 +7352,9 @@ func_mode_link () revision="$number_minor" lt_irix_increment=no ;; + *) + func_fatal_configuration "$modename: unknown library version type \`$version_type'" + ;; esac ;; no) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 56666f0e..534d1ccd 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -2512,17 +2512,6 @@ freebsd* | dragonfly*) esac ;; -gnu*) - version_type=linux # correct to gnu/linux during the next big refactor - need_lib_prefix=no - need_version=no - library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}' - soname_spec='${libname}${release}${shared_ext}$major' - shlibpath_var=LD_LIBRARY_PATH - shlibpath_overrides_runpath=no - hardcode_into_libs=yes - ;; - haiku*) version_type=linux # correct to gnu/linux during the next big refactor need_lib_prefix=no @@ -2639,7 +2628,7 @@ linux*oldld* | linux*aout* | linux*coff*) ;; # This must be glibc/ELF. -linux* | k*bsd*-gnu | kopensolaris*-gnu) +linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) version_type=linux # correct to gnu/linux during the next big refactor need_lib_prefix=no need_version=no @@ -2669,14 +2658,10 @@ linux* | k*bsd*-gnu | kopensolaris*-gnu) # before this can be enabled. hardcode_into_libs=yes - # Add ABI-specific directories to the system library path. - sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib" - # Append ld.so.conf contents to the search path if test -f /etc/ld.so.conf; then lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[ ]/d;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '` - sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec $lt_ld_extra" - + sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra" fi # We used to test for /lib/ld.so.1 and disable shared libraries on @@ -2688,6 +2673,18 @@ linux* | k*bsd*-gnu | kopensolaris*-gnu) dynamic_linker='GNU/Linux ld.so' ;; +netbsdelf*-gnu) + version_type=linux + need_lib_prefix=no + need_version=no + library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}' + soname_spec='${libname}${release}${shared_ext}$major' + shlibpath_var=LD_LIBRARY_PATH + shlibpath_overrides_runpath=no + hardcode_into_libs=yes + dynamic_linker='NetBSD ld.elf_so' + ;; + netbsd*) version_type=sunos need_lib_prefix=no @@ -3247,10 +3244,6 @@ freebsd* | dragonfly*) fi ;; -gnu*) - lt_cv_deplibs_check_method=pass_all - ;; - haiku*) lt_cv_deplibs_check_method=pass_all ;; @@ -3289,11 +3282,11 @@ irix5* | irix6* | nonstopux*) ;; # This must be glibc/ELF. -linux* | k*bsd*-gnu | kopensolaris*-gnu) +linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) lt_cv_deplibs_check_method=pass_all ;; -netbsd*) +netbsd* | netbsdelf*-gnu) if echo __ELF__ | $CC -E - | $GREP __ELF__ > /dev/null; then lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|_pic\.a)$' else @@ -4041,7 +4034,7 @@ m4_if([$1], [CXX], [ ;; esac ;; - linux* | k*bsd*-gnu | kopensolaris*-gnu) + linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) case $cc_basename in KCC*) # KAI C++ Compiler @@ -4105,7 +4098,7 @@ m4_if([$1], [CXX], [ ;; esac ;; - netbsd*) + netbsd* | netbsdelf*-gnu) ;; *qnx* | *nto*) # QNX uses GNU C++, but need to define -shared option too, otherwise @@ -4340,7 +4333,7 @@ m4_if([$1], [CXX], [ _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared' ;; - linux* | k*bsd*-gnu | kopensolaris*-gnu) + linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) case $cc_basename in # old Intel for x86_64 which still supported -KPIC. ecc*) @@ -4582,6 +4575,9 @@ m4_if([$1], [CXX], [ ;; esac ;; + linux* | k*bsd*-gnu | gnu*) + _LT_TAGVAR(link_all_deplibs, $1)=no + ;; *) _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' ;; @@ -4644,6 +4640,9 @@ dnl Note also adjust exclude_expsyms for C++ above. openbsd*) with_gnu_ld=no ;; + linux* | k*bsd*-gnu | gnu*) + _LT_TAGVAR(link_all_deplibs, $1)=no + ;; esac _LT_TAGVAR(ld_shlibs, $1)=yes @@ -4865,7 +4864,7 @@ _LT_EOF fi ;; - netbsd*) + netbsd* | netbsdelf*-gnu) if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable $libobjs $deplibs $linker_flags -o $lib' wlarc= @@ -5042,6 +5041,7 @@ _LT_EOF if test "$aix_use_runtimelinking" = yes; then shared_flag="$shared_flag "'${wl}-G' fi + _LT_TAGVAR(link_all_deplibs, $1)=no else # not using gcc if test "$host_cpu" = ia64; then @@ -5346,7 +5346,7 @@ _LT_EOF _LT_TAGVAR(link_all_deplibs, $1)=yes ;; - netbsd*) + netbsd* | netbsdelf*-gnu) if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags' # a.out else @@ -6226,9 +6226,6 @@ if test "$_lt_caught_CXX_error" != yes; then _LT_TAGVAR(ld_shlibs, $1)=yes ;; - gnu*) - ;; - haiku*) _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib' _LT_TAGVAR(link_all_deplibs, $1)=yes @@ -6390,7 +6387,7 @@ if test "$_lt_caught_CXX_error" != yes; then _LT_TAGVAR(inherit_rpath, $1)=yes ;; - linux* | k*bsd*-gnu | kopensolaris*-gnu) + linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*) case $cc_basename in KCC*) # Kuck and Associates, Inc. (KAI) C++ Compiler diff --git a/test/Makefile.in b/test/Makefile.in index 95b4cc4e..a5a6fe6a 100644 --- a/test/Makefile.in +++ b/test/Makefile.in @@ -315,7 +315,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -374,7 +375,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ diff --git a/test/name-test/Makefile.in b/test/name-test/Makefile.in index 6ea051eb..4f2e756b 100644 --- a/test/name-test/Makefile.in +++ b/test/name-test/Makefile.in @@ -193,7 +193,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -252,7 +253,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ diff --git a/test/name-test/test-autolaunch.c b/test/name-test/test-autolaunch.c index 5e519895..adbeb185 100644 --- a/test/name-test/test-autolaunch.c +++ b/test/name-test/test-autolaunch.c @@ -1,3 +1,5 @@ +#include "config.h" + #include <stdio.h> #include <stdlib.h> #include <string.h> diff --git a/test/test-exit.c b/test/test-exit.c index f3358185..b4f967ae 100644 --- a/test/test-exit.c +++ b/test/test-exit.c @@ -1,3 +1,5 @@ +#include "config.h" + /* This is a process that just exits with a failure code */ int main (int argc, char **argv) diff --git a/tools/Makefile.in b/tools/Makefile.in index b8e779f6..0caa60ef 100644 --- a/tools/Makefile.in +++ b/tools/Makefile.in @@ -183,7 +183,8 @@ DBUS_MICRO_VERSION = @DBUS_MICRO_VERSION@ DBUS_MINOR_VERSION = @DBUS_MINOR_VERSION@ DBUS_PATH_OR_ABSTRACT = @DBUS_PATH_OR_ABSTRACT@ DBUS_PREFIX = @DBUS_PREFIX@ -DBUS_SESSION_BUS_DEFAULT_ADDRESS = @DBUS_SESSION_BUS_DEFAULT_ADDRESS@ +DBUS_SESSION_BUS_CONNECT_ADDRESS = @DBUS_SESSION_BUS_CONNECT_ADDRESS@ +DBUS_SESSION_BUS_LISTEN_ADDRESS = @DBUS_SESSION_BUS_LISTEN_ADDRESS@ DBUS_SESSION_SOCKET_DIR = @DBUS_SESSION_SOCKET_DIR@ DBUS_STATIC_BUILD_CPPFLAGS = @DBUS_STATIC_BUILD_CPPFLAGS@ DBUS_SYSTEM_BUS_DEFAULT_ADDRESS = @DBUS_SYSTEM_BUS_DEFAULT_ADDRESS@ @@ -242,7 +243,6 @@ LT_CURRENT = @LT_CURRENT@ LT_REVISION = @LT_REVISION@ MAINT = @MAINT@ MAKEINFO = @MAKEINFO@ -MAN2HTML = @MAN2HTML@ MANIFEST_TOOL = @MANIFEST_TOOL@ MKDIR_P = @MKDIR_P@ NETWORK_libs = @NETWORK_libs@ diff --git a/tools/dbus-launch.c b/tools/dbus-launch.c index 1ec9ae59..2a9dabfa 100644 --- a/tools/dbus-launch.c +++ b/tools/dbus-launch.c @@ -633,6 +633,7 @@ babysit (int exit_with_session, s = getenv ("DBUS_DEBUG_OUTPUT"); if (s == NULL || *s == '\0') dup2 (dev_null_fd, 2); + close (dev_null_fd); } else { diff --git a/tools/strtoll.c b/tools/strtoll.c index e4f57701..7360c630 100644 --- a/tools/strtoll.c +++ b/tools/strtoll.c @@ -27,6 +27,7 @@ * SUCH DAMAGE. */ +#include "config.h" #include <limits.h> #ifdef HAVE_ERRNO_H diff --git a/tools/strtoull.c b/tools/strtoull.c index 459c5091..35595542 100644 --- a/tools/strtoull.c +++ b/tools/strtoull.c @@ -27,6 +27,7 @@ * SUCH DAMAGE. */ +#include "config.h" #include <limits.h> #ifdef HAVE_ERRNO_H |