Starting the kdbus discussions

[Lennart Poettering]

On Sun, 29.12.13 23:12, Ted Gould (ted at gould.cx) wrote:

> Frankly, I think you're being a bit confusing in this conversation.  I
> see your proposed architecture like this:
> 
>        +----------+               +----------------+
> +-----------+
>        |          |  systemd-bus  |  systemd       |  dbus  |
> |
>        |  Kernel  |+------------->|  compatibility |+------>|  Service
> |
>        |          |               |  daemon        |        |
> |
>        +----------+               +----------------+
> +-----------+
> 
> You point to the second arrow and go "100% compatible" and to the first
> arrow and say "no worries, GDBus fixes all your problems here."  But
> they're different discussions and you're convoluting them.

It looks like this:

There's the kernel component which is called "kdbus". It implements a
big chunk of the good old dbus-daemon, but doesn't actually understand
the marshalling or anything. What is left to userspace is setting up a
bus, uploading a policy, and prcoessing activation requests and a couple
of other things. systemd's PID 1 when booting up will do all that. 

Native kdbus clients (such as libsystemd-bus, or gdbus with Ryan's work,
or libdbus1 with Samsung work) simply directly connect to kdbus, and
that's that. However for old dbus1 clients which want to connect via
AF_UNIX/SOCK_STREAM we have a proxy service in place. It listens on the
old bus socket, takes all the messages, remarshals them, and forwards
them to kdbus. Messages from kdbus it will also forward to these old
clients. It is hence a bi-directional proxy that makes sure that classic
AF_UNIX clients can talk to kdbus just fine, without seeing any
difference.

In a legacy-free system everybody talks directly to kdbus and the proxy
is never used. Until that day dbus1 clients will go via the proxy
instead. That's all.

To good old clients the proxy is almost entirely induistingashable from
a classic dbus-daemon. You can just consider it a compatible
reimplementation of dbus-daemon, that just happens to have a fancy
kernel backend.

Now, there's one big difference when connecting directly to kdbus
vs. indirectly via the proxy: the old XML policy language is not used on
kdbus directly, the kernel enforces more Unix-like ACLs on service
names, and will not enforce anything on members/interfaces and so on,
the way dbus1 allowed that in the XML policy. When connecting to the
kdbus system bus directly you need to be aware of that, and do your own
access control (which is a lot easier to do though than in dbus1, since
messages carry creds and caps from the sender anyway). Since user busses
carry no policy anyway this is irrelevant for user busses. For old dbus1
clients it is the bus proxy which will enforce the XML policy, so that
we don't break compatibility there either.

> > Well, it's not that different from today. On Fedora at least we ship a
> > systemd service file each for all bus-activated system service these days,
> > and the dbus activation files are mostly just compatibility. So they
> > already are systemd unit files, and they just continue to be, its just a
> > bit more mandatory.
> 
> I'll take that as: "No, service files will not be supported in any
> way."

Old dbus1 service files are supported, but only for clients that connect
indirectly via the bus proxy. There's a systemd "generator" in place
that simply convers the old dbus1 service files into a pair of systemd
unit files each.  Modern clients that speak kdbus directly need to
provide unit files. 

> > There are nowadays pretty much exactly three bus libraries in use:
> > libdbus1, gdbus and libsystemd-bus (the latter currently only used by
> > systemd). The other libraries are either wrappers around libdbus1 or not
> > really maintained anymore, enough that I am happy to ignore them here.
> > 
> > Ryan is doing the porting work for gdbus, and the Samsung guys are doing
> > the porting work for libdbus1. With that in place, we have support from
> > 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.

Hmm, are you telling us to stop working on this? Thanks, but I think
I'll pass...

> Seems too late to have that conversation, perhaps I should have replied
> on Thursday to your e-mail, sorry for the delay.

Hmm?

> > Nope, they are in systemd because that's what makes sense. It's systemd
> > in PID 1 that issues the ioctl to create the system bus. It's systemd
> > which will upload the dbus policy into the kernel at the same time as
> > uploading the selinux, ima or smack policy. systemd learnt a new unit
> > type called ".busname" which is how we expose bus activation as high
> > level objects in systemd with uniform behaviour, similar to how socket
> > activation is already covered. The bus proxy is a socket activated
> > systemd service, the bus driver a bus activated systemd service. We want
> > IPC to be an integral, uniformly integrated part of the OS, that's why
> > it is part of systemd. (And anyway, I am also not interested in other
> > 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.

The spec is there for making sure this doesn't happen. I started this
discussion with the goal to ultimately get the kdbus transport stuff
included in the spec.

> 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?

You are confusing specifications with software. 

The software implementation I have been working on will certainly stay
in the systemd repository. And right now there is no spec for kdbus, at
all, just the terse overview I put together and linked here that is
supposed to be basis for discussion. The goal here is to make sure this
stuff ends up in the dbus specification maintained on fdo.

> > > 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.
> > 
> > Well, the spec exists precisely to minimize these differences and to
> > allow multiple implementations while staying compatible. I am trying to
> > 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.

Sorry, you are way off here... I mean, I started this discussion to get
this stuff documented in the dbus spec, and you accuse me of keeping
this for ourselves in the systemd tree. This is precisely nto what I am
trying to do. 

Anyway, I don't need to continue this discussion with you. Given your
contributions to dbus code so far have been zero, and you are not
constructive here I think I'll just ignore you in these discussions from
now on. 

Lennart

-- 
Lennart Poettering, Red Hat