zlacker

[parent] [thread] 1 comments
1. wokwok+(OP)[view] [source] 2022-10-02 15:30:09
>>>>> For GFP_ATOMIC, we could use preempt_count except that it isn't always enabled. Conveniently, it is already separated out into its own config. How do people feel about removing CONFIG_PREEMPT_COUNT and having the count always enabled?

>>>> No (Linus)

>>> As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that leaving it up to comments isn't enough.

>>> Do you have an opinion on the above?

>> This message. Ie. No. you can’t make everyone play by your rules. (Linus, grumpily)

> While I disagree with some of what you write, the point is taken.

> But I won't give up on Rust guarantees just yet, I'll try to find ergonomic ways to enforce them at compile time.

I mean, it doesn’t sound like he’s being petty or misunderstanding.

They want special rules (which won’t work) to do runtime checking for rust code. That seems weird, right?

Rust safety should be compile time. That’s the point…

I dunno, maybe I don’t understand what’s being said, but I don’t think Linus is particularly wrong here, even if it’s kind of shouty.

replies(1): >>oconno+ci
2. oconno+ci[view] [source] 2022-10-02 17:07:55
>>wokwok+(OP)
> Rust safety should be compile time. That’s the point…

Array bounds checks are one of the most important safety measures Rust takes, and those have to happen at runtime (if the optimizer can't prove they'll never fire). Similarly, locking types like `Mutex` of course do all their locking and unlocking at runtime, though they also use the type system to express the fact that they will do that.

[go to top]