Announcement

Collapse
No announcement yet.

Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel

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

  • #21
    "Sorry, I won't be able to start your OS today, Dave. Please run 'source $HOME/.cargo/env' and 'cargo install cbindgen', recompile your kernel, and try again"

    Comment


    • #22
      Originally posted by oleid View Post

      Considering the rest you listed, I suggest you have a look at what GTK did with its rust bindings.
      Well this is kind of it. Though Gtk and also the OpenGL bindings are certainly good, they were non-trivial to implement (i.e it wasn't a case of simply running bindgen). I don't think we should be adding this additional working onto the Linux kernel maintainers (who are already short of manpower as it is).

      Arguably Gtk was also designed with binding generation in mind. The Linux kernel was not.

      To be fair, the fact that crates.io even exists is generally evidence that binding generators aren't quite enough or we would simply have it inbuilt into the compiler to access C libraries directly.

      Comment


      • #23
        Originally posted by Danny3 View Post
        Ok, but how is the code written in Rust compared to C at the performance level ?
        Is Rust adding any safety checks at runtime that makes the code slower based on the assumption that the code is badly written ?
        There are some instances where Rust will do things like add runtime checking for array accesses where it can't statically guarantee that the index will always be in bounds. If that isn't desirable, then most of those functions or operations have an 'unchecked' variant.

        Comment


        • #24
          Originally posted by kpedersen View Post
          To be fair, the fact that crates.io even exists is generally evidence that binding generators aren't quite enough or we would simply have it inbuilt into the compiler to access C libraries directly.
          Not really. Creating bindings is not the only thing you've to do. You also have to integrate the library to the build system. There is no cross-platform standard to
          1. get all the dependencies of a C library you have to pass to the linker.
          2. to call the linker
          3. to build the C library if it is not available in the system (e.g. the bzip2 crate creates a static library and doesn't use the system lib).
          All that logic is available in the published crates. No need to do it yourself.

          Take meson for example. You'll find ready made wraps for lots of C libraries in their WrapDB, similar to crates.io

          Comment


          • #25
            Originally posted by onicsis View Post
            As long it's not a requirement to have rust compiler installed, to be able to properly build mainline kernel, guessing it's OK.
            I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++, is next to impossible in Rust - I've spent 2 months and failed, because the naive online examples don't work IRL because of the borrow checker which makes to whole thing a total mess, to this day I haven't seen a viable Rust solution, Mozilla's own Rust code from WebRender uses a JavaScript backend for this.

            Comment


            • #26
              Fun time. I'd think if my hardware are all supported by C code in kernel, I'd want it continue to be so. Don't convert any of them to Rust.

              New driver in Rust is fine as long as they are kernel module only. The mail kernel should be still be 100% C.

              I always think driver modules should be shipped in separate tarball from kernel source. They can of course stay in same git repo. The kernel source tarball now is quite big and every one building kernel has to download lots of driver source code that is not used at all.

              Comment


              • #27
                Originally posted by cl333r View Post
                I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++
                There are plenty of trees on crates.io. You can always fall back to raw pointers for such stuff and provide a safe wrapper. Nothing wrong with that.

                But I'm curious how you'd implement that in C++. Do you have a sample source of what exactly you have in mind at hand?

                Comment


                • #28
                  Originally posted by cl333r View Post
                  I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++, is next to impossible in Rust - I've spent 2 months and failed, because the naive online examples don't work IRL because of the borrow checker which makes to whole thing a total mess, to this day I haven't seen a viable Rust solution, Mozilla's own Rust code from WebRender uses a JavaScript backend for this.
                  If you really find it that difficult to think about a proper solution, just slap everything inside `Rc<RefCell<_>>` and call it a day. Or one step better, still without thinking, make all your structs internally mutable by slapping all mutable fields in `RefCell<_>` and just have all references as `Rc<_>`.

                  Comment


                  • #29
                    Originally posted by Pajn View Post

                    If you really find it that difficult to think about a proper solution, just slap everything inside `Rc<RefCell<_>>` and call it a day. Or one step better, still without thinking, make all your structs internally mutable by slapping all mutable fields in `RefCell<_>` and just have all references as `Rc<_>`.
                    RefCell doesn't fix much because it doesn't cancel the borrow checker, it's just that it moves from being detected at compile time to runtime, so your problem moves from not compiling to randomly crashing because of the runtime error.

                    Comment


                    • #30
                      Originally posted by cl333r View Post

                      RefCell doesn't fix much because it doesn't cancel the borrow checker, it's just that it moves from being detected at compile time to runtime, so your problem moves from not compiling to randomly crashing because of the runtime error.
                      True, RefCell should only be used as last resort. But if it doesn't help in your example case, how do you prevent undefined behaviour in similar C++ code?

                      Comment

                      Working...
                      X