Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756128AbbDOQBk (ORCPT ); Wed, 15 Apr 2015 12:01:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36180 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755050AbbDOQBc (ORCPT ); Wed, 15 Apr 2015 12:01:32 -0400 Message-ID: <552E8B11.4010803@redhat.com> Date: Wed, 15 Apr 2015 12:00:17 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: One Thousand Gnomes , 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 References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> In-Reply-To: <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1732 Lines: 40 On 04/15/2015 07:06 AM, One Thousand Gnomes wrote: >> 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 It is not clear to me why user space applications would have to change if the kernel bus used for dbus behaves differently from the userspace dbus daemon. Can't libdbus take care of the differences, and remove some of the problems highlighted by Alan (eg. the possibility of the protocol requiring the kernel to keep more messages in flight than we have memory for) ? -- 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/