Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755358AbbDUNSs (ORCPT ); Tue, 21 Apr 2015 09:18:48 -0400 Received: from pb-sasl1.int.icgroup.com ([208.72.237.25]:51424 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752263AbbDUNSo (ORCPT ); Tue, 21 Apr 2015 09:18:44 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; q=dns; s=sasl; b=jqWAJoWOWPdv6eVBVUCcaUQrtNhIxlEh SBvfR+Dr+dEl4deatHt97I0vVVHygeft3xLMq+PG+3v98YAniNNLLLBQMgTDTNVm f/BzLJwoNZpcUV7yNcC1ZaMeOh9HYzZ6Ine0gJpFGW94epX6R24GVCzFIBiypdLJ OhshiNnPmZs= MIME-Version: 1.0 In-Reply-To: <20150421103128.GA4870@kroah.com> References: <20150420205638.GA3015@kroah.com> <55356CC1.1040301@nod.at> <20150420214651.GA4215@kroah.com> <20150421103128.GA4870@kroah.com> Date: Tue, 21 Apr 2015 15:18:35 +0200 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: Olivier Galibert To: Greg Kroah-Hartman Cc: Andy Lutomirski , Richard Weinberger , David Herrmann , Linus Torvalds , Steven Rostedt , One Thousand Gnomes , Jiri Kosina , Al Viro , Borislav Petkov , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: EB4D1510-E828-11E4-9827-CB91CE401EC2-92059326!pb-sasl1.pobox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1364 Lines: 27 On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman wrote: > Bringing up SCM_RIGHTS means that this is not going to be a bus system > at all. One principal design goal is to _not_ have peer-to-peer > connections between all communicating parties, but rather one connection > to a central component. If that component is not in the kernel, it has > to be a userspace deamon, which in turn has all of the issues that > dbus-daemon currently has. You're not making sense there. If there is no daemon, then you're peer-to-peer, because there's no central component. If you consider the kernel the central component, then peer-to-peer is almost impossible by definition. It seems that almost everybody here thinks that the plumbing (e.g. transmitting messages in-order with multicasting) should be separated from the policy (who communicates with who), possibly leveraging the packet filtering infrastructure to implement the decided policy. What it is you reject about that point of view, which seems relatively normal when you think about building a collection of useful tools? OG. -- 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/