Date: Tue, 23 Apr 2013 00:48:51 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] pipe2 Message-ID: <20130422224851.GA29525@stack.nl> In-Reply-To: <20130422173118.GQ67273@kib.kiev.ua> References: <20130419224839.GA69212@stack.nl> <20130421210243.GA10436@stack.nl> <20130422173118.GQ67273@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130422224851.GA29525>