On 25.12.2017 16:25, Christos Zoulas wrote:
> 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
>
I've extracted two changes from the original mail:
https://mail-index.netbsd.org/tech-kern/2017/12/25/msg022836.html
In my opinion they are an added value.
Attachment:
signature.asc
Description: OpenPGP digital signature