[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0x5Bw7=0ng-s+KsUywqJYa0tk9cSWmZhx+cZRBOR87ZA@mail.gmail.com>
Date: Mon, 22 Nov 2021 21:48:39 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Cyril Hrubis <chrubis@...e.cz>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
LTP List <ltp@...ts.linux.it>,
GNU C Library <libc-alpha@...rceware.org>,
linux-arch <linux-arch@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
On Mon, Nov 22, 2021 at 5:43 PM Cyril Hrubis <chrubis@...e.cz> wrote:
>
> +
> +#include <asm/bitsperlong.h>
> +
> /*
> - * int-ll64 is used everywhere now.
> + * int-ll64 is used everywhere in kernel now.
> */
> -#include <asm-generic/int-ll64.h>
> +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__)
> +# include <asm-generic/int-l64.h>
> +#else
> +# include <asm-generic/int-ll64.h>
> +#endif
I don't think this is correct on all 64-bit architectures, as far as I
remember the
definition can use either 'long' or 'long long' depending on the user space
toolchain.
Out of the ten supported 64-bit architectures, there are four that already
use asm-generic/int-l64.h conditionally, and six that don't, and I
think at least
some of those are intentional.
I think it would be safer to do this one architecture at a time to make
sure this doesn't regress on those that require the int-ll64.h version.
There should also be a check for __SANE_USERSPACE_TYPES__
to let userspace ask for the ll64 version everywhere.
Arnd
Powered by blists - more mailing lists