-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Thiago Macieira
>On sexta-feira, 1 de novembro de 2013 14:25:48, Carsten Haitzler wrote:
>> e_dbus and eldbus (the e one(s)) use libdbus - so if libdbus ports to
>> kdbus.. efl will be fine. :)
>
>That's not going to happen. libdbus-1 will not be ported because the
codebase is too hard to work with. One of the major sources of >performance
problems in D-Bus is the recursive marshalling code in that library, which
was written in
>2005 and was never optimised.
>
>In order to support applications that haven't been ported, kdbus will
provide a bus converter. That is, it will launch a separate daemon >instead
of dbus- daemon that will create the expected socket addresses and will do
on-the-fly translation from the protocol 1 messages on >Unix sockets to
protocol 2 messages on kdbus.
As you know, we have the working libdbus sources for kdbus already.
Our current solution for kdbus is included kdbus transport layer which is
added by Samsung.
Applications are using this kdbus transport layer when they are
communicating (ie. : send and receive messages) each other
by kdbus. So, we don't have to provide a bus converter which is you mentions
before in our solution.
We found out that using the kdbus for transport layer is more faster than
using the socket-based transport layer after testing our solution. Because
daemon is not involved in message routing (ie. : Message routing is handled
directly in kdbus.) and kdbus is supporting single-copy. We test it already
on x86 and arm based targets. I'll provide you our test results soon.
Best Regards,
Hyungjun.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
