The Latest Progress On Rust For The Linux Kernel

[Azrael5]

What are the benefits in the integration of rust language into the kernel?

[Archprogrammer]

Which are the benefits in the integration of rust language into the kernel?

Well, for one it might improve Rust - not least by forcing the issue on multiple implementations.

But for the kernel itself - drivers are the obvious benefit. Both from a bug-standpoint, but also from a code-review/quality standpoint where _some_ issues with badly written C code won't be possible in Rust and this might (speculation) result in easier upstreaming of external driver written in Rust.

[tomas]

Not to me...

Why did this comment even get 1 "like"?
Was it the author himself perhaps? It's completely nonsense. That is not how the Rust borrow checker works. A 5 minute tutorial in Rust would have shown that. Hint: the Rust borrow checker is run at *compile time* not *run time*.

[oiaohm]

Why did this comment even get 1 "like"?
Was it the author himself perhaps? It's completely nonsense. That is not how the Rust borrow checker works. A 5 minute tutorial in Rust would have shown that. Hint: the Rust borrow checker is run at *compile time* not *run time*.

https://users.rust-lang.org/t/refcel...-runtime/52721

This is not 100 percent true that borrow checker in rust is 100% compile time only there are particular things with rust that are borrow checked at runtime. This does explain some of rust overhead with rust programs designed particular ways as they are triggering the runtime borrow checking. Most cases the program can be designed other ways in rust to avoid this.

[tomas]

https://users.rust-lang.org/t/refcel...-runtime/52721

Ok, fair enough. That appears to be a special case though. But I stand corrected.

[perpetually high]

Why did this comment even get 1 "like"?
Was it the author himself perhaps? It's completely nonsense. That is not how the Rust borrow checker works. A 5 minute tutorial in Rust would have shown that. Hint: the Rust borrow checker is run at *compile time* not *run time*.

I liked it at first because it sounded correct, then saw the corrections below and liked those. Then went back and unliked after your comment since it's obviously wrong information that I don't want to endorse (but did think he provided to the conversation). Which, there are some really smart people on phoronix. Preciate you guys explaining all that.

[mdedetrich]

https://users.rust-lang.org/t/refcel...-runtime/52721

This is not 100 percent true that borrow checker in rust is 100% compile time only there are particular things with rust that are borrow checked at runtime. This does explain some of rust overhead with rust programs designed particular ways as they are triggering the runtime borrow checking. Most cases the program can be designed other ways in rust to avoid this.

Sure but this is also somewhat misleading because you are using a RefCell, in other words you know that you are going to pay a runtime cost by using this abstraction. In C++ there are also abstractions which add runtime overhead but you know that only in this case you will get this overhead because you used this abstraction. This is what the whole "you only pay for what you use" mantra. Its not like the Rust compiler will silently insert runtime checks to satisfy the borrow checker, you are basically opt'ing into it.

If you don't use RefCell then you won't incur this runtime cost when Rust is doing its borrow checking. Its usually possible to refactor code that uses RefCel to not use RefCel by refactoring it into functions, since Rust's does compile time borrow checking analysis on the function level.

[oiaohm]

Sure but this is also somewhat misleading because you are using a RefCell, in other words you know that you are going to pay a runtime cost by using this abstraction. In C++ there are also abstractions which add runtime overhead but you know that only in this case you will get this overhead because you used this abstraction. This is what the whole "you only pay for what you use" mantra. Its not like the Rust compiler will silently insert runtime checks to satisfy the borrow checker, you are basically opt'ing into it.

If you don't use RefCell then you won't incur this runtime cost when Rust is doing its borrow checking. Its usually possible to refactor code that uses RefCel to not use RefCel by refactoring it into functions, since Rust's does compile time borrow checking analysis on the function level.

RefCell is not the only case either. The Oxide design of rust borrow checker include doing particular items at runtime. RefCell is one of the designed in runtime cases.

The reality is that Rust borrow checker was not design as compile time only. The rust borrow checker design to be a min runtime borrow checker were everything that it believes can be solved at compile time is not runtime checked. But there are cases around particular data structures where borrow checker has to work a runtime and that is part of rust design.

Yes you have a lot of people say that rust borrow checker does not have runtime parts this is false. Rust program will have runtime borrow checking if you use particular features that is the hard fact of the matter. Rust compiler at this stage does not have any warning flag options to show when you have used any of the options with runtime borrow checking this is kind of a weakness.

Please note one of the reasons why the Linux kernel stuck with C over C++ was to avoid the abstractions problem of adding extra runtime code. This is why it would be good for rust to have some extra compiler flags for inserted code issues.

Yes some of the examples people put up of rust code losing to C or C++ are in fact code that could be recoded to avoid using runtime borrow checker code so close the performance gap. Yes this would be good to be able to say put a build flag on have compiler say this is using runtime borrow checker in the following areas. Of course it might not be safe to remove the runtime borrow checking without doing even worse code on performance. Yes the reason why C/C++ might be winning in some of these cases is being thread unsafe and may other issues.

[IndioNuvemChuva]

https://users.rust-lang.org/t/refcel...-runtime/52721

This is not 100 percent true that borrow checker in rust is 100% compile time only there are particular things with rust that are borrow checked at runtime. This does explain some of rust overhead with rust programs designed particular ways as they are triggering the runtime borrow checking. Most cases the program can be designed other ways in rust to avoid this.

You are comparing apples to oranges here. The actual mechanism through RefCell does its "borrow checking" is not even close to that of the static borrow checker, so even calling it borrow checking is somewhat wrong to boot, and it is also much, much faster, on account of how it is implemented. On top of that, using it is offered as an explicit choice to users who wish to have a specific piece of data be "borrow checked" at runtime, for cases in which ownership rules can't be determined statically.

In terms of speed, RefCell does add one or two dozen instructions around resource acquisition and release points. And, for most applications, those acquisition and release points will be so sparse it will never be a real problem. However, in those applications they somehow turn out to be frequent, either by the nature of the procedure being implemented or, most likely, by the developer's unfamiliarity with the language and environment, they could always be replaced or rewritten at wish.

Asserting that "the borrow checker has a runtime component", then, is just plain wrong. The borrow checker runs entirely inside the compiler and that's it. Whatever access control mechanisms a developer decides to use after the fact are entirely their own choice, and those can, of course, range from no overhead at all, in the case they just decide for bypassing the compiler time checker with unsafe code, to very mildly expensive, in the case of wrapping a global structure around an RwLock or something, or hell, they could even write their own mechanism, if that's what they want.

[oleid]

The reality is that Rust borrow checker was not design as compile time only. The rust borrow checker design to be a min runtime borrow checker were everything that it believes can be solved at compile time is not runtime checked. But there are cases around particular data structures where borrow checker has to work a runtime and that is part of rust design.

Yes you have a lot of people say that rust borrow checker does not have runtime parts this is false. Rust program will have runtime borrow checking if you use particular features that is the hard fact of the matter.

Okay, I'm using rust for at least four years now and never come across any runtime borrow checking that was not opt-in, such as refcell. Do you have anything do back-up your claim?

Also, wasn't oxide designed after-the-fact and is not used within the compiler?