diff options
author | Daniel Mack <daniel@zonque.org> | 2014-11-13 20:33:03 +0100 |
---|---|---|
committer | Daniel Mack <daniel@zonque.org> | 2014-11-13 20:41:52 +0100 |
commit | 63cc4c3138fd0ce9cc97884373a2dd8959a13ee9 (patch) | |
tree | a3a1da14e79d69685cd1c5ecf8b0baff703a21f0 /src/libsystemd/sd-bus/PORTING-DBUS1 | |
parent | c1ec25a0634bba8ef82b69ac603597d4749baf9d (diff) | |
download | systemd-63cc4c3138fd0ce9cc97884373a2dd8959a13ee9.tar.gz |
sd-bus: sync with kdbus upstream (ABI break)
kdbus has seen a larger update than expected lately, most notably with
kdbusfs, a file system to expose the kdbus control files:
* Each time a file system of this type is mounted, a new kdbus
domain is created.
* The layout inside each mount point is the same as before, except
that domains are not hierarchically nested anymore.
* Domains are therefore also unnamed now.
* Unmounting a kdbusfs will automatically also detroy the
associated domain.
* Hence, the action of creating a kdbus domain is now as
privileged as mounting a filesystem.
* This way, we can get around creating dev nodes for everything,
which is last but not least something that is not limited by
20-bit minor numbers.
The kdbus specific bits in nspawn have all been dropped now, as nspawn
can rely on the container OS to set up its own kdbus domain, simply by
mounting a new instance.
A new set of mounts has been added to mount things *after* the kernel
modules have been loaded. For now, only kdbus is in this set, which is
invoked with mount_setup_late().
Diffstat (limited to 'src/libsystemd/sd-bus/PORTING-DBUS1')
-rw-r--r-- | src/libsystemd/sd-bus/PORTING-DBUS1 | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 81e94132b3..2dedb28bcf 100644 --- a/src/libsystemd/sd-bus/PORTING-DBUS1 +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 @@ -14,11 +14,11 @@ GVariant compatible marshaler to your library first. After you have done that: here's the basic principle how kdbus works: -You connect to a bus by opening its bus node in /dev/kdbus/. All +You connect to a bus by opening its bus node in /sys/fs/kdbus/. All buses have a device node there, it starts with a numeric UID of the owner of the bus, followed by a dash and a string identifying the -bus. The system bus is thus called /dev/kdbus/0-system, and for user -buses the device node is /dev/kdbus/1000-user (if 1000 is your user +bus. The system bus is thus called /sys/fs/kdbus/0-system, and for user +buses the device node is /sys/fs/kdbus/1000-user (if 1000 is your user id). (Before we proceed, please always keep a copy of libsystemd next @@ -496,12 +496,12 @@ parameter. Client libraries should use the following connection string when connecting to the system bus: - kernel:path=/dev/kdbus/0-system/bus;unix:path=/var/run/dbus/system_bus_socket + kernel:path=/sys/fs/kdbus/0-system/bus;unix:path=/var/run/dbus/system_bus_socket This will ensure that kdbus is preferred over the legacy AF_UNIX socket, but compatibility is kept. For the user bus use: - kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus + kernel:path=/sys/fs/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus With $UID replaced by the callers numer user ID, and $XDG_RUNTIME_DIR following the XDG basedir spec. |