[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1Rvf_+qmQ5pyDeKweVOFM_GoOKnG4HA3Ffs6LeVuoDhA@mail.gmail.com>
Date: Mon, 29 Nov 2021 15:34:22 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Cyril Hrubis <chrubis@...e.cz>
Cc: David Laight <David.Laight@...lab.com>,
David Howells <dhowells@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"ltp@...ts.linux.it" <ltp@...ts.linux.it>,
"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
On Mon, Nov 29, 2021 at 12:58 PM Cyril Hrubis <chrubis@...e.cz> wrote:
>
> What about guarding the change with __STDINT_COMPATIBLE_TYPES__ as:
>
> #if defined(__STDINT_COMPATIBLE_TYPES__)
> # include <stdint.h>
>
> typedef __u64 uint64_t;
> ...
I don't think we can include stdint.h here, the entire point of the custom
kernel types is to ensure the other kernel headers can use these types
without relying on libc headers.
While some of driver specific kernel headers have libc dependencies
in them, the general rule is to keep the kernel headers as standalone
usable.
Arnd
Powered by blists - more mailing lists