On Thu, Jun 16, 2022 at 04:51:08PM +0200, Jason A. Donenfeld wrote: > For better or for worse, I've always assumed that the kernel had its > reasons -- legitimate reasons, even -- for preferring `unsigned long` to > a userspace type like `uintptr_t`, so I've always tried to code that > way. I don't know why people call uintptr_t a "userspace type". It's a type invented by C99 that is an integer type large enough to hold a pointer. Which is exactly what we want here. > If that's a "dinosaur approach" that "has to stop", it'd certainly be > news to me (and I'm guessing others on the list too). I've never really > seen anybody question the kernel's `unsigned long` usage before. I've put in a proposal to ksummit-discuss that makes the case for using uintptr_t where it fits our needs. Here's a copy of it. --- 8< --- Zettalinux: It's Not Too Late To Start The current trend in memory sizes lead me to believe that we'll need 128-bit pointers by 2035. Hardware people are starting to think about it [1a] [1b] [2]. We have a cultural problem in Linux where we believe that all pointers (user or kernel) can be stuffed into an unsigned long and newer C solutions (uintptr_t) are derided as "userspace namespace mess". The only sane way to set up a C environment for a CPU with 128-bit pointers is sizeof(void *) == 16, sizeof(short) == 2, sizeof(int) == 4, sizeof(long) == 8, sizeof(long long) == 16. That means that casting a pointer to a long will drop the upper 64 bits, and we'll have to use long long for the uintptr_t on 128-bit. Fixing Linux to be 128-bit clean is going to be a big job, and I'm not proposing to do it myself. But we can at least start by not questioning when people use uintptr_t inside the kernel to represent an address. Getting the userspace API fixed is going to be the most important thing (eg io_uring was just added and is definitely not 128-bit clean). Fortunately, no 128-bit machines exist today, so we have a bit of time to get the UAPI right. But if not today, then we should start soon. There are two purposes for this session: * Agree that we do need to start thinking about 128-bit architectures (even if they're not going to show up in our offices tomorrow) * Come to terms with needing to use uintptr_t instead of unsigned long [1a] https://github.com/michaeljclark/rv8/blob/master/doc/src/rv128.md [1b] https://github.com/riscv/riscv-opcodes/blob/master/unratified/rv128_i [2] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
