* 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
