BPF Archive on lore.kernel.org
 help / color / Atom feed
From: Zack Weinberg <zackw@panix.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	linux-man <linux-man@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	glibc <libc-alpha@sourceware.org>, GCC <gcc-patches@gcc.gnu.org>,
	bpf <bpf@vger.kernel.org>, David Laight <David.Laight@aculab.com>,
	Joseph Myers <joseph@codesourcery.com>
Subject: Re: [RFC v2] bpf.2: Use standard types and attributes
Date: Tue, 4 May 2021 14:37:20 -0400
Message-ID: <CAKCAbMg_eRCsD-HYmryL8XEuZcaM1Qdfp4XD85QKT6To+h3QcQ@mail.gmail.com> (raw)
In-Reply-To: <YJFxArfp8wN3ILJb@kroah.com>

On Tue, May 4, 2021 at 12:06 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, May 04, 2021 at 05:53:29PM +0200, Alejandro Colomar (man-pages) wrote:
> > On 5/4/21 4:24 PM, Greg KH wrote:
> > > I agree, the two are not the same type at all, this change should not be
> > > accepted.
> >
> > I get that in the kernel you don't use the standard fixed-width types (with
> > some exceptions), probably not to mess with code that relies on <stdint.h>
> > not being included (I hope there's not much code that relies on this in
> > 2021, but who knows).
> >
> > But, there is zero difference between these types, from the point of view of
> > the compiler.  There's 100% compatibility between those types, and you're
> > able to mix'n'match them.  See some example below.
...
> There's a very old post from Linus where he describes the difference
> between things like __u32 and uint32_t.  They are not the same, they
> live in different namespaces, and worlds, and can not always be swapped
> out for each other on all arches.
>
> Dig it up if you are curious, but for user/kernel apis you HAVE to use
> the __uNN and can not use uintNN_t variants, so don't try to mix/match
> them, it's good to just follow the kernel standard please.
...
> Nacked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Speaking from the C library's perspective, I'm going to push back
pretty hard on this NAK, for several reasons.

First, this is a proposed change to the manpages, not the headers
themselves.  Manpage documentation of C structs is *not* expected to
match the actual declaration in the headers.  The documented field
type is usually assignment-compatible with the actual type, but not
always.  There's no guarantee whatsoever that the fields are in the
same order as the header, or that the listed set of fields is
complete.

I would say that as long as any value of type __u32 can be stored in a
variable of type uint32_t without data loss, and vice versa, there is
no reason why manpages should *have to* use __u32 in preference to
uint32_t, and that in the absence of such a reason, the standard type
should be used.

Second, it's true that __u32 and uint32_t are in different namespaces,
and it may well be necessary for uapi <linux/*.h> headers to use the
__uNN names in order to preserve the C standard's distinction between
the program and the implementation, but that's *not* a reason for
documentation aimed at writers of user-space programs to use the
__uNN names.  In fact, it is exactly the opposite!  User space program
authors should, all else equal, be *discouraged* from using the __uNN
names, and avoiding their use in manpages is one way to do that.

Third, if there does in fact exist a situation where __uNN and
uintNN_t are *not* assignment compatible, THAT IS A BUG IN THE KERNEL.
Frankly, it would be such a catastrophic bug that I think Linus has to
have been *wrong*.  We would have noticed the problems long ago if he
were right.

I'm going to have to ask you to produce hard evidence for your claim
that __uNN and uintNN_t are not (always) assignment compatible, and
hard evidence why that can't be fixed within the kernel, or else
withdraw your objection.

zw

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210423230609.13519-1-alx.manpages@gmail.com>
2021-04-23 23:20 ` [RFC] " Alexei Starovoitov
2021-04-24 17:56   ` Alejandro Colomar (man-pages)
2021-04-25 16:52     ` Alexei Starovoitov
2021-04-25 19:12       ` Zack Weinberg
2021-04-24 20:43   ` David Laight
2021-04-25 19:16     ` Zack Weinberg
2021-04-25 21:09       ` David Laight
2021-05-04 11:05 ` [RFC v2] " Alejandro Colomar
2021-05-04 14:12   ` Alexei Starovoitov
2021-05-04 14:24     ` Greg KH
2021-05-04 15:53       ` Alejandro Colomar (man-pages)
2021-05-04 16:06         ` Greg KH
2021-05-04 18:37           ` Zack Weinberg [this message]
2021-05-04 18:54             ` Alejandro Colomar (man-pages)
2021-05-04 19:45               ` Florian Weimer
2021-05-04 19:59                 ` Alejandro Colomar (man-pages)
2021-05-05  8:23                 ` David Laight
2021-05-05 22:22                   ` Joseph Myers
2021-05-04 20:06               ` Daniel Borkmann
2021-05-04 20:16                 ` Alejandro Colomar (man-pages)
2021-05-04 20:33                 ` Zack Weinberg
2021-05-04 21:23                   ` Alexei Starovoitov
2021-05-15 19:01               ` [PATCH v3] " Alejandro Colomar
2021-05-16  9:16                 ` Alejandro Colomar (man-pages)
2021-05-17 18:56                   ` Daniel Borkmann
2021-05-21 11:12                     ` Alejandro Colomar
2021-05-04 16:08         ` [RFC v2] " Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKCAbMg_eRCsD-HYmryL8XEuZcaM1Qdfp4XD85QKT6To+h3QcQ@mail.gmail.com \
    --to=zackw@panix.com \
    --cc=David.Laight@aculab.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git