Off-topic: D-Bus in the kernel

[Lennart Poettering]

On Tue, 21.09.10 14:49, Marcus Brinkmann (marcus.brinkmann at ruhr-uni-bochum.de) wrote:

> On 09/17/2010 06:14 PM, Thiago Macieira wrote:
> > Em Sexta-feira 17 Setembro 2010, às 17:38:19, Stef Bon escreveu:
> >> Well maybe fascinating, and possibly technical a challenge and possible,
> >> but the question is about do we want a inter proces communication suite 
> >> to be in the kernel??
> >>
> >> In my opinion this should not go into the kernel. This is not the task 
> >> of the kernel.
> > 
> > I quite disagree. I think that an IPC mechanism providing rendezvousing and 
> > routing of messages (many-to-many) is quite welcome and should be provided by 
> > the kernel.
> 
> 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.
> 
> My understanding is that DBus has come from the Gnome experience with Corba
> and other similar systems (specifically dcop).  My personal experience is from
> microkernels (Mach, L4, KeyKOS/EROS), which also provide communication
> facilities (in fact, that and memory/cpu management are their main features).
>  And the facilities that the latest generations of microkernels provide look
> nothing like DBus.  Without going into details, at least for the design of
> those IPC systems their reasons are well articulated and documented.  The
> desired properties are stated and the design is shown to fulfill these demands.

Well, there's quite a bit of a difference between IPC for microkernels
and IPC for ... well ... real-life applications.

Note that the D-Bus spec in great detail focusses on marshalling and
validation of marshalled data. To my knowledge this is out of scope for
the microkernel stuff but crucial for usage in desktopy apps, and hence
you are comparing oranges and apples.

Note that the D-Bus marshalling and semantics are actually flexibly
enough defined so that we could add additional transports underneath. A
longterm item on the todo list for example is an SSL transport. And
similarly you could of course implement a microkernel transport for this
too.

The way I see D-Bus is that it mostly focusses on the logic that's above
the transport layer. Since sockets are the primary IPC system on
Unix-like systems (and as a matter of fact on almost all other real-life
systems too) the spec then goes on and defines the protocol how it is
used for AF_UNIX and AF_INET sockets. But that doesn't mean that one
a) couldn't port it to other transports or b) couldn't extend the
current transports in a comptible fashion to learn new tricks.

Note that local multicasting has been available on Linux for quite some
time in the AF_NETLINK protocol, and is widely used (for example libudev
is based on it). Like almost any other real-life multicasting it is not
reliable however, and drops packets when the recv queues run over.

That siad, if you limit yourself to POSIX then you don't get this
functionality. But well, my recommendation is to forget about POSIX and
just take Linux as the standard interface to code against.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.