Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933571AbbDPKcD (ORCPT ); Thu, 16 Apr 2015 06:32:03 -0400 Received: from svenfoo.org ([82.94.215.22]:45460 "EHLO mail.zonque.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753242AbbDPKbz (ORCPT ); Thu, 16 Apr 2015 06:31:55 -0400 Message-ID: <552F8F97.3040208@zonque.org> Date: Thu, 16 Apr 2015 12:31:51 +0200 From: Daniel Mack User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andy Lutomirski , 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" , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1492 Lines: 33 On 04/16/2015 12:11 AM, Andy Lutomirski wrote: > 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. kdbus has the same thing, we call it a synchronous reply. That concept is actually comprehensively explained in kdbus.message(7): By default, all calls to kdbus are considered asynchronous, non-blocking. However, as there are many use cases that need to wait for a remote peer to answer a method call, there's a way to send a message and wait for a reply in a synchronous fashion. This is what the KDBUS_SEND_SYNC_REPLY controls. The KDBUS_CMD_SEND ioctl will block until the reply has arrived, the timeout limit is reached, in case the remote connection was shut down, or if interrupted by a signal before any reply; see signal(7). The offset of the reply message in the sender's pool is stored in in offset_reply when the ioctl has returned without error. Hence, there is no need for another KDBUS_CMD_RECV ioctl or anything else to receive the reply. Thanks, Daniel -- 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/