Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753863AbbDPQCw (ORCPT ); Thu, 16 Apr 2015 12:02:52 -0400 Received: from mail-qg0-f54.google.com ([209.85.192.54]:34093 "EHLO mail-qg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753486AbbDPQCh (ORCPT ); Thu, 16 Apr 2015 12:02:37 -0400 MIME-Version: 1.0 In-Reply-To: <20150415232218.7df214ba@lxorguk.ukuu.org.uk> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <20150414193533.GF889@ZenIV.linux.org.uk> <20150414194348.GA7540@kroah.com> <552EA700.7000200@gmail.com> <20150415232218.7df214ba@lxorguk.ukuu.org.uk> From: Havoc Pennington Date: Thu, 16 Apr 2015 12:02:06 -0400 X-Google-Sender-Auth: uUmAdjvq8rBRAUm-oIMhUvperf0 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: One Thousand Gnomes Cc: Austin S Hemmelgarn , Greg Kroah-Hartman , Al Viro , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2288 Lines: 50 On Wed, Apr 15, 2015 at 6:22 PM, One Thousand Gnomes 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/