From owner-freebsd-current@FreeBSD.ORG Tue May 28 09:43:35 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DF446B0 for ; Tue, 28 May 2013 09:43:35 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 32B6A838 for ; Tue, 28 May 2013 09:43:34 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r4S9hNLl041676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 09:43:24 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: copyin+copyout in one step ? From: David Chisnall In-Reply-To: Date: Tue, 28 May 2013 10:43:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D03D7B6-7530-4CCD-859B-FD6374E40424@FreeBSD.org> References: <20130527233801.GA32042@onelab2.iet.unipi.it> To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1503) Cc: Luigi Rizzo , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 09:43:35 -0000 On 28 May 2013, at 05:56, Zaphod Beeblebrox wrote: > Urm... Isn't the use of shared memory the more obvious way to transfer = data > between processes? Am I missing some nuance? I can't speak for Luigi's use-case, but the Binder APIs in BeOS and = Android call for this kind of copy. The receiving process contains a = ring buffer and the messages are pushed into it. You could implement = this in shared memory, but only if you trusted the sender not to modify = the data at incorrect times or write invalid values into the metadata = (or, in the case of Binder, to forge the pid / uid of the sender, which = it attached to each message). The kernel must act as an intermediary to = enforce correct use of the buffer and also to allow the caller to block = until space is available (perhaps by scheduling the receiver to run for = a bit) without spinning and to allow multiple writers to be queued when = there is no space, rather than have them racing. The buffers are in the = receiver's memory space because it is designed for resource constrained = environments and for malicious parties to communicate, so it avoids a = potential DoS by filling up kmem with buffers - a process that create a = load of receive ports will simply fill up its own address space and die. In the specific case of binder, you can avoid the overhead of extra VM = lookups by mapping the buffer into the address space of every sender = when you open the connection, but marking its access as privileged mode = only. This means that you'll be doing a simple copy. You can also = align the receive buffer in such a way that the consume counter is on a = different page to the rest of the data structure, allowing you to get a = page fault when the buffer transitions from full to non-full and there = are messages waiting. David