On 20/03/13 22:35, Lennart Poettering wrote:
> kdbus is a new kernel implementation of D-Bus that Kay and Greg have
> been working on.
Please talk to the D-Bus maintainers about any reimplementations or
replacements for D-Bus; we are on d...@lists.freedesktop.org.
(Cross-posted.)
Which parts of the D-Bus Specification does kdbus use?
* I assume it uses the type system and the concepts of object paths and
bus names, otherwise it'd be a pretty big stretch to call it "D-Bus"
at all.
* Does it have the same message semantics as traditional D-Bus
in terms of message headers, senders being unforgeable unique names,
broadcast/unicast signals, unicast method calls, unicast
replies/errors, guaranteed delivery, stuff like that?
* Does it have the same ordering guarantees (messages are
totally-ordered) as D-Bus? If not, what partial-ordering guarantees
*does* it give? (Causal ordering, perhaps?)
* Does it use the D-Bus message serialization format ("wire format")?
* Does it use the D-Bus SASL handshake?
> d) Port gdbus + classic libdbus.so to become clients for kdbus, too.
How do the other reimplementations of D-Bus (I am aware of at least
ndesk-dbus (C#), dbus-java, haskell-dbus, and Net::DBus (Perl)) interact
with kdbus? For instance, is there a bridge to the traditional D-Bus
wire protocol over Unix/IP/IPv6 stream sockets?
As far as I understand it, in the AF_BUS patchsets, the dbus-daemon
listened on both AF_BUS and stream sockets and bridged messages where
necessary, allowing interoperability without a flag day
(AF_BUS-to-AF_BUS messages bypassed the dbus-daemon entirely, while
AF_BUS-to-stream and stream-to-stream messages continued to pass through
the dbus-daemon). Obviously, anything requiring the performance gains of
a kernel-assisted transport still requires porting, but there doesn't
have to be a flag day.
S
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
