[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <67802ad7-c41d-47ac-a231-abec1e5aae2e@app.fastmail.com>
Date: Mon, 03 Nov 2025 10:41:47 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Huacai Chen" <chenhuacai@...nel.org>,
Thomas Weißschuh <linux@...ssschuh.net>
Cc: "WANG Xuerui" <kernel@...0n.name>,
"Jiaxun Yang" <jiaxun.yang@...goat.com>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] LoongArch: ptrace: Use UAPI types in UAPI header
On Mon, Nov 3, 2025, at 10:12, Huacai Chen wrote:
> Hi, Thomas,
>
> On Wed, Oct 29, 2025 at 11:20 PM Thomas Weißschuh <linux@...ssschuh.net> wrote:
>>
>> The kernel UAPI headers already contain fixed-width integer types,
>> there is no need to rely on libc types. There may not be a libc
>> available or it may not provide <stdint.h>, like for example on nolibc.
>>
>> This also aligns the header with the rest of the LoongArch UAPI headers.
Thanks! I ran into the same issue for a different series, so this is most welcome.
> Thank you for your patch, but could you please tell me some history
> and user guide about the three styles: u64, __u64 and unint64_t?
The kernel uapi headers use __u64 etc so they can be included in user
applications without clashing with any types they might define themselves
auch as u64.
The uint64_t style types are problematic because they are provided
by toolchain in userspace, so build-testing the uapi headers would depend
on a working (userspace) cross-compiler rather than just a minimal
(nolibc) toolchain, and because the standard headers are meant to
only be included if specified explicitly by application source code
rather than indirectly from another header.
This was more problematic in the past when it was more common for
applications to be built with pre-c99 compilers that were missing
stdint.h altogether.
Arnd
Powered by blists - more mailing lists