"DBus Embedded" - a clean break

[Ed Hemphill]

I share in the need for your idea... We looked at dbus for our embedded
system, but in the end it was simply too complicated and slow. It's great
for the Desktop and its features are important and necessary. But it doesnt
fit the bill for embedded systems.

I also looked at Android's binder, but it is too heavy on Java. In the end
we ended up writing our own system. We mostly use Unix domain sockets which
are very fast on Linux. We go all binary. If you need to move really big
pieces of data shared memory would be great - we just dont need it.


Ed



On Thu, Jan 20, 2011 at 1:53 AM, Ville M. Vainio <vivainio at gmail.com> wrote:

> Just some subversive thoughts (not a practical development project for
> now):
>
> - Dbus is very slow. It's okay on desktop, but on mobile platforms
> it's suboptimal
>
> - It could be much (10x?) faster - switch to shared memory, posix
> message queues for data transmission (references to relevant shared
> memory blocks), do not do any verification
>
> - Switch to peer-to-peer communication as soon as possible while doing
> the handshake through daemon (minimize context switches, transmission
> counts).
>
> - It should be possible to make apps using libdbus to still work with
> this new structure, to retain application compatibility. Obviously
> wire protocol disappears completely.
>
> - Retain the current serialization functionality. However, provide a
> way to skip it (since people say it's one reason why dbus is slow) and
> transmit raw binary data very quickly.
>
> Implementing this might be easier than fixing dbus, and it could get
> rid of thread synchronization problems. It would definitely fix speed.
> Thoughts?
>
> --
> Ville M. Vainio @@ Forum Nokia
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20110120/478659c7/attachment.html>