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 <[email protected]>
---
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
On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
<[email protected]> 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 <[email protected]>
> ---
> 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.
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/
From: Alexei Starovoitov
> Sent: 24 April 2021 00:20
>
> On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar
> <[email protected]> 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 <[email protected]>
> > ---
> > 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)
On Sat, Apr 24, 2021 at 10:56 AM Alejandro Colomar (man-pages)
<[email protected]> 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.
On Sun, Apr 25, 2021 at 12:52 PM Alexei Starovoitov via Libc-alpha
<[email protected]> wrote:
> On Sat, Apr 24, 2021 at 10:56 AM Alejandro Colomar (man-pages)
> <[email protected]> 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
On Sat, Apr 24, 2021 at 4:43 PM David Laight via Libc-alpha
<[email protected]> wrote:
> From: Alexei Starovoitov
> > On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar <[email protected]> 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
From: Zack Weinberg
> Sent: 25 April 2021 20:17
>
> On Sat, Apr 24, 2021 at 4:43 PM David Laight via Libc-alpha
> <[email protected]> wrote:
> > From: Alexei Starovoitov
> > > On Fri, Apr 23, 2021 at 4:15 PM Alejandro Colomar <[email protected]> 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)
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
[email protected]
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/
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 <[email protected]>
Cc: LKML <[email protected]>
Cc: glibc <[email protected]>
Cc: GCC <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: bpf <[email protected]>
Cc: David Laight <[email protected]>
Cc: Zack Weinberg <[email protected]>
Cc: Joseph Myers <[email protected]>
---
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
On Tue, May 4, 2021 at 4:05 AM Alejandro Colomar <[email protected]> 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 <[email protected]>
> Cc: LKML <[email protected]>
> Cc: glibc <[email protected]>
> Cc: GCC <[email protected]>
> Cc: Alexei Starovoitov <[email protected]>
> Cc: bpf <[email protected]>
> Cc: David Laight <[email protected]>
> Cc: Zack Weinberg <[email protected]>
> Cc: Joseph Myers <[email protected]>
> ---
> 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 <[email protected]>
On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
> On Tue, May 4, 2021 at 4:05 AM Alejandro Colomar <[email protected]> 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 <[email protected]>
> > Cc: LKML <[email protected]>
> > Cc: glibc <[email protected]>
> > Cc: GCC <[email protected]>
> > Cc: Alexei Starovoitov <[email protected]>
> > Cc: bpf <[email protected]>
> > Cc: David Laight <[email protected]>
> > Cc: Zack Weinberg <[email protected]>
> > Cc: Joseph Myers <[email protected]>
> > ---
> > 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 <[email protected]>
I agree, the two are not the same type at all, this change should not be
accepted.
thanks,
greg k-h
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 <[email protected]>
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/
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 <[email protected]>
>
> 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 <[email protected]>
as well.
thanks,
greg k-h
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 <[email protected]>
>
> 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
On Tue, May 4, 2021 at 12:06 PM Greg KH <[email protected]> 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 <[email protected]>
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
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/[email protected]/T/>
* coding style
<https://lore.kernel.org/lkml/[email protected]/>
* [patch] Small input fixes for 2.5.29
<https://lore.kernel.org/lkml/[email protected]/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 <[email protected]>
>
> 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/
* 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
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/[email protected]/T/>
>
> * coding style <https://lore.kernel.org/lkml/[email protected]/>
>
> * [patch] Small input fixes for 2.5.29 <https://lore.kernel.org/lkml/[email protected]/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 <[email protected]>
> >
> > 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
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/
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/
On Tue, May 4, 2021 at 4:06 PM Daniel Borkmann <[email protected]> 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
On Tue, May 4, 2021 at 1:33 PM Zack Weinberg <[email protected]> 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.
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)
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
[email protected]
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 <[email protected]>
Nacked-by: Alexei Starovoitov <[email protected]>
Nacked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Zack Weinberg <[email protected]>
Cc: LKML <[email protected]>
Cc: glibc <[email protected]>
Cc: GCC <[email protected]>
Cc: bpf <[email protected]>
Cc: David Laight <[email protected]>
Cc: Joseph Myers <[email protected]>
Cc: Florian Weimer <[email protected]>
Cc: Daniel Borkmann <[email protected]>
---
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
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/[email protected]/T/>
Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
Signed-off-by: Alejandro Colomar <[email protected]>
Nacked-by: Alexei Starovoitov <[email protected]>
Nacked-by: Greg Kroah-Hartman <[email protected]>
Nacked-by: Daniel Borkmann <[email protected]>
Acked-by: Zack Weinberg <[email protected]>
Cc: LKML <[email protected]>
Cc: glibc <[email protected]>
Cc: GCC <[email protected]>
Cc: bpf <[email protected]>
Cc: LTP List <[email protected]>
Cc: Linux API <[email protected]>
Cc: linux-arch <[email protected]>
Cc: David Laight <[email protected]>
Cc: Joseph Myers <[email protected]>
Cc: Florian Weimer <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Cyril Hrubis <[email protected]>
Cc: David Howells <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Florian Weimer <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Adhemerval Zanella <[email protected]>
---
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
On Wed, Aug 24, 2022 at 12:04 PM Alejandro Colomar
<[email protected]> 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 <[email protected]>
Please stop sending this patch.
Alexei,
On 8/24/22 20:55, Alejandro Colomar wrote:
> Link:
<https://lore.kernel.org/linux-man/[email protected]/T/>
> Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
> Signed-off-by: Alejandro Colomar <[email protected]>
> Nacked-by: Alexei Starovoitov <[email protected]>
> Nacked-by: Greg Kroah-Hartman <[email protected]>
> Nacked-by: Daniel Borkmann <[email protected]>
> Acked-by: Zack Weinberg <[email protected]>
On 8/25/22 00:40, Alexei Starovoitov wrote:
> On Wed, Aug 24, 2022 at 12:04 PM Alejandro Colomar
> <[email protected]> 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 <[email protected]>
>
> 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/>
On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
<[email protected]> 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
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
* 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
Hi Linux,
On 8/25/22 02:52, Linus Torvalds wrote:
> On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
> <[email protected]> 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/>
On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer <[email protected]> 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
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 <[email protected]>
School of Aerospace Science and Technology, Xidian University
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/>
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 <[email protected]>
School of Aerospace Science and Technology, Xidian University
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
> <[email protected]> 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/>
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/>
On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
<[email protected]> 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
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/>
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
[email protected]
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)
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
[email protected]
On Thu, Aug 25, 2022 at 7:38 AM Joseph Myers <[email protected]> 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