The road to Zettalinux [LWN.net]

The road to Zettalinux

Posted Sep 16, 2022 18:46 UTC (Fri) by re:fi.64 (subscriber, #132628)
In reply to: The road to Zettalinux by jonesmz
Parent article: The road to Zettalinux

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

to post comments

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.