Linux defines a few custom flags for waitpid(), make them available to
nolibc based programs.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 tools/include/nolibc/types.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
index 8cfc4c860fa4..801ea0bb186e 100644
--- a/tools/include/nolibc/types.h
+++ b/tools/include/nolibc/types.h
@@ -109,7 +109,10 @@
 #define WIFSIGNALED(status) ((status) - 1 < 0xff)
 
 /* waitpid() flags */
-#define WNOHANG      1
+#define WNOHANG      0x00000001
+#define __WNOTHREAD  0x20000000
+#define __WALL       0x40000000
+#define __WCLONE     0x80000000
 
 /* standard exit() codes */
 #define EXIT_SUCCESS 0

---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20231020-nolibc-waitpid-flags-80ac075ab978

Best regards,
-- 
Mark Brown <broonie@kernel.org>

Hi,

Oct 20, 2023 23:57:01 Mark Brown <broonie@kernel.org>:

> Linux defines a few custom flags for waitpid(), make them available to
> nolibc based programs.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> tools/include/nolibc/types.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
> index 8cfc4c860fa4..801ea0bb186e 100644
> --- a/tools/include/nolibc/types.h
> +++ b/tools/include/nolibc/types.h
> @@ -109,7 +109,10 @@
> #define WIFSIGNALED(status) ((status) - 1 < 0xff)
>
> /* waitpid() flags */
> -#define WNOHANG      1
> +#define WNOHANG      0x00000001
> +#define __WNOTHREAD  0x20000000
> +#define __WALL       0x40000000
> +#define __WCLONE     0x80000000

Wouldn't it be easier to include linux/wait.h instead?

In general quite a few defines from types.h
are actually copies from UAPI headers.

>
> /* standard exit() codes */
> #define EXIT_SUCCESS 0
>
> ---
> base-commit: 6465e260f48790807eef06b583b38ca9789b6072
> change-id: 20231020-nolibc-waitpid-flags-80ac075ab978
>
> Best regards,
> --
> Mark Brown <broonie@kernel.org>

Hi Thomas,

On Sat, Oct 21, 2023 at 11:00:20AM +0200, Thomas Weißschuh  wrote:
> Hi,
> 
> Oct 20, 2023 23:57:01 Mark Brown <broonie@kernel.org>:
> 
> > Linux defines a few custom flags for waitpid(), make them available to
> > nolibc based programs.
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> > tools/include/nolibc/types.h | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
> > index 8cfc4c860fa4..801ea0bb186e 100644
> > --- a/tools/include/nolibc/types.h
> > +++ b/tools/include/nolibc/types.h
> > @@ -109,7 +109,10 @@
> > #define WIFSIGNALED(status) ((status) - 1 < 0xff)
> >
> > /* waitpid() flags */
> > -#define WNOHANG      1
> > +#define WNOHANG      0x00000001
> > +#define __WNOTHREAD  0x20000000
> > +#define __WALL       0x40000000
> > +#define __WCLONE     0x80000000
> 
> Wouldn't it be easier to include linux/wait.h instead?

That's indeed the trend we should follow whenever possible. We've got
caught a few times in the past with build errors depending on the
includes ordering due to such redefinitions. I don't know if that's the
case for these ones (nor if including linux/wait.h would cause other
breakage) but it's worth considering at least.

The difficulty here is that originally nolibc did not *explicitly* depend
on UAPI headers, and was supposed to be self-sufficient (that was the
main point). Adapting to multiple archs caused the addition of ifdefs
all around, then trying to standardize the include file names instead
of just "nolibc.h" caused conflicts with programs already including
linux/anything.h. Anyway now we depend on linux/lots-of-stuff so I
think it's worth continuing in that direction so that we don't replicate
the UAPI maintenance effort.

Cheers,
Willy

On Sat, Oct 21, 2023 at 11:13:38AM +0200, Willy Tarreau wrote:
> On Sat, Oct 21, 2023 at 11:00:20AM +0200, Thomas Weißschuh  wrote:
> > Oct 20, 2023 23:57:01 Mark Brown <broonie@kernel.org>:

> > > Linux defines a few custom flags for waitpid(), make them available to
> > > nolibc based programs.

> > Wouldn't it be easier to include linux/wait.h instead?

> That's indeed the trend we should follow whenever possible. We've got
> caught a few times in the past with build errors depending on the
> includes ordering due to such redefinitions. I don't know if that's the
> case for these ones (nor if including linux/wait.h would cause other
> breakage) but it's worth considering at least.

> The difficulty here is that originally nolibc did not *explicitly* depend
> on UAPI headers, and was supposed to be self-sufficient (that was the
> main point). Adapting to multiple archs caused the addition of ifdefs
> all around, then trying to standardize the include file names instead
> of just "nolibc.h" caused conflicts with programs already including
> linux/anything.h. Anyway now we depend on linux/lots-of-stuff so I
> think it's worth continuing in that direction so that we don't replicate
> the UAPI maintenance effort.

OK, I'll do that - I'd not noticed that nolibc had started pulling in
linux/ headers so was trying to maintain the deliberate duplication.