DBus in the kernel?

[Lennart Poettering]

On Tue, 05.01.10 15:12, Michael Meeks (michael.meeks at novell.com) wrote:

> On Tue, 2010-01-05 at 15:06 +0200, Kimmo Hämäläinen wrote:
> > On Mon, 2010-01-04 at 22:55 +0100, ext Lennart Poettering wrote:
> > > On Mon, 04.01.10 16:40, Havoc Pennington (havoc.pennington at gmail.com) wrote:
> > > > What is the rationale for the bus itself in the kernel? Seems like one
> > > > big pain in the ass, and I can't guess the motivation...
> > > 
> > > Primarily three things:
> > > 
> > > 1) Getting rid of the double context switch for each msg. Right now
> 
> 	Soo - there seem to be, primarily a performance rational for this work,
> which is all well and good; but have people profiled dbus to find what
> is slow ? is it anything to do with the context switches (eg.) :-)

IIRC the collabora folks have some data on that, i think i even heard
something about a dbus profiler... Collaborateurs, say something!

For me personally the PCM data transfer stuff is the most
interesting. While I have not profiled D-Bus itself I have profiled
passing bigger PCM blobs via two unix stream sockets and two context
switches and I know how bad it is both for latency and for throughput,
and due to the marshalling dbus does doing the same via dbus would be
even worse.

> 	Finally, if the daemon is re-written to put in the kernel, hopefully
> it'll be a BSD licensed blob (?) that can be re-used in those other
> Unixen, such that we don't have to maintain the daemon  indefinitely in
> parallel ? :-)

Internally libdbus already abstracts transports. Maybe this is where
this actually might become handy.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4