linux-kernel - Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Aug 2022 00:42:32 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Alejandro Colomar <alx.manpages@...il.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alex Colomar <alx@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        linux-man <linux-man@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Zack Weinberg <zackw@...ix.com>,
        LKML <linux-kernel@...r.kernel.org>,
        glibc <libc-alpha@...rceware.org>, GCC <gcc-patches@....gnu.org>,
        bpf <bpf@...r.kernel.org>, LTP List <ltp@...ts.linux.it>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        David Laight <David.Laight@...lab.com>,
        Joseph Myers <joseph@...esourcery.com>,
        Florian Weimer <fweimer@...hat.com>,
        Cyril Hrubis <chrubis@...e.cz>,
        David Howells <dhowells@...hat.com>,
        Arnd Bergmann <arnd@...db.de>, Rich Felker <dalias@...c.org>,
        Adhemerval Zanella <adhemerval.zanella@...aro.org>,
        Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
<alx.manpages@...il.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