Re: Proposal to obsolete SYS_pipe

[christos%astron.com@localhost (Christos Zoulas)]

In article <e9f31472-83c5-d3d1-66c1-110a635a4f82%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 25.12.2017 03:42, John Nemeth wrote:
>> On Dec 24,  9:37pm, Mouse wrote:
>> }
>> } > http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt
>> } 
>> } I see no pipe2(2), nor change from pipe(2) to pipe(3) (with an xref to
>> } pipe2(2)), both of which, it seems to me, should be part of this.
>> 
>>      From: http://netbsd.gw.com/cgi-bin/man-cgi?pipe2+2+NetBSD-current
>> 
>> HISTORY
>>      A pipe() function call appeared in Version 6 AT&T UNIX.  The pipe2()
>>      function is inspired from Linux and appeared in NetBSD 6.0.
>> 
>> My NetBSD 7.x systems have the manpage as well.  One might wish to
>> look for manpages on a system newer then 1.4T.  :->
>> 
>>      The big thing is that I don't see what the difference between
>> pipe(2) and pipe2(2) are, other then that pipe2(2) takes an extra
>> flags argument, i.e. I don't see how it solves the problem stated
>> in the original message.
>> 
>
>The original problem:
>
>__syscall(SYS_pipe2, ... works, while syscall(SYS_pipe, ... is not
>easily usable.
>
>It's stated in the BUGS section of syscall(2):
>
>BUGS
>     There is no way to simulate system calls that have multiple return
>values
>     such as pipe(2).
>
>
>This propagates to rump special case handling and requests to use
>assembly snippets for every supported CPU. It might save little space in
>the kernel, but also save time of a developer porting the OS to a new
>CPU. Nobody will need to spend precious time on pipe.S anymore.
>
>I cannot remove entirely SYS_pipe, as it is used in software that bypass
>libc (like golang). Once compat_80 will be disabled at least in the
>default kernels, it will be gone from regular users. pipe2(2) is there
>since 5.99.x, and switching golang and other users to SYS_pipe2 won't
>affect any users of supported kernel versions.
>
>I've just entirely removed sys_pipe from rump and adjusted the needed
>code. There is certainly more room now to further simplify the rump
>retval[] code,but I have omitted it.
>
>I've skipped the change renaming or splitting the man pages.

It does not really matter; there are other syscalls that do this hack
like getpid() (ppid == retval[1]), get{u,g}id return the
(e{u,g}id == retval[1])... We'll need the compat code anyway in the
kernel (and perhaps in libc) since pipe is a bit popular -- which actually
makes it annoying because you'll only discover that you don't have the
compat code around unexpectedly. I don't see much value added with the
change, you can always use syscall pipe2 and the userland pipe() can use
pipe2(). I.e. I'd keep the kernel as is (we can always clean it up later)
and I would make the libc stuff use pipe2() so that the sanitizer parts
don't need the hack to work.

christos