Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754047AbbDOMlr (ORCPT ); Wed, 15 Apr 2015 08:41:47 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:37147 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716AbbDOMli (ORCPT ); Wed, 15 Apr 2015 08:41:38 -0400 Date: Wed, 15 Apr 2015 14:41:34 +0200 From: Greg Kroah-Hartman To: One Thousand Gnomes Cc: Jiri Kosina , Al Viro , Borislav Petkov , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415124134.GC20554@kroah.com> References: <20150414192357.GA6107@kroah.com> <20150414192429.GC26075@pd.tnic> <20150414193229.GB6107@kroah.com> <20150414194004.GG889@ZenIV.linux.org.uk> <20150414194804.GB7540@kroah.com> <20150415113727.0cfd5224@lxorguk.ukuu.org.uk> <20150415114936.GD19274@kroah.com> <20150415130354.458abfc2@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150415130354.458abfc2@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4290 Lines: 96 On Wed, Apr 15, 2015 at 01:03:54PM +0100, One Thousand Gnomes wrote: > > > There is no comparison between the elegance of X11 property setting and a > > > chunk of proposed kernel code that is half the size of a tiny X server! > > > > Hey, take that up with Havoc, he made the comparison :) > > And it concerns me you blindly repeat it without realising its wrong. It's a metaphor that makes sense to me given my limited knowledge of the x11 protocol. If it's wrong, ok, I'm willing to learn, but I think it's still relevant here. > > > The dbus model is also flawed in a load of other ways in user space > > > because message handling in the hands of people with no concept of > > > systemic performance analysis just leads to disaster. One of the big > > > reasons dbus is so "slow" isn't that dbus is "slow", it's that the > > > crapware on top of it makes *thousands* of dbus queries. > > > > There's the issue of thousands of dbus queries, and then there's the > > issue that making those queries takes a measurable amount of time. We > > can fix the later one, the first one, well, not so much, but we can > > provide the resources for them to make a faster system if they want to. > > If you fix the thousands of queries problem do you need kernel help at > all. I've worked with developers of such systems, and no, they can't fix that problem. They are using "legacy" applications that they have to run on some type of operating system, and really don't want to use legacy operating systems anymore. Those "legacy" oses provide a system bus that allows them to send thousands of queries just fine, but when moving to Linux, we don't have anything other than D-Bus, so their library is ported to use it, and they have to handle their old applications that need/want the zillions of messages. Then they thow the thing on a very underpowered ARM processor and complain about boot time being so slow, but that's a different issue... > > The internet model with state in the endpoints doesn't always transfer > > properly to local applications, see Havoc's email for the details about > > that. > > URL ? > > (note how beautifully btw the stateless network and the URL string will > become a reference to state) Heh, yes, but there's very little state here: http://lists.freedesktop.org/archives/dbus/2015-April/016651.html There's also a follow-on message from the current D-Bus maintainer: http://lists.freedesktop.org/archives/dbus/2015-April/016653.html > > > It's telling that I can lose and recover my internet connection without > > > rebooting but not my desktops internal messaging. > > > > Yes, as those are totally different things, let's not mix the issue up > > here please. > > They are *NOT* different things. They are fundamental properties of the > underlying architecture. I worked on stateful networks and still have > the scars. It is a fundamental property of stateful network that every > time any key component goes castors up you lose the lot. It is a fairly > fundamental property of stateless networks that equipment going castors > up has no material impact on the network > > The internet is built upon three fundamental breakthroughs in technology > > - That stateless networks scale and can be reliable while stateful ones > cannot scale and cannot be fixed to do so > > - That flow control is possible over a stateless network > > - That efficient data routing is possible over a stateless network > > Those are absolutely critical parts of any network or messaging > implementation. People take those stateless models and build stateful ones on top of them, yes, it's great. But you still need a stateful model somewhere in order to be able to achieve many things (think a shopping cart application). Anyway, this is getting off-topic, there is very little "state" in the kdbus kernel code here, other than a naming database that Havoc and Simon explain the need for, and the normal lifecycle of kdbus "nodes" (new, linked, active, inactive, drained, freed). thanks, greg k-h -- 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/