DBus in the kernel?

[Thiago Macieira]

Em Terça-feira 05 Janeiro 2010, às 09:23:09, Luiz Augusto von Dentz escreveu:
> Hi.
> 
> On Mon, Jan 4, 2010 at 11:55 PM, Lennart Poettering <mzqohf at 0pointer.de> 
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.
> > 
> > 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.
> > 
> > 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...
> 
> If I remember correctly there is also some other benefits to the boot
> if the the system bus happen to be initialized by kernel as there are
> quite many dbus daemons nowadays. Anyway the 3 reasons you gave should
> be enough to convince most, including myself.

It's possible to solve those three problems without a kernel-based bus, by 
having a cooperating, decentralised system operating on SHM. It would be hard, 
but possible.

The problem with a cooperating system is that any malicious code could break 
it.

This could be solved by a "kernel-like" bus, by having a co-routine. My idea 
here is to have the bus code access some privileged resources but still run in 
each process. What I'd like to see is a context switch without a full context 
switch.

So, for example, dbus_connection_send right now acquires the transport lock, 
writes it to the socket and then unlocks. Instead, what it would do is that it 
would switch to "bus mode", read the filter rules, deliver message to each 
target process and notify them, then switch back to "user mode". Each target 
process would already have the data ready to be read (or mapped via some 
shared memory mechanism). 

This could not be done without some kernel help though, since nothing in POSIX 
right now allows us to make this mechanism secure. My "switch to bus mode" 
above would require that libdbus-1 code (and only that code) be able to access 
some shared resources.

This of course is the result of a few minutes' thinking. It doesn't take into 
account blocking situations, etc.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20100105/ee493809/attachment.pgp