Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755318AbbDOLGv (ORCPT ); Wed, 15 Apr 2015 07:06:51 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:42997 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbbDOLGn (ORCPT ); Wed, 15 Apr 2015 07:06:43 -0400 Date: Wed, 15 Apr 2015 12:06:18 +0100 From: One Thousand Gnomes To: Greg Kroah-Hartman Cc: Jiri Kosina , 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: <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> In-Reply-To: <20150415085641.GH16381@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4035 Lines: 84 > To quote the email that he wrote: > The reason is that dbus views the world in a stateful way > assuming that connections, and name ownership, can be tracked > reliably. This is different from say http, and it's one reason > that people used to Internet-oriented protocols find dbus > strange. > > I'm one of those "people used to internet-oriented protocols", and I bet > that almost all of us kernel developers also fall into that category, as > the kernel for the most part, is one big tool to help implement those > Internet-oriented protocols :) I worked on protocols with state. I suffered X.25, X.29, coloured book, ISDN. It's a completely *crap* model. It has unfixable reliability problems. It has unfixable flow control problems. The only thing it buys you is the ability to have more traffic in flight between end points than you have transient memory for at the endpoints. You don't need a grand unified state to track service locations and access (ie names), which is fortunate or we'd be rebooting the internet and all attached computers all the time. > The very history of D-Bus, where it came from, who is now using it, what > happened to all of the other proposed solutions in this area, is worth > examining if you are interested in it. This type of protocol solves a History is why you got where you did. The history of Windows 98 explains how they got there. It doesn't mean that continuing the same mistake is a good idea. > embedded systems, desktops, you name it. All languages have bindings > for it, and it's the underpinning of a modern Linux stack. For us to Everything used to have just a choice of COBOL or FORTRAN bindings. That was not a good reason to continue to program the world in either of them. > that anyone here does either. In the many years I've spent working on > this, dbus has seemed to be odd, and strange, to the way that the kernel > has normally worked, because it is. And that's not a bad thing, it's > just different, and for us to support real needs and requirements of our > users, is the requirement of the Linux kernel. There are I think a set of intertwined problems here - An efficient delivery system for multicast messages delivered locally (be that MPI, dbus whatever - it's not "dbus or nothing") - A kernel side dynamic namespace to describe what goes where - A kernel side security model to describe who may receive what, and which additional information/tags/cred info - Something that provides state to stuff that needs it (and probably belongs in userspace - dbus name service etc) - Something that maps dbus and other models onto the kernel security model (and we have tools like EBPF which are very powerful) - Something that maps the kernel layer onto models like MPI-3 > Now if there are technical problems or insecurities in the proposed code > submission, wonderful, please let me know and I'll be glad to work to > address them. But let's just drop the whole "oooh, look, D-Bus is > horrible looking, we can't support that!", is not a valid justification. We can however leave it in userspace until we understand the right small clean way to support it and other needs. At the moment for example cluster people can't really use this stuff because its not network aware, and HPC people can't use it because it's got dbus hardwired into it so can't speak MPI-3 and the like even though MPI 3 has similar concepts around DPM, as well as having proper models for parallelism and collective operations that are lacking in dbus. If the userspace folks choose to continue to implement dbust over it but the kernel layer is clean and generic then all is good, because someone can replace dbust with something better. If its got dbust hard wired into it then its a complete mess. Alan -- 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/