Off-topic: D-Bus in the kernel

Marcus Brinkmann marcus.brinkmann at
Tue Sep 21 05:49:13 PDT 2010

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.

For DBus, alas, I find it hard to find any documentation in this regard.
seems to come close, but it is actually a negative statement, in that the
stated requirements are peripheral (control, license, implementation language
etc).  If DBus were a stable interface, its properties could be analyzed after
the fact, but the discussion on file descriptor passing for example showed
that there is still substantial flux.


More information about the dbus mailing list