Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> Look, us kernel developers only work on one huge, multithreaded, global
> state binary.  Our experience in multi-application interactions with
> shared state and permission requirements is usually quite limited.  If
> you don't trust the developers of those programs outside the kernel,
> don't use them, there are still distros out there that don't require
> them.

Speak for yourself. There are a lot of us here who work and have worked
on low level messaging, on networking, on clusters and on things like
distributed shared memory, infiniband etc. I've worked on networks,
including broken stateful protocols, I've maintined and developed
internet and ISDN router code, I've worked with message passing realtime
systems.

Equally the folks who wrote dbus generally also know sweet fa about
writing a kernel and maintaining it for 25 years. Gtk is on its 3rd
completely incompatible instance (and has incompatibilities even within
major versions), Gnome is on its third major incompatible release -
closer would be to say at least the "second project with the same name",
and neither are as old as the kernel.

dbus is not an appropriate design for a kernel messaging layer for a
variety of reasons. That's not to say dbus shouldn't be able to use a
fast kernel messaging layer, or that one shouldn't exist.

dbus is basically a very large very specialized and somewhat flawed
policy engine on top of what should be simple messaging. The two need
splitting apart.

Abstract low level messaging layers are not a new concept. V7 unix had
one experimentally. It's about getting the separation right.

IMHO that probably involves getting the right people in the right place
together - dbus designers, MPI and realtime people, kernel folks and
possibly also some of the hardware messaging folk.

In filesystem terms

- stop writing a dbus only file system
- figure out what a messaging "vfs" looks like
- figure out what an clean low level kernel model looks like
- figure out what has to be where to put the policy in userspace

What might also be worth review is how much dbus traffic actually ought to
be an object store implemented say with tmpfs and inotify type
functionality (or extensions of that) so that you can
set/read/enumerate/get change notifications on properties.

Alan