[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJU=r0qE-4ZHsvX4YndbFgDGvzAgNgVo7kPMGF4jCrVeg@mail.gmail.com>
Date: Sun, 25 Apr 2021 09:52:11 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>
Cc: bpf <bpf@...r.kernel.org>,
"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
linux-man <linux-man@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, libc-alpha@...rceware.org,
gcc-patches@....gnu.org
Subject: Re: [RFC] bpf.2: Use standard types and attributes
On Sat, Apr 24, 2021 at 10:56 AM Alejandro Colomar (man-pages)
<alx.manpages@...il.com> wrote:
>
> Hello Alexei,
>
> On 4/24/21 1:20 AM, Alexei Starovoitov wrote:
> > Nack.
> > The man page should describe the kernel api the way it is in .h file.
>
> Why?
Because man page must describe the linux uapi headers the way they
are installed in the system and not invent alternative implementations.
The users will include those .h with __u32 and will see them in their code.
Man page saying something else is a dangerous lie.
> using uint32_t in every situation where __u32 is expected. They're both
> typedefs for the same basic type.
That's irrelevant. Languages like golang have their own bpf.h equivalent
that matches /usr/include/linux/bpf.h.
> I can understand why Linux will keep using u32 types (and their __ user
> space variants), but that doesn't mean user space programs need to use
> the same type.
No one says that the users must use __u32. See golang example.
But if the users do #include <linux/bpf.h> they will get them and man page
must describe that.
> If we have a standard syntax for fixed-width integral types (and for
> anything, actually), the manual pages should probably follow it,
> whenever possible.
Absolutely not. linux man page must describe linux.
Powered by blists - more mailing lists