[systemd-devel] bus driver on kdbus

[Lennart Poettering]

On Mon, 14.04.14 14:16, Ryan Lortie (desrt at desrt.ca) wrote:

> Before we realised that this bug was a problem, however, having the bus
> driver was clearly closer to "classic dbus-1".

Yupp, and we do revisit what we do from time to time and do change our
opinions after consideration, which any engineer should do.

> > If you want i can put together a "reference implementation" of the
> > hashing logic. You'd just pass a list of tokens to add to the hash
> > vocabulary, and we return you the match hash. You could then drop that
> > into your sources, and you can update it when we do another revision of
> > the protocol, and all that without breaking compat.
> 
> I'd actually prefer if you put together a library that was the interface
> to kdbus.  If it's not possible to have the higher-level logic in the
> kernel, then why not have it in userspace?  If everyone is using the
> same shared library then

Well, I am not going to write a second library, you can be sure about
that.

I really don't understand you anymore I must say. It feels as if you
want to play the abstraction game to somehow improve your karma with the
freebsd guys, and I really don#t understand at all what the point of
that is.

YOu know, we can certainly change sd-bus to allow creation of
sd_bus_message objects from binary gvariant blobs and fd arrays, but
that's just a recipe for bad performance, and creates a huge headache
when using the socket backend. It was actually my intention to make sure
that the actual kdbus transport was high performance enough too be
sueful for gnome apps to transfer bluk data. With such abstraction games
you make such a goal incredibly hard.

I really don't see why you even want to play this game. Lukas is doing
the work on the kdbus port of glib, and he's willing to sheperd the
thing into repo, and maintain it.

Really, Ryan. Stop playing this stupid abstracted interface game. You
are creating a crap platform like that.

A big part of what kdbus is about is about minimizing copies for method
call transactions. For this we leave memory management and layout of
message objects to the sender and copy them together only at the last
possible step. By wanting us to do this all for you you kinda force us to
either create a complex callback-on-destroy scheme, or to copy early
on. I am really strongly  against either.

>  a) we don't have n copies of the bus interface copied everywhere

Well, stop pretending that "n" is a large number. It's pretty much 2,
not more. One in glib and maybe one in libdbus1, if we want that to
speak kdbus directly. sd-bus won't carry one.

> We run into trouble if we can have multiple versions of this library

Why?

> I'd also be open to the idea of defining a new bus type outright and
> saying that it's not permitted to send messages to org.freedesktop.DBus
> on this new bus type.  Aside from my reservations about match rules, I
> have no problem with turning GDBus API calls into ioctls (just as you do
> in systemd).  Sending messages to org.freedesktop.DBus on this new bus
> type would fail (since the destination is unknown).  This would give app
> authors a chance to opt-in to move over to the new bus type and to deal
> with compatibility issues as they do so.

if this is what it takes... We have to create a new bus type anyway for
the system bus, so that apps can acknowledge explicitly that they know
how to do their own security. 

So maybe this is the easiest way out: introduce two new bus types in
gdbus and by using those people can acknowledge that they:

a) for the system bus are aware they need to do their own security
b) for the user bus are aware they might not talk to a session anymore but a user bus
c) that they cannot talk to the driver anymore, and need to use gdbus API calls instead

And if people do not use the new bus types, we'd simply connect them to
the old proxy.

Lennart

-- 
Lennart Poettering, Red Hat