Off-topic: D-Bus in the kernel

[Havoc Pennington]

Hi,

On Tue, Sep 21, 2010 at 8:49 AM, Marcus Brinkmann
<marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> Instead of agreeing or disagreeing, I would wish for something else: That any
> design decisions in free software in general, and in an IPC system in
> particular, and especially for an IPC system in the kernel, are based on solid
> design principles that are articulated and defended.
>

The intro to the spec tries to answer this:
http://dbus.freedesktop.org/doc/dbus-specification.html

A couple of omitted things there include,
* "low-overhead" and efficiency requirements in general don't extend
to "lots of data"; dbus is a "control" rather than "transfer" protocol
* "low latency" refers to the lack of need to block on a round trip,
not to the length of time spent on a round trip
* ease of use generally trumps performance in the design, the
performance goals were to avoid blocking round trips and avoid huge
overhead like XML parsing, but while avoiding those major nasties,
being significantly slower than raw sockets was considered fine
* there is absolutely no attempt to have anything to do with what
server developers usually think of as "messaging"; dbus has zip, zero,
nada to do with distributed computing

An important point the spec intro does mention offhand is that dbus is
as much about some "process lifecycle and discovery" facilities as it
is about IPC. The problem being solved was not primarily "how do I
marshal an integer on the wire" but more "how do I start up and locate
and keep track of the things to send my integer to"

Havoc