DBus in the kernel?

[Kimmo Hämäläinen]

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
> for the usual synchronous remote system call you need at least 4
> context switches. If we can get rid of the message dispatching in
> userspace we can reduce that to 2. On x86 the context switches
> might be cheap, but on other CPUs (ARM) they are not.

Would this happen to session busses as well, or only the system bus?

> 2) This could allow eventual implementation of zero-copy data
> transfer, which is already available for the traditional socket
> types. That could make dbus viable as a trasnport for substantial
> data, e.g. PCM data or video frames.

Shared memory implementation would remove the daemon also, and reduce
memory copies, but I guess it's too tricky to implement.

> 3) This can fix priority-inversion problems, since two high-priority
> processes would not have to wait for a non-high-prio dbus daemon to
> dispatch things. (unless you make the whole daemon high-prio which is
> dangerous too however). This is actually a real problem.
> 
> And then, besides that it makes a lot of things more light-weight,
> since memory consumption and copying is reduced, hence less cache
> pressure, fewer processes, fds, other resources...

Yeah, but there are bad sides as well, such as kernel stability and
application dependency to a specific kernel version/API.

-Kimmo

> 
> Lennart
>