From: Florian Weimer <fweimer@redhat.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alejandro Colomar <alx.manpages@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Alex Colomar <alx@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
linux-man <linux-man@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Zack Weinberg <zackw@panix.com>,
LKML <linux-kernel@vger.kernel.org>,
glibc <libc-alpha@sourceware.org>, GCC <gcc-patches@gcc.gnu.org>,
bpf <bpf@vger.kernel.org>, LTP List <ltp@lists.linux.it>,
Linux API <linux-api@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
David Laight <David.Laight@aculab.com>,
Joseph Myers <joseph@codesourcery.com>,
Cyril Hrubis <chrubis@suse.cz>,
David Howells <dhowells@redhat.com>,
Arnd Bergmann <arnd@arndb.de>, Rich Felker <dalias@libc.org>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
Date: Thu, 25 Aug 2022 08:41:41 +0200 [thread overview]
Message-ID: <87ilmgddui.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <YwcPQ987poRYjfoL@kroah.com> (Greg Kroah-Hartman's message of "Thu, 25 Aug 2022 07:57:23 +0200")
* 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
next prev parent reply other threads:[~2022-08-25 6:41 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210423230609.13519-1-alx.manpages@gmail.com>
2021-04-23 23:20 ` [RFC] bpf.2: Use standard types and attributes 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
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
2022-08-24 18:55 ` [PATCH v3] Many pages: Document fixed-width types with ISO C naming Alejandro Colomar
2022-08-24 22:40 ` Alexei Starovoitov
2022-08-24 23:36 ` Alejandro Colomar
2022-08-25 0:52 ` Linus Torvalds
2022-08-25 7:20 ` Alejandro Colomar
2022-08-25 7:28 ` Xi Ruoyao
2022-08-25 7:48 ` Alejandro Colomar
2022-08-25 8:09 ` Xi Ruoyao
2022-08-25 7:42 ` Linus Torvalds
2022-08-25 7:59 ` Alejandro Colomar
2022-08-25 5:57 ` Greg Kroah-Hartman
2022-08-25 6:41 ` Florian Weimer [this message]
2022-08-25 7:27 ` Linus Torvalds
2022-08-25 14:38 ` Joseph Myers
2022-08-25 15:01 ` David Laight
2022-08-25 15:37 ` Joseph Myers
2022-08-25 16:43 ` Linus Torvalds
2022-08-25 7:44 ` Alejandro Colomar
2022-08-25 8:04 ` Alejandro Colomar
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=87ilmgddui.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=David.Laight@aculab.com \
--cc=adhemerval.zanella@linaro.org \
--cc=alexei.starovoitov@gmail.com \
--cc=alx.manpages@gmail.com \
--cc=alx@kernel.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chrubis@suse.cz \
--cc=dalias@libc.org \
--cc=daniel@iogearbox.net \
--cc=dhowells@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gregkh@linuxfoundation.org \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=mtk.manpages@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=zackw@panix.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).