Linux 6.1-rc1 Released With Rust Now In The Kernel, MGLRU Added, New Hardware Support

[zboszor]

You cannot be serious.

I am dead serious. Critical sections are there, it may just be hidden by your favourite programming-language-of-the-day.

The contrary is true: It will make programmers understand multi-threading better than with C.

It seems that the proverbial programmers can forget that multi-threading is not a concept of a programming language.
It's a hardware concept and may have different semantics on different architectures.

What do you mean by "There won't be anyone who can improve Rust"? Improve what exactly?

The language specification, the compiler internals, porting to a new architecture, etc. Programming languages are not carved in stone tablets.

Someone had to implement the current state of Rust, knowing all the details and pitfalls.

If everyone just builds on the abstraction, at some point the ones that understood the gruesome details of CPUs and multi-threading will die and no one will be able to improve the abstract.

The "Rust is better than C" mentality is showing this exact symptom.

[dragorth]

You can always make that argument, when is enough usage of Rust going to be enough for the kernel?

To a lot of people that have actually programmed in Rust (and evidently in the kernel itself) Rust has already been used enough to demonstrate its worth. To me its kind of clear that its just Rust haters/doubters that are coming up with every excuse imaginable to complain about something they don't like.

In the very post you quoted, I pointed out the fallacy of assuming you can know my reasons.

You should really take me at my word. The problem with putting Rust in at the LTS release is now this version of the implementation is now supported, even when you find the API is not as useful as thought, or is actively hindering usage or one of the many other reasons that first passes of things in the kernel usually need work. This is not about hating anything, this is about the wisdom of forcing this support for a first pass of anything.

Rust in the kernel doesn't have enough usage to be sure this implementation is in the best spot for such a long term support. What is the LTS? 3years? More? That is my concern.

Not that Rust is in the kernel. I think we should have the option to have more things in the kernel geared toward proving correctness. SeL4 is a great example of what the right tools could do. It just shouldn't be a first pass in an LTS release.

I pointed at when it would be acceptable, the MGLRU patches have been in production in Chromebooks for quite some thime, so that there is actually usag and experience behind the patches. Rust has had one test use case for its example, and not used in production. Put Rust in the next release, so it isn't in the LTS, which will give more resources to making it correct, instead of needing to maintain the current solution and provide workarounds for it.

[MauganRa]

I am dead serious. Critical sections are there, it may just be hidden by your favourite programming-language-of-the-day.

It seems that the proverbial programmers can forget that multi-threading is not a concept of a programming language.
It's a hardware concept and may have different semantics on different architectures.

Critical sections are not being hidden at all by Rust. To accommodate different semantics aside from the default ones, Rust allows crucial parts of the code to be declared as unsafe (read: trusted). Also, there is always room for more language extensions to provide more gradual ways of loosening semantics. And in the end, also the Rust compiler will produce assembly code, which can be inspected, and the salty discussions between kernel developers and compiler writers will find another arena. Business as usual.

The language specification, the compiler internals, porting to a new architecture, etc. Programming languages are not carved in stone tablets.

Someone had to implement the current state of Rust, knowing all the details and pitfalls.

If everyone just builds on the abstraction, at some point the ones that understood the gruesome details of CPUs and multi-threading will die and no one will be able to improve the abstract.

Rust contains very few truly magical abstractions. The borrow checker is just a safety belt, because history shows that we humans are not good enough at writing code without memory safety and concurrency bugs.

[MauganRa]

Rust in the kernel doesn't have enough usage to be sure this implementation is in the best spot for such a long term support. What is the LTS? 3years? More? That is my concern.
...

I pointed at when it would be acceptable, the MGLRU patches have been in production in Chromebooks for quite some thime, so that there is actually usag and experience behind the patches. Rust has had one test use case for its example, and not used in production. Put Rust in the next release, so it isn't in the LTS, which will give more resources to making it correct, instead of needing to maintain the current solution and provide workarounds for it.

This is actually the reason why the current support for Rust in an LTS is unlikely to cause issues: there are exactly zero uses for it in production. No driver is even close to being production-grade. There is not a single line of code that could cause issues across the whole LTS period. Apart from that, only a small part of the Rust support, probably the essential and relatively uncontroversial parts, have been merged, to avoid having to deal with this particular problem.

Things will heat up after the Apple M1/M2 graphics drivers get merged, but users of these platforms are anyways unlikely to stick to LTS versions.

[dragorth]

This is actually the reason why the current support for Rust in an LTS is unlikely to cause issues: there are exactly zero uses for it in production. No driver is even close to being production-grade. There is not a single line of code that could cause issues across the whole LTS period. Apart from that, only a small part of the Rust support, probably the essential and relatively uncontroversial parts, have been merged, to avoid having to deal with this particular problem.

Things will heat up after the Apple M1/M2 graphics drivers get merged, but users of these platforms are anyways unlikely to stick to LTS versions.

That is an interesting point I haven't considered, however I would point out the LTS is a signal to businesses it is okay to use this kernel. In practical terms, this may be the only version of the Rust code used to bring up a new driver until the next LTS for a small developer, or a large business. These would presumably be the ones most interested in starting with Rust for their drivers.

Keeping the subset small is better than nothing, but it is still a risky move.

[Weasel]

I never claimed/wrote that Rust provides full protection from malice.

It provides zero.

If you had read the same scientific articles as I have, you wouldn't have written what you just wrote.

Ah another clown I guess. Link?

[marios]

Rust haters missing the point: It's pain to code in C and fun to code in Rust. Specifically if you do multithreading.

Rust lovers missing the point: It's fun to code in C and pain to code in Rust. Specifically if you hate verbosity.

Of course neither the quoted text, nor my answer is true. And both are missing the point. Which is, fun and pain are subjective.