Starting the kdbus discussions

[Ted Gould]

Frankly, I think you're being a bit confusing in this conversation.  I
see your proposed architecture like this:

       +-----------+-               +-----------------+-
+------------+-
       +AHw          +AHw  systemd-bus  +AHw  systemd       +AHw  dbus  +AHw
+AHw
       +AHw  Kernel  +AHwAKw--------------+AD4AfA  compatibility +AHwAKw-------+AD4AfA  Service
+AHw
       +AHw          +AHw               +AHw  daemon        +AHw        +AHw
+AHw
       +-----------+-               +-----------------+-
+------------+-

You point to the second arrow and go +ACI-100+ACU compatible+ACI and to the first
arrow and say +ACI-no worries, GDBus fixes all your problems here.+ACI  But
they're different discussions and you're convoluting them.

On Mon, 2013-12-30 at 04:50 +-0100, Lennart Poettering wrote:

+AD4 On Sun, 29.12.13 20:42, Ted Gould (ted+AEA-gould.cx) wrote:
+AD4 +AD4 +AD4 Nope. We provide quite complete compatibility, there are only very few
+AD4 +AD4 +AD4 exceptions visible to app programmers. One is the different policy language
+AD4 +AD4 +AD4 use for the system bus, but even for that we provide full compatbility
+AD4 +AD4 +AD4 if people connect via the good old AF+AF8-UNIX protocol.
+AD4 +AD4 
+AD4 +AD4 From my understanding, every application that ships a service file today
+AD4 +AD4 will have to change that to be a systemd service if they expect to use
+AD4 +AD4 kdbus directly.  Not sure if the kdbus to dbus proxy would support the
+AD4 +AD4 dbus service files.  Seems that application expecting to use both would
+AD4 +AD4 need to ship both files and ensure compatibility there.
+AD4 
+AD4 Well, it's not that different from today. On Fedora at least we ship a
+AD4 systemd service file each for all bus-activated system service these days,
+AD4 and the dbus activation files are mostly just compatibility. So they
+AD4 already are systemd unit files, and they just continue to be, its just a
+AD4 bit more mandatory.



I'll take that as: +ACI-No, service files will not be supported in any way.+ACI


+AD4 +AD4 +AD4 The serialization format is mostly not visible to the outside anyway in
+AD4 +AD4 +AD4 gdbus/libdbus. All the signature logic of GVariant and dbus1 marshalling
+AD4 +AD4 +AD4 is pretty much identical however. In fact, gdbus converts everything
+AD4 +AD4 +AD4 from/to GVariant anyway in userspace already, even on dbus1
+AD4 +AD4 +AD4 marshalling. Morever, we even provide compatibility with dbus1
+AD4 +AD4 +AD4 marshalling, again in the bus proxy. If you complain that gvariant was
+AD4 +AD4 +AD4 so different from dbus1, then you probably shouldn't use glib's gdbus
+AD4 +AD4 +AD4 either.
+AD4 +AD4 
+AD4 +AD4 Not everyone who connects to DBus uses GDBus.  Optimizing the service
+AD4 +AD4 for a particular client library seems odd.  And it seems odd to say that
+AD4 +AD4 +ACI-this is DBus+ACI with a different serialization format.
+AD4 
+AD4 There are nowadays pretty much exactly three bus libraries in use:
+AD4 libdbus1, gdbus and libsystemd-bus (the latter currently only used by
+AD4 systemd). The other libraries are either wrappers around libdbus1 or not
+AD4 really maintained anymore, enough that I am happy to ignore them here.
+AD4 
+AD4 Ryan is doing the porting work for gdbus, and the Samsung guys are doing
+AD4 the porting work for libdbus1. With that in place, we have support from
+AD4 all three libs.



Great, glad that people have stepped up to do that work.  But, whether
the work is being done is independent of whether it should be done.
Seems too late to have that conversation, perhaps I should have replied
on Thursday to your e-mail, sorry for the delay.


+AD4 +AD4 +AD4 systemd repo and use systemd apis and technology, that is true. We also
+AD4 +AD4 +AD4 provide an alternative low-level D-Bus client library in systemd
+AD4 +AD4 +AD4 (libsystemd-bus) which can connect to both classic dbus1 and kdbus
+AD4 +AD4 +AD4 directly, and abstracts all differences away.
+AD4 +AD4 
+AD4 +AD4 I realize that you put them there for easier development, but do you
+AD4 +AD4 expect things like the compatibility proxy to remain in the systemd
+AD4 +AD4 repository?  Seems like it should release with dbus-daemon to maximize
+AD4 +AD4 compatibility.
+AD4 
+AD4 Nope, they are in systemd because that's what makes sense. It's systemd
+AD4 in PID 1 that issues the ioctl to create the system bus. It's systemd
+AD4 which will upload the dbus policy into the kernel at the same time as
+AD4 uploading the selinux, ima or smack policy. systemd learnt a new unit
+AD4 type called +ACI.busname+ACI which is how we expose bus activation as high
+AD4 level objects in systemd with uniform behaviour, similar to how socket
+AD4 activation is already covered. The bus proxy is a socket activated
+AD4 systemd service, the bus driver a bus activated systemd service. We want
+AD4 IPC to be an integral, uniformly integrated part of the OS, that's why
+AD4 it is part of systemd. (And anyway, I am also not interested in other
+AD4 systems, so why would I care?)



I figured you were interested in compatibility with dbus-daemon as well.
If the two were released in the same project, then they could be
released with the same feature set at the same time.  Otherwise they
will drift apart.


+AD4 I can certainly understand that you feel left out on Ubuntu with
+AD4 this. But please understand that that's hardly my problem, and we do
+AD4 stay compatible pretty much completely, to make life easy for you that
+AD4 you can stick with dbus-daemon.
+AD4 
+AD4 The alternative of course is to develop a different kdbus userspace for
+AD4 Ubuntu, and to make this easy for you I am posting this so that we can
+AD4 get this documented in the spec, and we all can do the same on the
+AD4 backend.



It is true.  I feel so left out that I cry in the corner between
e-mails.

What I don't see is a kdbus spec that is independent of systemd.  It
seems that all the relevant details live in the systemd repository.
Perhaps we could see the spec itself migrated out of the systemd
repository?


+AD4 +AD4 +AD4 Note in particular that when sockets are used as transport the
+AD4 +AD4 +AD4 unmodified dbus1 marshalling is used. This is extensively used by
+AD4 +AD4 +AD4 systemd to implement things like +ACI-systemctl -H+ACI or +ACI-systemctl -M+ACI which
+AD4 +AD4 +AD4 allows connections to another host via ssh, or connections to a local
+AD4 +AD4 +AD4 container via namespace-traversing sockets.
+AD4 +AD4 
+AD4 +AD4 The behaviors will be different.  Timings will be different.  The bugs
+AD4 +AD4 will be different.  Implying that all of this can be abstracted away is
+AD4 +AD4 unrealistic.
+AD4 
+AD4 Well, the spec exists precisely to minimize these differences and to
+AD4 allow multiple implementations while staying compatible. I am trying to
+AD4 work towards that goal. Are you?



Heh, I don't see that's what you're doing at all.  I see you as
delivering an ultimatum to the DBus community about how they've been
replaced.  Let's make the spec independent of systemd and then let's
talk about it.


+AD4 +AD4 +AD4 +AD4 I realize this is a work in progress, but it seems to me that it's not a
+AD4 +AD4 +AD4 +AD4 feasible replacement for DBus and in fact something different that is
+AD4 +AD4 +AD4 +AD4 intended to work in a more limited set of systems.
+AD4 +AD4 +AD4 
+AD4 +AD4 +AD4 Yeah, it might not be an appropriate choice for you/Ubuntu, but I see no
+AD4 +AD4 +AD4 reason why this would even matter to you, given that everybody else can
+AD4 +AD4 +AD4 use this just fine and things are pretty much compatible for app
+AD4 +AD4 +AD4 developers.
+AD4 +AD4 +AD4 
+AD4 +AD4 +AD4 Ubuntu is welcome to stay with classic dbus-daemon/dbus1, the APIs
+AD4 +AD4 +AD4 exposed by gdbus and so on abstract the backend away. 
+AD4 +AD4 
+AD4 +AD4 Certainly.  But there is also a discussion of +ACI-what is DBus?+ACI which the
+AD4 +AD4 DBus community needs to decide.  For me, this seems more like
+AD4 +AD4 systemd-bus than DBus.
+AD4 
+AD4 I fail to see what you are trying to achieve here?
+AD4 
+AD4 I mean, we either can get this discussed and done and into the spec and
+AD4 we agree on common ground and open interfaces, or we can part ways, not
+AD4 care about dbus1, do our thing independently of the old spec, not
+AD4 include you in any discussions and define a new spec, and make all our
+AD4 userspace work with only that. This would certainly cement the
+AD4 seperation between Ubuntu and friends and the rest of the world even
+AD4 further and make it even harder for you to use our technologies. I
+AD4 cannot see how that would be in your interest...
+AD4 
+AD4 Either you partake in the discussions and influence the spec at least
+AD4 somewhat, or you tell us to go away and don't influence anything. I
+AD4 somehow have the suspicion here though that kdbus is more interesting to
+AD4 most people than classic dbus1 pretty soon, so excuse my arrogance here,
+AD4 but good luck with that.


I don't excuse your arrogance.

Ted

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http:+AC8ALw-lists.freedesktop.org+AC8-archives+AC8-dbus+AC8-attachments+AC8-20131229+AC8-72f68c75+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-72f68c75+AC8-attachment.pgp>