Bug#727708: init system discussion status
On Sun, 05 Jan 2014 at 00:54:04 +0000, Dimitri John Ledkov wrote:
> post-208 rewrite, is interesting, burning bridges with dbus?
As in all emails I write about this, I'm trying to be consistent about
spelling the abstract specification "D-Bus" and its oddly-licensed
reference implementation "dbus". I am a D-Bus and dbus maintainer.
libsystemd-bus is not, in itself, something that burns any bridges with
traditional D-Bus. It's a reimplementation of dbus (D-Bus' reference
implementation) under a less bizarre license[1] (and probably a nicer
C API too), taking advantage of Linuxisms to be more concise and probably
more correct (whereas dbus is portable, with all the usual costs of
portability, like large chunks of #ifdef'd socket-wrangling code that haven't
actually worked for several years).
kdbus is a new, non-standardized, Linux-kernel-assisted transport for D-Bus,
supported by libsystemd-bus and by unmerged branches of GDBus and dbus.
I'm trying to make sure that it gets proper design/code review from
experienced D-Bus (and dbus) developers, and is added to the D-Bus
Specification. If you are interested in this, please join the D-Bus
upstream mailing list/bug tracker (and if you see discussion elsewhere
that should go to D-Bus' upstream locations, please direct it there).
If I maintained systemd, I would personally not have merged any kdbus
support into the master branch yet - I don't think it's ready for that -
but systemd upstream have chosen to include it in a deactivated state.
I'm not sure whether it's #ifdef'd out by default, or just not usable
on unmodified kernels, but either way, systemd on current kernels
(without either a patch or an out-of-tree module) doesn't and can't use it.
> Standardizing
> on a toolkit/ecosystem marshaling (GVariant), despite not being
> political, looks odd from cross-platform point of view.
D-Bus' marshalling is sufficiently weird that I can understand why
the kdbus developers want to use traditional D-Bus -> kdbus as a "flag day"
for switching to different marshalling - at the moment the plan seems
to be to say "traditional D-Bus over a socket always uses
D-Bus 1.0 marshalling, kdbus always uses GVariant marshalling" rather
than making them orthogonal, to have fewer combinations that need to be
tested. If GVariant's marshalling is better than D-Bus' (I haven't
researched it myself, but I can well believe that it is), then it seems
fine to use that, rather than inventing some third thing for the
sake of neutrality.
> Does that also
> mean that projects linking against libdbus1 cannot talk to systemd
> components native, without compat translator running on the systemd
> side?
At the moment: no, systemd still speaks the traditional D-Bus protocol
via a socket to dbus-daemon.
If/when kdbus is in the kernel and libsystemd-bus, but not dbus: yes,
the plan seems to be that systemd will to provide a bridge that replaces
dbus-daemon, for compatibility with current D-Bus implementations.
If/when a kdbus transport is added to dbus too (one exists in a branch/fork,
but has not been submitted upstream): no, libdbus1 (part of dbus) can use
that transport.
S
[1] dbus is dual GPL/AFL and cannot be relicensed to (say) MIT or LGPL,
because one significant early copyright holder has gone out of business
and it isn't clear who owns that part of the copyright now
Reply to: