"DBus Embedded" - a clean break

[Lennart Poettering]

On Thu, 20.01.11 13:05, Havoc Pennington (hp at pobox.com) wrote:

> 
> Hi,
> 
> You're just assuming a bunch of stuff here.
> 
> On Thu, Jan 20, 2011 at 2:53 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> > - It could be much (10x?) faster - switch to shared memory, posix
> > message queues for data transmission (references to relevant shared
> > memory blocks), do not do any verification
> 
> Do not do any verification is clearly faster, but is already possible
> with a 1-line change to the current code (grep for
> DBUS_VALIDATION_MODE_DATA_IS_UNTRUSTED)
> 
> shared mem / message queues are only hypothetically faster than unix
> sockets, at best. Once you add the locking and other crap to use them
> you are likely to end up without a huge win.
> unix sockets are *fast*

Also, using SHM as transport is incredible hard to get right due to
security. Due to the locking it is basically impossible to use it across
user boundaries (since you cannot allow normal processes to freeze the
system bus), which limits its use drastically, i.e. to the session/user
bus only. Of course one way out of that would be to do things
lock-lessly, but that just creates more problems than it solves.

In PA I implemented an SHM scheme, and I can tell you that it is
extremely hard to get this right, for example refcounting memory blocks
between processes in a robust way is so difficult it really hurts. And
if you then care about more than just Linux you are one step before
going insane.

Instead of adding an additional transport using SHM I think the time is
better spend on fixing the current socket logic. For example Albain's
work on mcast support for AF_UNIX should allow us to get rid of the
double context switching but is useful even outside of D-Bus and follows
existing semantics. Instead of doing userspace-only SHM it might make
sense to do this with kernel help, and support zero-copy socket
operations in some way. Of course, this all would be kernel hacking, but
I think this would actually drastically simplify a lot of things. For
example, the security issues regarding userspace-to-userspace locking go
away completely if you do this in the kernel.

So I agree completely with Havoc. The socket transport is not slow. And
if it can be improved in some areas, then improve it in-place, don't
create something new, that tries to bypass the socket logic altogether.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.