Experimental Rust Support Patches Submitted to Linux Kernel Mailing List (theregister.com) 55
"The Rust for Linux project, sponsored by Google, has advanced..." reported the Register earlier this week:
A new set of patches submitted to the Linux kernel mailing list summarizes the progress of the project to enable Rust to be used alongside C for implementing the Linux kernel. The progress is significant.
- ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports...
- Overall, "the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules," continued project leader Miguel Ojeda, a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux...
There is substantial support for the project across the industry. Google said in April "we feel that Rust is now ready to join C as a practical language for implementing the kernel" and that it would reduce the number of potential bugs and security vulnerabilities. Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of "efforts to move the internet's critical software infrastructure to memory safe code," under the project name Prossimo. The ISRG is also the nonprofit organisation behind Let's Encrypt free security certificates. Ojeda also mentioned that Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust." Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.
More detail is promised at the forthcoming Linux Plumber's Conference in September. In the meantime, the project is on GitHub here.
"In addition, we would like to announce that we are organizing a new conference that focuses on Rust and the Linux kernel..." Ojeda posted. "Details will be announced soon." And for context, the Register adds: Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is "getting to the point where maybe it might be mergeable for 5.14 or something like that."
- ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports...
- Overall, "the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules," continued project leader Miguel Ojeda, a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux...
There is substantial support for the project across the industry. Google said in April "we feel that Rust is now ready to join C as a practical language for implementing the kernel" and that it would reduce the number of potential bugs and security vulnerabilities. Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of "efforts to move the internet's critical software infrastructure to memory safe code," under the project name Prossimo. The ISRG is also the nonprofit organisation behind Let's Encrypt free security certificates. Ojeda also mentioned that Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust." Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.
More detail is promised at the forthcoming Linux Plumber's Conference in September. In the meantime, the project is on GitHub here.
"In addition, we would like to announce that we are organizing a new conference that focuses on Rust and the Linux kernel..." Ojeda posted. "Details will be announced soon." And for context, the Register adds: Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is "getting to the point where maybe it might be mergeable for 5.14 or something like that."
We will see how well that goes (Score:2)
Of course, the things the Rust fanatics believe in will mostly not materialize, because they are a pure fantasy. See "There is no silver bullet" and follow-ups. There will be some advantages, but it is entirely unclear whether they will outweigh the disadvantages. The real problem I see is that Rust has nowhere near the stability, support and assured long-term availability of C and GCC. The other real problem is of course mediocre and bad coders that mistakenly believe Rust will magically "fix" them.
Re: (Score:3)
Don't worry, they have also created a Code of Conduct that does not allow you to criticize them.
Re: (Score:2)
You can't spell Trust without Rust.
Re:Silly (Score:5, Insightful)
Buffer overflows are easy to avoid in C with a little discipline. If you lack that sort of discipline you probably won't do well as a kernel developer.
Ah, the "A disciplined programmer never makes mistakes" approach to software development. How very... 1990s of you.
Rust does a little more than preventing buffer overflows and memory allocation disasters. Sadly a lot of "disciplined" programmers are coding buffer overflow errors and memory allocation disasters even as I sit here typing this. All that tightly constrained languages like Rust can do is reduce the number of screw-ups perpetrated by "disciplined" programmers, they can't stop them completely. I'll take that as a win for the moment.
Re: (Score:3)
The problem is few people are fluent in C. They learn enough to get by. And that will make sure Rust code is just as buggy.
Not really. If you aren't fluent in Rust, its compiler is going to keep slapping you down with error messages until you either learn the concepts or give up.
Re: (Score:2)
Just like people learn from crashes how to code C safely?
I'm sure they really get the lesson hammered home when their crashes and bugs cause billion dollar security exploits like Heartbleed.
Unfortunately, there are hundreds of thousands of C developers and not enough money in the world's economy to dish all out those lessons.
Re: (Score:1)
What's wrong with Ada or SPARK then? Why make Rust?
Disclaimer: I have programmed in Ada - I'm not a hater. It does help reduce the risk of errors. It was designed for that.
Re: (Score:2)
I'm not sure. They do address the same niche.
Maybe one thing is that Rust probably goes farther into the compile-time verification vs runtime verification, so it might have higher potential performance.
Another might be that with the exception of Python, to get ahead in this world your language has to feature curly braces just like C. (And despite its success, the main objection to Python always seems to be its brace-less syntax.)
Re: (Score:2)
Re: (Score:2)
I would have thought that a static analysis tool could find anything leaky hidden in C
Many people don't use static analysis tools or don't use them properly. Many programmers don't even enable -Wall and -Wextra in their makefiles.
You are running code written by these people, whether you like it or not.
By putting the checks in the compiler, Rust makes it harder to bypass them.
Re: (Score:2)
Buffer overflows are easy to avoid in C with a little discipline.
I agree with you and it doesn't even require discipline, it just requires knowing how to do it.
This Rust code is aimed entirely at driver development. It's not going to replace the scheduler, which was written by skilled programmers. Drivers are often written by very poor programmers, and admitted to the kernel because having a poor driver is still better than having no driver at all. So there's a reasonable chance Rust in the kernel will result in better kernel code overall.
Re: (Score:1)
I agree with you and it doesn't even require discipline, it just requires knowing how to do it.
Ah yes, the ol' "never making mistakes just requires knowing how to do it" argument.
Seriously I don't understand what has Rust haters all up in arms over this. Why does it offend you so bad that a project you don't even maintain is using a programming language that you don't even care about?
Go ahead, point to the places on the doll where Rust touched you...
Re: (Score:2)
> Drivers are often written by very poor programmers
Where do they live, Elbonia? Coding in Rust is not going to help with that.
Re: (Score:1)
race conditions or corner cases in the vmm. Coding things in Rust is not going to improve the situation.
Within the kernel itself you're talking about data races. Data races are literally impossible in rust. The ownership model guarantees it.
Re: (Score:2)
"Buffer overflows are easy to avoid in C with a little discipline"
You guys are going to be left behind. I'm old, I've been programming in C for decades, but this is "planes are easy to fly without electronics with a little discipline" .. you're well on your way to being an anachronism. And anachronisms are free to believe they're right until the cows come home, but it won't matter because nobody the world has moved on and nobody is listening anymore. The improved safety lets employers not play russian roule
messy (Score:2)
This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation,
That's a bit of a hack.
Re:messy (Score:5, Insightful)
No it isn't. All compilers are designed with a front-end that parses the language to an intermediate tree representation and does high-level optimizations, and a back-end that does low-level optimizations and generates assembler. GCC already shares it's backend across multiple languages (c,c++,objc,fortran,ada,go). In the past, rust used LLVM for it's backend, now it is gaining the option to use GCC's backend instead. This will increase the number of architectures that rust can compile on, as well as eliminate the need to have LLVM when building the kernel (although the kernel does now compile with clang+LLVM if you wish).
This isn't generating C code from rust, then compiling that if that is what you are thinking.
Re: (Score:2)
It's using two different compilers to compile Rust. That is a hack.
Re: (Score:2)
Like pavon says, there's the front end, intermediate representation, and the back end. That's not "two different compilers". They're different stages of the compiling process, and it has been that way for decades. The front ends, like rustc, generate intermediate representation. Before, it only generated LLVM IR. Now it also generates the intermediate representation(s) used by GCC.
Compilers, especiall
Re: (Score:2)
You REALLY don't seem to understand how compilers work
I assure you I do understand how compilers work.
You are talking about a language that is not well defined enough to have more than one compiler. Unfortunately that compiler isn't mature enough to have many backends. So you have to start compiling with one compiler (or one compiler suite, if that makes you happier), then transition over to another compiler (or compiler suite) to finish the job.
That is a hack. I can run a hose from the drain of my kitchen sink into my bathtub, and it will effectively remove a
Re: (Score:2)
Re: (Score:1)
You're explaining how it works. I never disagreed with you.
I said it was inelegant, a hack. And everything you've said supported me.
Re: (Score:2)
You are talking about a language that is not well defined enough to have more than one compiler. Unfortunately that compiler isn't mature enough to have many backends. So you have to start compiling with one compiler (or one compiler suite, if that makes you happier), then transition over to another compiler (or compiler suite) to finish the job.
It is no more of a "hack" as using a different frontend for GCC [gnu.org] which has been done for decades. gcc is split into a frontend and backend; it is not mandatory to use gcc frontend to use the backend.
Re: (Score:2)
It's definitely a hack. Why did they build it like that? It's a workaround for the problem that there is no specification for Rust.
Re: (Score:3)
Re: (Score:1)
You completely ignored my comment, and went off writing a post on a different topic. I'll repeat it again to give you another chance to digest my wisdom and understand it:
" Why did they build it like that? It's a workaround for the problem that there is no specification for Rust."
If you want to address that, go ahead.
Re: (Score:2)
" Why did they build it like that? It's a workaround for the problem that there is no specification for Rust."
Also you: "I assure you I do understand how compilers work."
I suggest you brush up on how compilers work [wikipedia.org] as you do not seem to understand.
Re: (Score:1)
I've written compilers.
Do you want to attack another strawman, or do you want to try again? You've failed twice, I'd like to see you fail a third time.
It's a workaround for the problem that there is no specification for Rust.
Let's see what answer you have this time.
Re: (Score:2)
It is a workaround for the fact that the Rust compiler developers do not want to write a code generator.
There are dozens of code generators. What would be the point of writing another one? It will take years to get it to GCC or LLVM quality.
If someone does an independent Rust compiler, it will almost certainly be using an existing code generator. Because code generators, especially for x86, are hard -- and you cannot ignore x86 if you want a new language to succeed.
That decision has nothing to do with speci
Re: (Score:2)
You misunderstood my point.
The reason they can't write another frontend for GCC is because the language has no specification.
Re: (Score:2)
Do you want to attack another strawman, or do you want to try again? You've failed twice, I'd like to see you fail a third time.
Bahahaha. And yet you asked an extremely idiotic question that someone with an inkling of compiler knowledge would never ask. Sure I believe you . . not. Are the same guy that I had to tell to read ruling multiple times and could not be bothered to read a ruling that said exactly what I said it said?
Re: (Score:1)
No it's not. You REALLY don't seem to understand how compilers work. https://rustc-dev-guide.rust-l... [rust-lang.org] Like pavon says, there's the front end, intermediate representation, and the back end. That's not "two different compilers". They're different stages of the compiling process, and it has been that way for decades. The front ends, like rustc, generate intermediate representation. Before, it only generated LLVM IR. Now it also generates the intermediate representation(s) used by GCC. Compilers, especially multilanguage compilers, do not go straight from source to assembly. They are designed so that no matter the language, by the time it gets to generation of assembly, they all can benefit from the same checks and optimizations, because it would be stupid not to reuse the implementation. The whole POINT of GCC and LLVM is that you're supposed to leverage them so that you can just focus on the front end. It's not a hack - they are all designed that way.
If a leveraging of the "front end" is the goal yet the "front end" does not take fully into account the existing "back end" scope, yet still creates code "optimized" to bridge the two? It's kind of hack. Consider that refactoring and even initialization of an expressed memory instance can happen elsewhere in a running program. Which is why C assumes that your function knows what will/has been done with memory as it is assumes you know....
Re: (Score:3)
Yes, and is needed (today) only for those that insist that gcc must be used to compile the kernel,
People insist that GCC must be used to compile the kernel because LLVM won't compile the kernel for their platform. It's not insistence so much as "the only thing that will work."
Re: (Score:1)
Re: (Score:2)
It is C.
Comment removed (Score:5, Interesting)
Re: (Score:2)
Which makes me wonder if Rust in Linux is as much about promoting Rust everywhere, more than improving Linux.
That might be the purpose of the Rust people. Fortunately Linus won't let it happen if it doesn't improve the kernel.
It seems reasonable that device drivers written in Rust would be higher quality, since drivers are often written by barely-competent programmers to begin with.
Re: (Score:2)
Re: (Score:1)
Yes, the pointed-to object is cleaned up when the `box` itself leaves scope, but that doesn't require reference counting.
Re:Google future/fuchsia (Score:2)
Re: (Score:3)
Re: (Score:2)
meanwhile Google is supposedly ditching the Linux kernel for Fuschia/Zircon as the basis for Android in the next few years
One group at Google wants too ditch the Linux kernel for Fuschia. It's still a long way off from happening.