On Tue, May 04, 2021 at 05:53:29PM +0200, Alejandro Colomar (man-pages) wrote:

Hi Greg and Alexei,

quoted

On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:

quoted

For the same reasons as explained earlier:
Nacked-by: Alexei Starovoitov [off-list ref]

Okay, I'll add that.


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

quoted

accepted.

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

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

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

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

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

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

So consider this my:

Nacked-by: Greg Kroah-Hartman [off-list ref]

as well.

thanks,

greg k-h