Announcement

Collapse
No announcement yet.

Linux's VGEM Kernel Driver Being Rewritten In Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by ids1024 View Post

    Rust's compiler has been written in Rust for a long time. Though the earliest prototypes were in OCaml.

    But it does use LLVM for codegen.
    -

    Yes, Rustc is written in rust (Other rust compilers including mrustc and gcc-rs uses C++). However the usage of LLVM is why I was using the Google Go compiler example which does not use LLVM and uses Go entirely. This is technically feasible for Rust as well but probably not worth losing out on leveraging LLVM.

    Comment


    • #12
      Originally posted by Sethox View Post

      This is the sort of spreading news that makes me want to learn Rust myself, because then it's possible to contribute myself in the Linux Community (and beyond).
      Not saying it's not a good idea, but note that you can do that learning pretty much any language.

      Comment


      • #13
        Originally posted by Mario Junior View Post
        Rewrite rust in rust too.
        Bets Linux kernel's gonna be gradually rewritten in Rust.

        Comment


        • #14
          Originally posted by aht0 View Post
          Bets Linux kernel's gonna be gradually rewritten in Rust.
          I wouldn't bet for the whole kernel, but I certainly see most new drivers being done in Rust in the near/medium term.

          Comment


          • #15
            Originally posted by sinepgib View Post

            I wouldn't bet for the whole kernel, but I certainly see most new drivers being done in Rust in the near/medium term.
            Yep, and from that point, why gradually not do more?
            Rust bindings/support in such manner I'd really like to see in FreeBSD as well.

            Comment


            • #16
              Originally posted by sinepgib View Post

              I wouldn't bet for the whole kernel, but I certainly see most new drivers being done in Rust in the near/medium term.
              Given Asahi Lina's experience of it, I wouldn't doubt it.

              Comment


              • #17
                Originally posted by Sethox View Post

                This is the sort of spreading news that makes me want to learn Rust myself, because then it's possible to contribute myself in the Linux Community (and beyond).
                The book provided by the community is very good written - https://doc.rust-lang.org/book/

                Comment


                • #18
                  Originally posted by aht0 View Post
                  Yep, and from that point, why gradually not do more?
                  Rust bindings/support in such manner I'd really like to see in FreeBSD as well.
                  I see several ways it could end up in an incomplete migration:
                  - Friction with some more reluctant developers (not everyone is on board with Rust AFAIK), some of whom may be maintainers (so they have a call about whether or not Rust makes it into their subsystem).
                  - Some parts are simply not worth the extra effort, say, several architectures and drivers have had only minor bug fixes and corrections to fit interface changes for years. I don't think they will drop them only to avoid migrating them to Rust, as long as they don't get in the way of migrating the rest.
                  - Some parts may either be deemed too sensitive for a rewrite or it may simply not be that beneficial for that case to migrate to Rust (say, trivial code that you can really be sure has no memory safety/UB bugs).

                  I think stuff will be migrated on an as-needed (particularly buggy areas) and/or opportunistic (no need to keep doing new development in C) basis, rather than just go all in.

                  Comment


                  • #19
                    Originally posted by sinepgib View Post

                    I see several ways it could end up in an incomplete migration
                    I doubt there will ever be a 100% migration, but where appropriate, and resources are available, it might slowly happen...

                    - Friction with some more reluctant developers (not everyone is on board with Rust AFAIK), some of whom may be maintainers (so they have a call about whether or not Rust makes it into their subsystem).
                    They may have a call, but if they unreasonably restrict rust due to philosophical reasons they may find that others may end up being the subsystem maintainers.

                    - Some parts are simply not worth the extra effort, say, several architectures and drivers have had only minor bug fixes and corrections to fit interface changes for years. I don't think they will drop them only to avoid migrating them to Rust, as long as they don't get in the way of migrating the rest.
                    Rewriting just for the sake of rewriting into a different language is rarely justified. Many (older) ERP systems still have their existing COBOL code for which there is no reason to change, as it only has costs to do the work and to reverify the results. That does not mean that that COBOL code may not eventually get replaced, but it is rarely a priority as long as it just works as it always has.

                    - Some parts may either be deemed too sensitive for a rewrite or it may simply not be that beneficial for that case to migrate to Rust (say, trivial code that you can really be sure has no memory safety/UB bugs).
                    Some parts of the kernel will always be so low level architecture specific that assembly may be the best approach, but if the code is trivial, migrating to rust may be low hanging fruit that may be chosen precisely because it is trivial (starting simple is commonly considered a good approach (was not almost everyone's first C program "Hello World"?)).

                    Comment


                    • #20
                      Can somebody please clean-up the rusty corners of the kernel?

                      Comment

                      Working...
                      X