Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Open Source Linux

Experimental Rust Support Patches Submitted to Linux Kernel Mailing List (theregister.com) 55

Posted by EditorDavid from the trusting-rust dept.
"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."
This discussion has been archived. No new comments can be posted.

Experimental Rust Support Patches Submitted to Linux Kernel Mailing List More

Experimental Rust Support Patches Submitted to Linux Kernel Mailing List

Comments Filter:

  • 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.

  • 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)

      by pavon ( 30274 ) on Saturday July 10, 2021 @11:02AM (#61569609)

      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.

      • It's using two different compilers to compile Rust. That is a hack.

        • 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, especiall

          • 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

            • There is no "transitioning to another compiler". Rustc is the front end, now with a replaceable backend.

              • 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.

            • 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.

              • 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.

                • *sigh* Why does gcc offer choice so that developers can use either front end or back end as they feel? You should talk to the gnu team about how decades of gcc development is "a hack". I am sure you can convince them of your viewpoint. As for other models like Clang/LLVM, their whole way of doing things is "a hack". Perhaps you should let all these programmers know of their deficiencies?

                  • 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.

                    • " 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.

                    • 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)

                      by amorsen ( 7485 )

                      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

                    • You misunderstood my point.

                      The reason they can't write another frontend for GCC is because the language has no specification.

                    • 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?

          • 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....

Slashdot Top Deals

Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. - Oscar Wilde

Close