[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230729100401.GA4577@1wt.eu>
Date: Sat, 29 Jul 2023 12:04:01 +0200
From: Willy Tarreau <w@....eu>
To: Zhangjin Wu <falcon@...ylab.org>
Cc: linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
tanyuan@...ylab.org
Subject: Re: [PATCH 1/2] tools/nolibc: add pipe() support
On Sat, Jul 29, 2023 at 04:37:00PM +0800, Zhangjin Wu wrote:
> > This one does not have the correct prototype for the function exposed
> > to the user, pipe really is "int pipe(int pipefd[2])". Maybe you were
> > thinking about sys_pipe() instead ? But since MIPS also has pipe2() now,
> > there's no reason to make an exception.
> >
>
> Yes, pipe2() should be a better choice, but I have seen this sentence in
> syscall manpage [1]:
>
> /* On Alpha, IA-64, MIPS, SuperH, and SPARC/SPARC64, pipe() has the
> following prototype; see NOTES */
>
> #include <unistd.h>
>
> struct fd_pair {
> long fd[2];
> };
> struct fd_pair pipe(void);
>
> If it is about syscall, then we are ok to align all of the architectures
> together to use "int pipe(int pipefd[2])"
Yes it's OK, that's how applications expect it to be used:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pipe.html
For the archs you mention above, it's the libc that wraps the call,
exactly what we ought to do as well (using pipe2() since it will be
easier).
Willy
Powered by blists - more mailing lists