Starting the kdbus discussions

Glenn Schmottlach gschmottlach at gmail.com
Mon Dec 30 12:52:12 PST 2013


>
>> 1) Requires systemd integration in your distro?
>
> The existing userspace only works with systemd. Nothing stops others to
> write an alternative userspace implementation for this though. I started
> this discussion here to make sure we an get enough of this into the spec
> so that those bus implementations stay interoperable enough for apps to
> not care about the bus implementation used.
>

So it sounds like systemd is not strictly a dependency if you plan on
talking to kdbus directly. As I understand it the proxy "thingy" is
the piece with the systemd dependency since it was written using some
of the systemd APIs etc...

>> 2) Will require language bindings to libdbus to change . . . or is
>> this the shim the guys at Samsung are working on?
>
> All existing dbus clients will just continue to work, via the bus
> proxy. of course, they won't get any of the cooler features of kdbus
> this way, and things won't be as fast as they could since every message
> is remarshalled during proxying.
>
>> I ask about #2 because I have a Lua binding to D-Bus that uses the 'C'
>> reference library as it's glue to D-Bus. I was hoping the language
>> binding would *not* have to dramatically change to accommodate kdbus.
>
> The Smasung guys supposedly work on a direct backend on top of kdbus for
> libdbus1. I am not sure what the latest status of this is.

For my selfish (language binding) reasons, I guess I am very
interested in their work. Do you know if they've made their efforts
public somewhere so I could track their progress. I was not aware of
this activity until you mentioned it.

> Note that for our own roadmap we decided to primarily care for native
> gdbus and libsystemd-bus backends, and simply deal with libdbus1 clients
> via the bus proxy thingy, however we certainly welcome if libdbus1 also
> talks kdbus natively.

That's understandable given your background and focus . . . I'd likely
do the same. But a libdbus1 client shim that binds directly to kdbus
would be the most interest to me and I suspect other language bindings
written directly against the libdbus1 API. It appears that might
provide the best/easiest migration path forward for my application
since systemd and it's proxy is unavailable on my typical platforms.


More information about the dbus mailing list