gdbus or libdbus wrapper for kdbus

[Kay Sievers]

On Fri, Jul 19, 2013 at 3:52 AM, Yang Chengwei <chengwei.yang at intel.com> wrote:
> On Thu, Jul 18, 2013 at 08:15:22PM +0900, HyungJun Choi wrote:
>>
>> I think there's someone who is developing gdbus or libdbus wrapper for
>> kdbus.

No, and that would be way to early. Kdbus is not even usable now, only
the basic kernel building blocks and some rudimentary tests to measure
and validate the kernel data copy/passing mechanisms are available.
The kdbus kernel code is not useful for anything else at the moment,
major pieces are still missing to replace the current dbus
functionality.

> Not sure for gdbus, I think it has its own community.

When kdbus is ready, and the libsystemd-bus shared library (can talks
to kdbus and the current D-Bus socket) has replaced libdbus in
systemd, and we are confident systemd itself works reliable on kdbus,
gdbus/glib will probably be ported to use the kdbus kernel interface
directly. There are no specific plans for that at the moment though.

> To libdbus for
> kdbus, that's happening in systemd.

No, systemd has a library called libsystemd-bus, which has nothing in
common with the current libdbus. It will not be compatible in any
sense, and cannot be made to provide the libdbus interface.

At this moment, we don't even know if it would even be possible to
efficiently use kdbus below the current libdbus. Kdbus is not socket
based, it's an entirely different way to pass messages between local
processes. Kdbus has very different life time rules of bus objects,
which do not really map to libdbus. Object you receive over kdbus are
owned by the bus and need to be given back to the bus. Someone could
wrap all that in additional copies maybe, but I'm not sure if that
would be a great model and worth the effort.

The current idea is that systemd will provide a bridge service, that
offers the current D-Bus socket, and an unmodified libdbus (or an
alternative implementation) can talk to that socket like it talks
today to the dbus-daemon. That bridge should still be more efficient
(fewer copies and system calls) than the current full userspace
routing, because on side of the communication is directly connected.
But again, we are not there, and will still take us a while. At the
moment there is nothing that can be used in any real system.

Thanks,
Kay