DBus in the kernel?

[Lennart Poettering]

On Tue, 05.01.10 15:06, Kimmo Hämäläinen (kimmo.hamalainen at nokia.com) wrote:

> > 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?

The plan was to have an AF_DBUS socket implementation that can be used
to allocate as many busses you want to have.

> > 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.

All-userspace shm implementatins are immensly hard to get right in a
safe way: if you use SHM a rogue participant can always truncate the
memory segment triggering a SIGBUS on the other side when it acesses
the region. SIGBUS could be handled but you really dont want to do
that from a library. 

I don't think it would be worth doing userspace zero-copy. I did it
for the PulseAudio transport, and I can say it is a nightmare and only
is safe as long as you can trust both sides.

> > 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.

Uh? Nothing would change for the apps, they would continue to use the
traditional libdbus iface.

And anyway, I dont believe in "dependency hell". It's not a real
problem.

Lennart

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