Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753752AbbDPRQO (ORCPT ); Thu, 16 Apr 2015 13:16:14 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:44953 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752212AbbDPRQE (ORCPT ); Thu, 16 Apr 2015 13:16:04 -0400 Date: Thu, 16 Apr 2015 18:15:18 +0100 From: One Thousand Gnomes To: Daniel Mack Cc: Havoc Pennington , Rik van Riel , Greg Kroah-Hartman , Jiri Kosina , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150416181518.2cb4d6b5@lxorguk.ukuu.org.uk> In-Reply-To: <552FB5B4.9060700@zonque.org> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> <552E8B11.4010803@redhat.com> <20150415230816.657d2130@lxorguk.ukuu.org.uk> <552FB5B4.9060700@zonque.org> 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: 1401 Lines: 29 > And so does kdbus. By default, strict ordering is enforced when messages > are received, but optionally, that action may be constrained to messages > of a minimal priority. This allows for use cases where timing critical > data is interleaved with control data on the same connection. That's > described in kdbus.message(7), and is also covered by test cases. More to the point "and so do POSIX message queues". They are also a standard, a cross OS feature and relatively cleanly implemented in kernel, ditto some classes of socket behaviour are similar and SYS5 IPC (of which we shall not speak further I hope 8) ). I'm not saying that they solve the problem but they might avoid some of the complexities. Filtering is generalizable in Linux with a few lines of code, so rather than hardcoding dbus semantics EBPF can express pretty much any uni/multi/broadcast filtering policy rule for dbus or anything else. I agree entirely with Havoc that the ease of use wants to be preserved and semantics at the top of the dbus library shoudn't change. Dbus does have the problem of being too easy to use badly, but that's hard to fix technically 8) 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/