Re: ARM/AAarch64: NEON intrinsics in the kernel

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 21 May 2013 11:43, Richard Earnshaw <rearnsha@arm.com> wrote:
> Why don't you add a (maybe cut-down) stdint.h to the kernel.  It seems
> bizarre to me that the kernel is trying to provide standard types through a
> non-standard interface.
>

There have been heated debates going on for years about these things.

Quote from Linus Torvalds: (http://yarchive.net/comp/linux/kernel_headers.html)

"
The user is supposed to see "int32_t" and friends _only_ if the user
himself includes <stdint.h> or one of the very specific headers that is
documented by the standard to include it.

Trust me. We are NOT going to use <stdint.h> in the kernel.
"

This is fairly old, and some of the types have in fact been added to
<linux/types.h>, even if stdint.h is still absent.

The bottom line is that including arm_neon.h pulls in a host of stuff
into the namespace, even with -ffreestanding. (And in that case, the
fact that GCC built for bare metal and GCC built for GLIBC disagree on
the definition of __UINTPTR_TYPE__ is not helping a lot either)

I understand that the uintXX_t types have already been made part of
the public NEON instrinsics interface, so I am not proposing changing
that. I am just looking for a way to enable the use of NEON intrinsics
in the kernel.

Are there any other solution possible in your opinion? Do you agree
that POSIX states that stdint.h may only be included in specific well
defined cases? Could we perhaps make the #inclusion conditional? An
alternate header perhaps to accomodate non-C99 environments?

Regards,
Ard.