Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

On Wed, Apr 15, 2015 at 6:22 PM, One Thousand Gnomes
<gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
> Actually most message passing code uses things like JMS and the various
> MQ libraries. Most IoT uses things other than dbus, small deep embedded
> never uses dbus.

fwiw, to me it's a mistake to think of dbus as "the same space" as
something like JMS, or even small deep embedded uses.
The use cases and appropriate tradeoffs are different enough that it's
hard for me to think about them as one thing.

If different uses can share some common kernel mechanisms then great,
but one does have to be careful about
one-size-fits-all-actually-fits-nobody.

> In the desktop space dbus wins because its very very easy to use and by
> network effects. Everything else related already talks via dbus, so you
> are going to have to talk dbus anyway to get anything done.

You may agree with me, but to me "easy to use" is necessary to dbus's
utility - it's not a cosmetic feature.  I was on the receiving end of
the Linux desktop bug firehose both pre-dbus and post-dbus, and having
IPC that's easy to use *correctly* means there are fewer bugs in that
firehose. At least, fewer bugs caused by IPC.

Of course, the thing that needs to be easy is the library API; it's OK
if an underlying kernel API is hard, as long as it gives the library
developers what they need to implement the easier API.

It is OK to push complexity onto userspace, but it's a mistake to push
it onto apps (as opposed to libraries that can be gotten right once
for all apps). If you push complexity onto apps you get buggier apps,
because application developers are experts in their app domain but
aren't experts in every underlying platform feature.

Why is dbus relatively easy to use? Some important pieces:

 - the semantic guarantees such as ordering that we've already mentioned
 - completeness - solves locating and tracking other processes, solves
both unicast and broadcast, etc.
 - defines a mapping to objects-with-methods OO model

Can it be even better - for sure.

Havoc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/