On Tue, Mar 25, 2025 at 8:27 PM Peter Zijlstra [off-list ref] wrote:

On Tue, Mar 25, 2025 at 08:15:41AM -0400, guoren@kernel.org wrote:

quoted

From: "Guo Ren (Alibaba DAMO Academy)" <guoren@kernel.org>

Since 2001, the CONFIG_64BIT kernel has been built with the LP64 ABI,
but this patchset allows the CONFIG_64BIT kernel to use an ILP32 ABI

I'm thinking you're going to be finding a metric ton of assumptions
about 'unsigned long' being 64bit when 64BIT=y throughout the kernel.

Less than you imagined. Most code is compatible with ILP32 ABI due to
the CONFIG_32BIT. In my practice, it's deemed acceptable.

I know of a couple of places where 64BIT will result in different math
such that a 32bit 'unsigned long' will trivially overflow.

I would be grateful if you could share some with me.

Please, don't do this. This adds a significant maintenance burden on all
of us.

The 64ILP32 ABI would bear the maintenance burden, not traditional
64-bit or 32-bit ABIs. The patch set won't impact other CONFIG_64BIT
or CONFIG_32BIT. Numerous RV64 chips require the RV64ILP32 ABI to
reduce the memory and cache footprint; we will bear the burden. The
core code maintainers would receive patches that would make them use
BITS_PER_LONG and CONFIG_64BIT more accurately.

-- 
Best Regards
 Guo Ren