On Wed, Aug 19, 2015 at 4:47 PM, Ian Geiser <igei...@devonit.com> wrote:
> On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser <igei...@devonit.com> wrote: > > Greetings, I am struggling with search queries here so I need to ask > this outright. "what is the role of dbus going forward?" Is dbus the > preferred way going forward? Or should things really be using sd-bus.h > instead? > > > > D-Bus is not going away, only its internals are being replaced. Existing > clients will continue working. > > > > kdbus replaces the "dbus-daemon" router and the Unix socket transport with > a direct kernel API, but all existing programs can still connect to it via > systemd-bus-proxy (at least until they get native kdbus support). > > > > sd-bus.h is only a library for writing DBus clients & servers. Here the > choice is still up to you – sd-bus has better performance and native kdbus > support (and a better API than e.g. dbus-glib), but if you're writing > programs in GTK or Qt or EFL, then you'll still want GDBus or QtDBus or > Eldbus. > > > > *[igeiser] *Awesome, thanks for the clarification > > > > (I've heard GDBus already has native kdbus support in development, too.) > > > > I manage an embedded product that leverages system heavily at the system > level, but I want to expand this into the user session. The main focus is > to use "scopes" for classification and control of specific application's > process groups. The rub here is that while system-run can do this if I try > to do this via dbus the org.freedesktop.systemd1 is missing from the user > session no matter what or where I set my DBUS_SESSION_BUS_ADDRESS. I am > using systemd 224. > > Right, systemd will not be accessible on a session bus, since it runs > *outside* the session. > > > > So instead you'll find it on the *user* bus, which is available by > default on kdbus systems, but can be configured with dbus-daemon as well. > The current devel branch (1.9.20) of dbus-daemon installs the --user units > dbus.socket and dbus.service necessary for this. The user bus address is > "kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes" (if I got the > syntax right?), or > "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus". > > *[igeiser] *Can I access it using the path directly in 1.8.x using > ”unix:path=/run/user/$UID/system/private”? Or is that what the 1.9.20 > allows to happen? > Not quite; …/systemd/private is not even a bus – it's a direct peer-to-peer connection to systemd, providing just that one service. (It is therefore independent of which dbus-daemon version you're running.) So you need to connect to it in a slightly different way (e.g. "g_dbus_connection_new_for_address()"). Also keep in mind that this socket is for internal systemd use only (hence its name), and can be removed from systemd *at any time *in some future release. For your own projects it's better to set up the actual user bus. > (Technically the same can be done with dbus 1.8.x as well, but AFAIK the > developers do not approve.) > > > > *[igeiser] *Is this the method various “user units” howtos add a > dbus.socket and dbus.service into the user directory? I will research the > dbus repo for their details. This is happy lab fun time so I am play with > hacks if they don’t lead me away from the official solution. > Yes, that would work. (Though e.g. if you use polkit it should be the very latest version as well.) [Also that's some *weird* quoting style of yours] -- Mantas Mikulėnas <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
