The road to Zettalinux [LWN.net]

The road to Zettalinux

Posted Sep 16, 2022 17:25 UTC (Fri) by jonesmz (subscriber, #130234)
Parent article: The road to Zettalinux

> The problem now is that there is no 64-bit type in the mix. One solution might be to "ask the compiler folks" to provide a __int64_t type. But a better solution might just be to switch to Rust types, where i32 is a 32-bit, signed integer, while u128 would be unsigned and 128 bits. This convention is close to what the kernel uses already internally, though a switch from "s" to "i" for signed types would be necessary. Rust has all the types we need, he said, it would be best to just switch to them.

How does this follow at all?

"The C compilers can't be bothered to make specifically sized types, lets switch to an entirely different programming language" ???

to post comments

The road to Zettalinux

Posted Sep 16, 2022 18:46 UTC (Fri) by re:fi.64 (subscriber, #132628) [Link] (2 responses)

Switch to Rust's conventions around integral types, not switching anything else.

The road to Zettalinux

Posted Sep 16, 2022 23:03 UTC (Fri) by zev (subscriber, #88455) [Link] (1 responses)

What wasn't clear to me from the article though is what the Rust types provide that the existing C {u,s}{8,16,32,64} types used in the kernel don't. It mentioned the "s vs. i" issue, but is there a functional difference aside from that bit of nomenclature?

The road to Zettalinux

Posted Sep 18, 2022 6:25 UTC (Sun) by willy (subscriber, #9762) [Link]

They don't provide anything new. But those aren't standard C types, those are Linux types. My proposal is to (a) convert C code from using s64 to i64 so that people who are familiar with Rust will have a smoother transition. (b) use explicitly sized types instead of 'int', 'long', etc. I find it a good way to remind myself "This is not the mathematical concept of an integer; this is the engineering approximation with defined (or not) behaviour at overflow".

One of the defined types is isize/usize which matches the word size of the machine. We'd be a lot better off if more arithmetic inside the kernel were done in isize/usize units instead of just reaching for 'int'.

An example which came up recently is "number of bytes in a page". A lot of code just uses "int", and that works fine until you're on a PowerPC and use a 16GB HugeTLB page. Bam, silent truncation, you lose when trying to access the last 3/4 of the page. Possibly weird behaviour when accessing the 2GB to 4GB region of the page, depending on the exact function you're calling. If we reached for "isize" instead of "int", this wouldn't even be close to a problem.