linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] bpf.2: Use standard types and attributes
@ 2021-04-23 23:06 Alejandro Colomar
  2021-04-23 23:20 ` Alexei Starovoitov
                   ` (3 more replies)
  0 siblings, 4 replies; 49+ messages in thread
From: Alejandro Colomar @ 2021-04-23 23:06 UTC (permalink / raw)
  To: mtk.manpages, linux-man
  Cc: Alejandro Colomar, linux-kernel, libc-alpha, gcc-patches

Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't.  There are some using kernel
syntax '__u32'.  Fix those.

Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'.  Update those to use the shorter and more
portable C2x syntax, which hasn't been standardized yet, but is
already implemented in GCC, and available through either --std=c2x
or any of the --std=gnu... options.

Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---
 man2/bpf.2 | 47 +++++++++++++++++++++++------------------------
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 6e1ffa198..204f01bfc 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -188,39 +188,38 @@ commands:
 .EX
 union bpf_attr {
     struct {    /* Used by BPF_MAP_CREATE */
-        __u32         map_type;
-        __u32         key_size;    /* size of key in bytes */
-        __u32         value_size;  /* size of value in bytes */
-        __u32         max_entries; /* maximum number of entries
-                                      in a map */
+        uint32_t    map_type;
+        uint32_t    key_size;    /* size of key in bytes */
+        uint32_t    value_size;  /* size of value in bytes */
+        uint32_t    max_entries; /* maximum number of entries
+                                    in a map */
     };
 
-    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
-                   commands */
-        __u32         map_fd;
-        __aligned_u64 key;
+    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY commands */
+        uint32_t                     map_fd;
+        uint64_t [[gnu::aligned(8)]] key;
         union {
-            __aligned_u64 value;
-            __aligned_u64 next_key;
+            uint64_t [[gnu::aligned(8)]] value;
+            uint64_t [[gnu::aligned(8)]] next_key;
         };
-        __u64         flags;
+        uint64_t                     flags;
     };
 
     struct {    /* Used by BPF_PROG_LOAD */
-        __u32         prog_type;
-        __u32         insn_cnt;
-        __aligned_u64 insns;      /* \(aqconst struct bpf_insn *\(aq */
-        __aligned_u64 license;    /* \(aqconst char *\(aq */
-        __u32         log_level;  /* verbosity level of verifier */
-        __u32         log_size;   /* size of user buffer */
-        __aligned_u64 log_buf;    /* user supplied \(aqchar *\(aq
-                                     buffer */
-        __u32         kern_version;
-                                  /* checked when prog_type=kprobe
-                                     (since Linux 4.1) */
+        uint32_t                     prog_type;
+        uint32_t                     insn_cnt;
+        uint64_t [[gnu::aligned(8)]] insns;     /* \(aqconst struct bpf_insn *\(aq */
+        uint64_t [[gnu::aligned(8)]] license;   /* \(aqconst char *\(aq */
+        uint32_t                     log_level; /* verbosity level of verifier */
+        uint32_t                     log_size;  /* size of user buffer */
+        uint64_t [[gnu::aligned(8)]] log_buf;   /* user supplied \(aqchar *\(aq
+                                                   buffer */
+        uint32_t                     kern_version;
+                                                /* checked when prog_type=kprobe
+                                                   (since Linux 4.1) */
 .\"                 commit 2541517c32be2531e0da59dfd7efc1ce844644f5
     };
-} __attribute__((aligned(8)));
+} [[gnu::aligned(8)]];
 .EE
 .in
 .\"
-- 
2.31.0


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-23 23:06 [RFC] bpf.2: Use standard types and attributes Alejandro Colomar
@ 2021-04-23 23:20 ` Alexei Starovoitov
  2021-04-24 17:56   ` Alejandro Colomar (man-pages)
  2021-04-24 20:43   ` David Laight
  2021-04-26 17:19 ` Joseph Myers
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 49+ messages in thread
From: Alexei Starovoitov @ 2021-04-23 23:20 UTC (permalink / raw)
  To: Alejandro Colomar, bpf
  Cc: Michael Kerrisk (man-pages), linux-man, LKML, libc-alpha, gcc-patches

On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> Some manual pages are already using C99 syntax for integral
> types 'uint32_t', but some aren't.  There are some using kernel
> syntax '__u32'.  Fix those.
>
> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))'.  Update those to use the shorter and more
> portable C2x syntax, which hasn't been standardized yet, but is
> already implemented in GCC, and available through either --std=c2x
> or any of the --std=gnu... options.
>
> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> ---
>  man2/bpf.2 | 47 +++++++++++++++++++++++------------------------
>  1 file changed, 23 insertions(+), 24 deletions(-)
>
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index 6e1ffa198..204f01bfc 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -188,39 +188,38 @@ commands:
>  .EX
>  union bpf_attr {
>      struct {    /* Used by BPF_MAP_CREATE */
> -        __u32         map_type;
> -        __u32         key_size;    /* size of key in bytes */
> -        __u32         value_size;  /* size of value in bytes */
> -        __u32         max_entries; /* maximum number of entries
> -                                      in a map */
> +        uint32_t    map_type;
> +        uint32_t    key_size;    /* size of key in bytes */
> +        uint32_t    value_size;  /* size of value in bytes */
> +        uint32_t    max_entries; /* maximum number of entries
> +                                    in a map */

Nack.
The man page should describe the kernel api the way it is in .h file.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-23 23:20 ` Alexei Starovoitov
@ 2021-04-24 17:56   ` Alejandro Colomar (man-pages)
  2021-04-25 16:52     ` Alexei Starovoitov
  2021-04-24 20:43   ` David Laight
  1 sibling, 1 reply; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-04-24 17:56 UTC (permalink / raw)
  To: Alexei Starovoitov, bpf
  Cc: Michael Kerrisk (man-pages), linux-man, LKML, libc-alpha, gcc-patches

Hello Alexei,

On 4/24/21 1:20 AM, Alexei Starovoitov wrote:
> Nack.
> The man page should describe the kernel api the way it is in .h file.

Why?

When glibc uses __size_t (or any other non-standard types) just because 
the standard doesn't allow it to define some types in some specific 
header, the manual pages document the equivalent standard type, (i.e., 
if glibc uses __size_t, we document size_t).

The compiler, AFAIK (gcc is CCd, so they can jump in if I'm wrong), 
using uint32_t in every situation where __u32 is expected.  They're both 
typedefs for the same basic type.

I can understand why Linux will keep using u32 types (and their __ user 
space variants), but that doesn't mean user space programs need to use 
the same type.

If we have a standard syntax for fixed-width integral types (and for 
anything, actually), the manual pages should probably follow it, 
whenever possible.  Any deviation from the standard (be it C or POSIX) 
should have a very good reason to be;  otherwise, it only creates confusion.

Thanks,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
Senior SW Engineer; http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [RFC] bpf.2: Use standard types and attributes
  2021-04-23 23:20 ` Alexei Starovoitov
  2021-04-24 17:56   ` Alejandro Colomar (man-pages)
@ 2021-04-24 20:43   ` David Laight
  2021-04-25 19:16     ` Zack Weinberg
  1 sibling, 1 reply; 49+ messages in thread
From: David Laight @ 2021-04-24 20:43 UTC (permalink / raw)
  To: 'Alexei Starovoitov', Alejandro Colomar, bpf
  Cc: Michael Kerrisk (man-pages), linux-man, LKML, libc-alpha, gcc-patches

From: Alexei Starovoitov
> Sent: 24 April 2021 00:20
> 
> On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
> >
> > Some manual pages are already using C99 syntax for integral
> > types 'uint32_t', but some aren't.  There are some using kernel
> > syntax '__u32'.  Fix those.
> >
> > Some pages also document attributes, using GNU syntax
> > '__attribute__((xxx))'.  Update those to use the shorter and more
> > portable C2x syntax, which hasn't been standardized yet, but is
> > already implemented in GCC, and available through either --std=c2x
> > or any of the --std=gnu... options.
> >
> > Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> > ---
> >  man2/bpf.2 | 47 +++++++++++++++++++++++------------------------
> >  1 file changed, 23 insertions(+), 24 deletions(-)
> >
> > diff --git a/man2/bpf.2 b/man2/bpf.2
> > index 6e1ffa198..204f01bfc 100644
> > --- a/man2/bpf.2
> > +++ b/man2/bpf.2
> > @@ -188,39 +188,38 @@ commands:
> >  .EX
> >  union bpf_attr {
> >      struct {    /* Used by BPF_MAP_CREATE */
> > -        __u32         map_type;
> > -        __u32         key_size;    /* size of key in bytes */
> > -        __u32         value_size;  /* size of value in bytes */
> > -        __u32         max_entries; /* maximum number of entries
> > -                                      in a map */
> > +        uint32_t    map_type;
> > +        uint32_t    key_size;    /* size of key in bytes */
> > +        uint32_t    value_size;  /* size of value in bytes */
> > +        uint32_t    max_entries; /* maximum number of entries
> > +                                    in a map */
> 
> Nack.
> The man page should describe the kernel api the way it is in .h file.

And the code below is no more portable that a #pragma'.
It is probably worse than __attribute__((aligned(8)))
+            uint64_t [[gnu::aligned(8)]] value;
The standards committee are smoking dope again.
At least the '__aligned_u64 value;' form stands a reasonable
chance of being converted by cpp into whatever your compiler supports.

OTOH the bfp developers want shooting for defining a structure
with hidden padding fields.
It they ensured that all 64bit fields were aligned they wouldn't
need the __aligned_u64 at all.
And would be much less likely to leak kernel stack to userspace.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-24 17:56   ` Alejandro Colomar (man-pages)
@ 2021-04-25 16:52     ` Alexei Starovoitov
  2021-04-25 19:12       ` Zack Weinberg
  0 siblings, 1 reply; 49+ messages in thread
From: Alexei Starovoitov @ 2021-04-25 16:52 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages)
  Cc: bpf, Michael Kerrisk (man-pages),
	linux-man, LKML, libc-alpha, gcc-patches

On Sat, Apr 24, 2021 at 10:56 AM Alejandro Colomar (man-pages)
<alx.manpages@gmail.com> wrote:
>
> Hello Alexei,
>
> On 4/24/21 1:20 AM, Alexei Starovoitov wrote:
> > Nack.
> > The man page should describe the kernel api the way it is in .h file.
>
> Why?

Because man page must describe the linux uapi headers the way they
are installed in the system and not invent alternative implementations.
The users will include those .h with __u32 and will see them in their code.
Man page saying something else is a dangerous lie.

> using uint32_t in every situation where __u32 is expected.  They're both
> typedefs for the same basic type.

That's irrelevant. Languages like golang have their own bpf.h equivalent
that matches /usr/include/linux/bpf.h.

> I can understand why Linux will keep using u32 types (and their __ user
> space variants), but that doesn't mean user space programs need to use
> the same type.

No one says that the users must use __u32. See golang example.
But if the users do #include <linux/bpf.h> they will get them and man page
must describe that.

> If we have a standard syntax for fixed-width integral types (and for
> anything, actually), the manual pages should probably follow it,
> whenever possible.

Absolutely not. linux man page must describe linux.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-25 16:52     ` Alexei Starovoitov
@ 2021-04-25 19:12       ` Zack Weinberg
  0 siblings, 0 replies; 49+ messages in thread
From: Zack Weinberg @ 2021-04-25 19:12 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Alejandro Colomar (man-pages),
	linux-man, GNU C Library, LKML, gcc-patches,
	Michael Kerrisk (man-pages),
	bpf

On Sun, Apr 25, 2021 at 12:52 PM Alexei Starovoitov via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> On Sat, Apr 24, 2021 at 10:56 AM Alejandro Colomar (man-pages)
> <alx.manpages@gmail.com> wrote:
> >
> > Hello Alexei,
> >
> > On 4/24/21 1:20 AM, Alexei Starovoitov wrote:
> > > Nack.
> > > The man page should describe the kernel api the way it is in .h file.
> >
> > Why?
>
> Because man page must describe the linux uapi headers the way they
> are installed in the system and not invent alternative implementations.
> The users will include those .h with __u32 and will see them in their code.
> Man page saying something else is a dangerous lie.

Why do you consider it _dangerous_ for the manpages to replace __u32
with uint32_t, when we know by construction that the two types will
always be the same?  Alejandro's preference for the types standardized
by ISO C seems perfectly reasonable to me for documentation; people
reading the documentation can be expected to already know what they
mean, unlike the  Linux-specifc __[iu]NN types.  Also, all else being
equal, documentation should avoid use of symbols in the ISO C reserved
namespace.

If anything I would argue that it is the uapi headers that should be
changed, to use the <stdint.h> types.

zw

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-24 20:43   ` David Laight
@ 2021-04-25 19:16     ` Zack Weinberg
  2021-04-25 21:09       ` David Laight
  0 siblings, 1 reply; 49+ messages in thread
From: Zack Weinberg @ 2021-04-25 19:16 UTC (permalink / raw)
  To: David Laight
  Cc: Alexei Starovoitov, Alejandro Colomar, bpf, linux-man,
	gcc-patches, libc-alpha, Michael Kerrisk (man-pages),
	LKML

On Sat, Apr 24, 2021 at 4:43 PM David Laight via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> From: Alexei Starovoitov
> > On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar <alx.manpages@gmail.com> wrote:
...
> > > Some pages also document attributes, using GNU syntax
> > > '__attribute__((xxx))'.  Update those to use the shorter and more
> > > portable C2x syntax, which hasn't been standardized yet, but is
> > > already implemented in GCC, and available through either --std=c2x
> > > or any of the --std=gnu... options.
..
> And the code below is no more portable that a #pragma'.
> It is probably worse than __attribute__((aligned(8)))
> +            uint64_t [[gnu::aligned(8)]] value;
> The standards committee are smoking dope again.
> At least the '__aligned_u64 value;' form stands a reasonable
> chance of being converted by cpp into whatever your compiler supports.

Is it actually necessary to mention the alignment overrides at all in
the manpages?  They are only relevant to people working at the level
of physical layout of the data in RAM, and those people are probably
going to have to consult the header file anyway.

zw

^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [RFC] bpf.2: Use standard types and attributes
  2021-04-25 19:16     ` Zack Weinberg
@ 2021-04-25 21:09       ` David Laight
  0 siblings, 0 replies; 49+ messages in thread
From: David Laight @ 2021-04-25 21:09 UTC (permalink / raw)
  To: 'Zack Weinberg'
  Cc: Alexei Starovoitov, Alejandro Colomar, bpf, linux-man,
	gcc-patches, libc-alpha, Michael Kerrisk (man-pages),
	LKML

From: Zack Weinberg
> Sent: 25 April 2021 20:17
> 
> On Sat, Apr 24, 2021 at 4:43 PM David Laight via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> > From: Alexei Starovoitov
> > > On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar <alx.manpages@gmail.com> wrote:
> ...
> > > > Some pages also document attributes, using GNU syntax
> > > > '__attribute__((xxx))'.  Update those to use the shorter and more
> > > > portable C2x syntax, which hasn't been standardized yet, but is
> > > > already implemented in GCC, and available through either --std=c2x
> > > > or any of the --std=gnu... options.
> ..
> > And the code below is no more portable that a #pragma'.
> > It is probably worse than __attribute__((aligned(8)))
> > +            uint64_t [[gnu::aligned(8)]] value;
> > The standards committee are smoking dope again.
> > At least the '__aligned_u64 value;' form stands a reasonable
> > chance of being converted by cpp into whatever your compiler supports.
> 
> Is it actually necessary to mention the alignment overrides at all in
> the manpages?  They are only relevant to people working at the level
> of physical layout of the data in RAM, and those people are probably
> going to have to consult the header file anyway.

Depends, if the man page defines the structure - it needs to
contain its definition.
If theory the man page ought to be the definition, and the code
do what the man page says happens.

An alternative is for the man page to say that the structure
contains some fields - without prescribing the order, or
stopping the implementation adding additional fields (or even
changing the actual numeric type).
This is more common in the standards documents.
IMHO The Linux pages really ought to say how linux does things.
(With notes about portability.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-23 23:06 [RFC] bpf.2: Use standard types and attributes Alejandro Colomar
  2021-04-23 23:20 ` Alexei Starovoitov
@ 2021-04-26 17:19 ` Joseph Myers
  2021-04-26 17:46   ` Alejandro Colomar (man-pages)
  2021-05-04 11:05 ` [RFC v2] " Alejandro Colomar
  2022-08-24 18:55 ` [PATCH v3] Many pages: Document fixed-width types with ISO C naming Alejandro Colomar
  3 siblings, 1 reply; 49+ messages in thread
From: Joseph Myers @ 2021-04-26 17:19 UTC (permalink / raw)
  To: Alejandro Colomar
  Cc: mtk.manpages, linux-man, gcc-patches, libc-alpha, linux-kernel

On Sat, 24 Apr 2021, Alejandro Colomar via Libc-alpha wrote:

> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))'.  Update those to use the shorter and more
> portable C2x syntax, which hasn't been standardized yet, but is
> already implemented in GCC, and available through either --std=c2x
> or any of the --std=gnu... options.

If you mention alignment in the manpage at all, the same reasoning would 
say you should use _Alignas(8) not [[gnu::aligned(8)]], in any context 
where _Alignas is valid.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC] bpf.2: Use standard types and attributes
  2021-04-26 17:19 ` Joseph Myers
@ 2021-04-26 17:46   ` Alejandro Colomar (man-pages)
  0 siblings, 0 replies; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-04-26 17:46 UTC (permalink / raw)
  To: Joseph Myers
  Cc: mtk.manpages, linux-man, gcc-patches, libc-alpha, linux-kernel

Hi Joseph,

On 4/26/21 7:19 PM, Joseph Myers wrote:
> On Sat, 24 Apr 2021, Alejandro Colomar via Libc-alpha wrote:
> 
>> Some pages also document attributes, using GNU syntax
>> '__attribute__((xxx))'.  Update those to use the shorter and more
>> portable C2x syntax, which hasn't been standardized yet, but is
>> already implemented in GCC, and available through either --std=c2x
>> or any of the --std=gnu... options.
> 
> If you mention alignment in the manpage at all, the same reasoning would
> say you should use _Alignas(8) not [[gnu::aligned(8)]], in any context
> where _Alignas is valid.
> 

Agree.

I just didn't know 'alignas()' (a.k.a. '_Alignas()'), so I used 
attributes and only changed the syntax.  But yes, we should use that C11 
feature.  Given that we already used 'noreturn' and not '_Noreturn' (see 
exit(3) and its family), I'll use 'alignas()'.

I'll send a v2 with those changes.

Thanks,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [RFC v2] bpf.2: Use standard types and attributes
  2021-04-23 23:06 [RFC] bpf.2: Use standard types and attributes Alejandro Colomar
  2021-04-23 23:20 ` Alexei Starovoitov
  2021-04-26 17:19 ` Joseph Myers
@ 2021-05-04 11:05 ` Alejandro Colomar
  2021-05-04 14:12   ` Alexei Starovoitov
  2022-08-24 18:55 ` [PATCH v3] Many pages: Document fixed-width types with ISO C naming Alejandro Colomar
  3 siblings, 1 reply; 49+ messages in thread
From: Alejandro Colomar @ 2021-05-04 11:05 UTC (permalink / raw)
  To: mtk.manpages, linux-man
  Cc: Alejandro Colomar, LKML, glibc, GCC, Alexei Starovoitov, bpf,
	David Laight, Zack Weinberg, Joseph Myers

Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't.  There are some using kernel
syntax '__u32'.  Fix those.

Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'.  Update those to use the shorter and more
portable C11 keywords such as 'alignas()' when possible, and C2x
syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
yet, but is already implemented in GCC, and available through
either --std=c2x or any of the --std=gnu... options.

The standard isn't very clear on how to use alignas() or
[[]]-style attributes, so the following link is useful in the case
of 'alignas()' and '[[gnu::aligned()]]':
<https://stackoverflow.com/q/67271825/6872717>

Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: glibc <libc-alpha@sourceware.org>
Cc: GCC <gcc-patches@gcc.gnu.org>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Zack Weinberg <zackw@panix.com>
Cc: Joseph Myers <joseph@codesourcery.com>
---
 man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 6e1ffa198..04b8fbcef 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -186,41 +186,40 @@ commands:
 .PP
 .in +4n
 .EX
-union bpf_attr {
+union [[gnu::aligned(8)]] bpf_attr {
     struct {    /* Used by BPF_MAP_CREATE */
-        __u32         map_type;
-        __u32         key_size;    /* size of key in bytes */
-        __u32         value_size;  /* size of value in bytes */
-        __u32         max_entries; /* maximum number of entries
-                                      in a map */
+        uint32_t    map_type;
+        uint32_t    key_size;    /* size of key in bytes */
+        uint32_t    value_size;  /* size of value in bytes */
+        uint32_t    max_entries; /* maximum number of entries
+                                    in a map */
     };
 
-    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
-                   commands */
-        __u32         map_fd;
-        __aligned_u64 key;
+    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY commands */
+        uint32_t            map_fd;
+        uint64_t alignas(8) key;
         union {
-            __aligned_u64 value;
-            __aligned_u64 next_key;
+            uint64_t alignas(8) value;
+            uint64_t alignas(8) next_key;
         };
-        __u64         flags;
+        uint64_t            flags;
     };
 
     struct {    /* Used by BPF_PROG_LOAD */
-        __u32         prog_type;
-        __u32         insn_cnt;
-        __aligned_u64 insns;      /* \(aqconst struct bpf_insn *\(aq */
-        __aligned_u64 license;    /* \(aqconst char *\(aq */
-        __u32         log_level;  /* verbosity level of verifier */
-        __u32         log_size;   /* size of user buffer */
-        __aligned_u64 log_buf;    /* user supplied \(aqchar *\(aq
-                                     buffer */
-        __u32         kern_version;
-                                  /* checked when prog_type=kprobe
-                                     (since Linux 4.1) */
+        uint32_t            prog_type;
+        uint32_t            insn_cnt;
+        uint64_t alignas(8) insns;     /* \(aqconst struct bpf_insn *\(aq */
+        uint64_t alignas(8) license;   /* \(aqconst char *\(aq */
+        uint32_t            log_level; /* verbosity level of verifier */
+        uint32_t            log_size;  /* size of user buffer */
+        uint64_t alignas(8) log_buf;   /* user supplied \(aqchar *\(aq
+                                          buffer */
+        uint32_t            kern_version;
+                                       /* checked when prog_type=kprobe
+                                          (since Linux 4.1) */
 .\"                 commit 2541517c32be2531e0da59dfd7efc1ce844644f5
     };
-} __attribute__((aligned(8)));
+};
 .EE
 .in
 .\"
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 11:05 ` [RFC v2] " Alejandro Colomar
@ 2021-05-04 14:12   ` Alexei Starovoitov
  2021-05-04 14:24     ` Greg KH
  0 siblings, 1 reply; 49+ messages in thread
From: Alexei Starovoitov @ 2021-05-04 14:12 UTC (permalink / raw)
  To: Alejandro Colomar
  Cc: Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, David Laight, Zack Weinberg,
	Joseph Myers

On Tue, May 4, 2021 at 4:05 AM Alejandro Colomar <alx.manpages@gmail.com> wrote:
>
> Some manual pages are already using C99 syntax for integral
> types 'uint32_t', but some aren't.  There are some using kernel
> syntax '__u32'.  Fix those.
>
> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))'.  Update those to use the shorter and more
> portable C11 keywords such as 'alignas()' when possible, and C2x
> syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
> yet, but is already implemented in GCC, and available through
> either --std=c2x or any of the --std=gnu... options.
>
> The standard isn't very clear on how to use alignas() or
> [[]]-style attributes, so the following link is useful in the case
> of 'alignas()' and '[[gnu::aligned()]]':
> <https://stackoverflow.com/q/67271825/6872717>
>
> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> Cc: LKML <linux-kernel@vger.kernel.org>
> Cc: glibc <libc-alpha@sourceware.org>
> Cc: GCC <gcc-patches@gcc.gnu.org>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: bpf <bpf@vger.kernel.org>
> Cc: David Laight <David.Laight@ACULAB.COM>
> Cc: Zack Weinberg <zackw@panix.com>
> Cc: Joseph Myers <joseph@codesourcery.com>
> ---
>  man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
>  1 file changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index 6e1ffa198..04b8fbcef 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -186,41 +186,40 @@ commands:
>  .PP
>  .in +4n
>  .EX
> -union bpf_attr {
> +union [[gnu::aligned(8)]] bpf_attr {
>      struct {    /* Used by BPF_MAP_CREATE */
> -        __u32         map_type;
> -        __u32         key_size;    /* size of key in bytes */
> -        __u32         value_size;  /* size of value in bytes */
> -        __u32         max_entries; /* maximum number of entries
> -                                      in a map */
> +        uint32_t    map_type;
> +        uint32_t    key_size;    /* size of key in bytes */
> +        uint32_t    value_size;  /* size of value in bytes */
> +        uint32_t    max_entries; /* maximum number of entries
> +                                    in a map */

For the same reasons as explained earlier:
Nacked-by: Alexei Starovoitov <ast@kernel.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 14:12   ` Alexei Starovoitov
@ 2021-05-04 14:24     ` Greg KH
  2021-05-04 15:53       ` Alejandro Colomar (man-pages)
  0 siblings, 1 reply; 49+ messages in thread
From: Greg KH @ 2021-05-04 14:24 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Alejandro Colomar, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, David Laight, Zack Weinberg,
	Joseph Myers

On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
> On Tue, May 4, 2021 at 4:05 AM Alejandro Colomar <alx.manpages@gmail.com> wrote:
> >
> > Some manual pages are already using C99 syntax for integral
> > types 'uint32_t', but some aren't.  There are some using kernel
> > syntax '__u32'.  Fix those.
> >
> > Some pages also document attributes, using GNU syntax
> > '__attribute__((xxx))'.  Update those to use the shorter and more
> > portable C11 keywords such as 'alignas()' when possible, and C2x
> > syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
> > yet, but is already implemented in GCC, and available through
> > either --std=c2x or any of the --std=gnu... options.
> >
> > The standard isn't very clear on how to use alignas() or
> > [[]]-style attributes, so the following link is useful in the case
> > of 'alignas()' and '[[gnu::aligned()]]':
> > <https://stackoverflow.com/q/67271825/6872717>
> >
> > Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> > Cc: LKML <linux-kernel@vger.kernel.org>
> > Cc: glibc <libc-alpha@sourceware.org>
> > Cc: GCC <gcc-patches@gcc.gnu.org>
> > Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> > Cc: bpf <bpf@vger.kernel.org>
> > Cc: David Laight <David.Laight@ACULAB.COM>
> > Cc: Zack Weinberg <zackw@panix.com>
> > Cc: Joseph Myers <joseph@codesourcery.com>
> > ---
> >  man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
> >  1 file changed, 24 insertions(+), 25 deletions(-)
> >
> > diff --git a/man2/bpf.2 b/man2/bpf.2
> > index 6e1ffa198..04b8fbcef 100644
> > --- a/man2/bpf.2
> > +++ b/man2/bpf.2
> > @@ -186,41 +186,40 @@ commands:
> >  .PP
> >  .in +4n
> >  .EX
> > -union bpf_attr {
> > +union [[gnu::aligned(8)]] bpf_attr {
> >      struct {    /* Used by BPF_MAP_CREATE */
> > -        __u32         map_type;
> > -        __u32         key_size;    /* size of key in bytes */
> > -        __u32         value_size;  /* size of value in bytes */
> > -        __u32         max_entries; /* maximum number of entries
> > -                                      in a map */
> > +        uint32_t    map_type;
> > +        uint32_t    key_size;    /* size of key in bytes */
> > +        uint32_t    value_size;  /* size of value in bytes */
> > +        uint32_t    max_entries; /* maximum number of entries
> > +                                    in a map */
> 
> For the same reasons as explained earlier:
> Nacked-by: Alexei Starovoitov <ast@kernel.org>

I agree, the two are not the same type at all, this change should not be
accepted.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 14:24     ` Greg KH
@ 2021-05-04 15:53       ` Alejandro Colomar (man-pages)
  2021-05-04 16:06         ` Greg KH
  2021-05-04 16:08         ` [RFC v2] " Daniel Borkmann
  0 siblings, 2 replies; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-05-04 15:53 UTC (permalink / raw)
  To: Greg KH, Alexei Starovoitov
  Cc: Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, David Laight, Zack Weinberg,
	Joseph Myers

Hi Greg and Alexei,

> On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
>> For the same reasons as explained earlier:
>> Nacked-by: Alexei Starovoitov <ast@kernel.org>

Okay, I'll add that.


On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same 
type at all, this change should not be
> accepted.

I get that in the kernel you don't use the standard fixed-width types 
(with some exceptions), probably not to mess with code that relies on 
<stdint.h> not being included (I hope there's not much code that relies 
on this in 2021, but who knows).

But, there is zero difference between these types, from the point of 
view of the compiler.  There's 100% compatibility between those types, 
and you're able to mix'n'match them.  See some example below.

Could you please explain why the documentation, which supposedly only 
documents the API and not the internal implementation, should not use 
standard naming conventions?  The standard is much easier to read for 
userspace programmers, which might ignore why the kernel does some 
things in some specific ways.

BTW, just to clarify, bpf.2 is just a small sample to get reviews; the 
original intention was to replace __uNN by uintNN_t in all of the manual 
pages.

Thanks,

Alex

...

Example:

$ cat test.c
#include <stdint.h>

typedef int __s32;

int32_t foo(void);

int main(void)
{
	return 1 - foo();
}


__s32 foo(void)
{
	return 1;
}
$ cc -Wall -Wextra -Werror -S -Og test.c -o test.s
$ cat test.s
	.file	"test.c"
	.text
	.globl	foo
	.type	foo, @function
foo:
.LFB1:
	.cfi_startproc
	movl	$1, %eax
	ret
	.cfi_endproc
.LFE1:
	.size	foo, .-foo
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	call	foo
	movl	%eax, %edx
	movl	$1, %eax
	subl	%edx, %eax
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Debian 10.2.1-6) 10.2.1 20210110"
	.section	.note.GNU-stack,"",@progbits
$


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 15:53       ` Alejandro Colomar (man-pages)
@ 2021-05-04 16:06         ` Greg KH
  2021-05-04 18:37           ` Zack Weinberg
  2021-05-04 16:08         ` [RFC v2] " Daniel Borkmann
  1 sibling, 1 reply; 49+ messages in thread
From: Greg KH @ 2021-05-04 16:06 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages)
  Cc: Alexei Starovoitov, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, David Laight, Zack Weinberg,
	Joseph Myers

On Tue, May 04, 2021 at 05:53:29PM +0200, Alejandro Colomar (man-pages) wrote:
> Hi Greg and Alexei,
> 
> > On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
> > > For the same reasons as explained earlier:
> > > Nacked-by: Alexei Starovoitov <ast@kernel.org>
> 
> Okay, I'll add that.
> 
> 
> On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same type at
> all, this change should not be
> > accepted.
> 
> I get that in the kernel you don't use the standard fixed-width types (with
> some exceptions), probably not to mess with code that relies on <stdint.h>
> not being included (I hope there's not much code that relies on this in
> 2021, but who knows).
> 
> But, there is zero difference between these types, from the point of view of
> the compiler.  There's 100% compatibility between those types, and you're
> able to mix'n'match them.  See some example below.
> 
> Could you please explain why the documentation, which supposedly only
> documents the API and not the internal implementation, should not use
> standard naming conventions?  The standard is much easier to read for
> userspace programmers, which might ignore why the kernel does some things in
> some specific ways.
> 
> BTW, just to clarify, bpf.2 is just a small sample to get reviews; the
> original intention was to replace __uNN by uintNN_t in all of the manual
> pages.

There's a very old post from Linus where he describes the difference
between things like __u32 and uint32_t.  They are not the same, they
live in different namespaces, and worlds, and can not always be swapped
out for each other on all arches.

Dig it up if you are curious, but for user/kernel apis you HAVE to use
the __uNN and can not use uintNN_t variants, so don't try to mix/match
them, it's good to just follow the kernel standard please.

So consider this my:

Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

as well.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 15:53       ` Alejandro Colomar (man-pages)
  2021-05-04 16:06         ` Greg KH
@ 2021-05-04 16:08         ` Daniel Borkmann
  1 sibling, 0 replies; 49+ messages in thread
From: Daniel Borkmann @ 2021-05-04 16:08 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages), Greg KH, Alexei Starovoitov
  Cc: Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, David Laight, Zack Weinberg,
	Joseph Myers

On 5/4/21 5:53 PM, Alejandro Colomar (man-pages) wrote:
> Hi Greg and Alexei,
> 
>> On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
>>> For the same reasons as explained earlier:
>>> Nacked-by: Alexei Starovoitov <ast@kernel.org>
> 
> Okay, I'll add that.
> 
> On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same type at all, this change should not be
>> accepted.
> 
> I get that in the kernel you don't use the standard fixed-width types (with some exceptions), probably not to mess with code that relies on <stdint.h> not being included (I hope there's not much code that relies on this in 2021, but who knows).
> 
> But, there is zero difference between these types, from the point of view of the compiler.  There's 100% compatibility between those types, and you're able to mix'n'match them.  See some example below.
> 
> Could you please explain why the documentation, which supposedly only documents the API and not the internal implementation, should not use standard naming conventions?  The standard is much easier to read for userspace programmers, which might ignore why the kernel does some things in some specific ways.
> 
> BTW, just to clarify, bpf.2 is just a small sample to get reviews; the original intention was to replace __uNN by uintNN_t in all of the manual pages.

But what /problem/ is this really solving? Why bother to change this /now/
after so many years?! I think this is causing more confusion than solving
anything, really. Moreover, what are you doing with all the __{le,be}{16,32,64}
types in uapi? Anyway, NAK for bpf.2 specifically, and the idea generally..

Best,
Daniel

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 16:06         ` Greg KH
@ 2021-05-04 18:37           ` Zack Weinberg
  2021-05-04 18:54             ` Alejandro Colomar (man-pages)
  0 siblings, 1 reply; 49+ messages in thread
From: Zack Weinberg @ 2021-05-04 18:37 UTC (permalink / raw)
  To: Greg KH
  Cc: Alejandro Colomar (man-pages),
	Alexei Starovoitov, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, David Laight, Joseph Myers

On Tue, May 4, 2021 at 12:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, May 04, 2021 at 05:53:29PM +0200, Alejandro Colomar (man-pages) wrote:
> > On 5/4/21 4:24 PM, Greg KH wrote:
> > > I agree, the two are not the same type at all, this change should not be
> > > accepted.
> >
> > I get that in the kernel you don't use the standard fixed-width types (with
> > some exceptions), probably not to mess with code that relies on <stdint.h>
> > not being included (I hope there's not much code that relies on this in
> > 2021, but who knows).
> >
> > But, there is zero difference between these types, from the point of view of
> > the compiler.  There's 100% compatibility between those types, and you're
> > able to mix'n'match them.  See some example below.
...
> There's a very old post from Linus where he describes the difference
> between things like __u32 and uint32_t.  They are not the same, they
> live in different namespaces, and worlds, and can not always be swapped
> out for each other on all arches.
>
> Dig it up if you are curious, but for user/kernel apis you HAVE to use
> the __uNN and can not use uintNN_t variants, so don't try to mix/match
> them, it's good to just follow the kernel standard please.
...
> Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Speaking from the C library's perspective, I'm going to push back
pretty hard on this NAK, for several reasons.

First, this is a proposed change to the manpages, not the headers
themselves.  Manpage documentation of C structs is *not* expected to
match the actual declaration in the headers.  The documented field
type is usually assignment-compatible with the actual type, but not
always.  There's no guarantee whatsoever that the fields are in the
same order as the header, or that the listed set of fields is
complete.

I would say that as long as any value of type __u32 can be stored in a
variable of type uint32_t without data loss, and vice versa, there is
no reason why manpages should *have to* use __u32 in preference to
uint32_t, and that in the absence of such a reason, the standard type
should be used.

Second, it's true that __u32 and uint32_t are in different namespaces,
and it may well be necessary for uapi <linux/*.h> headers to use the
__uNN names in order to preserve the C standard's distinction between
the program and the implementation, but that's *not* a reason for
documentation aimed at writers of user-space programs to use the
__uNN names.  In fact, it is exactly the opposite!  User space program
authors should, all else equal, be *discouraged* from using the __uNN
names, and avoiding their use in manpages is one way to do that.

Third, if there does in fact exist a situation where __uNN and
uintNN_t are *not* assignment compatible, THAT IS A BUG IN THE KERNEL.
Frankly, it would be such a catastrophic bug that I think Linus has to
have been *wrong*.  We would have noticed the problems long ago if he
were right.

I'm going to have to ask you to produce hard evidence for your claim
that __uNN and uintNN_t are not (always) assignment compatible, and
hard evidence why that can't be fixed within the kernel, or else
withdraw your objection.

zw

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 18:37           ` Zack Weinberg
@ 2021-05-04 18:54             ` Alejandro Colomar (man-pages)
  2021-05-04 19:45               ` Florian Weimer
                                 ` (2 more replies)
  0 siblings, 3 replies; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-05-04 18:54 UTC (permalink / raw)
  To: Zack Weinberg, Greg KH, Daniel Borkmann
  Cc: Alexei Starovoitov, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight

Hi Greg, Daniel,

On 5/4/21 6:06 PM, Greg KH wrote:
 > There's a very old post from Linus where he describes the difference
 > between things like __u32 and uint32_t.  They are not the same, they
 > live in different namespaces, and worlds, and can not always be swapped
 > out for each other on all arches.>
 > Dig it up if you are curious, but for user/kernel apis you HAVE to use
 > the __uNN and can not use uintNN_t variants, so don't try to mix/match
 > them, it's good to just follow the kernel standard please.
I found these:

* [RFC] Splitting kernel headers and deprecating __KERNEL__ 
<https://lore.kernel.org/lkml/Pine.LNX.4.58.0412140734340.3279@ppc970.osdl.org/T/>

* coding style 
<https://lore.kernel.org/lkml/alpine.LFD.0.98.0706160840290.14121@woody.linux-foundation.org/>

* [patch] Small input fixes for 2.5.29 
<https://lore.kernel.org/lkml/Pine.LNX.4.33.0207301417190.2051-100000@penguin.transmeta.com/T/>

I already knew the first one, and now found the other two.  If there's 
any other thread that is relevant, I couldn't find it.

The thing is, in all of those threads, the only reasons to avoid 
<stdint.h> types in the kernel (at least, the only explicitly mentioned 
ones) are (a bit simplified, but this is the general idea of those threads):

* Possibly breaking something in such a big automated change.
* Namespace collision with userspace (the C standard allows defining 
uint32_t for nefarious purposes as long as you don't include <stdint.h>. 
  POSIX prohibits that, though)
* Uglier

But

* The manual pages only document the variable size and signedness by 
using either '__u32' or 'uint32_t'.  We state that the variable is an 
unsigned integer of exactly 32 bits; nothing more and nothing less.  It 
doesn't specify that those types are defined in <linux/bpf.h> (or 
whatever header a specific manual page uses).  In fact, in uint32_t(3) 
we clearly state the headers that shall provide the type.  In the end, 
the kernel will receive a 32 bit number.  I'm not exactly sure about 
what is wrong with this.  Is there any magic in the kernel/user 
interface beyond what the standard and the compiler define that I ignore?

* At that time (~2004), the C99 and POSIX.1-2001 standards were quite 
young, and it was likely to find code that defined uint32_t.  Currently, 
it is hard to find something that compiles without C99, and even if C99 
allows you to define uint32_t as long as you don't include <stdint.h>, 
it would be really stupid to do so.  And POSIX, which completely 
prohibits defining uint32_t, is also very present in Linux and other 
UNIX systems.  So we can probably guarantee that using <stdint.h> in the 
kernel wouldn't break anything.  But yet this isn't trying to do so. 
This is only about the manual pages.

I haven't read it in any of those threads, but suspect that the static 
analyzer used for the kernel might use extra information from the 
different 'u32'/'__u32' type names to do some extra checks.  Does it?

 > and can not always be swapped out for each other on all arches.

Really?  'uint32_t' is defined as "an unsigned integer type of a fixed 
width of exactly 32 bits".  How is that different from '[__]u32'? 
Aren't the kernel types guaranteed to be unsigned integers of exactly 32 
bits?  AFAICT, they are 100% binary compatible; and if not, it's 
probably a kernel bug.

Yes there are archs that don't provide 64 bit integers (I ignore if any 
of the archs supported by Linux does though), but if an arch doesn't 
provide 'uint64_t', it will neither be possible to have '__u64'.

[
        uintN_t
               Include: <stdint.h>.  Alternatively, <inttypes.h>.

               uint8_t, uint16_t, uint32_t, uint64_t

               An unsigned integer type of a fixed width  of  ex‐
               actly  N  bits, N being the value specified in its
               type name.  According to the C language  standard,
               they  shall  be  capable  of storing values in the
               range [0, UINTN_MAX], substituting N by the appro‐
               priate number.

               According   to   POSIX,   uint8_t,  uint16_t,  and
               uint32_t are required; uint64_t is  only  required
               in implementations that provide integer types with
               width 64; and all other types of this form are op‐
               tional.

] -- uint32_t(3)


 >
 > So consider this my:
 >
 > Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 >
 > as well.
Okay.

On 5/4/21 6:08 PM, Daniel Borkmann wrote:
 >
 > But what /problem/ is this really solving? Why bother to change this 
/now/
 > after so many years?! I think this is causing more confusion than solving
 > anything, really. Moreover, what are you doing with all the
 > __{le,be}{16,32,64}
 > types in uapi? Anyway, NAK for bpf.2 specifically, and the idea 
generally..
 >

I'm trying to clarify the manual pages as much as possible, by using 
standard conventions and similar structure all around the pages.  Not 
everyone understands kernel conventions.  Basically, Zack said very much 
what I had in mind with this patch.


Thanks for your reviews!

Regards,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 18:54             ` Alejandro Colomar (man-pages)
@ 2021-05-04 19:45               ` Florian Weimer
  2021-05-04 19:59                 ` Alejandro Colomar (man-pages)
  2021-05-05  8:23                 ` David Laight
  2021-05-04 20:06               ` Daniel Borkmann
  2021-05-15 19:01               ` [PATCH v3] " Alejandro Colomar
  2 siblings, 2 replies; 49+ messages in thread
From: Florian Weimer @ 2021-05-04 19:45 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages)
  Cc: Zack Weinberg, Greg KH, Daniel Borkmann, Alexei Starovoitov,
	Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight

* Alejandro Colomar:

> The thing is, in all of those threads, the only reasons to avoid
> <stdint.h> types in the kernel (at least, the only explicitly
> mentioned ones) are (a bit simplified, but this is the general idea of
> those threads):
>
> * Possibly breaking something in such a big automated change.
> * Namespace collision with userspace (the C standard allows defining
>   uint32_t for nefarious purposes as long as you don't include
>  <stdint.h>.   POSIX prohibits that, though)
> * Uglier

__u64 can't be formatted with %llu on all architectures.  That's not
true for uint64_t, where you have to use %lu on some architectures to
avoid compiler warnings (and technically undefined behavior).  There are
preprocessor macros to get the expected format specifiers, but they are
clunky.  I don't know if the problem applies to uint32_t.  It does
happen with size_t and ptrdiff_t on 32-bit targets (both vary between
int and long).

Thanks,
Florian


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 19:45               ` Florian Weimer
@ 2021-05-04 19:59                 ` Alejandro Colomar (man-pages)
  2021-05-05  8:23                 ` David Laight
  1 sibling, 0 replies; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-05-04 19:59 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Zack Weinberg, Greg KH, Daniel Borkmann, Alexei Starovoitov,
	Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight

Hi Florian,

On 5/4/21 9:45 PM, Florian Weimer wrote:
> * Alejandro Colomar:
> 
>> The thing is, in all of those threads, the only reasons to avoid
>> <stdint.h> types in the kernel (at least, the only explicitly
>> mentioned ones) are (a bit simplified, but this is the general idea of
>> those threads):
>>
>> * Possibly breaking something in such a big automated change.
>> * Namespace collision with userspace (the C standard allows defining
>>    uint32_t for nefarious purposes as long as you don't include
>>   <stdint.h>.   POSIX prohibits that, though)
>> * Uglier
> 
> __u64 can't be formatted with %llu on all architectures.  That's not
> true for uint64_t, where you have to use %lu on some architectures to
> avoid compiler warnings (and technically undefined behavior).  There are
> preprocessor macros to get the expected format specifiers, but they are
> clunky.  I don't know if the problem applies to uint32_t.  It does
> happen with size_t and ptrdiff_t on 32-bit targets (both vary between
> int and long).
> 

Hmmm, that's interesting.  It looks like Linux always uses long long for 
64 bit types, while glibc uses 'long' as long as it's possible, and only 
uses 'long long' when necessary.  Assignment is still 100% valid both 
ways and binary compatibility also 100% (AFAIK), given they're the same 
length and signedness, but pointers are incompatible.  That's something 
to note, even though in this case there are no pointers involved, so no 
incompatibilities.  Maybe the kernel and glibc could use the same rules 
to improve compatibility, but that's out of the scope of this.

Thanks,

Alex


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 18:54             ` Alejandro Colomar (man-pages)
  2021-05-04 19:45               ` Florian Weimer
@ 2021-05-04 20:06               ` Daniel Borkmann
  2021-05-04 20:16                 ` Alejandro Colomar (man-pages)
  2021-05-04 20:33                 ` Zack Weinberg
  2021-05-15 19:01               ` [PATCH v3] " Alejandro Colomar
  2 siblings, 2 replies; 49+ messages in thread
From: Daniel Borkmann @ 2021-05-04 20:06 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages), Zack Weinberg, Greg KH
  Cc: Alexei Starovoitov, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight,
	davem

On 5/4/21 8:54 PM, Alejandro Colomar (man-pages) wrote:
> On 5/4/21 6:06 PM, Greg KH wrote:
>  > There's a very old post from Linus where he describes the difference
>  > between things like __u32 and uint32_t.  They are not the same, they
>  > live in different namespaces, and worlds, and can not always be swapped
>  > out for each other on all arches.>
>  > Dig it up if you are curious, but for user/kernel apis you HAVE to use
>  > the __uNN and can not use uintNN_t variants, so don't try to mix/match
>  > them, it's good to just follow the kernel standard please.
> I found these:
> 
> * [RFC] Splitting kernel headers and deprecating __KERNEL__ <https://lore.kernel.org/lkml/Pine.LNX.4.58.0412140734340.3279@ppc970.osdl.org/T/>
> 
> * coding style <https://lore.kernel.org/lkml/alpine.LFD.0.98.0706160840290.14121@woody.linux-foundation.org/>
> 
> * [patch] Small input fixes for 2.5.29 <https://lore.kernel.org/lkml/Pine.LNX.4.33.0207301417190.2051-100000@penguin.transmeta.com/T/>
> 
> I already knew the first one, and now found the other two.  If there's any other thread that is relevant, I couldn't find it.
> 
> The thing is, in all of those threads, the only reasons to avoid <stdint.h> types in the kernel (at least, the only explicitly mentioned ones) are (a bit simplified, but this is the general idea of those threads):
> 
> * Possibly breaking something in such a big automated change.
> * Namespace collision with userspace (the C standard allows defining uint32_t for nefarious purposes as long as you don't include <stdint.h>.  POSIX prohibits that, though)
> * Uglier
> 
> But
> 
> * The manual pages only document the variable size and signedness by using either '__u32' or 'uint32_t'.  We state that the variable is an unsigned integer of exactly 32 bits; nothing more and nothing less.  It doesn't specify that those types are defined in <linux/bpf.h> (or whatever header a specific manual page uses).  In fact, in uint32_t(3) we clearly state the headers that shall provide the type.  In the end, the kernel will receive a 32 bit number.  I'm not exactly sure about what is wrong with this.  Is there any magic in the kernel/user interface beyond what the standard and the compiler define that I ignore?
> 
> * At that time (~2004), the C99 and POSIX.1-2001 standards were quite young, and it was likely to find code that defined uint32_t.  Currently, it is hard to find something that compiles without C99, and even if C99 allows you to define uint32_t as long as you don't include <stdint.h>, it would be really stupid to do so.  And POSIX, which completely prohibits defining uint32_t, is also very present in Linux and other UNIX systems.  So we can probably guarantee that using <stdint.h> in the kernel wouldn't break anything.  But yet this isn't trying to do so. This is only about the manual pages.
> 
> I haven't read it in any of those threads, but suspect that the static analyzer used for the kernel might use extra information from the different 'u32'/'__u32' type names to do some extra checks.  Does it?
> 
>  > and can not always be swapped out for each other on all arches.
> 
> Really?  'uint32_t' is defined as "an unsigned integer type of a fixed width of exactly 32 bits".  How is that different from '[__]u32'? Aren't the kernel types guaranteed to be unsigned integers of exactly 32 bits?  AFAICT, they are 100% binary compatible; and if not, it's probably a kernel bug.
> 
> Yes there are archs that don't provide 64 bit integers (I ignore if any of the archs supported by Linux does though), but if an arch doesn't provide 'uint64_t', it will neither be possible to have '__u64'.
> 
> [
>         uintN_t
>                Include: <stdint.h>.  Alternatively, <inttypes.h>.
> 
>                uint8_t, uint16_t, uint32_t, uint64_t
> 
>                An unsigned integer type of a fixed width  of  ex‐
>                actly  N  bits, N being the value specified in its
>                type name.  According to the C language  standard,
>                they  shall  be  capable  of storing values in the
>                range [0, UINTN_MAX], substituting N by the appro‐
>                priate number.
> 
>                According   to   POSIX,   uint8_t,  uint16_t,  and
>                uint32_t are required; uint64_t is  only  required
>                in implementations that provide integer types with
>                width 64; and all other types of this form are op‐
>                tional.
> 
> ] -- uint32_t(3)
> 
> 
>  >
>  > So consider this my:
>  >
>  > Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>  >
>  > as well.
> Okay.
> 
> On 5/4/21 6:08 PM, Daniel Borkmann wrote:
>  >
>  > But what /problem/ is this really solving? Why bother to change this /now/
>  > after so many years?! I think this is causing more confusion than solving
>  > anything, really. Moreover, what are you doing with all the
>  > __{le,be}{16,32,64}
>  > types in uapi? Anyway, NAK for bpf.2 specifically, and the idea generally..
> 
> I'm trying to clarify the manual pages as much as possible, by using standard conventions and similar structure all around the pages.  Not everyone understands kernel conventions.  Basically, Zack said very much what I had in mind with this patch.

But then are you also converting, for example, __{le,be}{16,32,64} to plain
uint{16,32,64}_t in the man pages and thus removing contextual information
(or inventing new equivalent types)?

What about other types exposed to user space like __sum16, __wsum, or __poll_t
when they are part of a man page, etc?

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 20:06               ` Daniel Borkmann
@ 2021-05-04 20:16                 ` Alejandro Colomar (man-pages)
  2021-05-04 20:33                 ` Zack Weinberg
  1 sibling, 0 replies; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-05-04 20:16 UTC (permalink / raw)
  To: Daniel Borkmann, Zack Weinberg, Greg KH
  Cc: Alexei Starovoitov, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight,
	davem

Hi Daniel,

On 5/4/21 10:06 PM, Daniel Borkmann wrote:
>>
>> On 5/4/21 6:08 PM, Daniel Borkmann wrote:
>>  >
>>  > But what /problem/ is this really solving? Why bother to change 
>> this /now/
>>  > after so many years?! I think this is causing more confusion than 
>> solving
>>  > anything, really. Moreover, what are you doing with all the
>>  > __{le,be}{16,32,64}
>>  > types in uapi? Anyway, NAK for bpf.2 specifically, and the idea 
>> generally..
>>
>> I'm trying to clarify the manual pages as much as possible, by using 
>> standard conventions and similar structure all around the pages.  Not 
>> everyone understands kernel conventions.  Basically, Zack said very 
>> much what I had in mind with this patch.
> 
> But then are you also converting, for example, __{le,be}{16,32,64} to plain
> uint{16,32,64}_t in the man pages and thus removing contextual information
> (or inventing new equivalent types)?
> 
> What about other types exposed to user space like __sum16, __wsum, or 
> __poll_t
> when they are part of a man page, etc?

Sorry, I forgot to address that part in my answer.  If there's no 
standard way of naming a type without losing information, we can use the 
kernel naming.  I have no objection to that.

These are the only pages that seem to be using those:

$ grep -Enr '\b__[a-z][a-z]+[0-9]+' man?
man2/clone.2:44:clone, __clone2, clone3 \- create a child process
man2/clone.2:1694:.BI "int __clone2(int (*" "fn" ")(void *),"
man2/clone.2:1717:.BR __clone2 ()
man7/sock_diag.7:362:    __be16  idiag_sport;
man7/sock_diag.7:363:    __be16  idiag_dport;
man7/sock_diag.7:364:    __be32  idiag_src[4];
man7/sock_diag.7:365:    __be32  idiag_dst[4];
man7/bpf-helpers.7:514:.B \fBlong bpf_skb_vlan_push(struct sk_buff 
*\fP\fIskb\fP\fB, __be16\fP \fIvlan_proto\fP\fB, u16\fP 
\fIvlan_tci\fP\fB)\fP
man7/bpf-helpers.7:878:.B \fBs64 bpf_csum_diff(__be32 *\fP\fIfrom\fP\fB, 
u32\fP \fIfrom_size\fP\fB, __be32 *\fP\fIto\fP\fB, u32\fP 
\fIto_size\fP\fB, __wsum\fP \fIseed\fP\fB)\fP
man7/bpf-helpers.7:949:.B \fBlong bpf_skb_change_proto(struct sk_buff 
*\fP\fIskb\fP\fB, __be16\fP \fIproto\fP\fB, u64\fP \fIflags\fP\fB)\fP
man7/system_data_types.7:473:.I __int128
man7/system_data_types.7:475:.I __int128
man7/system_data_types.7:1584:.I unsigned __int128
man7/system_data_types.7:1586:.I unsigned __int128
$

So sock_diag.7 and bpf-helpers.7 and only a handful of cases. Not much 
of a problem.  I'd keep those untouched.

Regards,

Alex



-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 20:06               ` Daniel Borkmann
  2021-05-04 20:16                 ` Alejandro Colomar (man-pages)
@ 2021-05-04 20:33                 ` Zack Weinberg
  2021-05-04 21:23                   ` Alexei Starovoitov
  1 sibling, 1 reply; 49+ messages in thread
From: Zack Weinberg @ 2021-05-04 20:33 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: Alejandro Colomar (man-pages),
	Greg KH, Alexei Starovoitov, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight,
	David Miller

On Tue, May 4, 2021 at 4:06 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > I'm trying to clarify the manual pages as much as possible, by using standard conventions and similar structure all around the pages.  Not everyone understands kernel conventions.  Basically, Zack said very much what I had in mind with this patch.
>
> But then are you also converting, for example, __{le,be}{16,32,64} to plain
> uint{16,32,64}_t in the man pages and thus removing contextual information
> (or inventing new equivalent types)?
>
> What about other types exposed to user space like __sum16, __wsum, or __poll_t
> when they are part of a man page, etc?

Fields that are specifically in some endianness that isn't
(necessarily) the CPU's _should_ be documented as such in the manpage,
but I dunno if __{le,be}{16,32,64} as a type name is the ideal way to
do it.  There is no off-the-shelf notation for this as far as I know.

I do not know what __sum16, __wsum, and __poll_t are used for, but I
want to remind everyone again that the kernel's concerns are not
necessarily user space's concerns and the information that should
appear in the manpages is the information that is most relevant to
user space programmers.

zw

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 20:33                 ` Zack Weinberg
@ 2021-05-04 21:23                   ` Alexei Starovoitov
  0 siblings, 0 replies; 49+ messages in thread
From: Alexei Starovoitov @ 2021-05-04 21:23 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Daniel Borkmann, Alejandro Colomar (man-pages),
	Greg KH, Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers, David Laight,
	David Miller

On Tue, May 4, 2021 at 1:33 PM Zack Weinberg <zackw@panix.com> wrote:
> the information that should
> appear in the manpages is the information that is most relevant to
> user space programmers.

The bpf programs are compiled for the kernel and run in the kernel.
Hence bpf man pages must reflect the kernel.
Also there is BTF where type names are part of the verification process.
if a user decides to rename a type it will be rejected by the kernel verifier.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-04 19:45               ` Florian Weimer
  2021-05-04 19:59                 ` Alejandro Colomar (man-pages)
@ 2021-05-05  8:23                 ` David Laight
  2021-05-05 22:22                   ` Joseph Myers
  1 sibling, 1 reply; 49+ messages in thread
From: David Laight @ 2021-05-05  8:23 UTC (permalink / raw)
  To: 'Florian Weimer', Alejandro Colomar (man-pages)
  Cc: Zack Weinberg, Greg KH, Daniel Borkmann, Alexei Starovoitov,
	Michael Kerrisk (man-pages),
	linux-man, LKML, glibc, GCC, bpf, Joseph Myers

From: Florian Weimer
> Sent: 04 May 2021 20:46
> 
> * Alejandro Colomar:
> 
> > The thing is, in all of those threads, the only reasons to avoid
> > <stdint.h> types in the kernel (at least, the only explicitly
> > mentioned ones) are (a bit simplified, but this is the general idea of
> > those threads):
> >
> > * Possibly breaking something in such a big automated change.
> > * Namespace collision with userspace (the C standard allows defining
> >   uint32_t for nefarious purposes as long as you don't include
> >  <stdint.h>.   POSIX prohibits that, though)
> > * Uglier
> 
> __u64 can't be formatted with %llu on all architectures.  That's not
> true for uint64_t, where you have to use %lu on some architectures to
> avoid compiler warnings (and technically undefined behavior).  There are
> preprocessor macros to get the expected format specifiers, but they are
> clunky.  I don't know if the problem applies to uint32_t.  It does
> happen with size_t and ptrdiff_t on 32-bit targets (both vary between
> int and long).

uint32_t can be 'randomly' either int or long on typical 32bit architectures.
The correct way to print it is with eg "xxx %5.4" PRI_u32 " yyy".

Typed like ptrdiff_t and size_t exist because of things like the x86
segmented model. Pointers are 32bit (segment and offset), size_t is
(probably) 16 bit (nothing can be any bigger), but ptrdiff_t has to
be 32bit to contain [-65535 .. 65535].

Kernel code has used u8, u16 and u32 since well before the standards
body even thought about fixed width types (and well before Linux).
ISTR they were considered as the standard names, but rejected and the
current definitions approved.
They were probably too worried about code already using u32 for a
variable.
(Shame they never fixed math.h)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [RFC v2] bpf.2: Use standard types and attributes
  2021-05-05  8:23                 ` David Laight
@ 2021-05-05 22:22                   ` Joseph Myers
  0 siblings, 0 replies; 49+ messages in thread
From: Joseph Myers @ 2021-05-05 22:22 UTC (permalink / raw)
  To: David Laight
  Cc: 'Florian Weimer', Alejandro Colomar (man-pages),
	linux-man, Daniel Borkmann, Greg KH, LKML, GCC,
	Michael Kerrisk (man-pages),
	glibc, bpf, Alexei Starovoitov

On Wed, 5 May 2021, David Laight via Libc-alpha wrote:

> > __u64 can't be formatted with %llu on all architectures.  That's not
> > true for uint64_t, where you have to use %lu on some architectures to
> > avoid compiler warnings (and technically undefined behavior).  There are
> > preprocessor macros to get the expected format specifiers, but they are
> > clunky.  I don't know if the problem applies to uint32_t.  It does
> > happen with size_t and ptrdiff_t on 32-bit targets (both vary between
> > int and long).
> 
> uint32_t can be 'randomly' either int or long on typical 32bit architectures.
> The correct way to print it is with eg "xxx %5.4" PRI_u32 " yyy".

C2X adds printf length modifiers such as "w32", so you can use a 
friendlier %w32u, for example.  (Not yet implemented in glibc or in GCC's 
format checking.)

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [PATCH v3] bpf.2: Use standard types and attributes
  2021-05-04 18:54             ` Alejandro Colomar (man-pages)
  2021-05-04 19:45               ` Florian Weimer
  2021-05-04 20:06               ` Daniel Borkmann
@ 2021-05-15 19:01               ` Alejandro Colomar
  2021-05-16  9:16                 ` Alejandro Colomar (man-pages)
  2 siblings, 1 reply; 49+ messages in thread
From: Alejandro Colomar @ 2021-05-15 19:01 UTC (permalink / raw)
  To: mtk.manpages
  Cc: Alejandro Colomar, linux-man, Alexei Starovoitov,
	Greg Kroah-Hartman, Zack Weinberg, LKML, glibc, GCC, bpf,
	David Laight, Joseph Myers, Florian Weimer, Daniel Borkmann

Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't.  There are some using kernel
syntax '__u32'.  Fix those.

Both the kernel and the standard types are 100% binary compatible,
and the source code differences between them are very small, and
not important in a manual page:

- Some of them are implemented with different underlying types
  (e.g., s64 is always long long, while int64_t may be long long
  or long, depending on the arch).  This causes the following
  differences.

- length modifiers required by printf are different, resulting in
  a warning ('-Wformat=').

- pointer assignment causes a warning:
  ('-Wincompatible-pointer-types'), but there aren't any pointers
  in this page.

But, AFAIK, all of those warnings can be safely ignored, due to
the binary compatibility between the types.

...

Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'.  Update those to use the shorter and more
portable C11 keywords such as 'alignas()' when possible, and C2x
syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
yet, but is already implemented in GCC, and available through
either --std=c2x or any of the --std=gnu... options.

The standard isn't very clear on how to use alignas() or
[[]]-style attributes, and the GNU documentation isn't better, so
the following link is a useful experiment about the different
alignment syntaxes:
__attribute__((aligned())), alignas(), and [[gnu::aligned()]]:
<https://stackoverflow.com/q/67271825/6872717>

Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Nacked-by: Alexei Starovoitov <ast@kernel.org>
Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Zack Weinberg <zackw@panix.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: glibc <libc-alpha@sourceware.org>
Cc: GCC <gcc-patches@gcc.gnu.org>
Cc: bpf <bpf@vger.kernel.org>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Joseph Myers <joseph@codesourcery.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
---
 man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 6e1ffa198..04b8fbcef 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -186,41 +186,40 @@ commands:
 .PP
 .in +4n
 .EX
-union bpf_attr {
+union [[gnu::aligned(8)]] bpf_attr {
     struct {    /* Used by BPF_MAP_CREATE */
-        __u32         map_type;
-        __u32         key_size;    /* size of key in bytes */
-        __u32         value_size;  /* size of value in bytes */
-        __u32         max_entries; /* maximum number of entries
-                                      in a map */
+        uint32_t    map_type;
+        uint32_t    key_size;    /* size of key in bytes */
+        uint32_t    value_size;  /* size of value in bytes */
+        uint32_t    max_entries; /* maximum number of entries
+                                    in a map */
     };
 
-    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
-                   commands */
-        __u32         map_fd;
-        __aligned_u64 key;
+    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY commands */
+        uint32_t            map_fd;
+        uint64_t alignas(8) key;
         union {
-            __aligned_u64 value;
-            __aligned_u64 next_key;
+            uint64_t alignas(8) value;
+            uint64_t alignas(8) next_key;
         };
-        __u64         flags;
+        uint64_t            flags;
     };
 
     struct {    /* Used by BPF_PROG_LOAD */
-        __u32         prog_type;
-        __u32         insn_cnt;
-        __aligned_u64 insns;      /* \(aqconst struct bpf_insn *\(aq */
-        __aligned_u64 license;    /* \(aqconst char *\(aq */
-        __u32         log_level;  /* verbosity level of verifier */
-        __u32         log_size;   /* size of user buffer */
-        __aligned_u64 log_buf;    /* user supplied \(aqchar *\(aq
-                                     buffer */
-        __u32         kern_version;
-                                  /* checked when prog_type=kprobe
-                                     (since Linux 4.1) */
+        uint32_t            prog_type;
+        uint32_t            insn_cnt;
+        uint64_t alignas(8) insns;     /* \(aqconst struct bpf_insn *\(aq */
+        uint64_t alignas(8) license;   /* \(aqconst char *\(aq */
+        uint32_t            log_level; /* verbosity level of verifier */
+        uint32_t            log_size;  /* size of user buffer */
+        uint64_t alignas(8) log_buf;   /* user supplied \(aqchar *\(aq
+                                          buffer */
+        uint32_t            kern_version;
+                                       /* checked when prog_type=kprobe
+                                          (since Linux 4.1) */
 .\"                 commit 2541517c32be2531e0da59dfd7efc1ce844644f5
     };
-} __attribute__((aligned(8)));
+};
 .EE
 .in
 .\"
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] bpf.2: Use standard types and attributes
  2021-05-15 19:01               ` [PATCH v3] " Alejandro Colomar
@ 2021-05-16  9:16                 ` Alejandro Colomar (man-pages)
  2021-05-17 18:56                   ` Daniel Borkmann
  0 siblings, 1 reply; 49+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-05-16  9:16 UTC (permalink / raw)
  To: mtk.manpages
  Cc: linux-man, Alexei Starovoitov, Greg Kroah-Hartman, Zack Weinberg,
	LKML, glibc, GCC, bpf, David Laight, Joseph Myers,
	Florian Weimer, Daniel Borkmann

On 5/15/21 9:01 PM, Alejandro Colomar wrote:
> Some manual pages are already using C99 syntax for integral
> types 'uint32_t', but some aren't.  There are some using kernel
> syntax '__u32'.  Fix those.
> 
> Both the kernel and the standard types are 100% binary compatible,
> and the source code differences between them are very small, and
> not important in a manual page:
> 
> - Some of them are implemented with different underlying types
>    (e.g., s64 is always long long, while int64_t may be long long
>    or long, depending on the arch).  This causes the following
>    differences.
> 
> - length modifiers required by printf are different, resulting in
>    a warning ('-Wformat=').
> 
> - pointer assignment causes a warning:
>    ('-Wincompatible-pointer-types'), but there aren't any pointers
>    in this page.
> 
> But, AFAIK, all of those warnings can be safely ignored, due to
> the binary compatibility between the types.
> 
> ...
> 
> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))'.  Update those to use the shorter and more
> portable C11 keywords such as 'alignas()' when possible, and C2x
> syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
> yet, but is already implemented in GCC, and available through
> either --std=c2x or any of the --std=gnu... options.
> 
> The standard isn't very clear on how to use alignas() or
> [[]]-style attributes, and the GNU documentation isn't better, so
> the following link is a useful experiment about the different
> alignment syntaxes:
> __attribute__((aligned())), alignas(), and [[gnu::aligned()]]:
> <https://stackoverflow.com/q/67271825/6872717>
> 
> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Discussion: 
<https://lore.kernel.org/linux-man/6740a229-842e-b368-86eb-defc786b3658@gmail.com/T/>
> Nacked-by: Alexei Starovoitov <ast@kernel.org>
> Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Acked-by: Zack Weinberg <zackw@panix.com>
> Cc: LKML <linux-kernel@vger.kernel.org>
> Cc: glibc <libc-alpha@sourceware.org>
> Cc: GCC <gcc-patches@gcc.gnu.org>
> Cc: bpf <bpf@vger.kernel.org>
> Cc: David Laight <David.Laight@ACULAB.COM>
> Cc: Joseph Myers <joseph@codesourcery.com>
> Cc: Florian Weimer <fweimer@redhat.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> ---
>   man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
>   1 file changed, 24 insertions(+), 25 deletions(-)
> 
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index 6e1ffa198..04b8fbcef 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -186,41 +186,40 @@ commands:
>   .PP
>   .in +4n
>   .EX
> -union bpf_attr {
> +union [[gnu::aligned(8)]] bpf_attr {
>       struct {    /* Used by BPF_MAP_CREATE */
> -        __u32         map_type;
> -        __u32         key_size;    /* size of key in bytes */
> -        __u32         value_size;  /* size of value in bytes */
> -        __u32         max_entries; /* maximum number of entries
> -                                      in a map */
> +        uint32_t    map_type;
> +        uint32_t    key_size;    /* size of key in bytes */
> +        uint32_t    value_size;  /* size of value in bytes */
> +        uint32_t    max_entries; /* maximum number of entries
> +                                    in a map */
>       };
>   
> -    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
> -                   commands */
> -        __u32         map_fd;
> -        __aligned_u64 key;
> +    struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY commands */
> +        uint32_t            map_fd;
> +        uint64_t alignas(8) key;
>           union {
> -            __aligned_u64 value;
> -            __aligned_u64 next_key;
> +            uint64_t alignas(8) value;
> +            uint64_t alignas(8) next_key;
>           };
> -        __u64         flags;
> +        uint64_t            flags;
>       };
>   
>       struct {    /* Used by BPF_PROG_LOAD */
> -        __u32         prog_type;
> -        __u32         insn_cnt;
> -        __aligned_u64 insns;      /* \(aqconst struct bpf_insn *\(aq */
> -        __aligned_u64 license;    /* \(aqconst char *\(aq */
> -        __u32         log_level;  /* verbosity level of verifier */
> -        __u32         log_size;   /* size of user buffer */
> -        __aligned_u64 log_buf;    /* user supplied \(aqchar *\(aq
> -                                     buffer */
> -        __u32         kern_version;
> -                                  /* checked when prog_type=kprobe
> -                                     (since Linux 4.1) */
> +        uint32_t            prog_type;
> +        uint32_t            insn_cnt;
> +        uint64_t alignas(8) insns;     /* \(aqconst struct bpf_insn *\(aq */
> +        uint64_t alignas(8) license;   /* \(aqconst char *\(aq */
> +        uint32_t            log_level; /* verbosity level of verifier */
> +        uint32_t            log_size;  /* size of user buffer */
> +        uint64_t alignas(8) log_buf;   /* user supplied \(aqchar *\(aq
> +                                          buffer */
> +        uint32_t            kern_version;
> +                                       /* checked when prog_type=kprobe
> +                                          (since Linux 4.1) */
>   .\"                 commit 2541517c32be2531e0da59dfd7efc1ce844644f5
>       };
> -} __attribute__((aligned(8)));
> +};
>   .EE
>   .in
>   .\"
> 


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] bpf.2: Use standard types and attributes
  2021-05-16  9:16                 ` Alejandro Colomar (man-pages)
@ 2021-05-17 18:56                   ` Daniel Borkmann
  2021-05-21 11:12                     ` Alejandro Colomar
  0 siblings, 1 reply; 49+ messages in thread
From: Daniel Borkmann @ 2021-05-17 18:56 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages), mtk.manpages
  Cc: linux-man, Alexei Starovoitov, Greg Kroah-Hartman, Zack Weinberg,
	LKML, glibc, GCC, bpf, David Laight, Joseph Myers,
	Florian Weimer

On 5/16/21 11:16 AM, Alejandro Colomar (man-pages) wrote:
> On 5/15/21 9:01 PM, Alejandro Colomar wrote:
>> Some manual pages are already using C99 syntax for integral
>> types 'uint32_t', but some aren't.  There are some using kernel
>> syntax '__u32'.  Fix those.
>>
>> Both the kernel and the standard types are 100% binary compatible,
>> and the source code differences between them are very small, and
>> not important in a manual page:
>>
>> - Some of them are implemented with different underlying types
>>    (e.g., s64 is always long long, while int64_t may be long long
>>    or long, depending on the arch).  This causes the following
>>    differences.
>>
>> - length modifiers required by printf are different, resulting in
>>    a warning ('-Wformat=').
>>
>> - pointer assignment causes a warning:
>>    ('-Wincompatible-pointer-types'), but there aren't any pointers
>>    in this page.
>>
>> But, AFAIK, all of those warnings can be safely ignored, due to
>> the binary compatibility between the types.
>>
>> ...
>>
>> Some pages also document attributes, using GNU syntax
>> '__attribute__((xxx))'.  Update those to use the shorter and more
>> portable C11 keywords such as 'alignas()' when possible, and C2x
>> syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
>> yet, but is already implemented in GCC, and available through
>> either --std=c2x or any of the --std=gnu... options.
>>
>> The standard isn't very clear on how to use alignas() or
>> [[]]-style attributes, and the GNU documentation isn't better, so
>> the following link is a useful experiment about the different
>> alignment syntaxes:
>> __attribute__((aligned())), alignas(), and [[gnu::aligned()]]:
>> <https://stackoverflow.com/q/67271825/6872717>
>>
>> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> Discussion: <https://lore.kernel.org/linux-man/6740a229-842e-b368-86eb-defc786b3658@gmail.com/T/>
>> Nacked-by: Alexei Starovoitov <ast@kernel.org>
>> Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

You forgot to retain my ...

Nacked-by: Daniel Borkmann <daniel@iogearbox.net>

>> Acked-by: Zack Weinberg <zackw@panix.com>
>> Cc: LKML <linux-kernel@vger.kernel.org>
>> Cc: glibc <libc-alpha@sourceware.org>
>> Cc: GCC <gcc-patches@gcc.gnu.org>
>> Cc: bpf <bpf@vger.kernel.org>
>> Cc: David Laight <David.Laight@ACULAB.COM>
>> Cc: Joseph Myers <joseph@codesourcery.com>
>> Cc: Florian Weimer <fweimer@redhat.com>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>>   man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
>>   1 file changed, 24 insertions(+), 25 deletions(-)
>>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] bpf.2: Use standard types and attributes
  2021-05-17 18:56                   ` Daniel Borkmann
@ 2021-05-21 11:12                     ` Alejandro Colomar
  0 siblings, 0 replies; 49+ messages in thread
From: Alejandro Colomar @ 2021-05-21 11:12 UTC (permalink / raw)
  To: Daniel Borkmann, Alejandro Colomar (man-pages), mtk.manpages
  Cc: linux-man, Alexei Starovoitov, Greg Kroah-Hartman, Zack Weinberg,
	LKML, glibc, GCC, bpf, David Laight, Joseph Myers,
	Florian Weimer

Hello Daniel,

On 5/17/21 8:56 PM, Daniel Borkmann wrote:
> On 5/16/21 11:16 AM, Alejandro Colomar (man-pages) wrote:
>>>
>>> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
>> Discussion: 
>> <https://lore.kernel.org/linux-man/6740a229-842e-b368-86eb-defc786b3658@gmail.com/T/> 
>>
>>> Nacked-by: Alexei Starovoitov <ast@kernel.org>
>>> Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> You forgot to retain my ...
> 
> Nacked-by: Daniel Borkmann <daniel@iogearbox.net>

Yup! Sorry, I forgot :)

Thanks,

Alex

> 
>>> Acked-by: Zack Weinberg <zackw@panix.com>
>>> Cc: LKML <linux-kernel@vger.kernel.org>
>>> Cc: glibc <libc-alpha@sourceware.org>
>>> Cc: GCC <gcc-patches@gcc.gnu.org>
>>> Cc: bpf <bpf@vger.kernel.org>
>>> Cc: David Laight <David.Laight@ACULAB.COM>
>>> Cc: Joseph Myers <joseph@codesourcery.com>
>>> Cc: Florian Weimer <fweimer@redhat.com>
>>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>>> ---
>>>   man2/bpf.2 | 49 ++++++++++++++++++++++++-------------------------
>>>   1 file changed, 24 insertions(+), 25 deletions(-)
>>>


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2021-04-23 23:06 [RFC] bpf.2: Use standard types and attributes Alejandro Colomar
                   ` (2 preceding siblings ...)
  2021-05-04 11:05 ` [RFC v2] " Alejandro Colomar
@ 2022-08-24 18:55 ` Alejandro Colomar
  2022-08-24 22:40   ` Alexei Starovoitov
  3 siblings, 1 reply; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-24 18:55 UTC (permalink / raw)
  To: linux-man
  Cc: Alejandro Colomar, Alexei Starovoitov, Greg Kroah-Hartman,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Joseph Myers,
	Florian Weimer, Cyril Hrubis, David Howells, Arnd Bergmann,
	Rich Felker, Adhemerval Zanella

Kernel __u64 and similar types are ABI-compatible, and mostly
API-compatible with ISO C types.  User-space programmers don't
care about kernel details, and should only use libc types.
Document syscalls and structures provided by the Linux kernel as
if they used libc types.

There's work in the kernel to remove this small API
incompatibility, which is only for pointers or printf specifiers.

Since I couldn't find any structure that uses pointers, there
shouldn't be any issues here.  Also, the only pointer I found was
in a syscall parameter, but since syscall(2) doesn't check its
arguments' types, we're also safe there.

This patch doesn't go without controversy.  Check the discussions
in the links below.

Found with:

$ grep -rn '\b_*[su][8136][624]*\b' man* \
  | grep -v -e /bpf-helpers.7 -e /proc.5 -e /epoll_event.3type -e /wcscmp.3 \
            -e /crypt.3 -e /mempcpy.3 -e /memcmp.3 -e /string.3 -e /wcsncmp.3 \
            -e /wcscasecmp.3 -e /wmemcmp.3 -e /strcasecmp.3 -e /bcmp.3 \
            -e /bstring.3 -e /endian.3 -e /strverscmp.3 -e /wcsncasecmp.3 \
            -e /strcoll.3 -e /strcmp.3 \
  | tee /dev/tty \
  | wc -l;

Link: <https://lore.kernel.org/linux-man/20210423230609.13519-1-alx.manpages@gmail.com/T/>
Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Nacked-by: Alexei Starovoitov <ast@kernel.org>
Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nacked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Zack Weinberg <zackw@panix.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: glibc <libc-alpha@sourceware.org>
Cc: GCC <gcc-patches@gcc.gnu.org>
Cc: bpf <bpf@vger.kernel.org>
Cc: LTP List <ltp@lists.linux.it>
Cc: Linux API <linux-api@vger.kernel.org>
Cc: linux-arch <linux-arch@vger.kernel.org>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Joseph Myers <joseph@codesourcery.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Cyril Hrubis <chrubis@suse.cz>
Cc: David Howells <dhowells@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Rich Felker <dalias@libc.org>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
---

Hi,

I removed attributes from this patch.  It now only changes types,
and only types that don't have anything special in them.  __be64
or things like that are not included in this patch.  __aligned_u64
isn't either.

I made clear what the incompatibilities are, and I hope Cyril
fixes them soon, but anyway, they shouldn't affect for the cases
documented here.  And if they affect somehow, a programmer will
probably know the reason; but I'd consider that a kernel bug, or
at least something to improve there.

I'm decided to push for this change, and would like to see the
kernel making the necessary steps to make it smoother, since it
shouldn't be hard (the patch is there already; it only needs a
little bit of love).

Anyway, I don't think it will cause important problems to readers
of the manual pages, and instead expect an improvement.

Cheers,

Alex


 man2/bpf.2                     |  28 +-
 man2/capget.2                  |  10 +-
 man2/clone.2                   |  36 +--
 man2/getunwind.2               |   6 +-
 man2/io_submit.2               |  22 +-
 man2/ioctl_ficlonerange.2      |   8 +-
 man2/ioctl_fideduperange.2     |  20 +-
 man2/ioctl_getfsmap.2          |  28 +-
 man2/ioctl_userfaultfd.2       |  37 +--
 man2/kcmp.2                    |   6 +-
 man2/keyctl.2                  |   8 +-
 man2/landlock_add_rule.2       |   4 +-
 man2/landlock_create_ruleset.2 |   2 +-
 man2/mount_setattr.2           |   8 +-
 man2/perf_event_open.2         | 486 ++++++++++++++++-----------------
 man2/ptrace.2                  |  40 +--
 man2/sched_setattr.2           |  20 +-
 man2/seccomp.2                 |  24 +-
 man2/seccomp_unotify.2         |  32 +--
 man2/statx.2                   |  42 +--
 man2/userfaultfd.2             |  28 +-
 man2type/open_how.2type        |   6 +-
 man3type/epoll_event.3type     |   2 +-
 man4/loop.4                    |   6 +-
 man4/random.4                  |   6 +-
 man7/fanotify.7                |  28 +-
 man7/netdevice.7               |   2 +-
 man7/netlink.7                 |  14 +-
 man7/packet.7                  |  16 +-
 man7/rtnetlink.7               |  20 +-
 man7/sock_diag.7               | 122 +++++----
 31 files changed, 568 insertions(+), 549 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index d05b73ec2..84d1b62e5 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -169,34 +169,34 @@ commands:
 .EX
 union bpf_attr {
     struct {    /* Used by BPF_MAP_CREATE */
-        __u32         map_type;
-        __u32         key_size;    /* size of key in bytes */
-        __u32         value_size;  /* size of value in bytes */
-        __u32         max_entries; /* maximum number of entries
+        uint32_t      map_type;
+        uint32_t      key_size;    /* size of key in bytes */
+        uint32_t      value_size;  /* size of value in bytes */
+        uint32_t      max_entries; /* maximum number of entries
                                       in a map */
     };
 
     struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
                    commands */
-        __u32         map_fd;
+        uint32_t      map_fd;
         __aligned_u64 key;
         union {
             __aligned_u64 value;
             __aligned_u64 next_key;
         };
-        __u64         flags;
+        uint64_t      flags;
     };
 
     struct {    /* Used by BPF_PROG_LOAD */
-        __u32         prog_type;
-        __u32         insn_cnt;
+        uint32_t      prog_type;
+        uint32_t      insn_cnt;
         __aligned_u64 insns;      /* \(aqconst struct bpf_insn *\(aq */
         __aligned_u64 license;    /* \(aqconst char *\(aq */
-        __u32         log_level;  /* verbosity level of verifier */
-        __u32         log_size;   /* size of user buffer */
+        uint32_t      log_level;  /* verbosity level of verifier */
+        uint32_t      log_size;   /* size of user buffer */
         __aligned_u64 log_buf;    /* user supplied \(aqchar *\(aq
                                      buffer */
-        __u32         kern_version;
+        uint32_t      kern_version;
                                   /* checked when prog_type=kprobe
                                      (since Linux 4.1) */
 .\"                 commit 2541517c32be2531e0da59dfd7efc1ce844644f5
@@ -317,7 +317,7 @@ of 1 and the eBPF program contains
 .in +4n
 .EX
 value = bpf_map_lookup_elem(...);
-*(u32 *) value = 1;
+*(uint32_t *) value = 1;
 .EE
 .in
 .IP
@@ -1212,7 +1212,7 @@ main(int argc, char *argv[])
         BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol)),
                                 /* r0 = ip\->proto */
         BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, \-4),
-                                /* *(u32 *)(fp \- 4) = r0 */
+                                /* *(uint32_t *)(fp \- 4) = r0 */
         BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),       /* r2 = fp */
         BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, \-4),      /* r2 = r2 \- 4 */
         BPF_LD_MAP_FD(BPF_REG_1, map_fd),           /* r1 = map_fd */
@@ -1222,7 +1222,7 @@ main(int argc, char *argv[])
                                 /* if (r0 == 0) goto pc+2 */
         BPF_MOV64_IMM(BPF_REG_1, 1),                /* r1 = 1 */
         BPF_XADD(BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
-                                /* lock *(u64 *) r0 += r1 */
+                                /* lock *(uint64_t *) r0 += r1 */
 .\"                                == atomic64_add
         BPF_MOV64_IMM(BPF_REG_0, 0),                /* r0 = 0 */
         BPF_EXIT_INSN(),                            /* return r0 */
diff --git a/man2/capget.2 b/man2/capget.2
index 5820c29f1..1e155075f 100644
--- a/man2/capget.2
+++ b/man2/capget.2
@@ -71,14 +71,14 @@ The structures are defined as follows.
 #define _LINUX_CAPABILITY_U32S_3     2
 
 typedef struct __user_cap_header_struct {
-   __u32 version;
-   int pid;
+   uint32_t  version;
+   int       pid;
 } *cap_user_header_t;
 
 typedef struct __user_cap_data_struct {
-   __u32 effective;
-   __u32 permitted;
-   __u32 inheritable;
+   uint32_t  effective;
+   uint32_t  permitted;
+   uint32_t  inheritable;
 } *cap_user_data_t;
 .EE
 .in
diff --git a/man2/clone.2 b/man2/clone.2
index e3f8e6904..8964c5607 100644
--- a/man2/clone.2
+++ b/man2/clone.2
@@ -188,24 +188,24 @@ is a structure of the following form:
 .in +4n
 .EX
 struct clone_args {
-    u64 flags;        /* Flags bit mask */
-    u64 pidfd;        /* Where to store PID file descriptor
-                         (\fIint *\fP) */
-    u64 child_tid;    /* Where to store child TID,
-                         in child\(aqs memory (\fIpid_t *\fP) */
-    u64 parent_tid;   /* Where to store child TID,
-                         in parent\(aqs memory (\fIpid_t *\fP) */
-    u64 exit_signal;  /* Signal to deliver to parent on
-                         child termination */
-    u64 stack;        /* Pointer to lowest byte of stack */
-    u64 stack_size;   /* Size of stack */
-    u64 tls;          /* Location of new TLS */
-    u64 set_tid;      /* Pointer to a \fIpid_t\fP array
-                         (since Linux 5.5) */
-    u64 set_tid_size; /* Number of elements in \fIset_tid\fP
-                         (since Linux 5.5) */
-    u64 cgroup;       /* File descriptor for target cgroup
-                         of child (since Linux 5.7) */
+    uint64_t  flags;        /* Flags bit mask */
+    uint64_t  pidfd;        /* Where to store PID file descriptor
+                               (\fIint *\fP) */
+    uint64_t  child_tid;    /* Where to store child TID,
+                               in child\(aqs memory (\fIpid_t *\fP) */
+    uint64_t  parent_tid;   /* Where to store child TID,
+                               in parent\(aqs memory (\fIpid_t *\fP) */
+    uint64_t  exit_signal;  /* Signal to deliver to parent on
+                               child termination */
+    uint64_t  stack;        /* Pointer to lowest byte of stack */
+    uint64_t  stack_size;   /* Size of stack */
+    uint64_t  tls;          /* Location of new TLS */
+    uint64_t  set_tid;      /* Pointer to a \fIpid_t\fP array
+                               (since Linux 5.5) */
+    uint64_t  set_tid_size; /* Number of elements in \fIset_tid\fP
+                               (since Linux 5.5) */
+    uint64_t  cgroup;       /* File descriptor for target cgroup
+                               of child (since Linux 5.7) */
 };
 .EE
 .in
diff --git a/man2/getunwind.2 b/man2/getunwind.2
index 94935ba02..fb64a1185 100644
--- a/man2/getunwind.2
+++ b/man2/getunwind.2
@@ -55,9 +55,9 @@ The unwind table contains entries of the following form:
 .PP
 .in +4n
 .EX
-u64 start;      (64\-bit address of start of function)
-u64 end;        (64\-bit address of end of function)
-u64 info;       (BUF\-relative offset to unwind info)
+uint64_t  start;      (64\-bit address of start of function)
+uint64_t  end;        (64\-bit address of end of function)
+uint64_t  info;       (BUF\-relative offset to unwind info)
 .EE
 .in
 .PP
diff --git a/man2/io_submit.2 b/man2/io_submit.2
index 308d90575..7eccba170 100644
--- a/man2/io_submit.2
+++ b/man2/io_submit.2
@@ -54,17 +54,17 @@ defines the parameters that control the I/O operation.
 #include <linux/aio_abi.h>
 
 struct iocb {
-    __u64   aio_data;
-    __u32   PADDED(aio_key, aio_rw_flags);
-    __u16   aio_lio_opcode;
-    __s16   aio_reqprio;
-    __u32   aio_fildes;
-    __u64   aio_buf;
-    __u64   aio_nbytes;
-    __s64   aio_offset;
-    __u64   aio_reserved2;
-    __u32   aio_flags;
-    __u32   aio_resfd;
+    uint64_t  aio_data;
+    uint32_t  PADDED(aio_key, aio_rw_flags);
+    uint16_t  aio_lio_opcode;
+    int16_t   aio_reqprio;
+    uint32_t  aio_fildes;
+    uint64_t  aio_buf;
+    uint64_t  aio_nbytes;
+    int64_t   aio_offset;
+    uint64_t  aio_reserved2;
+    uint32_t  aio_flags;
+    uint32_t  aio_resfd;
 };
 .EE
 .in
diff --git a/man2/ioctl_ficlonerange.2 b/man2/ioctl_ficlonerange.2
index c16d14b8b..71d546578 100644
--- a/man2/ioctl_ficlonerange.2
+++ b/man2/ioctl_ficlonerange.2
@@ -52,10 +52,10 @@ the following form:
 .in +4n
 .EX
 struct file_clone_range {
-    __s64 src_fd;
-    __u64 src_offset;
-    __u64 src_length;
-    __u64 dest_offset;
+    int64_t   src_fd;
+    uint64_t  src_offset;
+    uint64_t  src_length;
+    uint64_t  dest_offset;
 };
 .EE
 .in
diff --git a/man2/ioctl_fideduperange.2 b/man2/ioctl_fideduperange.2
index 573022aac..ee857510f 100644
--- a/man2/ioctl_fideduperange.2
+++ b/man2/ioctl_fideduperange.2
@@ -44,11 +44,11 @@ This information is conveyed in a structure of the following form:
 .in +4n
 .EX
 struct file_dedupe_range {
-    __u64 src_offset;
-    __u64 src_length;
-    __u16 dest_count;
-    __u16 reserved1;
-    __u32 reserved2;
+    uint64_t  src_offset;
+    uint64_t  src_length;
+    uint16_t  dest_count;
+    uint16_t  reserved1;
+    uint32_t  reserved2;
     struct file_dedupe_range_info info[0];
 };
 .EE
@@ -70,11 +70,11 @@ and the destination information is conveyed in the following form:
 .in +4n
 .EX
 struct file_dedupe_range_info {
-    __s64 dest_fd;
-    __u64 dest_offset;
-    __u64 bytes_deduped;
-    __s32 status;
-    __u32 reserved;
+    int64_t   dest_fd;
+    uint64_t  dest_offset;
+    uint64_t  bytes_deduped;
+    int32_t   status;
+    uint32_t  reserved;
 };
 .EE
 .in
diff --git a/man2/ioctl_getfsmap.2 b/man2/ioctl_getfsmap.2
index 0cc41cef5..6625041f3 100644
--- a/man2/ioctl_getfsmap.2
+++ b/man2/ioctl_getfsmap.2
@@ -28,25 +28,25 @@ The sole argument to this operation should be a pointer to a single
 .in +4n
 .EX
 struct fsmap {
-    __u32 fmr_device;      /* Device ID */
-    __u32 fmr_flags;       /* Mapping flags */
-    __u64 fmr_physical;    /* Device offset of segment */
-    __u64 fmr_owner;       /* Owner ID */
-    __u64 fmr_offset;      /* File offset of segment */
-    __u64 fmr_length;      /* Length of segment */
-    __u64 fmr_reserved[3]; /* Must be zero */
+    uint32_t  fmr_device;      /* Device ID */
+    uint32_t  fmr_flags;       /* Mapping flags */
+    uint64_t  fmr_physical;    /* Device offset of segment */
+    uint64_t  fmr_owner;       /* Owner ID */
+    uint64_t  fmr_offset;      /* File offset of segment */
+    uint64_t  fmr_length;      /* Length of segment */
+    uint64_t  fmr_reserved[3]; /* Must be zero */
 };
 
 struct fsmap_head {
-    __u32 fmh_iflags;       /* Control flags */
-    __u32 fmh_oflags;       /* Output flags */
-    __u32 fmh_count;        /* # of entries in array incl. input */
-    __u32 fmh_entries;      /* # of entries filled in (output) */
-    __u64 fmh_reserved[6];  /* Must be zero */
+    uint32_t  fmh_iflags;      /* Control flags */
+    uint32_t  fmh_oflags;      /* Output flags */
+    uint32_t  fmh_count;       /* # of entries in array incl. input*/
+    uint32_t  fmh_entries;     /* # of entries filled in (output) */
+    uint64_t  fmh_reserved[6]; /* Must be zero */
 
-    struct fsmap fmh_keys[2];  /* Low and high keys for
+    struct fsmap  fmh_keys[2]; /* Low and high keys for
                                   the mapping search */
-    struct fsmap fmh_recs[];   /* Returned records */
+    struct fsmap  fmh_recs[];  /* Returned records */
 };
 .EE
 .in
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 88876ce4e..fe047dea1 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -72,9 +72,9 @@ structure, defined as:
 .in +4n
 .EX
 struct uffdio_api {
-    __u64 api;        /* Requested API version (input) */
-    __u64 features;   /* Requested features (input/output) */
-    __u64 ioctls;     /* Available ioctl() operations (output) */
+    uint64_t  api;       /* Requested API version (input) */
+    uint64_t  features;  /* Requested features (input/output) */
+    uint64_t  ioctls;    /* Available ioctl() operations (output) */
 };
 .EE
 .in
@@ -278,14 +278,14 @@ structure, defined as:
 .in +4n
 .EX
 struct uffdio_range {
-    __u64 start;    /* Start of range */
-    __u64 len;      /* Length of range (bytes) */
+    uint64_t  start;    /* Start of range */
+    uint64_t  len;      /* Length of range (bytes) */
 };
 
 struct uffdio_register {
     struct uffdio_range range;
-    __u64 mode;     /* Desired mode of operation (input) */
-    __u64 ioctls;   /* Available ioctl() operations (output) */
+    uint64_t  mode;     /* Desired mode of operation (input) */
+    uint64_t  ioctls;   /* Available ioctl() operations (output) */
 };
 .EE
 .in
@@ -447,11 +447,11 @@ structure pointed to by
 .in +4n
 .EX
 struct uffdio_copy {
-    __u64 dst;    /* Destination of copy */
-    __u64 src;    /* Source of copy */
-    __u64 len;    /* Number of bytes to copy */
-    __u64 mode;   /* Flags controlling behavior of copy */
-    __s64 copy;   /* Number of bytes copied, or negated error */
+    uint64_t  dst;   /* Destination of copy */
+    uint64_t  src;   /* Source of copy */
+    uint64_t  len;   /* Number of bytes to copy */
+    uint64_t  mode;  /* Flags controlling behavior of copy */
+    int64_t   copy;  /* Number of bytes copied, or negated error */
 };
 .EE
 .in
@@ -564,8 +564,8 @@ structure pointed to by
 .EX
 struct uffdio_zeropage {
     struct uffdio_range range;
-    __u64 mode;     /* Flags controlling behavior of copy */
-    __s64 zeropage; /* Number of bytes zeroed, or negated error */
+    uint64_t mode;     /* Flags controlling behavior of copy */
+    int64_t  zeropage; /* Number of bytes zeroed, or negated error */
 };
 .EE
 .in
@@ -700,7 +700,7 @@ structure as shown below:
 .EX
 struct uffdio_writeprotect {
     struct uffdio_range range; /* Range to change write permission*/
-    __u64 mode;                /* Mode to change write permission */
+    uint64_t  mode;            /* Mode to change write permission */
 };
 .EE
 .in
@@ -769,9 +769,10 @@ structure as shown below:
 .in +4n
 .EX
 struct uffdio_continue {
-    struct uffdio_range range; /* Range to install PTEs for and continue */
-    __u64 mode;                /* Flags controlling the behavior of continue */
-    __s64 mapped;              /* Number of bytes mapped, or negated error */
+    struct uffdio_range range;
+                     /* Range to install PTEs for and continue */
+    uint64_t mode;   /* Flags controlling the behavior of continue */
+    int64_t  mapped; /* Number of bytes mapped, or negated error */
 };
 .EE
 .in
diff --git a/man2/kcmp.2 b/man2/kcmp.2
index 886d5d66c..0c5e5096a 100644
--- a/man2/kcmp.2
+++ b/man2/kcmp.2
@@ -165,9 +165,9 @@ This structure has the form:
 .in +4n
 .EX
 struct kcmp_epoll_slot {
-    __u32 efd;
-    __u32 tfd;
-    __u64 toff;
+    uint32_t  efd;
+    uint32_t  tfd;
+    uint64_t  toff;
 };
 .EE
 .in
diff --git a/man2/keyctl.2 b/man2/keyctl.2
index 2b57b5e12..a3cc0202d 100644
--- a/man2/keyctl.2
+++ b/man2/keyctl.2
@@ -1489,10 +1489,10 @@ parameters of the KDF operation to be applied:
 .in +4n
 .EX
 struct keyctl_kdf_params {
-    char *hashname;     /* Hash algorithm name */
-    char *otherinfo;    /* SP800\-56A OtherInfo */
-    __u32 otherinfolen; /* Length of otherinfo data */
-    __u32 __spare[8];   /* Reserved */
+    char     *hashname;     /* Hash algorithm name */
+    char     *otherinfo;    /* SP800\-56A OtherInfo */
+    uint32_t  otherinfolen; /* Length of otherinfo data */
+    uint32_t  __spare[8];   /* Reserved */
 };
 .EE
 .in
diff --git a/man2/landlock_add_rule.2 b/man2/landlock_add_rule.2
index 61a39f702..cf0892f50 100644
--- a/man2/landlock_add_rule.2
+++ b/man2/landlock_add_rule.2
@@ -53,8 +53,8 @@ points to the following structure:
 .in +4n
 .EX
 struct landlock_path_beneath_attr {
-    __u64 allowed_access;
-    __s32 parent_fd;
+    uint64_t  allowed_access;
+    int32_t   parent_fd;
 } __attribute__((packed));
 .EE
 .in
diff --git a/man2/landlock_create_ruleset.2 b/man2/landlock_create_ruleset.2
index 92a640e7e..aa1cb6350 100644
--- a/man2/landlock_create_ruleset.2
+++ b/man2/landlock_create_ruleset.2
@@ -39,7 +39,7 @@ It points to the following structure:
 .in +4n
 .EX
 struct landlock_ruleset_attr {
-    __u64 handled_access_fs;
+    uint64_t  handled_access_fs;
 };
 .EE
 .in
diff --git a/man2/mount_setattr.2 b/man2/mount_setattr.2
index 160fd2526..c106c0fee 100644
--- a/man2/mount_setattr.2
+++ b/man2/mount_setattr.2
@@ -130,10 +130,10 @@ is a structure of the following form:
 .in +4n
 .EX
 struct mount_attr {
-    __u64 attr_set;     /* Mount properties to set */
-    __u64 attr_clr;     /* Mount properties to clear */
-    __u64 propagation;  /* Mount propagation type */
-    __u64 userns_fd;    /* User namespace file descriptor */
+    uint64_t  attr_set;     /* Mount properties to set */
+    uint64_t  attr_clr;     /* Mount properties to clear */
+    uint64_t  propagation;  /* Mount propagation type */
+    uint64_t  userns_fd;    /* User namespace file descriptor */
 };
 .EE
 .in
diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index 8186c21c7..baae6b403 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -195,88 +195,88 @@ for the event being created.
 .in +4n
 .EX
 struct perf_event_attr {
-    __u32 type;                 /* Type of event */
-    __u32 size;                 /* Size of attribute structure */
-    __u64 config;               /* Type\-specific configuration */
+    uint32_t  type;               /* Type of event */
+    uint32_t  size;               /* Size of attribute structure */
+    uint64_t  config;             /* Type\-specific configuration */
 
     union {
-        __u64 sample_period;    /* Period of sampling */
-        __u64 sample_freq;      /* Frequency of sampling */
+        uint64_t  sample_period;  /* Period of sampling */
+        uint64_t  sample_freq;    /* Frequency of sampling */
     };
 
-    __u64 sample_type;  /* Specifies values included in sample */
-    __u64 read_format;  /* Specifies values returned in read */
+    uint64_t  sample_type;  /* Specifies values included in sample */
+    uint64_t  read_format;  /* Specifies values returned in read */
 
-    __u64 disabled       : 1,   /* off by default */
-          inherit        : 1,   /* children inherit it */
-          pinned         : 1,   /* must always be on PMU */
-          exclusive      : 1,   /* only group on PMU */
-          exclude_user   : 1,   /* don\(aqt count user */
-          exclude_kernel : 1,   /* don\(aqt count kernel */
-          exclude_hv     : 1,   /* don\(aqt count hypervisor */
-          exclude_idle   : 1,   /* don\(aqt count when idle */
-          mmap           : 1,   /* include mmap data */
-          comm           : 1,   /* include comm data */
-          freq           : 1,   /* use freq, not period */
-          inherit_stat   : 1,   /* per task counts */
-          enable_on_exec : 1,   /* next exec enables */
-          task           : 1,   /* trace fork/exit */
-          watermark      : 1,   /* wakeup_watermark */
-          precise_ip     : 2,   /* skid constraint */
-          mmap_data      : 1,   /* non\-exec mmap data */
-          sample_id_all  : 1,   /* sample_type all events */
-          exclude_host   : 1,   /* don\(aqt count in host */
-          exclude_guest  : 1,   /* don\(aqt count in guest */
-          exclude_callchain_kernel : 1,
-                                /* exclude kernel callchains */
-          exclude_callchain_user   : 1,
-                                /* exclude user callchains */
-          mmap2          :  1,  /* include mmap with inode data */
-          comm_exec      :  1,  /* flag comm events that are
-                                   due to exec */
-          use_clockid    :  1,  /* use clockid for time fields */
-          context_switch :  1,  /* context switch data */
-          write_backward :  1,  /* Write ring buffer from end
-                                   to beginning */
-          namespaces     :  1,  /* include namespaces data */
-          ksymbol        :  1,  /* include ksymbol events */
-          bpf_event      :  1,  /* include bpf events */
-          aux_output     :  1,  /* generate AUX records
-                                   instead of events */
-          cgroup         :  1,  /* include cgroup events */
-          text_poke      :  1,  /* include text poke events */
+    uint64_t  disabled       : 1,  /* off by default */
+              inherit        : 1,  /* children inherit it */
+              pinned         : 1,  /* must always be on PMU */
+              exclusive      : 1,  /* only group on PMU */
+              exclude_user   : 1,  /* don\(aqt count user */
+              exclude_kernel : 1,  /* don\(aqt count kernel */
+              exclude_hv     : 1,  /* don\(aqt count hypervisor */
+              exclude_idle   : 1,  /* don\(aqt count when idle */
+              mmap           : 1,  /* include mmap data */
+              comm           : 1,  /* include comm data */
+              freq           : 1,  /* use freq, not period */
+              inherit_stat   : 1,  /* per task counts */
+              enable_on_exec : 1,  /* next exec enables */
+              task           : 1,  /* trace fork/exit */
+              watermark      : 1,  /* wakeup_watermark */
+              precise_ip     : 2,  /* skid constraint */
+              mmap_data      : 1,  /* non\-exec mmap data */
+              sample_id_all  : 1,  /* sample_type all events */
+              exclude_host   : 1,  /* don\(aqt count in host */
+              exclude_guest  : 1,  /* don\(aqt count in guest */
+              exclude_callchain_kernel : 1,
+                                   /* exclude kernel callchains */
+              exclude_callchain_user   : 1,
+                                   /* exclude user callchains */
+              mmap2          : 1,  /* include mmap with inode data */
+              comm_exec      : 1,  /* flag comm events that are
+                                      due to exec */
+              use_clockid    : 1,  /* use clockid for time fields */
+              context_switch : 1,  /* context switch data */
+              write_backward : 1,  /* Write ring buffer from end
+                                      to beginning */
+              namespaces     : 1,  /* include namespaces data */
+              ksymbol        : 1,  /* include ksymbol events */
+              bpf_event      : 1,  /* include bpf events */
+              aux_output     : 1,  /* generate AUX records
+                                      instead of events */
+              cgroup         : 1,  /* include cgroup events */
+              text_poke      : 1,  /* include text poke events */
 
-          __reserved_1   : 30;
+              __reserved_1   :30;
 
     union {
-        __u32 wakeup_events;    /* wakeup every n events */
-        __u32 wakeup_watermark; /* bytes before wakeup */
+        uint32_t wakeup_events;    /* wakeup every n events */
+        uint32_t wakeup_watermark; /* bytes before wakeup */
     };
 
-    __u32     bp_type;          /* breakpoint type */
+    uint32_t     bp_type;          /* breakpoint type */
 
     union {
-        __u64 bp_addr;          /* breakpoint address */
-        __u64 kprobe_func;      /* for perf_kprobe */
-        __u64 uprobe_path;      /* for perf_uprobe */
-        __u64 config1;          /* extension of config */
+        uint64_t bp_addr;          /* breakpoint address */
+        uint64_t kprobe_func;      /* for perf_kprobe */
+        uint64_t uprobe_path;      /* for perf_uprobe */
+        uint64_t config1;          /* extension of config */
     };
 
     union {
-        __u64 bp_len;           /* breakpoint length */
-        __u64 kprobe_addr;      /* with kprobe_func == NULL */
-        __u64 probe_offset;     /* for perf_[k,u]probe */
-        __u64 config2;          /* extension of config1 */
+        uint64_t bp_len;           /* breakpoint length */
+        uint64_t kprobe_addr;      /* with kprobe_func == NULL */
+        uint64_t probe_offset;     /* for perf_[k,u]probe */
+        uint64_t config2;          /* extension of config1 */
     };
-    __u64 branch_sample_type;   /* enum perf_branch_sample_type */
-    __u64 sample_regs_user;     /* user regs to dump on samples */
-    __u32 sample_stack_user;    /* size of stack to dump on
-                                   samples */
-    __s32 clockid;              /* clock to use for time fields */
-    __u64 sample_regs_intr;     /* regs to dump on samples */
-    __u32 aux_watermark;        /* aux bytes before wakeup */
-    __u16 sample_max_stack;     /* max frames in callchain */
-    __u16 __reserved_2;         /* align to u64 */
+    uint64_t  branch_sample_type;  /* enum perf_branch_sample_type */
+    uint64_t  sample_regs_user;    /* user regs to dump on samples */
+    uint32_t  sample_stack_user;   /* size of stack to dump on
+                                      samples */
+    int32_t   clockid;             /* clock to use for time fields */
+    uint64_t  sample_regs_intr;    /* regs to dump on samples */
+    uint32_t  aux_watermark;       /* aux bytes before wakeup */
+    uint16_t  sample_max_stack;    /* max frames in callchain */
+    uint16_t  __reserved_2;        /* align to uint64_t  */
 
 };
 .EE
@@ -1121,12 +1121,12 @@ The layout is described by this pseudo-structure:
 .in +4n
 .EX
 struct sample_id {
-    { u32 pid, tid; }   /* if PERF_SAMPLE_TID set */
-    { u64 time;     }   /* if PERF_SAMPLE_TIME set */
-    { u64 id;       }   /* if PERF_SAMPLE_ID set */
-    { u64 stream_id;}   /* if PERF_SAMPLE_STREAM_ID set  */
-    { u32 cpu, res; }   /* if PERF_SAMPLE_CPU set */
-    { u64 id;       }   /* if PERF_SAMPLE_IDENTIFIER set */
+    { uint32_t  pid, tid; } /* if PERF_SAMPLE_TID set */
+    { uint64_t  time;     } /* if PERF_SAMPLE_TIME set */
+    { uint64_t  id;       } /* if PERF_SAMPLE_ID set */
+    { uint64_t  stream_id;} /* if PERF_SAMPLE_STREAM_ID set */
+    { uint32_t  cpu, res; } /* if PERF_SAMPLE_CPU set */
+    { uint64_t  id;       } /* if PERF_SAMPLE_IDENTIFIER set*/
 };
 .EE
 .in
@@ -1492,12 +1492,12 @@ was specified to allow reading all events in a group at once:
 .in +4n
 .EX
 struct read_format {
-    u64 nr;            /* The number of events */
-    u64 time_enabled;  /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
-    u64 time_running;  /* if PERF_FORMAT_TOTAL_TIME_RUNNING */
+    uint64_t  nr;           /* The number of events */
+    uint64_t  time_enabled; /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
+    uint64_t  time_running; /* if PERF_FORMAT_TOTAL_TIME_RUNNING */
     struct {
-        u64 value;     /* The value of the event */
-        u64 id;        /* if PERF_FORMAT_ID */
+        uint64_t  value;    /* The value of the event */
+        uint64_t  id;       /* if PERF_FORMAT_ID */
     } values[nr];
 };
 .EE
@@ -1512,10 +1512,10 @@ specified:
 .in +4n
 .EX
 struct read_format {
-    u64 value;         /* The value of the event */
-    u64 time_enabled;  /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
-    u64 time_running;  /* if PERF_FORMAT_TOTAL_TIME_RUNNING */
-    u64 id;            /* if PERF_FORMAT_ID */
+    uint64_t  value;        /* The value of the event */
+    uint64_t  time_enabled; /* if PERF_FORMAT_TOTAL_TIME_ENABLED */
+    uint64_t  time_running; /* if PERF_FORMAT_TOTAL_TIME_RUNNING */
+    uint64_t  id;           /* if PERF_FORMAT_ID */
 };
 .EE
 .in
@@ -1572,36 +1572,36 @@ The structure of the first metadata mmap page is as follows:
 .in +4n
 .EX
 struct perf_event_mmap_page {
-    __u32 version;        /* version number of this structure */
-    __u32 compat_version; /* lowest version this is compat with */
-    __u32 lock;           /* seqlock for synchronization */
-    __u32 index;          /* hardware counter identifier */
-    __s64 offset;         /* add to hardware counter value */
-    __u64 time_enabled;   /* time event active */
-    __u64 time_running;   /* time event on CPU */
+    uint32_t  version;        /* version number of this structure */
+    uint32_t  compat_version; /* lowest version this is compat with*/
+    uint32_t  lock;           /* seqlock for synchronization */
+    uint32_t  index;          /* hardware counter identifier */
+    int64_t   offset;         /* add to hardware counter value */
+    uint64_t  time_enabled;   /* time event active */
+    uint64_t  time_running;   /* time event on CPU */
     union {
-        __u64   capabilities;
+        uint64_t     capabilities;
         struct {
-            __u64 cap_usr_time / cap_usr_rdpmc / cap_bit0 : 1,
-                  cap_bit0_is_deprecated : 1,
-                  cap_user_rdpmc         : 1,
-                  cap_user_time          : 1,
-                  cap_user_time_zero     : 1,
+            uint64_t cap_usr_time / cap_usr_rdpmc / cap_bit0 : 1,
+                     cap_bit0_is_deprecated : 1,
+                     cap_user_rdpmc         : 1,
+                     cap_user_time          : 1,
+                     cap_user_time_zero     : 1,
         };
     };
-    __u16 pmc_width;
-    __u16 time_shift;
-    __u32 time_mult;
-    __u64 time_offset;
-    __u64 __reserved[120];   /* Pad to 1 k */
-    __u64 data_head;         /* head in the data section */
-    __u64 data_tail;         /* user\-space written tail */
-    __u64 data_offset;       /* where the buffer starts */
-    __u64 data_size;         /* data buffer size */
-    __u64 aux_head;
-    __u64 aux_tail;
-    __u64 aux_offset;
-    __u64 aux_size;
+    uint16_t  pmc_width;
+    uint16_t  time_shift;
+    uint32_t  time_mult;
+    uint64_t  time_offset;
+    uint64_t  __reserved[120];   /* Pad to 1 k */
+    uint64_t  data_head;         /* head in the data section */
+    uint64_t  data_tail;         /* user\-space written tail */
+    uint64_t  data_offset;       /* where the buffer starts */
+    uint64_t  data_size;         /* data buffer size */
+    uint64_t  aux_head;
+    uint64_t  aux_tail;
+    uint64_t  aux_offset;
+    uint64_t  aux_size;
 
 }
 .EE
@@ -1681,9 +1681,9 @@ the following code can be used to do a read:
 .IP
 .in +4n
 .EX
-u32 seq, time_mult, time_shift, idx, width;
-u64 count, enabled, running;
-u64 cyc, time_offset;
+uint32_t  seq, time_mult, time_shift, idx, width;
+uint64_t  count, enabled, running;
+uint64_t  cyc, time_offset;
 
 do {
     seq = pc\->lock;
@@ -1749,11 +1749,11 @@ delta since
 .IP
 .in +4n
 .EX
-u64 quot, rem;
-u64 delta;
+uint64_t  quot, rem;
+uint64_t  delta;
 
 quot  = cyc >> time_shift;
-rem   = cyc & (((u64)1 << time_shift) \- 1);
+rem   = cyc & (((uint64_t) 1 << time_shift) \- 1);
 delta = time_offset + quot * time_mult +
         ((rem * time_mult) >> time_shift);
 .EE
@@ -1808,7 +1808,7 @@ And vice versa:
 .in +4n
 .EX
 quot = cyc >> time_shift;
-rem  = cyc & (((u64)1 << time_shift) \- 1);
+rem  = cyc & (((uint64_t) 1 << time_shift) \- 1);
 timestamp = time_zero + quot * time_mult +
             ((rem * time_mult) >> time_shift);
 .EE
@@ -1910,9 +1910,9 @@ The mmap values start with a header:
 .in +4n
 .EX
 struct perf_event_header {
-    __u32   type;
-    __u16   misc;
-    __u16   size;
+    uint32_t  type;
+    uint16_t  misc;
+    uint16_t  size;
 };
 .EE
 .in
@@ -2031,12 +2031,12 @@ They have the following structure:
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid, tid;
-    u64    addr;
-    u64    len;
-    u64    pgoff;
-    char   filename[];
+    struct perf_event_header  header;
+    uint32_t  pid, tid;
+    uint64_t  addr;
+    uint64_t  len;
+    uint64_t  pgoff;
+    char      filename[];
 };
 .EE
 .in
@@ -2064,10 +2064,10 @@ This record indicates when events are lost.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    id;
-    u64    lost;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  id;
+    uint64_t  lost;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2086,11 +2086,11 @@ This record indicates a change in the process name.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid;
-    u32    tid;
-    char   comm[];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  pid;
+    uint32_t  tid;
+    char      comm[];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2112,11 +2112,11 @@ This record indicates a process exit event.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid, ppid;
-    u32    tid, ptid;
-    u64    time;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  pid, ppid;
+    uint32_t  tid, ptid;
+    uint64_t  time;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2127,11 +2127,11 @@ This record indicates a throttle/unthrottle event.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    time;
-    u64    id;
-    u64    stream_id;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  time;
+    uint64_t  id;
+    uint64_t  stream_id;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2142,11 +2142,11 @@ This record indicates a fork event.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid, ppid;
-    u32    tid, ptid;
-    u64    time;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  pid, ppid;
+    uint32_t  tid, ptid;
+    uint64_t  time;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2157,10 +2157,10 @@ This record indicates a read event.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid, tid;
-    struct read_format values;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  pid, tid;
+    struct read_format  values;
+    struct sample_id    sample_id;
 };
 .EE
 .in
@@ -2172,39 +2172,39 @@ This record indicates a sample.
 .EX
 struct {
     struct perf_event_header header;
-    u64    sample_id;   /* if PERF_SAMPLE_IDENTIFIER */
-    u64    ip;          /* if PERF_SAMPLE_IP */
-    u32    pid, tid;    /* if PERF_SAMPLE_TID */
-    u64    time;        /* if PERF_SAMPLE_TIME */
-    u64    addr;        /* if PERF_SAMPLE_ADDR */
-    u64    id;          /* if PERF_SAMPLE_ID */
-    u64    stream_id;   /* if PERF_SAMPLE_STREAM_ID */
-    u32    cpu, res;    /* if PERF_SAMPLE_CPU */
-    u64    period;      /* if PERF_SAMPLE_PERIOD */
+    uint64_t  sample_id;  /* if PERF_SAMPLE_IDENTIFIER */
+    uint64_t  ip;         /* if PERF_SAMPLE_IP */
+    uint32_t  pid, tid;   /* if PERF_SAMPLE_TID */
+    uint64_t  time;       /* if PERF_SAMPLE_TIME */
+    uint64_t  addr;       /* if PERF_SAMPLE_ADDR */
+    uint64_t  id;         /* if PERF_SAMPLE_ID */
+    uint64_t  stream_id;  /* if PERF_SAMPLE_STREAM_ID */
+    uint32_t  cpu, res;   /* if PERF_SAMPLE_CPU */
+    uint64_t  period;     /* if PERF_SAMPLE_PERIOD */
     struct read_format v;
-                        /* if PERF_SAMPLE_READ */
-    u64    nr;          /* if PERF_SAMPLE_CALLCHAIN */
-    u64    ips[nr];     /* if PERF_SAMPLE_CALLCHAIN */
-    u32    size;        /* if PERF_SAMPLE_RAW */
-    char   data[size];  /* if PERF_SAMPLE_RAW */
-    u64    bnr;         /* if PERF_SAMPLE_BRANCH_STACK */
+                          /* if PERF_SAMPLE_READ */
+    uint64_t  nr;         /* if PERF_SAMPLE_CALLCHAIN */
+    uint64_t  ips[nr];    /* if PERF_SAMPLE_CALLCHAIN */
+    uint32_t  size;       /* if PERF_SAMPLE_RAW */
+    char      data[size]; /* if PERF_SAMPLE_RAW */
+    uint64_t  bnr;        /* if PERF_SAMPLE_BRANCH_STACK*/
     struct perf_branch_entry lbr[bnr];
-                        /* if PERF_SAMPLE_BRANCH_STACK */
-    u64    abi;         /* if PERF_SAMPLE_REGS_USER */
-    u64    regs[weight(mask)];
-                        /* if PERF_SAMPLE_REGS_USER */
-    u64    size;        /* if PERF_SAMPLE_STACK_USER */
-    char   data[size];  /* if PERF_SAMPLE_STACK_USER */
-    u64    dyn_size;    /* if PERF_SAMPLE_STACK_USER &&
-                           size != 0 */
-    u64    weight;      /* if PERF_SAMPLE_WEIGHT */
-    u64    data_src;    /* if PERF_SAMPLE_DATA_SRC */
-    u64    transaction; /* if PERF_SAMPLE_TRANSACTION */
-    u64    abi;         /* if PERF_SAMPLE_REGS_INTR */
-    u64    regs[weight(mask)];
-                        /* if PERF_SAMPLE_REGS_INTR */
-    u64    phys_addr;   /* if PERF_SAMPLE_PHYS_ADDR */
-    u64    cgroup;      /* if PERF_SAMPLE_CGROUP */
+                          /* if PERF_SAMPLE_BRANCH_STACK*/
+    uint64_t  abi;        /* if PERF_SAMPLE_REGS_USER */
+    uint64_t  regs[weight(mask)];
+                          /* if PERF_SAMPLE_REGS_USER */
+    uint64_t  size;       /* if PERF_SAMPLE_STACK_USER */
+    char      data[size]; /* if PERF_SAMPLE_STACK_USER */
+    uint64_t  dyn_size;   /* if PERF_SAMPLE_STACK_USER &&
+                             size != 0 */
+    uint64_t  weight;     /* if PERF_SAMPLE_WEIGHT */
+    uint64_t  data_src;   /* if PERF_SAMPLE_DATA_SRC */
+    uint64_t  transaction;/* if PERF_SAMPLE_TRANSACTION */
+    uint64_t  abi;        /* if PERF_SAMPLE_REGS_INTR */
+    uint64_t  regs[weight(mask)];
+                          /* if PERF_SAMPLE_REGS_INTR */
+    uint64_t  phys_addr;  /* if PERF_SAMPLE_PHYS_ADDR */
+    uint64_t  cgroup;     /* if PERF_SAMPLE_CGROUP */
 };
 .EE
 .in
@@ -2654,20 +2654,20 @@ shared mappings.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid;
-    u32    tid;
-    u64    addr;
-    u64    len;
-    u64    pgoff;
-    u32    maj;
-    u32    min;
-    u64    ino;
-    u64    ino_generation;
-    u32    prot;
-    u32    flags;
-    char   filename[];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  pid;
+    uint32_t  tid;
+    uint64_t  addr;
+    uint64_t  len;
+    uint64_t  pgoff;
+    uint32_t  maj;
+    uint32_t  min;
+    uint64_t  ino;
+    uint64_t  ino_generation;
+    uint32_t  prot;
+    uint32_t  flags;
+    char      filename[];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2718,11 +2718,11 @@ AUX buffer region.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    aux_offset;
-    u64    aux_size;
-    u64    flags;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  aux_offset;
+    uint64_t  aux_size;
+    uint64_t  flags;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2757,9 +2757,9 @@ addresses in the AUX buffer with the proper executable.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid;
-    u32    tid;
+    struct perf_event_header  header;
+    uint32_t  pid;
+    uint32_t  tid;
 };
 .EE
 .in
@@ -2780,9 +2780,9 @@ indicates some number of samples that may have been lost.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    lost;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  lost;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2829,10 +2829,10 @@ or away from the current process.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32 next_prev_pid;
-    u32 next_prev_tid;
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  next_prev_pid;
+    uint32_t  next_prev_tid;
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2854,12 +2854,12 @@ This record includes various namespace information of a process.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u32    pid;
-    u32    tid;
-    u64    nr_namespaces;
-    struct { u64 dev, inode } [nr_namespaces];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint32_t  pid;
+    uint32_t  tid;
+    uint64_t  nr_namespaces;
+    struct { uint64_t dev, inode } [nr_namespaces];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2912,13 +2912,13 @@ This record indicates kernel symbol register/unregister events.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    addr;
-    u32    len;
-    u16    ksym_type;
-    u16    flags;
-    char   name[];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  addr;
+    uint32_t  len;
+    uint16_t  ksym_type;
+    uint16_t  flags;
+    char      name[];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2952,12 +2952,12 @@ This record indicates BPF program is loaded or unloaded.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u16 type;
-    u16 flags;
-    u32 id;
-    u8 tag[BPF_TAG_SIZE];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint16_t  type;
+    uint16_t  flags;
+    uint32_t  id;
+    uint8_t   tag[BPF_TAG_SIZE];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -2991,10 +2991,10 @@ This record indicates a new cgroup is created and activated.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    id;
-    char   path[];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  id;
+    char      path[];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -3019,12 +3019,12 @@ and the corresponding length is zero in this case.
 .in +4n
 .EX
 struct {
-    struct perf_event_header header;
-    u64    addr;
-    u16    old_len;
-    u16    new_len;
-    u8     bytes[];
-    struct sample_id sample_id;
+    struct perf_event_header  header;
+    uint64_t  addr;
+    uint16_t  old_len;
+    uint16_t  new_len;
+    uint8_t   bytes[];
+    struct sample_id  sample_id;
 };
 .EE
 .in
@@ -3282,9 +3282,9 @@ The argument is a pointer to a structure
 .in +4n
 .EX
 struct perf_event_query_bpf {
-    __u32    ids_len;
-    __u32    prog_cnt;
-    __u32    ids[0];
+    uint32_t  ids_len;
+    uint32_t  prog_cnt;
+    uint32_t  ids[0];
 };
 .EE
 .in
diff --git a/man2/ptrace.2 b/man2/ptrace.2
index 734645d29..d552d0256 100644
--- a/man2/ptrace.2
+++ b/man2/ptrace.2
@@ -395,10 +395,10 @@ etc.) that are not otherwise exposed to user space.
 .in +4n
 .EX
 struct ptrace_peeksiginfo_args {
-    u64 off;    /* Ordinal position in queue at which
-                   to start copying signals */
-    u32 flags;  /* PTRACE_PEEKSIGINFO_SHARED or 0 */
-    s32 nr;     /* Number of signals to copy */
+    uint64_t  off;    /* Ordinal position in queue at which
+                         to start copying signals */
+    uint32_t  flags;  /* PTRACE_PEEKSIGINFO_SHARED or 0 */
+    int32_t   nr;     /* Number of signals to copy */
 };
 .EE
 .in
@@ -1041,28 +1041,28 @@ structure contains the following fields:
 .in +4n
 .EX
 struct ptrace_syscall_info {
-    __u8 op;        /* Type of system call stop */
-    __u32 arch;     /* AUDIT_ARCH_* value; see seccomp(2) */
-    __u64 instruction_pointer; /* CPU instruction pointer */
-    __u64 stack_pointer;    /* CPU stack pointer */
+    uint8_t  op;   /* Type of system call stop */
+    uint32_t arch; /* AUDIT_ARCH_* value; see seccomp(2) */
+    uint64_t instruction_pointer; /* CPU instruction pointer*/
+    uint64_t stack_pointer;       /* CPU stack pointer */
     union {
         struct {    /* op == PTRACE_SYSCALL_INFO_ENTRY */
-            __u64 nr;       /* System call number */
-            __u64 args[6];  /* System call arguments */
+            uint64_t nr;       /* System call number */
+            uint64_t args[6];  /* System call arguments */
         } entry;
         struct {    /* op == PTRACE_SYSCALL_INFO_EXIT */
-            __s64 rval;     /* System call return value */
-            __u8 is_error;  /* System call error flag;
-                               Boolean: does rval contain
-                               an error value (\-ERRCODE) or
-                               a nonerror return value? */
+            int64_t  rval;     /* System call return value */
+            uint8_t  is_error; /* System call error flag;
+                                  Boolean: does rval contain
+                                  an error value (\-ERRCODE) or
+                                  a nonerror return value? */
         } exit;
         struct {    /* op == PTRACE_SYSCALL_INFO_SECCOMP */
-            __u64 nr;       /* System call number */
-            __u64 args[6];  /* System call arguments */
-            __u32 ret_data; /* SECCOMP_RET_DATA portion
-                               of SECCOMP_RET_TRACE
-                               return value */
+            uint64_t nr;       /* System call number */
+            uint64_t args[6];  /* System call arguments */
+            uint32_t ret_data; /* SECCOMP_RET_DATA portion
+                                  of SECCOMP_RET_TRACE
+                                  return value */
         } seccomp;
     };
 };
diff --git a/man2/sched_setattr.2 b/man2/sched_setattr.2
index 701970369..221438336 100644
--- a/man2/sched_setattr.2
+++ b/man2/sched_setattr.2
@@ -87,17 +87,17 @@ This structure has the following form:
 .in +4n
 .EX
 struct sched_attr {
-    u32 size;              /* Size of this structure */
-    u32 sched_policy;      /* Policy (SCHED_*) */
-    u64 sched_flags;       /* Flags */
-    s32 sched_nice;        /* Nice value (SCHED_OTHER,
-                              SCHED_BATCH) */
-    u32 sched_priority;    /* Static priority (SCHED_FIFO,
-                              SCHED_RR) */
+    uint32_t  size;              /* Size of this structure */
+    uint32_t  sched_policy;      /* Policy (SCHED_*) */
+    uint64_t  sched_flags;       /* Flags */
+    int32_t   sched_nice;        /* Nice value (SCHED_OTHER,
+                                    SCHED_BATCH) */
+    uint32_t  sched_priority;    /* Static priority (SCHED_FIFO,
+                                    SCHED_RR) */
     /* Remaining fields are for SCHED_DEADLINE */
-    u64 sched_runtime;
-    u64 sched_deadline;
-    u64 sched_period;
+    uint64_t  sched_runtime;
+    uint64_t  sched_deadline;
+    uint64_t  sched_period;
 };
 .EE
 .in
diff --git a/man2/seccomp.2 b/man2/seccomp.2
index c49076ea3..a3a0e6fa1 100644
--- a/man2/seccomp.2
+++ b/man2/seccomp.2
@@ -275,9 +275,9 @@ which has the following form:
 .IP
 .EX
 struct seccomp_notif_sizes
-    __u16 seccomp_notif;      /* Size of notification structure */
-    __u16 seccomp_notif_resp; /* Size of response structure */
-    __u16 seccomp_data;       /* Size of \(aqstruct seccomp_data\(aq */
+    uint16_t seccomp_notif;   /* Size of notification structure */
+    uint16_t seccomp_notif_resp; /* Size of response structure */
+    uint16_t seccomp_data;    /* Size of \(aqstruct seccomp_data\(aq */
 };
 .EE
 .IP
@@ -306,10 +306,10 @@ Each program must contain one or more BPF instructions:
 .in +4n
 .EX
 struct sock_filter {            /* Filter block */
-    __u16 code;                 /* Actual filter code */
-    __u8  jt;                   /* Jump true */
-    __u8  jf;                   /* Jump false */
-    __u32 k;                    /* Generic multiuse field */
+    uint16_t  code;             /* Actual filter code */
+    uint8_t   jt;               /* Jump true */
+    uint8_t   jf;               /* Jump false */
+    uint32_t  k;                /* Generic multiuse field */
 };
 .EE
 .in
@@ -328,11 +328,11 @@ buffer of the following form:
 .in +4n
 .EX
 struct seccomp_data {
-    int   nr;                   /* System call number */
-    __u32 arch;                 /* AUDIT_ARCH_* value
-                                   (see <linux/audit.h>) */
-    __u64 instruction_pointer;  /* CPU instruction pointer */
-    __u64 args[6];              /* Up to 6 system call arguments */
+    int       nr;                   /* System call number */
+    uint32_t  arch;                 /* AUDIT_ARCH_* value
+                                       (see <linux/audit.h>) */
+    uint64_t  instruction_pointer;  /* CPU instruction pointer */
+    uint64_t  args[6];              /* Up to 6 system call arguments */
 };
 .EE
 .in
diff --git a/man2/seccomp_unotify.2 b/man2/seccomp_unotify.2
index bfb968014..b75160a6b 100644
--- a/man2/seccomp_unotify.2
+++ b/man2/seccomp_unotify.2
@@ -23,7 +23,7 @@ Standard C library
 .BI "          struct seccomp_notif *" req );
 .BI "int ioctl(int " fd ", SECCOMP_IOCTL_NOTIF_SEND,"
 .BI "          struct seccomp_notif_resp *" resp );
-.BI "int ioctl(int " fd ", SECCOMP_IOCTL_NOTIF_ID_VALID, __u64 *" id );
+.BI "int ioctl(int " fd ", SECCOMP_IOCTL_NOTIF_ID_VALID, uint64_t *" id );
 .BI "int ioctl(int " fd ", SECCOMP_IOCTL_NOTIF_ADDFD,"
 .BI "          struct seccomp_notif_addfd *" addfd );
 .fi
@@ -321,10 +321,10 @@ This structure must be zeroed out before the call.
 .in +4n
 .EX
 struct seccomp_notif {
-    __u64  id;              /* Cookie */
-    __u32  pid;             /* TID of target thread */
-    __u32  flags;           /* Currently unused (0) */
-    struct seccomp_data data;   /* See seccomp(2) */
+    uint64_t  id;              /* Cookie */
+    uint32_t  pid;             /* TID of target thread */
+    uint32_t  flags;           /* Currently unused (0) */
+    struct seccomp_data data;  /* See seccomp(2) */
 };
 .EE
 .in
@@ -503,10 +503,10 @@ argument of this structure is a pointer to a structure of the following form:
 .in +4n
 .EX
 struct seccomp_notif_resp {
-    __u64 id;           /* Cookie value */
-    __s64 val;          /* Success return value */
-    __s32 error;        /* 0 (success) or negative error number */
-    __u32 flags;        /* See below */
+    uint64_t  id;     /* Cookie value */
+    int64_t   val;    /* Success return value */
+    int32_t   error;  /* 0 (success) or negative error number */
+    uint32_t  flags;  /* See below */
 };
 .EE
 .in
@@ -694,13 +694,13 @@ argument is a pointer to a structure of the following form:
 .in +4n
 .EX
 struct seccomp_notif_addfd {
-    __u64 id;           /* Cookie value */
-    __u32 flags;        /* Flags */
-    __u32 srcfd;        /* Local file descriptor number */
-    __u32 newfd;        /* 0 or desired file descriptor
-                           number in target */
-    __u32 newfd_flags;  /* Flags to set on target file
-                           descriptor */
+    uint64_t  id;           /* Cookie value */
+    uint32_t  flags;        /* Flags */
+    uint32_t  srcfd;        /* Local file descriptor number */
+    uint32_t  newfd;        /* 0 or desired file descriptor
+                               number in target */
+    uint32_t  newfd_flags;  /* Flags to set on target file
+                               descriptor */
 };
 .EE
 .in
diff --git a/man2/statx.2 b/man2/statx.2
index 0d1b4591f..c339c65f3 100644
--- a/man2/statx.2
+++ b/man2/statx.2
@@ -31,20 +31,20 @@ The returned buffer is a structure of the following type:
 .in +4n
 .EX
 struct statx {
-    __u32 stx_mask;        /* Mask of bits indicating
-                              filled fields */
-    __u32 stx_blksize;     /* Block size for filesystem I/O */
-    __u64 stx_attributes;  /* Extra file attribute indicators */
-    __u32 stx_nlink;       /* Number of hard links */
-    __u32 stx_uid;         /* User ID of owner */
-    __u32 stx_gid;         /* Group ID of owner */
-    __u16 stx_mode;        /* File type and mode */
-    __u64 stx_ino;         /* Inode number */
-    __u64 stx_size;        /* Total size in bytes */
-    __u64 stx_blocks;      /* Number of 512B blocks allocated */
-    __u64 stx_attributes_mask;
-                           /* Mask to show what\(aqs supported
-                              in stx_attributes */
+    uint32_t  stx_mask;        /* Mask of bits indicating
+                                  filled fields */
+    uint32_t  stx_blksize;     /* Block size for filesystem I/O */
+    uint64_t  stx_attributes;  /* Extra file attribute indicators */
+    uint32_t  stx_nlink;       /* Number of hard links */
+    uint32_t  stx_uid;         /* User ID of owner */
+    uint32_t  stx_gid;         /* Group ID of owner */
+    uint16_t  stx_mode;        /* File type and mode */
+    uint64_t  stx_ino;         /* Inode number */
+    uint64_t  stx_size;        /* Total size in bytes */
+    uint64_t  stx_blocks;      /* Number of 512B blocks allocated */
+    uint64_t  stx_attributes_mask;
+                               /* Mask to show what\(aqs supported
+                                  in stx_attributes */
 
     /* The following fields are file timestamps */
     struct statx_timestamp stx_atime;  /* Last access */
@@ -54,14 +54,14 @@ struct statx {
 
     /* If this file represents a device, then the next two
        fields contain the ID of the device */
-    __u32 stx_rdev_major;  /* Major ID */
-    __u32 stx_rdev_minor;  /* Minor ID */
+    uint32_t  stx_rdev_major;  /* Major ID */
+    uint32_t  stx_rdev_minor;  /* Minor ID */
 
     /* The next two fields contain the ID of the device
        containing the filesystem where the file resides */
-    __u32 stx_dev_major;   /* Major ID */
-    __u32 stx_dev_minor;   /* Minor ID */
-    __u64 stx_mnt_id;      /* Mount ID */
+    uint32_t  stx_dev_major;   /* Major ID */
+    uint32_t  stx_dev_minor;   /* Minor ID */
+    uint64_t  stx_mnt_id;      /* Mount ID */
 };
 .EE
 .in
@@ -71,8 +71,8 @@ The file timestamps are structures of the following type:
 .in +4n
 .EX
 struct statx_timestamp {
-    __s64 tv_sec;    /* Seconds since the Epoch (UNIX time) */
-    __u32 tv_nsec;   /* Nanoseconds since tv_sec */
+    int64_t   tv_sec;    /* Seconds since the Epoch (UNIX time) */
+    uint32_t  tv_nsec;   /* Nanoseconds since tv_sec */
 };
 .EE
 .in
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index a49bc984c..eda0ca10d 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -397,31 +397,31 @@ or an event required for the non-cooperative userfaultfd usage:
 .in +4n
 .EX
 struct uffd_msg {
-    __u8  event;            /* Type of event */
+    uint8_t  event;             /* Type of event */
     ...
     union {
         struct {
-            __u64 flags;    /* Flags describing fault */
-            __u64 address;  /* Faulting address */
+            uint64_t  flags;    /* Flags describing fault */
+            uint64_t  address;  /* Faulting address */
             union {
-                __u32 ptid; /* Thread ID of the fault */
+                uint32_t  ptid; /* Thread ID of the fault */
             } feat;
         } pagefault;
 
-        struct {            /* Since Linux 4.11 */
-            __u32 ufd;      /* Userfault file descriptor
-                               of the child process */
+        struct {                /* Since Linux 4.11 */
+            uint32_t  ufd;      /* Userfault file descriptor
+                                   of the child process */
         } fork;
 
-        struct {            /* Since Linux 4.11 */
-            __u64 from;     /* Old address of remapped area */
-            __u64 to;       /* New address of remapped area */
-            __u64 len;      /* Original mapping length */
+        struct {                /* Since Linux 4.11 */
+            uint64_t  from;     /* Old address of remapped area */
+            uint64_t  to;       /* New address of remapped area */
+            uint64_t  len;      /* Original mapping length */
         } remap;
 
-        struct {            /* Since Linux 4.11 */
-            __u64 start;    /* Start address of removed area */
-            __u64 end;      /* End address of removed area */
+        struct {                /* Since Linux 4.11 */
+            uint64_t  start;    /* Start address of removed area */
+            uint64_t  end;      /* End address of removed area */
         } remove;
         ...
     } arg;
diff --git a/man2type/open_how.2type b/man2type/open_how.2type
index 6037f0a01..311feafc3 100644
--- a/man2type/open_how.2type
+++ b/man2type/open_how.2type
@@ -13,9 +13,9 @@ Linux kernel headers
 .B #include <linux/openat2.h>
 .PP
 .B struct open_how {
-.BR "    u64  flags;" "    /* " O_ "* flags */"
-.BR "    u64  mode;" "     /* Mode for " O_ { CREAT , TMPFILE "} */"
-.BR "    u64  resolve;" "  /* " RESOLVE_ "* flags */"
+.BR "    uint64_t  flags;" "    /* " O_ "* flags */"
+.BR "    uint64_t  mode;" "     /* Mode for " O_ { CREAT , TMPFILE "} */"
+.BR "    uint64_t  resolve;" "  /* " RESOLVE_ "* flags */"
     /* ... */
 .B };
 .fi
diff --git a/man3type/epoll_event.3type b/man3type/epoll_event.3type
index 761dce591..743d0cee5 100644
--- a/man3type/epoll_event.3type
+++ b/man3type/epoll_event.3type
@@ -46,7 +46,7 @@ with a slightly different definition:
 
 struct epoll_event {
     __poll_t  events;
-    __u64     data;
+    uint64_t  data;
 };
 .EE
 .in
diff --git a/man4/loop.4 b/man4/loop.4
index f4d4e7df2..f016ffd9e 100644
--- a/man4/loop.4
+++ b/man4/loop.4
@@ -185,10 +185,10 @@ as:
 .in +4n
 .EX
 struct loop_config {
-    __u32               fd;
-    __u32               block_size;
+    uint32_t            fd;
+    uint32_t            block_size;
     struct loop_info64  info;
-    __u64               __reserved[8];
+    uint64_t            __reserved[8];
 };
 .EE
 .in
diff --git a/man4/random.4 b/man4/random.4
index 273bc051d..be515691f 100644
--- a/man4/random.4
+++ b/man4/random.4
@@ -306,9 +306,9 @@ The following structure is used:
 .in +4n
 .EX
 struct rand_pool_info {
-    int    entropy_count;
-    int    buf_size;
-    __u32  buf[0];
+    int       entropy_count;
+    int       buf_size;
+    uint32_t  buf[0];
 };
 .EE
 .in
diff --git a/man7/fanotify.7 b/man7/fanotify.7
index 0f9750ab4..c68e374b8 100644
--- a/man7/fanotify.7
+++ b/man7/fanotify.7
@@ -125,13 +125,13 @@ the read buffer contains one or more of the following structures:
 .in +4n
 .EX
 struct fanotify_event_metadata {
-    __u32 event_len;
-    __u8 vers;
-    __u8 reserved;
-    __u16 metadata_len;
+    uint32_t  event_len;
+    uint8_t   vers;
+    uint8_t   reserved;
+    uint16_t  metadata_len;
     __aligned_u64 mask;
-    __s32 fd;
-    __s32 pid;
+    int32_t   fd;
+    int32_t   pid;
 };
 .EE
 .in
@@ -223,7 +223,7 @@ structure within the read buffer:
 .EX
 struct fanotify_event_info_pidfd {
         struct fanotify_event_info_header hdr;
-        __s32 pidfd;
+        int32_t  pidfd;
 };
 .EE
 .in
@@ -241,8 +241,8 @@ This structure is defined as follows:
 .EX
 struct fanotify_event_info_error {
     struct fanotify_event_info_header hdr;
-    __s32 error;
-    __u32 error_count;
+    int32_t   error;
+    uint32_t  error_count;
 };
 .EE
 .in
@@ -258,9 +258,9 @@ This structure is defined as follows:
 .in +4n
 .EX
 struct fanotify_event_info_header {
-	__u8 info_type;
-	__u8 pad;
-	__u16 len;
+	uint8_t   info_type;
+	uint8_t   pad;
+	uint16_t  len;
 };
 .EE
 .in
@@ -743,8 +743,8 @@ fanotify file descriptor:
 .in +4n
 .EX
 struct fanotify_response {
-    __s32 fd;
-    __u32 response;
+    int32_t   fd;
+    uint32_t  response;
 };
 .EE
 .in
diff --git a/man7/netdevice.7 b/man7/netdevice.7
index 769fec19b..df0c39097 100644
--- a/man7/netdevice.7
+++ b/man7/netdevice.7
@@ -66,7 +66,7 @@ structure:
 .EX
 struct in6_ifreq {
     struct in6_addr     ifr6_addr;
-    u32                 ifr6_prefixlen;
+    uint32_t            ifr6_prefixlen;
     int                 ifr6_ifindex; /* Interface index */
 };
 .EE
diff --git a/man7/netlink.7 b/man7/netlink.7
index 667cae0a6..68bf67a1d 100644
--- a/man7/netlink.7
+++ b/man7/netlink.7
@@ -169,11 +169,11 @@ the payload follows.
 .in +4n
 .EX
 struct nlmsghdr {
-    __u32 nlmsg_len;    /* Length of message including header */
-    __u16 nlmsg_type;   /* Type of message content */
-    __u16 nlmsg_flags;  /* Additional flags */
-    __u32 nlmsg_seq;    /* Sequence number */
-    __u32 nlmsg_pid;    /* Sender port ID */
+    uint32_t  nlmsg_len;    /* Length of message including header */
+    uint16_t  nlmsg_type;   /* Type of message content */
+    uint16_t  nlmsg_flags;  /* Additional flags */
+    uint32_t  nlmsg_seq;    /* Sequence number */
+    uint32_t  nlmsg_pid;    /* Sender port ID */
 };
 .EE
 .in
@@ -363,7 +363,7 @@ struct sockaddr_nl {
     sa_family_t     nl_family;  /* AF_NETLINK */
     unsigned short  nl_pad;     /* Zero */
     pid_t           nl_pid;     /* Port ID */
-    __u32           nl_groups;  /* Multicast groups mask */
+    uint32_t        nl_groups;  /* Multicast groups mask */
 };
 .EE
 .in
@@ -465,7 +465,7 @@ Join/leave a group specified by
 Retrieve all groups a socket is a member of.
 .I optval
 is a pointer to
-.B __u32
+.B uint32_t
 and
 .I optlen
 is the size of the array.
diff --git a/man7/packet.7 b/man7/packet.7
index 2f04ab258..d3c1d8a7b 100644
--- a/man7/packet.7
+++ b/man7/packet.7
@@ -259,14 +259,14 @@ It is defined as
 .in +4n
 .EX
 struct tpacket_auxdata {
-    __u32 tp_status;
-    __u32 tp_len;      /* packet length */
-    __u32 tp_snaplen;  /* captured length */
-    __u16 tp_mac;
-    __u16 tp_net;
-    __u16 tp_vlan_tci;
-    __u16 tp_vlan_tpid; /* Since Linux 3.14; earlier, these
-                           were unused padding bytes */
+    uint32_t tp_status;
+    uint32_t tp_len;       /* packet length */
+    uint32_t tp_snaplen;   /* captured length */
+    uint16_t tp_mac;
+    uint16_t tp_net;
+    uint16_t tp_vlan_tci;
+    uint16_t tp_vlan_tpid; /* Since Linux 3.14; earlier, these
+                              were unused padding bytes */
 .\" commit a0cdfcf39362410d5ea983f4daf67b38de129408 added tp_vlan_tpid
 };
 .EE
diff --git a/man7/rtnetlink.7 b/man7/rtnetlink.7
index f85d6a683..21d5f9220 100644
--- a/man7/rtnetlink.7
+++ b/man7/rtnetlink.7
@@ -435,16 +435,16 @@ structure.
 struct ndmsg {
     unsigned char ndm_family;
     int           ndm_ifindex;  /* Interface index */
-    __u16         ndm_state;    /* State */
-    __u8          ndm_flags;    /* Flags */
-    __u8          ndm_type;
+    uint16_t      ndm_state;    /* State */
+    uint8_t       ndm_flags;    /* Flags */
+    uint8_t       ndm_type;
 };
 
 struct nda_cacheinfo {
-    __u32         ndm_confirmed;
-    __u32         ndm_used;
-    __u32         ndm_updated;
-    __u32         ndm_refcnt;
+    uint32_t      ndm_confirmed;
+    uint32_t      ndm_used;
+    uint32_t      ndm_updated;
+    uint32_t      ndm_refcnt;
 };
 .EE
 .IP
@@ -513,9 +513,9 @@ attributes.
 struct tcmsg {
     unsigned char    tcm_family;
     int              tcm_ifindex;   /* interface index */
-    __u32            tcm_handle;    /* Qdisc handle */
-    __u32            tcm_parent;    /* Parent qdisc */
-    __u32            tcm_info;
+    uint32_t         tcm_handle;    /* Qdisc handle */
+    uint32_t         tcm_parent;    /* Parent qdisc */
+    uint32_t         tcm_info;
 };
 .EE
 .TS
diff --git a/man7/sock_diag.7 b/man7/sock_diag.7
index c412d9b10..bc8db13b8 100644
--- a/man7/sock_diag.7
+++ b/man7/sock_diag.7
@@ -55,8 +55,8 @@ a common part shared by all address families:
 .in +4n
 .EX
 struct sock_diag_req {
-    __u8 sdiag_family;
-    __u8 sdiag_protocol;
+    uint8_t  sdiag_family;
+    uint8_t  sdiag_protocol;
 };
 .EE
 .in
@@ -112,13 +112,13 @@ For UNIX domain sockets the request is represented in the following structure:
 .in +4n
 .EX
 struct unix_diag_req {
-    __u8    sdiag_family;
-    __u8    sdiag_protocol;
-    __u16   pad;
-    __u32   udiag_states;
-    __u32   udiag_ino;
-    __u32   udiag_show;
-    __u32   udiag_cookie[2];
+    uint8_t   sdiag_family;
+    uint8_t   sdiag_protocol;
+    uint16_t  pad;
+    uint32_t  udiag_states;
+    uint32_t  udiag_ino;
+    uint32_t  udiag_show;
+    uint32_t  udiag_cookie[2];
 };
 .EE
 .in
@@ -177,8 +177,8 @@ structure:
 .in +4n
 .EX
 struct unix_diag_vfs {
-    __u32 udiag_vfs_dev;
-    __u32 udiag_vfs_ino;
+    uint32_t udiag_vfs_dev;
+    uint32_t udiag_vfs_ino;
 };
 .EE
 .in
@@ -196,14 +196,18 @@ The inode number of the corresponding on-disk socket inode.
 .B UDIAG_SHOW_PEER
 The attribute reported in answer to this request is
 .BR UNIX_DIAG_PEER .
-The payload associated with this attribute is a __u32 value
+The payload associated with this attribute is a
+.I uint32_t
+value
 which is the peer's inode number.
 This attribute is reported for connected sockets only.
 .TP
 .B UDIAG_SHOW_ICONS
 The attribute reported in answer to this request is
 .BR UNIX_DIAG_ICONS .
-The payload associated with this attribute is an array of __u32 values
+The payload associated with this attribute is an array of
+.I uint32_t
+values
 which are inode numbers of sockets that has passed the
 .BR connect (2)
 call, but hasn't been processed with
@@ -220,8 +224,8 @@ structure:
 .in +4n
 .EX
 struct unix_diag_rqlen {
-    __u32 udiag_rqueue;
-    __u32 udiag_wqueue;
+    uint32_t  udiag_rqueue;
+    uint32_t  udiag_wqueue;
 };
 .EE
 .in
@@ -251,13 +255,17 @@ the amount of memory available for sending.
 .B UDIAG_SHOW_MEMINFO
 The attribute reported in answer to this request is
 .BR UNIX_DIAG_MEMINFO .
-The payload associated with this attribute is an array of __u32 values
+The payload associated with this attribute is an array of
+.I uint32_t
+values
 described below in the subsection "Socket memory information".
 .PP
 The following attributes are reported back without any specific request:
 .TP
 .B UNIX_DIAG_SHUTDOWN
-The payload associated with this attribute is __u8 value which represents
+The payload associated with this attribute is
+.I uint8_t
+value which represents
 bits of
 .BR shutdown (2)
 state.
@@ -275,12 +283,12 @@ The response to a query for UNIX domain sockets is represented as an array of
 .in +4n
 .EX
 struct unix_diag_msg {
-    __u8    udiag_family;
-    __u8    udiag_type;
-    __u8    udiag_state;
-    __u8    pad;
-    __u32   udiag_ino;
-    __u32   udiag_cookie[2];
+    uint8_t   udiag_family;
+    uint8_t   udiag_type;
+    uint8_t   udiag_state;
+    uint8_t   pad;
+    uint32_t  udiag_ino;
+    uint32_t  udiag_cookie[2];
 };
 .EE
 .in
@@ -323,11 +331,11 @@ the request is represented in the following structure:
 .in +4n
 .EX
 struct inet_diag_req_v2 {
-    __u8    sdiag_family;
-    __u8    sdiag_protocol;
-    __u8    idiag_ext;
-    __u8    pad;
-    __u32   idiag_states;
+    uint8_t   sdiag_family;
+    uint8_t   sdiag_protocol;
+    uint8_t   idiag_ext;
+    uint8_t   pad;
+    uint32_t  idiag_states;
     struct inet_diag_sockid id;
 };
 .EE
@@ -340,12 +348,12 @@ is defined as follows:
 .in +4n
 .EX
 struct inet_diag_sockid {
-    __be16  idiag_sport;
-    __be16  idiag_dport;
-    __be32  idiag_src[4];
-    __be32  idiag_dst[4];
-    __u32   idiag_if;
-    __u32   idiag_cookie[2];
+    __be16    idiag_sport;
+    __be16    idiag_dport;
+    __be32    idiag_src[4];
+    __be32    idiag_dst[4];
+    uint32_t  idiag_if;
+    uint32_t  idiag_cookie[2];
 };
 .EE
 .in
@@ -375,16 +383,22 @@ as described below:
 .RS
 .TP
 .B INET_DIAG_TOS
-The payload associated with this attribute is a __u8 value
+The payload associated with this attribute is a
+.I uint8_t
+value
 which is the TOS of the socket.
 .TP
 .B INET_DIAG_TCLASS
-The payload associated with this attribute is a __u8 value
+The payload associated with this attribute is a
+.I uint8_t
+value
 which is the TClass of the socket.
 IPv6 sockets only.
 For LISTEN and CLOSE sockets, this is followed by
 .B INET_DIAG_SKV6ONLY
-attribute with associated __u8 payload value meaning whether the socket
+attribute with associated
+.I uint8_t
+payload value meaning whether the socket
 is IPv6-only or not.
 .TP
 .B INET_DIAG_MEMINFO
@@ -394,10 +408,10 @@ structure:
 .in +4n
 .EX
 struct inet_diag_meminfo {
-    __u32 idiag_rmem;
-    __u32 idiag_wmem;
-    __u32 idiag_fmem;
-    __u32 idiag_tmem;
+    uint32_t  idiag_rmem;
+    uint32_t  idiag_wmem;
+    uint32_t  idiag_fmem;
+    uint32_t  idiag_tmem;
 };
 .EE
 .in
@@ -419,7 +433,9 @@ The amount of data in send queue.
 .RE
 .TP
 .B INET_DIAG_SKMEMINFO
-The payload associated with this attribute is an array of __u32 values
+The payload associated with this attribute is an array of
+.I uint32_t
+values
 described below in the subsection "Socket memory information".
 .TP
 .B INET_DIAG_INFO
@@ -478,18 +494,18 @@ The response to a query for IPv4 or IPv6 sockets is represented as an array of
 .in +4n
 .EX
 struct inet_diag_msg {
-    __u8    idiag_family;
-    __u8    idiag_state;
-    __u8    idiag_timer;
-    __u8    idiag_retrans;
+    uint8_t   idiag_family;
+    uint8_t   idiag_state;
+    uint8_t   idiag_timer;
+    uint8_t   idiag_retrans;
 
     struct inet_diag_sockid id;
 
-    __u32   idiag_expires;
-    __u32   idiag_rqueue;
-    __u32   idiag_wqueue;
-    __u32   idiag_uid;
-    __u32   idiag_inode;
+    uint32_t  idiag_expires;
+    uint32_t  idiag_rqueue;
+    uint32_t  idiag_wqueue;
+    uint32_t  idiag_uid;
+    uint32_t  idiag_inode;
 };
 .EE
 .in
@@ -571,7 +587,9 @@ The payload associated with
 .B UNIX_DIAG_MEMINFO
 and
 .B INET_DIAG_SKMEMINFO
-netlink attributes is an array of the following __u32 values:
+netlink attributes is an array of the following
+.I uint32_t
+values:
 .TP
 .B SK_MEMINFO_RMEM_ALLOC
 The amount of data in receive queue.
-- 
2.37.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-24 18:55 ` [PATCH v3] Many pages: Document fixed-width types with ISO C naming Alejandro Colomar
@ 2022-08-24 22:40   ` Alexei Starovoitov
  2022-08-24 23:36     ` Alejandro Colomar
  0 siblings, 1 reply; 49+ messages in thread
From: Alexei Starovoitov @ 2022-08-24 22:40 UTC (permalink / raw)
  To: Alejandro Colomar
  Cc: linux-man, Alexei Starovoitov, Greg Kroah-Hartman,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Joseph Myers,
	Florian Weimer, Cyril Hrubis, David Howells, Arnd Bergmann,
	Rich Felker, Adhemerval Zanella

On Wed, Aug 24, 2022 at 12:04 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index d05b73ec2..84d1b62e5 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -169,34 +169,34 @@ commands:
>  .EX
>  union bpf_attr {
>      struct {    /* Used by BPF_MAP_CREATE */
> -        __u32         map_type;
> -        __u32         key_size;    /* size of key in bytes */
> -        __u32         value_size;  /* size of value in bytes */
> -        __u32         max_entries; /* maximum number of entries
> +        uint32_t      map_type;
> +        uint32_t      key_size;    /* size of key in bytes */
> +        uint32_t      value_size;  /* size of value in bytes */
> +        uint32_t      max_entries; /* maximum number of entries
>                                        in a map */
>      };
>
>      struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
>                     commands */
> -        __u32         map_fd;
> +        uint32_t      map_fd;
>          __aligned_u64 key;
>          union {
>              __aligned_u64 value;
>              __aligned_u64 next_key;
>          };
> -        __u64         flags;
> +        uint64_t      flags;
>      };
>
>      struct {    /* Used by BPF_PROG_LOAD */
> -        __u32         prog_type;
> -        __u32         insn_cnt;
> +        uint32_t      prog_type;
> +        uint32_t      insn_cnt;

For the N-th time:
Nacked-by: Alexei Starovoitov <ast@kernel.org>

Please stop sending this patch.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-24 22:40   ` Alexei Starovoitov
@ 2022-08-24 23:36     ` Alejandro Colomar
  2022-08-25  0:52       ` Linus Torvalds
  2022-08-25  5:57       ` Greg Kroah-Hartman
  0 siblings, 2 replies; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-24 23:36 UTC (permalink / raw)
  To: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov
  Cc: linux-man, Alexei Starovoitov, Greg Kroah-Hartman,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Joseph Myers,
	Florian Weimer, Cyril Hrubis, David Howells, Arnd Bergmann,
	Rich Felker, Adhemerval Zanella, Michael Kerrisk, Linus Torvalds


[-- Attachment #1.1: Type: text/plain, Size: 3139 bytes --]

Alexei,


On 8/24/22 20:55, Alejandro Colomar wrote:
 > Link: 
<https://lore.kernel.org/linux-man/20210423230609.13519-1-alx.manpages@gmail.com/T/>
 > Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
 > Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
 > Nacked-by: Alexei Starovoitov <ast@kernel.org>
 > Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 > Nacked-by: Daniel Borkmann <daniel@iogearbox.net>
 > Acked-by: Zack Weinberg <zackw@panix.com>



On 8/25/22 00:40, Alexei Starovoitov wrote:
> On Wed, Aug 24, 2022 at 12:04 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> diff --git a/man2/bpf.2 b/man2/bpf.2
>> index d05b73ec2..84d1b62e5 100644
>> --- a/man2/bpf.2
>> +++ b/man2/bpf.2

[...]

>>
>>       struct {    /* Used by BPF_PROG_LOAD */
>> -        __u32         prog_type;
>> -        __u32         insn_cnt;
>> +        uint32_t      prog_type;
>> +        uint32_t      insn_cnt;
> 
> For the N-th time:
> Nacked-by: Alexei Starovoitov <ast@kernel.org>
> 
> Please stop sending this patch.

Sorry, but no.

First, this has only been v3, and v1 was a year and a half ago, don't 
make it like I'm constantly making you lose your precious time, because 
I'm actively trying not to.

Second, I already made a big notice that you and a few more have 
strongly opposed to the patch, respectfully keeping all of your NAKs in 
my patch, as you can see above.

I gave very detailed reasons of why this patch is reasonable and, back 
in the days of v1, Zack (from glibc) gave even better reasons of why the 
manual pages should document ISO C (libc) types, and not kernel ones, 
and why it shouldn't matter to user-space programmers.

But from your side what do we have?  Just direct NAKs without much 
explanation.  The only one who gave some explanation was Greg, and he 
vaguely pointed to Linus's comments about it in the past, with no 
precise pointer to it.  I investigated a lot before v2, and could not 
find anything strong enough to recommend using kernel types in user 
space, so I pushed v2, and the discussion was kept.

I would like that if you still oppose to the patch, at least were able 
to provide some facts to this discussion.

But the most fundamental thing that I ask is that you respect me.

With this attitude, the only thing you're going to get is that I apply 
the patch right after, because:

1) The patch is right.  Go talk to glibc and gcc maintainers, who know 
how types work by heart if you have doubts.

2) I'm the maintainer of this project, and under doubts, it's my decission.

I'm trying to be nice, and ask for review to make sure I'm not making 
some big mistake by accident, and I get disrespect?  No thanks.


Patch applied.


Now, if someone with a bit more respect still thinks this change is 
incorrect, and is wanting to share some facts to show me my mistake, 
I'll happily review it and revert the patch if necessary.  For now, the 
patch is applied.


Alex


-- 
Alejandro Colomar
Linux man-pages maintainer
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-24 23:36     ` Alejandro Colomar
@ 2022-08-25  0:52       ` Linus Torvalds
  2022-08-25  7:20         ` Alejandro Colomar
  2022-08-25  5:57       ` Greg Kroah-Hartman
  1 sibling, 1 reply; 49+ messages in thread
From: Linus Torvalds @ 2022-08-25  0:52 UTC (permalink / raw)
  To: Alejandro Colomar
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Greg Kroah-Hartman, Daniel Borkmann, Zack Weinberg, LKML, glibc,
	GCC, bpf, LTP List, Linux API, linux-arch, David Laight,
	Joseph Myers, Florian Weimer, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk

On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> I'm trying to be nice, and ask for review to make sure I'm not making
> some big mistake by accident, and I get disrespect?  No thanks.

You've been told multiple times that the kernel doesn't use the
"standard" names, and *cannot* use them for namespace reasons, and you
ignore all the feedback, and then you claim you are asking for review?

That's not "asking for review". That's "I think I know the answer, and
when people tell me otherwise I ignore them".

The fact is, kernel UAPI header files MUST NOT use the so-called standard names.

We cannot provide said names, because they are only provided by the
standard header files.

And since kernel header files cannot provide them, then kernel UAPI
header files cannot _use_ them.

End result: any kernel UAPI header file will continue to use __u32 etc
naming that doesn't have any namespace pollution issues.

Nothing else is even remotely acceptable.

Stop trying to make this something other than it is.

And if you cannot accept these simple technical reasons, why do you
expect respect?

Why are you so special that you think you can change the rules for
kernel uapi files over the *repeated* objections from maintainers who
know better?

                  Linus

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-24 23:36     ` Alejandro Colomar
  2022-08-25  0:52       ` Linus Torvalds
@ 2022-08-25  5:57       ` Greg Kroah-Hartman
  2022-08-25  6:41         ` Florian Weimer
  2022-08-25  7:44         ` Alejandro Colomar
  1 sibling, 2 replies; 49+ messages in thread
From: Greg Kroah-Hartman @ 2022-08-25  5:57 UTC (permalink / raw)
  To: Alejandro Colomar
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Joseph Myers,
	Florian Weimer, Cyril Hrubis, David Howells, Arnd Bergmann,
	Rich Felker, Adhemerval Zanella, Michael Kerrisk, Linus Torvalds

On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
> But from your side what do we have?  Just direct NAKs without much
> explanation.  The only one who gave some explanation was Greg, and he
> vaguely pointed to Linus's comments about it in the past, with no precise
> pointer to it.  I investigated a lot before v2, and could not find anything
> strong enough to recommend using kernel types in user space, so I pushed v2,
> and the discussion was kept.

So despite me saying that "this is not ok", and many other maintainers
saying "this is not ok", you applied a patch with our objections on it?
That is very odd and a bit rude.

> I would like that if you still oppose to the patch, at least were able to
> provide some facts to this discussion.

The fact is that the kernel can not use the namespace that userspace has
with ISO C names.  It's that simple as the ISO standard does NOT
describe the variable types for an ABI that can cross the user/kernel
boundry.

Work with the ISO C standard if you wish to document such type usage,
and get it approved and then we would be willing to consider such a
change.  But until then, we have to stick to our variable name types,
just like all other operating systems have to (we are not alone here.)

Please revert your change.

greg k-h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  5:57       ` Greg Kroah-Hartman
@ 2022-08-25  6:41         ` Florian Weimer
  2022-08-25  7:27           ` Linus Torvalds
  2022-08-25  7:44         ` Alejandro Colomar
  1 sibling, 1 reply; 49+ messages in thread
From: Florian Weimer @ 2022-08-25  6:41 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Alejandro Colomar, Alexei Starovoitov, Alex Colomar,
	Alexei Starovoitov, linux-man, Daniel Borkmann, Zack Weinberg,
	LKML, glibc, GCC, bpf, LTP List, Linux API, linux-arch,
	David Laight, Joseph Myers, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk,
	Linus Torvalds

* Greg Kroah-Hartman:

> On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
>> But from your side what do we have?  Just direct NAKs without much
>> explanation.  The only one who gave some explanation was Greg, and he
>> vaguely pointed to Linus's comments about it in the past, with no precise
>> pointer to it.  I investigated a lot before v2, and could not find anything
>> strong enough to recommend using kernel types in user space, so I pushed v2,
>> and the discussion was kept.
>
> So despite me saying that "this is not ok", and many other maintainers
> saying "this is not ok", you applied a patch with our objections on it?
> That is very odd and a bit rude.

The justifications brought forward are just regurgitating previous
misinformation.  If you do that, it's hard to take you seriously.

There is actually a good reason for using __u64: it's always based on
long long, so the format strings are no longer architecture-specific,
and those ugly macro hacks are not needed to achieve portability.  But
that's really the only reason I'm aware of.  Admittedly, it's a pretty
good reason.

>> I would like that if you still oppose to the patch, at least were able to
>> provide some facts to this discussion.
>
> The fact is that the kernel can not use the namespace that userspace has
> with ISO C names.  It's that simple as the ISO standard does NOT
> describe the variable types for an ABI that can cross the user/kernel
> boundry.

You cannot avoid using certain ISO C names with current GCC or Clang,
however hard you try.  But currently, the kernel does not try at all,
not really: it is not using -ffreestanding and -fno-builtin, at least
not consistently.  This means that if the compiler sees a known function
(with the right name and a compatible prototype), it will optimize based
on that.  What kind of headers you use does not matter.

<stdarg.h>, <stddef.h>, <stdint.h> are compiler-provided headers that
are designed to be safe to use for bare-metal contexts (like in
kernels).  Avoiding them is not necessary per se.  However, <stdint.h>
is not particularly useful if you want to use your own printf-style
functions with the usual format specifiers (see above for __u64).  But
on its own, it's perfectly safe to use.  You have problems with
<stdint.h> *because* you use well-known, standard facilities in kernel
space (the printf format specifiers), not because you avoid them.  So
exactly the opposite of what you say.

> But until then, we have to stick to our variable name types,
> just like all other operating systems have to (we are not alone here.)

FreeBSD uses <stdint.h> and the <inttypes.h> formatting macros in kernel
space.  I don't think that's unusual at all for current kernels.  It's
particularly safe for FreeBSD because they use a monorepo and toolchain
variance among developers is greatly reduced.  Linux would need to
provide its own <inttypes.h> equivalent for the formatting macros
(as it's not a compiler header; FreeBSD has <machine/_inttypes.h>).

At this point and with the current ABIs we have for Linux, it makes
equal (maybe more) sense to avoid the <stdint.h> types altogether and
use Linux-specific typedefs with have architecture-independent format
strings.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  0:52       ` Linus Torvalds
@ 2022-08-25  7:20         ` Alejandro Colomar
  2022-08-25  7:28           ` Xi Ruoyao
  2022-08-25  7:42           ` Linus Torvalds
  0 siblings, 2 replies; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-25  7:20 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Greg Kroah-Hartman, Daniel Borkmann, Zack Weinberg, LKML, glibc,
	GCC, bpf, LTP List, Linux API, linux-arch, David Laight,
	Joseph Myers, Florian Weimer, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk


[-- Attachment #1.1: Type: text/plain, Size: 1975 bytes --]

Hi Linux,

On 8/25/22 02:52, Linus Torvalds wrote:
> On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> I'm trying to be nice, and ask for review to make sure I'm not making
>> some big mistake by accident, and I get disrespect?  No thanks.
> 
> You've been told multiple times that the kernel doesn't use the
> "standard" names, and *cannot* use them for namespace reasons, and you
> ignore all the feedback, and then you claim you are asking for review?

This patch is not about kernel, but about the section 2 and 3 manual 
pages, which are directed towards user-space readers most of the time. 
Admittedly, some syscalls are only callable from within the kernel 
itself, but that's very rare.

[...]

> 
> The fact is, kernel UAPI header files MUST NOT use the so-called standard names.

I don't know for sure, and I never pretended to say otherwise.  But what 
IMHO the kernel could do is to make the types compatible, by typedefing 
to the same fundamental types (i.e., long or long long) that user-space 
types do.

> 
> We cannot provide said names, because they are only provided by the
> standard header files.
> 
> And since kernel header files cannot provide them, then kernel UAPI
> header files cannot _use_ them.
> 
> End result: any kernel UAPI header file will continue to use __u32 etc
> naming that doesn't have any namespace pollution issues.
> 
> Nothing else is even remotely acceptable.
> 
> Stop trying to make this something other than it is.
> 
> And if you cannot accept these simple technical reasons, why do you
> expect respect?
> 
> Why are you so special that you think you can change the rules for
> kernel uapi files over the *repeated* objections from maintainers who
> know better?

No sorry, if someone understood this patch as changing anything in UAPI, 
it is not.

Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  6:41         ` Florian Weimer
@ 2022-08-25  7:27           ` Linus Torvalds
  2022-08-25 14:38             ` Joseph Myers
  0 siblings, 1 reply; 49+ messages in thread
From: Linus Torvalds @ 2022-08-25  7:27 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Greg Kroah-Hartman, Alejandro Colomar, Alexei Starovoitov,
	Alex Colomar, Alexei Starovoitov, linux-man, Daniel Borkmann,
	Zack Weinberg, LKML, glibc, GCC, bpf, LTP List, Linux API,
	linux-arch, David Laight, Joseph Myers, Cyril Hrubis,
	David Howells, Arnd Bergmann, Rich Felker, Adhemerval Zanella,
	Michael Kerrisk

On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> The justifications brought forward are just regurgitating previous
> misinformation.  If you do that, it's hard to take you seriously.

Pot, meet kettle.

> There is actually a good reason for using __u64: it's always based on
> long long, so the format strings are no longer architecture-specific,
[..]

That's a small detail that yes, we've tried to avoid the absolute
humongous mess that the C standard library has with their horrendous
'PRId*' mess, but honestly, it's just a tiny detail.

The real issue is that we want to be able to control our own types,
and our own names, and in the process have sometimes been able to
standardize on types that makes it easier to just not have to deal
with "oh, somebody picked 'int' on this architecture, and 'long' on
this other, and they are both 32-bit types".

We still have to deal with that for '[s]size_t', but that's such a
standard legacy type that thankfully we have the whole '%zu/%zd' thing
for that.

And yes, sometimes we screw up even *though* we were the ones that
picked the types, and we've had pointless differences where '__u64'
could be 'unsigned long' on a 64-bit architecture, and 'unsigned long
long' on a 32-bit one, and then we were able to fix our own little
broken type system exactly because it was *OUR* little type system.

So you are correct that then in the specific case of '__u64' we have
been able to simply just standardize on 'unsigned long long' and make
printf strings simpler.

But you are wrong to think that that is somehow a special thing.

It's not.

It's very much all the same thing: we have types *we* control, and
thanks to that we can do them the way *we* need them done, and can fix
them when we made a silly mistake.

In other words, it's the whole *point* of not ever using 'stdint.h' at
all for those things.

(It's also about avoiding the kinds of unholy things that happen in
system header files. Have you ever *looked* at them? Christ. The
amount of absolute crap you get from including <stdint.h> in user
space is scary)

> You cannot avoid using certain ISO C names with current GCC or Clang,
> however hard you try.

You  are now the one who is regurgitating complete mis-information.

You do it so prettily, and with such weasel-wording, that I know you
must be knowingly threading that fine line between "actively
misleading" but trying to avoid "outright lying"..

You say "certain ISO C names" to try to make it sound as if this was
at all relevant to things like "uint32_t" and friends.

But deep down, you know you're basically lying by omission.

Because it's true that we have to know and care about things like
'size_t', which comes up for all the basic string.h functions.

So yes, we have a very small set of types that we make sure matches
the compiler notion of said types, and we carefully use things like

    typedef __kernel_ulong_t __kernel_size_t;

and then we have our own 'stdarg.h which uses

    typedef __builtin_va_list va_list;

that is explicitly the one that the compiler exposes with those double
underscores exactly because even the compiler can't expose the
"standard" name due to namespace issues.

And no, NONE OF THOSE ARE USABLE IN THE UAPI HEADERS!

And equally importantly, none of those have *anything* to do with the
'uint32_t' kind of names.

The fact that yes, we care about what the compiler thinks "size_t" is
(because we do want the compiler to do memset() for us) has absolutely
*NOTHING* to do with uint32_t and <stdint.h>.

And I'm pretty sure you knew that, but you tried to make it sound like
they were somehow all in the same boat.

And yes, some drivers tend to actually use 'uint32_t' in the kernel,
and we allow it, but they cannot be used by user interfaces. So a uapi
file really *really* shouldn't ever use them.

And no, we don't use "-ffreestanding" and friends - we actually have
occasionally wanted and tried to do so just to make the boundary lines
clearer, but then that will make gcc no longer do sane things for
'memcpy()'' and friends, so it's kind of a balancing act.

> <stdarg.h>, <stddef.h>, <stdint.h> are compiler-provided headers that
> are designed to be safe to use for bare-metal contexts (like in
> kernels).  Avoiding them is not necessary per se.

We explicitly avoid them all.

We historically used stdarg.h and stddef.h (but never stdint.h -
there's absolutely _zero_ upside), but it was always a slight pain.

So we simply bake our own, exactly because it's simply less painful
than having to deal with possible system-provided ones.

People do odd compiler things with host compilers, bad or odd
installations of cross-build environments, it's just not worth the
pain to deal with the "system header files" when they just don't
provide any real value.

                        Linus

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:20         ` Alejandro Colomar
@ 2022-08-25  7:28           ` Xi Ruoyao
  2022-08-25  7:48             ` Alejandro Colomar
  2022-08-25  7:42           ` Linus Torvalds
  1 sibling, 1 reply; 49+ messages in thread
From: Xi Ruoyao @ 2022-08-25  7:28 UTC (permalink / raw)
  To: Alejandro Colomar, Linus Torvalds
  Cc: linux-man, Rich Felker, Alexei Starovoitov, David Howells,
	Alexei Starovoitov, Joseph Myers, linux-arch, Zack Weinberg,
	Daniel Borkmann, Alex Colomar, Michael Kerrisk, Cyril Hrubis,
	Arnd Bergmann, GCC, LTP List, Florian Weimer, glibc,
	Greg Kroah-Hartman, LKML, David Laight, Linux API, bpf

On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches
wrote:
> I don't know for sure, and I never pretended to say otherwise.  But what 
> IMHO the kernel could do is to make the types compatible, by typedefing 
> to the same fundamental types (i.e., long or long long) that user-space 
> types do.

In user-space things are already inconsistent as we have multiple libc
implementations.  Telling every libc implementation to sync their
typedef w/o a WG14 decision will only cause "aggressive discussion" (far
more aggressive than this thread, I'd say).

If int64_t etc. were defined as builtin types since epoch, things would
be a lot easier.  But we can't change history.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:20         ` Alejandro Colomar
  2022-08-25  7:28           ` Xi Ruoyao
@ 2022-08-25  7:42           ` Linus Torvalds
  2022-08-25  7:59             ` Alejandro Colomar
  1 sibling, 1 reply; 49+ messages in thread
From: Linus Torvalds @ 2022-08-25  7:42 UTC (permalink / raw)
  To: Alejandro Colomar
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Greg Kroah-Hartman, Daniel Borkmann, Zack Weinberg, LKML, glibc,
	GCC, bpf, LTP List, Linux API, linux-arch, David Laight,
	Joseph Myers, Florian Weimer, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk

On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> This patch is not about kernel, but about the section 2 and 3 manual
> pages, which are directed towards user-space readers most of the time.

They are about the types to the kernel interfaces. Those types that
the kernel defines and exposes.

And the kernel type in question looks like this:

        struct { /* anonymous struct used by BPF_PROG_LOAD command */
                __u32           prog_type;      /* one of enum bpf_prog_type */
                __u32           insn_cnt;
                __aligned_u64   insns;
                __aligned_u64   license;

because the kernel UAPI header wants to

 (a) work whether or not <stdint.h> was included

 (b) doesn't want to include <stdint.h> so as to not pollute the namespace

 (c) actually wants to use our special types

I quoted a few more fields for that (c) reason: we've had a long
history of getting the user space API wrong due to strange alignment
issues, where 32-bit and 64-bit targets had different alignment for
types. So then we ended up with various compat structures to translate
from one to the other because they had all the same fields, but
different padding.

This happened a few times with the DRM people, and they finally got
tired of it, and started using that "__aligned_u64" type, which is
just the same old __u64, but explicitly aligned to its natural
alignment.

So these are the members that the interface actually uses.

If you document those members, wouldn't it be good to have that
documentation be actually accurate?

Honestly, I don't think it makes a *huge* amount of difference, but
documentation that doesn't actually match the source of the
documentation will just confuse somebody in the end. Somebody will go
"that's not right", and maybe even change the structure definitions to
match the documentation.

Which would be wrong.

Now, you don't have to take the kernel uapi headers. We *try* to make
those usable as-is, but hey, there has been problems in the past, and
it's not necessarily wrong to take the kernel header and then munge it
to be "appropriate" for user space.

So I guess you can just make your own structures with the names and
syntax you want, and say "these are *my* header files, and *my*
documentation for them".

That's fine. But I'm not surprised if the kernel maintainer then goes
"no, that's not the interface I agreed to" if only because it's a pain
to verify that you got it all right. Maybe it was all trivial and
automated and there can be no errors, but it's still a "why is there a
different copy of this complicated interface".

If you really want to describe things to people, wouldn't it be nicer
to just say "there's a 32-bit unsigned 'prog_type' member" and leave
it at that?

Do you really want to enforce your opinion of what is prettier on the
maintainer that wrote that thing, and then argue with him when he
doesn't agree?

                  Linus

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  5:57       ` Greg Kroah-Hartman
  2022-08-25  6:41         ` Florian Weimer
@ 2022-08-25  7:44         ` Alejandro Colomar
  2022-08-25  8:04           ` Alejandro Colomar
  1 sibling, 1 reply; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-25  7:44 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Joseph Myers,
	Florian Weimer, Cyril Hrubis, David Howells, Arnd Bergmann,
	Rich Felker, Adhemerval Zanella, Michael Kerrisk, Linus Torvalds


[-- Attachment #1.1: Type: text/plain, Size: 2191 bytes --]

Hi Greg,

On 8/25/22 07:57, Greg Kroah-Hartman wrote:
> On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
>> But from your side what do we have?  Just direct NAKs without much
>> explanation.  The only one who gave some explanation was Greg, and he
>> vaguely pointed to Linus's comments about it in the past, with no precise
>> pointer to it.  I investigated a lot before v2, and could not find anything
>> strong enough to recommend using kernel types in user space, so I pushed v2,
>> and the discussion was kept.
> 
> So despite me saying that "this is not ok", and many other maintainers
> saying "this is not ok", you applied a patch with our objections on it?
> That is very odd and a bit rude.
> 
>> I would like that if you still oppose to the patch, at least were able to
>> provide some facts to this discussion.
> 
> The fact is that the kernel can not use the namespace that userspace has
> with ISO C names.  It's that simple as the ISO standard does NOT
> describe the variable types for an ABI that can cross the user/kernel
> boundry.

I understand that.  But user-space programs are allowed to use the 
standard types when calling a syscall that really uses kernel types.

IMHO, it should be irrelevant for the user how the kernel decides to 
call a 64-bit unsigned integer, right?

Or do you mean that some of the pages I modified

> 
> Work with the ISO C standard if you wish to document such type usage,
> and get it approved and then we would be willing to consider such a
> change.  But until then, we have to stick to our variable name types,
> just like all other operating systems have to (we are not alone here.)
> 
> Please revert your change.

Thanks for asking nicely.

Since there's ongoing discussion, and I don't want to make it look like 
ignoring it, I've reverted the patch for now.  If I apply it again, I 
hope that it will be with some more consensus, as I've always tried to 
do.  Sorry if I was a bit irascible yesterday.  Shit happens.

TL;DR:  Patch reverted; asking nicely works. =)

> 
> greg k-h

Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:28           ` Xi Ruoyao
@ 2022-08-25  7:48             ` Alejandro Colomar
  2022-08-25  8:09               ` Xi Ruoyao
  0 siblings, 1 reply; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-25  7:48 UTC (permalink / raw)
  To: Xi Ruoyao, Linus Torvalds
  Cc: linux-man, Rich Felker, Alexei Starovoitov, David Howells,
	Alexei Starovoitov, Joseph Myers, linux-arch, Zack Weinberg,
	Daniel Borkmann, Alex Colomar, Michael Kerrisk, Cyril Hrubis,
	Arnd Bergmann, GCC, LTP List, Florian Weimer, glibc,
	Greg Kroah-Hartman, LKML, David Laight, Linux API, bpf


[-- Attachment #1.1: Type: text/plain, Size: 1088 bytes --]

Hi Xi,

On 8/25/22 09:28, Xi Ruoyao wrote:
> On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches
> wrote:
>> I don't know for sure, and I never pretended to say otherwise.  But what
>> IMHO the kernel could do is to make the types compatible, by typedefing
>> to the same fundamental types (i.e., long or long long) that user-space
>> types do.
> 
> In user-space things are already inconsistent as we have multiple libc
> implementations.  Telling every libc implementation to sync their
> typedef w/o a WG14 decision will only cause "aggressive discussion" (far
> more aggressive than this thread, I'd say).
> 
> If int64_t etc. were defined as builtin types since epoch, things would
> be a lot easier.  But we can't change history.

This would be great.  I mean, the fundamental types should be u8, u16, 
... and int, long, ... typedefs for these, and not the other way around, 
if the language was designed today.

Maybe GCC could consider something like that.

Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:42           ` Linus Torvalds
@ 2022-08-25  7:59             ` Alejandro Colomar
  0 siblings, 0 replies; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-25  7:59 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Greg Kroah-Hartman, Daniel Borkmann, Zack Weinberg, LKML, glibc,
	GCC, bpf, LTP List, Linux API, linux-arch, David Laight,
	Joseph Myers, Florian Weimer, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk


[-- Attachment #1.1: Type: text/plain, Size: 4000 bytes --]

Hi Linus,

(Oops, I mistyped you name in my previous reply; I'm on a roll for funny 
typos this week it seems)

On 8/25/22 09:42, Linus Torvalds wrote:
> On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> This patch is not about kernel, but about the section 2 and 3 manual
>> pages, which are directed towards user-space readers most of the time.
> 
> They are about the types to the kernel interfaces. Those types that
> the kernel defines and exposes.
> 
> And the kernel type in question looks like this:
> 
>          struct { /* anonymous struct used by BPF_PROG_LOAD command */
>                  __u32           prog_type;      /* one of enum bpf_prog_type */
>                  __u32           insn_cnt;
>                  __aligned_u64   insns;
>                  __aligned_u64   license;
> 
> because the kernel UAPI header wants to
> 
>   (a) work whether or not <stdint.h> was included

These days, (a) is more of a theoretical thing, since programs avoiding 
C99 <stdint.h> will have a hard time.

> 
>   (b) doesn't want to include <stdint.h> so as to not pollute the namespace
> 
>   (c) actually wants to use our special types
> 
> I quoted a few more fields for that (c) reason: we've had a long
> history of getting the user space API wrong due to strange alignment
> issues, where 32-bit and 64-bit targets had different alignment for
> types. So then we ended up with various compat structures to translate
> from one to the other because they had all the same fields, but
> different padding.
> 
> This happened a few times with the DRM people, and they finally got
> tired of it, and started using that "__aligned_u64" type, which is
> just the same old __u64, but explicitly aligned to its natural
> alignment.
> 
> So these are the members that the interface actually uses.
> 
> If you document those members, wouldn't it be good to have that
> documentation be actually accurate?
> 
> Honestly, I don't think it makes a *huge* amount of difference, but
> documentation that doesn't actually match the source of the
> documentation will just confuse somebody in the end. Somebody will go
> "that's not right", and maybe even change the structure definitions to
> match the documentation.
> 
> Which would be wrong.
> 
> Now, you don't have to take the kernel uapi headers. We *try* to make
> those usable as-is, but hey, there has been problems in the past, and
> it's not necessarily wrong to take the kernel header and then munge it
> to be "appropriate" for user space.
> 
> So I guess you can just make your own structures with the names and
> syntax you want, and say "these are *my* header files, and *my*
> documentation for them".
> 
> That's fine. But I'm not surprised if the kernel maintainer then goes
> "no, that's not the interface I agreed to" if only because it's a pain
> to verify that you got it all right. Maybe it was all trivial and
> automated and there can be no errors, but it's still a "why is there a
> different copy of this complicated interface".
> 
> If you really want to describe things to people, wouldn't it be nicer
> to just say "there's a 32-bit unsigned 'prog_type' member" and leave
> it at that?
> 
> Do you really want to enforce your opinion of what is prettier on the
> maintainer that wrote that thing, and then argue with him when he
> doesn't agree?

You convinced me.  The man-pages will document the types exactly as they 
are in kernel.  It's just simpler.

As the patch was recently reverted after Greg asked me to do, I'll keep 
it that way.  I guess this closes the man-pages discussion.

I'd still like to see the kernel types be API-compatible with the 
user-space ones, for which there's a patch around, and also making the 
<stdint.h> types be builtind could also be nice.  Let's see if that 
works out.

Cheers,

Alex

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:44         ` Alejandro Colomar
@ 2022-08-25  8:04           ` Alejandro Colomar
  0 siblings, 0 replies; 49+ messages in thread
From: Alejandro Colomar @ 2022-08-25  8:04 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Joseph Myers,
	Florian Weimer, Cyril Hrubis, David Howells, Arnd Bergmann,
	Rich Felker, Adhemerval Zanella, Michael Kerrisk, Linus Torvalds


[-- Attachment #1.1: Type: text/plain, Size: 2406 bytes --]

On 8/25/22 09:44, Alejandro Colomar wrote:
> Hi Greg,
> 
> On 8/25/22 07:57, Greg Kroah-Hartman wrote:
>> On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
>>> But from your side what do we have?  Just direct NAKs without much
>>> explanation.  The only one who gave some explanation was Greg, and he
>>> vaguely pointed to Linus's comments about it in the past, with no 
>>> precise
>>> pointer to it.  I investigated a lot before v2, and could not find 
>>> anything
>>> strong enough to recommend using kernel types in user space, so I 
>>> pushed v2,
>>> and the discussion was kept.
>>
>> So despite me saying that "this is not ok", and many other maintainers
>> saying "this is not ok", you applied a patch with our objections on it?
>> That is very odd and a bit rude.
>>
>>> I would like that if you still oppose to the patch, at least were 
>>> able to
>>> provide some facts to this discussion.
>>
>> The fact is that the kernel can not use the namespace that userspace has
>> with ISO C names.  It's that simple as the ISO standard does NOT
>> describe the variable types for an ABI that can cross the user/kernel
>> boundry.
> 
> I understand that.  But user-space programs are allowed to use the 
> standard types when calling a syscall that really uses kernel types.
> 
> IMHO, it should be irrelevant for the user how the kernel decides to 
> call a 64-bit unsigned integer, right?
> 
> Or do you mean that some of the pages I modified

... are intended mostly for kernel-space programmers?

> 
>>
>> Work with the ISO C standard if you wish to document such type usage,
>> and get it approved and then we would be willing to consider such a
>> change.  But until then, we have to stick to our variable name types,
>> just like all other operating systems have to (we are not alone here.)
>>
>> Please revert your change.
> 
> Thanks for asking nicely.
> 
> Since there's ongoing discussion, and I don't want to make it look like 
> ignoring it, I've reverted the patch for now.  If I apply it again, I 
> hope that it will be with some more consensus, as I've always tried to 
> do.  Sorry if I was a bit irascible yesterday.  Shit happens.
> 
> TL;DR:  Patch reverted; asking nicely works. =)
> 
>>
>> greg k-h
> 
> Cheers,
> 
> Alex
> 

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:48             ` Alejandro Colomar
@ 2022-08-25  8:09               ` Xi Ruoyao
  0 siblings, 0 replies; 49+ messages in thread
From: Xi Ruoyao @ 2022-08-25  8:09 UTC (permalink / raw)
  To: Alejandro Colomar, Linus Torvalds
  Cc: linux-man, Rich Felker, Alexei Starovoitov, David Howells,
	Alexei Starovoitov, Joseph Myers, linux-arch, Zack Weinberg,
	Daniel Borkmann, Alex Colomar, Michael Kerrisk, Cyril Hrubis,
	Arnd Bergmann, GCC, LTP List, Florian Weimer, glibc,
	Greg Kroah-Hartman, LKML, David Laight, Linux API, bpf

On Thu, 2022-08-25 at 09:48 +0200, Alejandro Colomar wrote:
> Hi Xi,
> 
> On 8/25/22 09:28, Xi Ruoyao wrote:
> > On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches
> > wrote:
> > > I don't know for sure, and I never pretended to say otherwise.  But what
> > > IMHO the kernel could do is to make the types compatible, by typedefing
> > > to the same fundamental types (i.e., long or long long) that user-space
> > > types do.
> > 
> > In user-space things are already inconsistent as we have multiple libc
> > implementations.  Telling every libc implementation to sync their
> > typedef w/o a WG14 decision will only cause "aggressive discussion" (far
> > more aggressive than this thread, I'd say).
> > 
> > If int64_t etc. were defined as builtin types since epoch, things would
> > be a lot easier.  But we can't change history.
> 
> This would be great.  I mean, the fundamental types should be u8, u16,
> ... and int, long, ... typedefs for these, and not the other way around, 
> if the language was designed today.
> 
> Maybe GCC could consider something like that.

GCC already have __UINT8_TYPE__ etc. but again telling all libc
implementations to use "typedef __UINT8_TYPE__ uint8_t" etc. will make
no effect expect annoying their maintainers.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25  7:27           ` Linus Torvalds
@ 2022-08-25 14:38             ` Joseph Myers
  2022-08-25 15:01               ` David Laight
  2022-08-25 16:43               ` Linus Torvalds
  0 siblings, 2 replies; 49+ messages in thread
From: Joseph Myers @ 2022-08-25 14:38 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Florian Weimer, Greg Kroah-Hartman, Alejandro Colomar,
	Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk

On Thu, 25 Aug 2022, Linus Torvalds wrote:

> That's a small detail that yes, we've tried to avoid the absolute
> humongous mess that the C standard library has with their horrendous
> 'PRId*' mess, but honestly, it's just a tiny detail.

I've not yet implemented it for glibc or for GCC format checking, but C23 
adds 'wN' format length modifiers so you will be able to e.g. use "%w64d" 
with printf to print an int64_t and won't need those PRI macros any more.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25 14:38             ` Joseph Myers
@ 2022-08-25 15:01               ` David Laight
  2022-08-25 15:37                 ` Joseph Myers
  2022-08-25 16:43               ` Linus Torvalds
  1 sibling, 1 reply; 49+ messages in thread
From: David Laight @ 2022-08-25 15:01 UTC (permalink / raw)
  To: 'Joseph Myers', Linus Torvalds
  Cc: Florian Weimer, Greg Kroah-Hartman, Alejandro Colomar,
	Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk

From: Joseph Myers
> Sent: 25 August 2022 15:39
> 
> On Thu, 25 Aug 2022, Linus Torvalds wrote:
> 
> > That's a small detail that yes, we've tried to avoid the absolute
> > humongous mess that the C standard library has with their horrendous
> > 'PRId*' mess, but honestly, it's just a tiny detail.
> 
> I've not yet implemented it for glibc or for GCC format checking, but C23
> adds 'wN' format length modifiers so you will be able to e.g. use "%w64d"
> with printf to print an int64_t and won't need those PRI macros any more.

Is that meant to work regardless of whether the type is
int, long or long long provided the size is correct?

Or does it require the compiler know which type inttypes.h
uses for uint32_t and uint64_t?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25 15:01               ` David Laight
@ 2022-08-25 15:37                 ` Joseph Myers
  0 siblings, 0 replies; 49+ messages in thread
From: Joseph Myers @ 2022-08-25 15:37 UTC (permalink / raw)
  To: David Laight
  Cc: Linus Torvalds, Florian Weimer, Greg Kroah-Hartman,
	Alejandro Colomar, Alexei Starovoitov, Alex Colomar,
	Alexei Starovoitov, linux-man, Daniel Borkmann, Zack Weinberg,
	LKML, glibc, GCC, bpf, LTP List, Linux API, linux-arch,
	Cyril Hrubis, David Howells, Arnd Bergmann, Rich Felker,
	Adhemerval Zanella, Michael Kerrisk

On Thu, 25 Aug 2022, David Laight wrote:

> From: Joseph Myers
> > Sent: 25 August 2022 15:39
> > 
> > On Thu, 25 Aug 2022, Linus Torvalds wrote:
> > 
> > > That's a small detail that yes, we've tried to avoid the absolute
> > > humongous mess that the C standard library has with their horrendous
> > > 'PRId*' mess, but honestly, it's just a tiny detail.
> > 
> > I've not yet implemented it for glibc or for GCC format checking, but C23
> > adds 'wN' format length modifiers so you will be able to e.g. use "%w64d"
> > with printf to print an int64_t and won't need those PRI macros any more.
> 
> Is that meant to work regardless of whether the type is
> int, long or long long provided the size is correct?
> 
> Or does it require the compiler know which type inttypes.h
> uses for uint32_t and uint64_t?

The type passed needs to be that used for the relevant stdint.h typedef, 
not another of the same size.  (For format checking, that means the 
compiler needs to know what the types used in stdint.h are.)

It's now required that if int32_t exists, int_least32_t must have the same 
type, so int_least32_t can also be used with that format (and there are 
'wfN' formats for int_fastN_t / uint_fastN_t as well).

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
  2022-08-25 14:38             ` Joseph Myers
  2022-08-25 15:01               ` David Laight
@ 2022-08-25 16:43               ` Linus Torvalds
  1 sibling, 0 replies; 49+ messages in thread
From: Linus Torvalds @ 2022-08-25 16:43 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Florian Weimer, Greg Kroah-Hartman, Alejandro Colomar,
	Alexei Starovoitov, Alex Colomar, Alexei Starovoitov, linux-man,
	Daniel Borkmann, Zack Weinberg, LKML, glibc, GCC, bpf, LTP List,
	Linux API, linux-arch, David Laight, Cyril Hrubis, David Howells,
	Arnd Bergmann, Rich Felker, Adhemerval Zanella, Michael Kerrisk

On Thu, Aug 25, 2022 at 7:38 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> I've not yet implemented it for glibc or for GCC format checking, but C23
> adds 'wN' format length modifiers so you will be able to e.g. use "%w64d"
> with printf to print an int64_t and won't need those PRI macros any more.

Yeah, that's going to help user space.

We don't typically have huge issues with it (any more) in the kernel
exactly because we refused to do the syntactically horrendous PRIxyz
thing.

So in the kernel, we still do have some format string issues, but they
tend to be about "different architectures and configurations do
different things for this type", and those different things are sadly
not necessarily about a fixed width.

IOW, we used to have horrors like "sector_t can be 32-bit or 64-bit
depending on config options" (because small machines didn't want the
overhead of having to pass 64-bit things around - from back when
32-bit was a primary target).

We got rid of *that* thing a few years ago because it just wasn't
worth supporting any more, but some similar issues remain.

So we still have a number of cases of "if you really need to print
this out, you need to use '%llui' and cast the value to 'unsigned long
long'".

But it's happily not as common as it used to be.

                 Linus

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2022-08-25 16:52 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-23 23:06 [RFC] bpf.2: Use standard types and attributes Alejandro Colomar
2021-04-23 23:20 ` Alexei Starovoitov
2021-04-24 17:56   ` Alejandro Colomar (man-pages)
2021-04-25 16:52     ` Alexei Starovoitov
2021-04-25 19:12       ` Zack Weinberg
2021-04-24 20:43   ` David Laight
2021-04-25 19:16     ` Zack Weinberg
2021-04-25 21:09       ` David Laight
2021-04-26 17:19 ` Joseph Myers
2021-04-26 17:46   ` Alejandro Colomar (man-pages)
2021-05-04 11:05 ` [RFC v2] " Alejandro Colomar
2021-05-04 14:12   ` Alexei Starovoitov
2021-05-04 14:24     ` Greg KH
2021-05-04 15:53       ` Alejandro Colomar (man-pages)
2021-05-04 16:06         ` Greg KH
2021-05-04 18:37           ` Zack Weinberg
2021-05-04 18:54             ` Alejandro Colomar (man-pages)
2021-05-04 19:45               ` Florian Weimer
2021-05-04 19:59                 ` Alejandro Colomar (man-pages)
2021-05-05  8:23                 ` David Laight
2021-05-05 22:22                   ` Joseph Myers
2021-05-04 20:06               ` Daniel Borkmann
2021-05-04 20:16                 ` Alejandro Colomar (man-pages)
2021-05-04 20:33                 ` Zack Weinberg
2021-05-04 21:23                   ` Alexei Starovoitov
2021-05-15 19:01               ` [PATCH v3] " Alejandro Colomar
2021-05-16  9:16                 ` Alejandro Colomar (man-pages)
2021-05-17 18:56                   ` Daniel Borkmann
2021-05-21 11:12                     ` Alejandro Colomar
2021-05-04 16:08         ` [RFC v2] " Daniel Borkmann
2022-08-24 18:55 ` [PATCH v3] Many pages: Document fixed-width types with ISO C naming Alejandro Colomar
2022-08-24 22:40   ` Alexei Starovoitov
2022-08-24 23:36     ` Alejandro Colomar
2022-08-25  0:52       ` Linus Torvalds
2022-08-25  7:20         ` Alejandro Colomar
2022-08-25  7:28           ` Xi Ruoyao
2022-08-25  7:48             ` Alejandro Colomar
2022-08-25  8:09               ` Xi Ruoyao
2022-08-25  7:42           ` Linus Torvalds
2022-08-25  7:59             ` Alejandro Colomar
2022-08-25  5:57       ` Greg Kroah-Hartman
2022-08-25  6:41         ` Florian Weimer
2022-08-25  7:27           ` Linus Torvalds
2022-08-25 14:38             ` Joseph Myers
2022-08-25 15:01               ` David Laight
2022-08-25 15:37                 ` Joseph Myers
2022-08-25 16:43               ` Linus Torvalds
2022-08-25  7:44         ` Alejandro Colomar
2022-08-25  8:04           ` Alejandro Colomar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).