Hacker News Reader

Comment by j16sdiz | Hacker News Reader

For most driver or subsystem, maybe you don't need to know how mm works.

Rust is different. The kernel Rust teams are trying to encode some safety invariant. If any of those mismatch with the C side, it breaks. Those invariant need some non trivial knowledge of rust to understand

View on HN

Is there an example of what you're describing?

There’s a recent drama where the Rust folks asked some people to clarify some of the semantics of some of the filesystem APIs, and this request wasn’t taken well. There’s been a bunch of hn threads about it.

like which?

I apologize, I am on my phone, so rather than curating links, check out https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu..., most of which are about this situation.

not sure if this is what the op referred but like this one https://news.ycombinator.com/item?id=41450347

didn't find threads that regarding "clarify APIs semantics", but kernel docs are indeed not in a very good condition. Since C does not provide same level of soundness that Rust does, there are many hidden traps.

asahi developer had a good discuss about this https://threadreaderapp.com/thread/1829852697107055047.html

This overall situation is, yes. And the stuff from Lina is related, thanks for also pointing that out.

About invariants generally: Rust wants to know when memory behind each pointer is immutable, or mutable by Rust only, or could be mutated by something else while Rust has a pointer to it. Rust also encodes which types can't be moved to another thread, and which pointers own their memory and need to be freed by Rust.

These are part of the type system, so they need to be defined precisely. The answer to these questions can't be just "it depends". If there are run-time or config-dependent conditions when the same data is owned or not or immutable or not, Rust has enums, unions and unsafe escape hatches to guard access to it.

Reply on news.ycombinator.com