linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEntwhGY4Tix3NG_GU4+zTUiWEM=XGpNPwb5LnfPXamKe5oFLA@mail.gmail.com>
Date:	Thu, 16 Apr 2015 12:02:06 -0400
From:	Havoc Pennington <hp@...ox.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Wed, Apr 15, 2015 at 6:22 PM, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/