Skip site navigation (1)Skip section navigation (2)
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>