A memory model for Rust code in the kernel [LWN.net] (lwn.net)
from snaggen@programming.dev to rust@programming.dev on 06 Apr 2024 08:36
https://programming.dev/post/12428001

#rust

threaded - newest

gravitas_deficiency@sh.itjust.works on 06 Apr 2024 12:42 next collapse

Without that caching, performance would slow to a crawl, severely impacting the production, delivery, and consumption of cat videos, phishing spam, and cryptocurrency scams. This prospect is seen as a bad thing.

lol.

But also, interesting article!

onlinepersona@programming.dev on 07 Apr 2024 08:53 next collapse

This is why I’m curious about RedoxOS. It’s new, written in Rust, and has the chance to implement a different memory model without caring about a bunch of legacy code. I don’t know if Linus is right and that access is context dependent (it does sound right) and maybe that distinction from atomicity by type is unnecessary, but having never written kernel nor machine code, I have no idea about that kind of stuff.

Maybe sticking to the old will work out well enough or while implementing it in Rust they’ll find bugs. At least some fresh eyes will look at it during reimplementation.

Anti Commercial AI thingy

CC BY-NC-SA 4.0

tatterdemalion@programming.dev on 07 Apr 2024 10:44 collapse

I assume this means that standard library locking primitives will not be usable in the kernel? What about atomic intrinsics?