Re: [Ksummit-discuss] [TECH TOPIC] Bus IPC

[Josh Triplett <josh@joshtriplett.org>]

On Mon, Aug 01, 2016 at 12:36:07PM +0200, David Herrmann wrote:
> Hi Josh!
> 
> On Sun, Jul 31, 2016 at 12:21 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Fri, Jul 29, 2016 at 12:24:03AM +0200, David Herrmann wrote:
> >> Tom Gundersen and I would like to propose a technical session on
> >> in-kernel IPC systems. For roughly half a year now we have been
> >> developing (with others) a capability-based [1] IPC system for linux,
> >> called bus1 [2]. We would like to present bus1, start a discussion on
> >> open problems, and talk about the possible path forward for an upstream
> >> inclusion.
> >>
> >> While bus1 emerged out of the kdbus project, it is a new, independent
> >> project, designed from scratch.
> >
> > I'd heard that the plan for bus1 was to provide DBus-compatible
> > semantics via a userspace compatibility layer.  Do you still plan to do
> > that, so that current users of DBus can run on bus1 without
> > modification, or will current users of DBus need to port to bus1?
> 
> DBus has very limited requirements to the transport layer, so bus1
> would work just fine. If you want to get rid of the broker, though,
> you need to support some of the quirks of DBus. Most importantly,
> dbus-daemon supports almost arbitrary broadcast-filters of any
> transmitted broadcast message, as well as a very expressive policy
> language to perform per-message filtering. We do not support either on
> bus1, since we abstain from any global state. Hence, you cannot get
> rid of the broker if you use bus1 as DBus transport.
> 
> Having said that, we still believe that DBus will not go away over
> night, and we do want to improve it. By restricting the dbus-spec to
> destination-based broadcast-filters, and employing a replacement
> policy language similar to the one of kdbus, you can shortcut the
> broker, though. All you would need for DBus-compatibility is a
> bus-manager that connects peers according to the policy, but it would
> no longer route messages. Furthermore, by shifting DBus to
> signal-subscriptions rather than signal-matching, we do pave the way
> for a future without such a bus-manager.
> If there are clients incompatible to the mentioned restrictions to the
> DBus spec (and I am unaware of any besides 'dconf', which we know
> workarounds for), a bus-broker can always be employed as an add-on,
> thus keeping full DBus compatibility.

A compatibility broker in userspace seems fine for compatibility; I just
wanted to learn more about the plan to handle that.

- Josh Triplett