Klint: Compile-Time Detection of Atomic Context Violations for Kernel Rust Code

Re:Klint: Compile-Time Detection of Atomic Context Violation... by bonzini on Saturday March 18, 2023 @10:42AM (#35209492)

It's here: "People familiar with paradigms in Rust might also wonder if a token type, or some possible context and capabilities extension might help with this, but unfortunately it would not help this scenario. You can't do negative reasoning with token types thus a token-based approach would require almost all functions to carry tokens in their signatures".

In other words, arguments and the type system can be used to tell a callee what it can do, but not what it cannot do.

[ Parent | on HN ]

Re:Klint: Compile-Time Detection of Atomic Context Violation... by tialaramex on Saturday March 18, 2023 @12:30PM (#35210457)

I'm not convinced that "almost all functions carry tokens in their signatures" is a disaster given the desired result. I'd like to read more about why this way forward was rejected.

If I am trying to call X and I need a CanSleep token but I haven't got one, this prompts me to investigate why I haven't got one. Oh! I gave my CanSleep token to this Spin Lock. Why did the Spin Lock need my CanSleep token? Ah, because sleeping while holding a spin lock is death, that makes sense. I can get my CanSleep token back but only by releasing the spin lock, however I need this spin lock. Hmm. Aha! I should re-factor this code so that I just remember we need to call X, and I ensure I do it right after I have released the Spin Lock and retrieved my CanSleep token. Excellent.

[ Parent | on HN ]

Re:Klint: Compile-Time Detection of Atomic Context Violation... by bonzini on Saturday March 18, 2023 @05:25PM (#35213253)

It's not a disaster, it's quite inconvenient though and the effect would be the same as the lint that the article discusses.

[ Parent | on HN ]

Re:Klint: Compile-Time Detection of Atomic Context Violation... by tialaramex on Saturday March 18, 2023 @10:35PM (#35215430)

Can the inconvenience be mostly dissolved by a proc macro though?

Leveraging the type system scales better than ad hoc lints. Maybe later we need to keep track of several tokens, Rust has no problem making a Vec<CanSleep> and will optimise that exactly the way you expect (it's just a counter, the CanSleeps don't need storing anywhere) likewise a [Option<CanSleep>; 4] is just four bytes to track whether each element is None or Some(CanSleep).

[ Parent | on HN ]