Re: Proposal to obsolete SYS_pipe

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Mon, Dec 25, 2017 at 16:37:43 +0100, Kamil Rytarowski wrote:

> On 24.12.2017 22:25, Kamil Rytarowski wrote:
>
> > http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt
> 
> I've extracted two patches from the above proposal.
> 
> In these patches SYS_pipe is not marked COMPAT_80 and not removed from
> rump. I've left it as it is.
> 
> 1. Implement pipe() with pipe2(2) in libc:
> 
> New source code is now Machine Independent.
> 
> http://netbsd.org/~kamil/patch-00040-implement-pipe-with-pipe2-in-libc.txt
> 
> The generated code in libc for x86_64 is also simpler and shorter:
> 
> 000000000008b2a2 <_pipe>:
>    8b2a2:       31 f6                   xor    %esi,%esi
>    8b2a4:       e9 b7 f5 fa ff          jmpq   3a860 <pipe2@plt>

But you incur the price of pipe2's copyout().  I'm curious, does
anyone know how things like SMAP contribute to that price?


> 2. Refactor pipe1() kernel-internal function to operate over int[2]
> rather than register_t[2].  Stop returning garbage through retval[2]
> from pipe2(2).

Please, can you be more specific with your characterizations.
"Returning garbage" is vague, and without further details (that you do
know yourself but don't disclose) makes every reader expend time and
mental effort to figure out what are you really talking about.

For the reference, sys_pipe2() overwrites retval[1] with the second
descriptor b/c it passes retval[] to pipe1(), like sys_pipe() does.
But what is the intended effect for pipe() causes retval[1] register
to be clobbered for pipe2().


-uwe