[v3] Many pages: Document fixed-width types with ISO C naming
Commit Message
Kernel __u64 and similar types are ABI-compatible, and mostly
API-compatible with ISO C types. User-space programmers don't
care about kernel details, and should only use libc types.
Document syscalls and structures provided by the Linux kernel as
if they used libc types.
There's work in the kernel to remove this small API
incompatibility, which is only for pointers or printf specifiers.
Since I couldn't find any structure that uses pointers, there
shouldn't be any issues here. Also, the only pointer I found was
in a syscall parameter, but since syscall(2) doesn't check its
arguments' types, we're also safe there.
This patch doesn't go without controversy. Check the discussions
in the links below.
Found with:
$ grep -rn '\b_*[su][8136][624]*\b' man* \
| grep -v -e /bpf-helpers.7 -e /proc.5 -e /epoll_event.3type -e /wcscmp.3 \
-e /crypt.3 -e /mempcpy.3 -e /memcmp.3 -e /string.3 -e /wcsncmp.3 \
-e /wcscasecmp.3 -e /wmemcmp.3 -e /strcasecmp.3 -e /bcmp.3 \
-e /bstring.3 -e /endian.3 -e /strverscmp.3 -e /wcsncasecmp.3 \
-e /strcoll.3 -e /strcmp.3 \
| tee /dev/tty \
| wc -l;
Link: <https://lore.kernel.org/linux-man/20210423230609.13519-1-alx.manpages@gmail.com/T/>
Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Nacked-by: Alexei Starovoitov <ast@kernel.org>
Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nacked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Zack Weinberg <zackw@panix.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: glibc <libc-alpha@sourceware.org>
Cc: GCC <gcc-patches@gcc.gnu.org>
Cc: bpf <bpf@vger.kernel.org>
Cc: LTP List <ltp@lists.linux.it>
Cc: Linux API <linux-api@vger.kernel.org>
Cc: linux-arch <linux-arch@vger.kernel.org>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Joseph Myers <joseph@codesourcery.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Cyril Hrubis <chrubis@suse.cz>
Cc: David Howells <dhowells@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Rich Felker <dalias@libc.org>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
---
Hi,
I removed attributes from this patch. It now only changes types,
and only types that don't have anything special in them. __be64
or things like that are not included in this patch. __aligned_u64
isn't either.
I made clear what the incompatibilities are, and I hope Cyril
fixes them soon, but anyway, they shouldn't affect for the cases
documented here. And if they affect somehow, a programmer will
probably know the reason; but I'd consider that a kernel bug, or
at least something to improve there.
I'm decided to push for this change, and would like to see the
kernel making the necessary steps to make it smoother, since it
shouldn't be hard (the patch is there already; it only needs a
little bit of love).
Anyway, I don't think it will cause important problems to readers
of the manual pages, and instead expect an improvement.
Cheers,
Alex
man2/bpf.2 | 28 +-
man2/capget.2 | 10 +-
man2/clone.2 | 36 +--
man2/getunwind.2 | 6 +-
man2/io_submit.2 | 22 +-
man2/ioctl_ficlonerange.2 | 8 +-
man2/ioctl_fideduperange.2 | 20 +-
man2/ioctl_getfsmap.2 | 28 +-
man2/ioctl_userfaultfd.2 | 37 +--
man2/kcmp.2 | 6 +-
man2/keyctl.2 | 8 +-
man2/landlock_add_rule.2 | 4 +-
man2/landlock_create_ruleset.2 | 2 +-
man2/mount_setattr.2 | 8 +-
man2/perf_event_open.2 | 486 ++++++++++++++++-----------------
man2/ptrace.2 | 40 +--
man2/sched_setattr.2 | 20 +-
man2/seccomp.2 | 24 +-
man2/seccomp_unotify.2 | 32 +--
man2/statx.2 | 42 +--
man2/userfaultfd.2 | 28 +-
man2type/open_how.2type | 6 +-
man3type/epoll_event.3type | 2 +-
man4/loop.4 | 6 +-
man4/random.4 | 6 +-
man7/fanotify.7 | 28 +-
man7/netdevice.7 | 2 +-
man7/netlink.7 | 14 +-
man7/packet.7 | 16 +-
man7/rtnetlink.7 | 20 +-
man7/sock_diag.7 | 122 +++++----
31 files changed, 568 insertions(+), 549 deletions(-)
Comments
On Wed, Aug 24, 2022 at 12:04 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index d05b73ec2..84d1b62e5 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -169,34 +169,34 @@ commands:
> .EX
> union bpf_attr {
> struct { /* Used by BPF_MAP_CREATE */
> - __u32 map_type;
> - __u32 key_size; /* size of key in bytes */
> - __u32 value_size; /* size of value in bytes */
> - __u32 max_entries; /* maximum number of entries
> + uint32_t map_type;
> + uint32_t key_size; /* size of key in bytes */
> + uint32_t value_size; /* size of value in bytes */
> + uint32_t max_entries; /* maximum number of entries
> in a map */
> };
>
> struct { /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
> commands */
> - __u32 map_fd;
> + uint32_t map_fd;
> __aligned_u64 key;
> union {
> __aligned_u64 value;
> __aligned_u64 next_key;
> };
> - __u64 flags;
> + uint64_t flags;
> };
>
> struct { /* Used by BPF_PROG_LOAD */
> - __u32 prog_type;
> - __u32 insn_cnt;
> + uint32_t prog_type;
> + uint32_t insn_cnt;
For the N-th time:
Nacked-by: Alexei Starovoitov <ast@kernel.org>
Please stop sending this patch.
Alexei,
On 8/24/22 20:55, Alejandro Colomar wrote:
> Link:
<https://lore.kernel.org/linux-man/20210423230609.13519-1-alx.manpages@gmail.com/T/>
> Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> Nacked-by: Alexei Starovoitov <ast@kernel.org>
> Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Nacked-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Zack Weinberg <zackw@panix.com>
On 8/25/22 00:40, Alexei Starovoitov wrote:
> On Wed, Aug 24, 2022 at 12:04 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> diff --git a/man2/bpf.2 b/man2/bpf.2
>> index d05b73ec2..84d1b62e5 100644
>> --- a/man2/bpf.2
>> +++ b/man2/bpf.2
[...]
>>
>> struct { /* Used by BPF_PROG_LOAD */
>> - __u32 prog_type;
>> - __u32 insn_cnt;
>> + uint32_t prog_type;
>> + uint32_t insn_cnt;
>
> For the N-th time:
> Nacked-by: Alexei Starovoitov <ast@kernel.org>
>
> Please stop sending this patch.
Sorry, but no.
First, this has only been v3, and v1 was a year and a half ago, don't
make it like I'm constantly making you lose your precious time, because
I'm actively trying not to.
Second, I already made a big notice that you and a few more have
strongly opposed to the patch, respectfully keeping all of your NAKs in
my patch, as you can see above.
I gave very detailed reasons of why this patch is reasonable and, back
in the days of v1, Zack (from glibc) gave even better reasons of why the
manual pages should document ISO C (libc) types, and not kernel ones,
and why it shouldn't matter to user-space programmers.
But from your side what do we have? Just direct NAKs without much
explanation. The only one who gave some explanation was Greg, and he
vaguely pointed to Linus's comments about it in the past, with no
precise pointer to it. I investigated a lot before v2, and could not
find anything strong enough to recommend using kernel types in user
space, so I pushed v2, and the discussion was kept.
I would like that if you still oppose to the patch, at least were able
to provide some facts to this discussion.
But the most fundamental thing that I ask is that you respect me.
With this attitude, the only thing you're going to get is that I apply
the patch right after, because:
1) The patch is right. Go talk to glibc and gcc maintainers, who know
how types work by heart if you have doubts.
2) I'm the maintainer of this project, and under doubts, it's my decission.
I'm trying to be nice, and ask for review to make sure I'm not making
some big mistake by accident, and I get disrespect? No thanks.
Patch applied.
Now, if someone with a bit more respect still thinks this change is
incorrect, and is wanting to share some facts to show me my mistake,
I'll happily review it and revert the patch if necessary. For now, the
patch is applied.
Alex
--
Alejandro Colomar
Linux man-pages maintainer
<http://www.alejandro-colomar.es/>
On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> I'm trying to be nice, and ask for review to make sure I'm not making
> some big mistake by accident, and I get disrespect? No thanks.
You've been told multiple times that the kernel doesn't use the
"standard" names, and *cannot* use them for namespace reasons, and you
ignore all the feedback, and then you claim you are asking for review?
That's not "asking for review". That's "I think I know the answer, and
when people tell me otherwise I ignore them".
The fact is, kernel UAPI header files MUST NOT use the so-called standard names.
We cannot provide said names, because they are only provided by the
standard header files.
And since kernel header files cannot provide them, then kernel UAPI
header files cannot _use_ them.
End result: any kernel UAPI header file will continue to use __u32 etc
naming that doesn't have any namespace pollution issues.
Nothing else is even remotely acceptable.
Stop trying to make this something other than it is.
And if you cannot accept these simple technical reasons, why do you
expect respect?
Why are you so special that you think you can change the rules for
kernel uapi files over the *repeated* objections from maintainers who
know better?
Linus
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
> <alx.manpages@gmail.com> wrote:
>>
>> I'm trying to be nice, and ask for review to make sure I'm not making
>> some big mistake by accident, and I get disrespect? No thanks.
>
> You've been told multiple times that the kernel doesn't use the
> "standard" names, and *cannot* use them for namespace reasons, and you
> ignore all the feedback, and then you claim you are asking for review?
This patch is not about kernel, but about the section 2 and 3 manual
pages, which are directed towards user-space readers most of the time.
Admittedly, some syscalls are only callable from within the kernel
itself, but that's very rare.
[...]
>
> The fact is, kernel UAPI header files MUST NOT use the so-called standard names.
I don't know for sure, and I never pretended to say otherwise. But what
IMHO the kernel could do is to make the types compatible, by typedefing
to the same fundamental types (i.e., long or long long) that user-space
types do.
>
> We cannot provide said names, because they are only provided by the
> standard header files.
>
> And since kernel header files cannot provide them, then kernel UAPI
> header files cannot _use_ them.
>
> End result: any kernel UAPI header file will continue to use __u32 etc
> naming that doesn't have any namespace pollution issues.
>
> Nothing else is even remotely acceptable.
>
> Stop trying to make this something other than it is.
>
> And if you cannot accept these simple technical reasons, why do you
> expect respect?
>
> Why are you so special that you think you can change the rules for
> kernel uapi files over the *repeated* objections from maintainers who
> know better?
No sorry, if someone understood this patch as changing anything in UAPI,
it is not.
Cheers,
Alex
--
Alejandro Colomar
<http://www.alejandro-colomar.es/>
On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> The justifications brought forward are just regurgitating previous
> misinformation. If you do that, it's hard to take you seriously.
Pot, meet kettle.
> There is actually a good reason for using __u64: it's always based on
> long long, so the format strings are no longer architecture-specific,
[..]
That's a small detail that yes, we've tried to avoid the absolute
humongous mess that the C standard library has with their horrendous
'PRId*' mess, but honestly, it's just a tiny detail.
The real issue is that we want to be able to control our own types,
and our own names, and in the process have sometimes been able to
standardize on types that makes it easier to just not have to deal
with "oh, somebody picked 'int' on this architecture, and 'long' on
this other, and they are both 32-bit types".
We still have to deal with that for '[s]size_t', but that's such a
standard legacy type that thankfully we have the whole '%zu/%zd' thing
for that.
And yes, sometimes we screw up even *though* we were the ones that
picked the types, and we've had pointless differences where '__u64'
could be 'unsigned long' on a 64-bit architecture, and 'unsigned long
long' on a 32-bit one, and then we were able to fix our own little
broken type system exactly because it was *OUR* little type system.
So you are correct that then in the specific case of '__u64' we have
been able to simply just standardize on 'unsigned long long' and make
printf strings simpler.
But you are wrong to think that that is somehow a special thing.
It's not.
It's very much all the same thing: we have types *we* control, and
thanks to that we can do them the way *we* need them done, and can fix
them when we made a silly mistake.
In other words, it's the whole *point* of not ever using 'stdint.h' at
all for those things.
(It's also about avoiding the kinds of unholy things that happen in
system header files. Have you ever *looked* at them? Christ. The
amount of absolute crap you get from including <stdint.h> in user
space is scary)
> You cannot avoid using certain ISO C names with current GCC or Clang,
> however hard you try.
You are now the one who is regurgitating complete mis-information.
You do it so prettily, and with such weasel-wording, that I know you
must be knowingly threading that fine line between "actively
misleading" but trying to avoid "outright lying"..
You say "certain ISO C names" to try to make it sound as if this was
at all relevant to things like "uint32_t" and friends.
But deep down, you know you're basically lying by omission.
Because it's true that we have to know and care about things like
'size_t', which comes up for all the basic string.h functions.
So yes, we have a very small set of types that we make sure matches
the compiler notion of said types, and we carefully use things like
typedef __kernel_ulong_t __kernel_size_t;
and then we have our own 'stdarg.h which uses
typedef __builtin_va_list va_list;
that is explicitly the one that the compiler exposes with those double
underscores exactly because even the compiler can't expose the
"standard" name due to namespace issues.
And no, NONE OF THOSE ARE USABLE IN THE UAPI HEADERS!
And equally importantly, none of those have *anything* to do with the
'uint32_t' kind of names.
The fact that yes, we care about what the compiler thinks "size_t" is
(because we do want the compiler to do memset() for us) has absolutely
*NOTHING* to do with uint32_t and <stdint.h>.
And I'm pretty sure you knew that, but you tried to make it sound like
they were somehow all in the same boat.
And yes, some drivers tend to actually use 'uint32_t' in the kernel,
and we allow it, but they cannot be used by user interfaces. So a uapi
file really *really* shouldn't ever use them.
And no, we don't use "-ffreestanding" and friends - we actually have
occasionally wanted and tried to do so just to make the boundary lines
clearer, but then that will make gcc no longer do sane things for
'memcpy()'' and friends, so it's kind of a balancing act.
> <stdarg.h>, <stddef.h>, <stdint.h> are compiler-provided headers that
> are designed to be safe to use for bare-metal contexts (like in
> kernels). Avoiding them is not necessary per se.
We explicitly avoid them all.
We historically used stdarg.h and stddef.h (but never stdint.h -
there's absolutely _zero_ upside), but it was always a slight pain.
So we simply bake our own, exactly because it's simply less painful
than having to deal with possible system-provided ones.
People do odd compiler things with host compilers, bad or odd
installations of cross-build environments, it's just not worth the
pain to deal with the "system header files" when they just don't
provide any real value.
Linus
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.
On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> This patch is not about kernel, but about the section 2 and 3 manual
> pages, which are directed towards user-space readers most of the time.
They are about the types to the kernel interfaces. Those types that
the kernel defines and exposes.
And the kernel type in question looks like this:
struct { /* anonymous struct used by BPF_PROG_LOAD command */
__u32 prog_type; /* one of enum bpf_prog_type */
__u32 insn_cnt;
__aligned_u64 insns;
__aligned_u64 license;
because the kernel UAPI header wants to
(a) work whether or not <stdint.h> was included
(b) doesn't want to include <stdint.h> so as to not pollute the namespace
(c) actually wants to use our special types
I quoted a few more fields for that (c) reason: we've had a long
history of getting the user space API wrong due to strange alignment
issues, where 32-bit and 64-bit targets had different alignment for
types. So then we ended up with various compat structures to translate
from one to the other because they had all the same fields, but
different padding.
This happened a few times with the DRM people, and they finally got
tired of it, and started using that "__aligned_u64" type, which is
just the same old __u64, but explicitly aligned to its natural
alignment.
So these are the members that the interface actually uses.
If you document those members, wouldn't it be good to have that
documentation be actually accurate?
Honestly, I don't think it makes a *huge* amount of difference, but
documentation that doesn't actually match the source of the
documentation will just confuse somebody in the end. Somebody will go
"that's not right", and maybe even change the structure definitions to
match the documentation.
Which would be wrong.
Now, you don't have to take the kernel uapi headers. We *try* to make
those usable as-is, but hey, there has been problems in the past, and
it's not necessarily wrong to take the kernel header and then munge it
to be "appropriate" for user space.
So I guess you can just make your own structures with the names and
syntax you want, and say "these are *my* header files, and *my*
documentation for them".
That's fine. But I'm not surprised if the kernel maintainer then goes
"no, that's not the interface I agreed to" if only because it's a pain
to verify that you got it all right. Maybe it was all trivial and
automated and there can be no errors, but it's still a "why is there a
different copy of this complicated interface".
If you really want to describe things to people, wouldn't it be nicer
to just say "there's a 32-bit unsigned 'prog_type' member" and leave
it at that?
Do you really want to enforce your opinion of what is prettier on the
maintainer that wrote that thing, and then argue with him when he
doesn't agree?
Linus
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/>
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/>
Hi Linus,
(Oops, I mistyped you name in my previous reply; I'm on a roll for funny
typos this week it seems)
On 8/25/22 09:42, Linus Torvalds wrote:
> On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> This patch is not about kernel, but about the section 2 and 3 manual
>> pages, which are directed towards user-space readers most of the time.
>
> They are about the types to the kernel interfaces. Those types that
> the kernel defines and exposes.
>
> And the kernel type in question looks like this:
>
> struct { /* anonymous struct used by BPF_PROG_LOAD command */
> __u32 prog_type; /* one of enum bpf_prog_type */
> __u32 insn_cnt;
> __aligned_u64 insns;
> __aligned_u64 license;
>
> because the kernel UAPI header wants to
>
> (a) work whether or not <stdint.h> was included
These days, (a) is more of a theoretical thing, since programs avoiding
C99 <stdint.h> will have a hard time.
>
> (b) doesn't want to include <stdint.h> so as to not pollute the namespace
>
> (c) actually wants to use our special types
>
> I quoted a few more fields for that (c) reason: we've had a long
> history of getting the user space API wrong due to strange alignment
> issues, where 32-bit and 64-bit targets had different alignment for
> types. So then we ended up with various compat structures to translate
> from one to the other because they had all the same fields, but
> different padding.
>
> This happened a few times with the DRM people, and they finally got
> tired of it, and started using that "__aligned_u64" type, which is
> just the same old __u64, but explicitly aligned to its natural
> alignment.
>
> So these are the members that the interface actually uses.
>
> If you document those members, wouldn't it be good to have that
> documentation be actually accurate?
>
> Honestly, I don't think it makes a *huge* amount of difference, but
> documentation that doesn't actually match the source of the
> documentation will just confuse somebody in the end. Somebody will go
> "that's not right", and maybe even change the structure definitions to
> match the documentation.
>
> Which would be wrong.
>
> Now, you don't have to take the kernel uapi headers. We *try* to make
> those usable as-is, but hey, there has been problems in the past, and
> it's not necessarily wrong to take the kernel header and then munge it
> to be "appropriate" for user space.
>
> So I guess you can just make your own structures with the names and
> syntax you want, and say "these are *my* header files, and *my*
> documentation for them".
>
> That's fine. But I'm not surprised if the kernel maintainer then goes
> "no, that's not the interface I agreed to" if only because it's a pain
> to verify that you got it all right. Maybe it was all trivial and
> automated and there can be no errors, but it's still a "why is there a
> different copy of this complicated interface".
>
> If you really want to describe things to people, wouldn't it be nicer
> to just say "there's a 32-bit unsigned 'prog_type' member" and leave
> it at that?
>
> Do you really want to enforce your opinion of what is prettier on the
> maintainer that wrote that thing, and then argue with him when he
> doesn't agree?
You convinced me. The man-pages will document the types exactly as they
are in kernel. It's just simpler.
As the patch was recently reverted after Greg asked me to do, I'll keep
it that way. I guess this closes the man-pages discussion.
I'd still like to see the kernel types be API-compatible with the
user-space ones, for which there's a patch around, and also making the
<stdint.h> types be builtind could also be nice. Let's see if that
works out.
Cheers,
Alex
--
Alejandro Colomar
<http://www.alejandro-colomar.es/>
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, 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.
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.
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).
On Thu, Aug 25, 2022 at 7:38 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> I've not yet implemented it for glibc or for GCC format checking, but C23
> adds 'wN' format length modifiers so you will be able to e.g. use "%w64d"
> with printf to print an int64_t and won't need those PRI macros any more.
Yeah, that's going to help user space.
We don't typically have huge issues with it (any more) in the kernel
exactly because we refused to do the syntactically horrendous PRIxyz
thing.
So in the kernel, we still do have some format string issues, but they
tend to be about "different architectures and configurations do
different things for this type", and those different things are sadly
not necessarily about a fixed width.
IOW, we used to have horrors like "sector_t can be 32-bit or 64-bit
depending on config options" (because small machines didn't want the
overhead of having to pass 64-bit things around - from back when
32-bit was a primary target).
We got rid of *that* thing a few years ago because it just wasn't
worth supporting any more, but some similar issues remain.
So we still have a number of cases of "if you really need to print
this out, you need to use '%llui' and cast the value to 'unsigned long
long'".
But it's happily not as common as it used to be.
Linus
@@ -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 */
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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;
};
};
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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;
@@ -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
@@ -46,7 +46,7 @@ with a slightly different definition:
struct epoll_event {
__poll_t events;
- __u64 data;
+ uint64_t data;
};
.EE
.in
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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.
@@ -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
@@ -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
@@ -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.