Starting the kdbus discussions

[Ted Gould]

On Sun, 2013-12-29 at 21:29 +-0100, Lennart Poettering wrote:

+AD4 On Sun, 29.12.13 13:52, Ted Gould (ted+AEA-gould.cx) wrote:
+AD4 +AD4 On Fri, 2013-12-27 at 01:04 +-0100, Lennart Poettering wrote:
+AD4 +AD4 +AD4 This makes us comfortable to start discussion on the dbus ML regarding
+AD4 +AD4 +AD4 the details and what this means for the dbus spec. I have put together a
+AD4 +AD4 +AD4 document now that explains what we are doing and how to port a dbus1
+AD4 +AD4 +AD4 library over to a kdbus backend. Much of this hopefully should end up in
+AD4 +AD4 +AD4 the dbus spec one day.
+AD4 +AD4 +AD4 
+AD4 +AD4 +AD4 http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/PORTING-DBUS1
+AD4 +AD4 
+AD4 +AD4 
+AD4 +AD4 Glad that you're ready to start talking about this.  I guess the
+AD4 +AD4 question I really want to ask is perhaps the elephant in the room.  With
+AD4 +AD4 a different serialization format, a different name registration scheme,
+AD4 +AD4 different connection parameters, different service description files...
+AD4 +AD4 heck, some of the fields seem arbitrarily inverted.   This doesn't seem
+AD4 +AD4 like DBus at all, but something entirely different, more +ACI-DBus inspired+ACI
+AD4 +AD4 rather than something related to DBus itself.
+AD4 
+AD4 Nope. We provide quite complete compatibility, there are only very few
+AD4 exceptions visible to app programmers. One is the different policy language
+AD4 use for the system bus, but even for that we provide full compatbility
+AD4 if people connect via the good old AF+AF8-UNIX protocol.



From my understanding, every application that ships a service file today
will have to change that to be a systemd service if they expect to use
kdbus directly.  Not sure if the kdbus to dbus proxy would support the
dbus service files.  Seems that application expecting to use both would
need to ship both files and ensure compatibility there.


+AD4 The flags are no +ACI-arbitrarily+ACI inverted. We simply dropped the weird
+AD4 inversion that dbus1 had there in the first place. Moreover, this is
+AD4 not visible to the outside anyway, as applications should connect via a
+AD4 library such as libsystemd-bus, or gdbus to the thing, and those library
+AD4 trivially abstract the app developer away from this diffrence.



Sure, if you were making a new protocol that makes sense.


+AD4 The serialization format is mostly not visible to the outside anyway in
+AD4 gdbus/libdbus. All the signature logic of GVariant and dbus1 marshalling
+AD4 is pretty much identical however. In fact, gdbus converts everything
+AD4 from/to GVariant anyway in userspace already, even on dbus1
+AD4 marshalling. Morever, we even provide compatibility with dbus1
+AD4 marshalling, again in the bus proxy. If you complain that gvariant was
+AD4 so different from dbus1, then you probably shouldn't use glib's gdbus
+AD4 either.



Not everyone who connects to DBus uses GDBus.  Optimizing the service
for a particular client library seems odd.  And it seems odd to say that
+ACI-this is DBus+ACI with a different serialization format.


+AD4 +AD4 Also, it seems that there are rather direct dependencies on systemd.
+AD4 
+AD4 Both the kernel space side and userspace side are free software. The
+AD4 activation logic, the bus driver and the compatbility proxy live in the
+AD4 systemd repo and use systemd apis and technology, that is true. We also
+AD4 provide an alternative low-level D-Bus client library in systemd
+AD4 (libsystemd-bus) which can connect to both classic dbus1 and kdbus
+AD4 directly, and abstracts all differences away.



I realize that you put them there for easier development, but do you
expect things like the compatibility proxy to remain in the systemd
repository?  Seems like it should release with dbus-daemon to maximize
compatibility.


+AD4 +AD4 While I consider that a negative in itself, it also means that DBus has
+AD4 +AD4 a direct dependency on Linux as I understand that systemd only intends
+AD4 +AD4 to support Linux.  And that seems also a negative for DBus.
+AD4 
+AD4 Why would it? To applications things look pretty much the same, we
+AD4 provide the same sockets, and client libraries connecting directly to
+AD4 kdbus can hide this under the same library interface.
+AD4 
+AD4 Note in particular that when sockets are used as transport the
+AD4 unmodified dbus1 marshalling is used. This is extensively used by
+AD4 systemd to implement things like +ACI-systemctl -H+ACI or +ACI-systemctl -M+ACI which
+AD4 allows connections to another host via ssh, or connections to a local
+AD4 container via namespace-traversing sockets.


The behaviors will be different.  Timings will be different.  The bugs
will be different.  Implying that all of this can be abstracted away is
unrealistic.


+AD4 +AD4 I realize this is a work in progress, but it seems to me that it's not a
+AD4 +AD4 feasible replacement for DBus and in fact something different that is
+AD4 +AD4 intended to work in a more limited set of systems.
+AD4 
+AD4 Yeah, it might not be an appropriate choice for you/Ubuntu, but I see no
+AD4 reason why this would even matter to you, given that everybody else can
+AD4 use this just fine and things are pretty much compatible for app
+AD4 developers.
+AD4 
+AD4 Ubuntu is welcome to stay with classic dbus-daemon/dbus1, the APIs
+AD4 exposed by gdbus and so on abstract the backend away. 


Certainly.  But there is also a discussion of +ACI-what is DBus?+ACI which the
DBus community needs to decide.  For me, this seems more like
systemd-bus than DBus.

Ted

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http:+AC8ALw-lists.freedesktop.org+AC8-archives+AC8-dbus+AC8-attachments+AC8-20131229+AC8-6684db6f+AC8-attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application+AC8-pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http:+AC8ALw-lists.freedesktop.org+AC8-archives+AC8-dbus+AC8-attachments+AC8-20131229+AC8-6684db6f+AC8-attachment.pgp>