Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756292AbbDOWLr (ORCPT ); Wed, 15 Apr 2015 18:11:47 -0400 Received: from mail-la0-f46.google.com ([209.85.215.46]:36598 "EHLO mail-la0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752916AbbDOWLj (ORCPT ); Wed, 15 Apr 2015 18:11:39 -0400 MIME-Version: 1.0 In-Reply-To: <20150415225611.0c256ea6@lxorguk.ukuu.org.uk> References: <8738434yjk.fsf@x220.int.ebiederm.org> <20150413194217.GA10837@kroah.com> <20150413202233.GR889@ZenIV.linux.org.uk> <20150415084812.GG16381@kroah.com> <20150415122555.74258d63@lxorguk.ukuu.org.uk> <20150415154551.GE6801@home.goodmis.org> <20150415163520.GA25105@kroah.com> <20150415130649.6f9ab20f@gandalf.local.home> <20150415173145.GA26146@kroah.com> <20150415225611.0c256ea6@lxorguk.ukuu.org.uk> From: Andy Lutomirski Date: Wed, 15 Apr 2015 15:11:17 -0700 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: One Thousand Gnomes Cc: Greg Kroah-Hartman , Steven Rostedt , Richard Weinberger , Al Viro , "Eric W. Biederman" , Linus Torvalds , Andrew Morton , Arnd Bergmann , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3127 Lines: 68 On Wed, Apr 15, 2015 at 2:56 PM, One Thousand Gnomes wrote: > On Wed, 15 Apr 2015 19:31:45 +0200 >> Don't make idle comments, the tty layer is far more complex and larger >> than the kdbus code, with much nastier issues and problems. And we >> handle that just fine :) > > The tty layer is the way it is because of design decisions dating back 20 > years that were (with hindsight) wrong coupled with the fact that POSIX > took a lot of the behavioural guarantees from an armwaving claim about > what Unix(tm) implemented without thinking about how to implement them > (as far as I can tell - given many of the guarantees are broken in Unix!) > >> I'll again refer to ALSA here, no one writes a "raw" ALSA program, they >> all use the library to interact with the kernel. Do that here, there >> are wonderful dbus libraries out there, for all languages. Use them >> instead. > > Agreed entirely - I don't disagree that we need a fast messaging layer. > The question is what bits belong in kernel. Go wants one, JMS wants one, > porting from stuff like QNX wants one (although they use the POSIX API > on QNX), MPI wants one (but with some useful and subtly different > semantics), various embedded things from tiny uKernels want one. > > The question is what the kernel bit should actually look like, and how > many we need. > > My guess is that we actually have three of the big use cases covered > > - futexes and shared memory cover the tiny uKernel emulation bits (and on > a lawnmower engine sized ARM thats probably the only way to get the > speed approaching that of a tiny rtos) > - posix queues cover things like QNX porting > - publish/subscribe - via tmpfs > > but we don't cover > > - multicasting > - some types of credential and authority passing > - scatter/gather without excessive userspace wakes I would really like to see a very lightweight capability-based messaging system. By "capability-based" I don't mean Linux capabilities. I mean that a user program could give some very lightweight token to a peer authorizing that peer to use some service (by reference to the same token), and the peer could pass it on to other peers as an introduction mechanism. (Search for "capability-based security".) This is functionally identical to passing AF_UNIX socket fds over SCM_RIGHTS, but I want something much lighter weight. Also, getting the really high performance stuff right would be nice. Binder has one thing going for it (IIRC -- I've talked about it to some of the authors, but I've never so much as glanced at the code): it has a primitive to send and wait for a reply. This reduces the load on scheduler. I wish kdbus were blazingly fast, but I don't think it is :( I think the bar should be either similar performance to (peer-to-peer) AF_UNIX or something possibly more complex but considerably faster. --Andy -- 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/