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
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alejandro Colomar <alx.manpages@gmail.com>, linux-man <linux-man@vger.kernel.org>, Rich Felker <dalias@libc.org>, Alexei Starovoitov <ast@kernel.org>, David Howells <dhowells@redhat.com>, Alexei Starovoitov <alexei.starovoitov@gmail.com>, Joseph Myers <joseph@codesourcery.com>, linux-arch <linux-arch@vger.kernel.org>, Zack Weinberg <zackw@panix.com>, Daniel Borkmann <daniel@iogearbox.net>, Alex Colomar <alx@kernel.org>, Michael Kerrisk <mtk.manpages@gmail.com>, Arnd Bergmann <arnd@arndb.de>, GCC <gcc-patches@gcc.gnu.org>, LTP List <ltp@lists.linux.it>, glibc <libc-alpha@sourceware.org>, Linux API <linux-api@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, David Laight <David.Laight@aculab.com>, Adhemerval Zanella <adhemerval.zanella@linaro.org>, bpf <bpf@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [LTP] [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 -- Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-08-25 6:42 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-23 23:06 [RFC] bpf.2: Use standard types and attributes Alejandro Colomar 2021-04-23 23:20 ` 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-04-26 17:19 ` Joseph Myers 2021-04-26 17:46 ` Alejandro Colomar (man-pages) 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 18:55 ` [LTP] " Alejandro Colomar 2022-08-24 22:40 ` Alexei Starovoitov 2022-08-24 22:40 ` [LTP] " Alexei Starovoitov 2022-08-24 23:36 ` Alejandro Colomar 2022-08-24 23:36 ` [LTP] " Alejandro Colomar 2022-08-25 0:52 ` Linus Torvalds 2022-08-25 0:52 ` [LTP] " Linus Torvalds 2022-08-25 7:20 ` Alejandro Colomar 2022-08-25 7:20 ` [LTP] " Alejandro Colomar 2022-08-25 7:28 ` Xi Ruoyao 2022-08-25 7:28 ` [LTP] " Xi Ruoyao via ltp 2022-08-25 7:48 ` Alejandro Colomar 2022-08-25 7:48 ` [LTP] " Alejandro Colomar 2022-08-25 8:09 ` Xi Ruoyao 2022-08-25 8:09 ` [LTP] " Xi Ruoyao via ltp 2022-08-25 7:42 ` Linus Torvalds 2022-08-25 7:42 ` [LTP] " Linus Torvalds 2022-08-25 7:59 ` Alejandro Colomar 2022-08-25 7:59 ` [LTP] " Alejandro Colomar 2022-08-25 5:57 ` Greg Kroah-Hartman 2022-08-25 5:57 ` [LTP] " Greg Kroah-Hartman 2022-08-25 6:41 ` Florian Weimer [this message] 2022-08-25 6:41 ` Florian Weimer 2022-08-25 7:27 ` Linus Torvalds 2022-08-25 7:27 ` [LTP] " Linus Torvalds 2022-08-25 14:38 ` Joseph Myers 2022-08-25 14:38 ` [LTP] " Joseph Myers 2022-08-25 15:01 ` David Laight 2022-08-25 15:01 ` David Laight 2022-08-25 15:37 ` Joseph Myers 2022-08-25 15:37 ` [LTP] " Joseph Myers 2022-08-25 16:43 ` Linus Torvalds 2022-08-25 16:43 ` Linus Torvalds 2022-08-25 7:44 ` Alejandro Colomar 2022-08-25 7:44 ` [LTP] " Alejandro Colomar 2022-08-25 8:04 ` Alejandro Colomar 2022-08-25 8:04 ` [LTP] " 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.