From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 22 22:49:07 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2099986B for ; Mon, 22 Apr 2013 22:49:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id E0E6C1B61 for ; Mon, 22 Apr 2013 22:49:06 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 88FC8120207; Tue, 23 Apr 2013 00:48:51 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 7209F2848C; Tue, 23 Apr 2013 00:48:51 +0200 (CEST) Date: Tue, 23 Apr 2013 00:48:51 +0200 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: [patch] pipe2 Message-ID: <20130422224851.GA29525@stack.nl> References: <20130419224839.GA69212@stack.nl> <20130421210243.GA10436@stack.nl> <20130422173118.GQ67273@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130422173118.GQ67273@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 22:49:07 -0000 On Mon, Apr 22, 2013 at 08:31:18PM +0300, Konstantin Belousov wrote: > On Sun, Apr 21, 2013 at 11:02:43PM +0200, Jilles Tjoelker wrote: > > On Sat, Apr 20, 2013 at 12:48:39AM +0200, Jilles Tjoelker wrote: > > > I'm also working on pipe2() (using linuxulator work) and dup3() (patch > > > from Jukka A. Ukkonen). > > This is an implementation of pipe2. As with the accept4 patch, make > > sysent needs to be run in sys/kern and sys/compat/freebsd32. > > As a bonus, new architectures might implement pipe(p) as pipe2(p, 0) > > avoiding the need for assembler (but behaviour is different if the > > pointer is invalid). > I do not see anything wrong with the patch. That said, I prefer the > pipe(2) approach of delegating the access to the usermode memory to > usermode, which avoids the need of the calls to kern_close(). Delegating the access gives better semantics (a signal instead of an [EFAULT] error) but I don't like adding architecture-specific assembler wrappers like pipe.S. Also, different calling conventions than expected from the C level prototype may make things harder to understand. Perhaps the wrapper can be implemented in C with the below declarations but it is quite likely that this is not fully portable. struct pipereturn { register_t a, b; }; struct pipereturn __sys_pipe(void); -- Jilles Tjoelker