Compatibility between D-Bus and kdbus

[Lennart Poettering]

On Tue, 25.11.14 11:24, Thiago Macieira (thiago at kde.org) wrote:

> Another point we have to take into account is that we'll have fewer rules now 
> because the syntax is simpler. The client library will need to sort out false 
> positives and drop unneeded messages. That said, the number can't be too 
> small.

Actually the kdbus match logic should not allow fewer rules, and the
syntax isn't any simpler. kdbus matches are as fine-grained as dbus1
matches, though they are probabilistic and might allow false
positives. In fact, since the bloom stuff cannot be used to match
against kernel signals like NameOwnerChanged you might need *more*
matches on kdbus than on dbus1...

> > > I'm not sure we need to keep the total ordering like you described. We can
> > > probably relax it a bit to simply ensure causality.
> > 
> > My experience from implementing a D-Bus subset over link-local multicast
> > on OLPC/Sugar, which explicitly didn't have better than causal ordering,
> > is that application authors don't understand causal ordering.
> 
> Understand or not, did it make a difference?
> 
> > > Will systemd-kdbus provide [o.fd.DBus] on the bus so applications that
> > > make
> > > calls directly be able to continue working?
> > 
> > My understanding is "no, but client libraries may catch those messages
> > and fake a reply".
> 
> I'd rather not intercept outgoing messages that aren't link-local. But if 
> that's what's needed, I'll do. Except for:

Note that in sd-bus case I decided not to do any emulation, and simply
declare that if you use sd-bus you also have to use sd-bus' own
high-level functions that then either use the ioctls as backend or on
dbus1 the bus driver. If you try to use the bus driver calls on the
kdbus backend of sd-bus then you will only get errors back...

Lennart

-- 
Lennart Poettering, Red Hat