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

  • reavertm
    replied
    Originally posted by 144Hz View Post
    Same thing on the desktop.
    s/the/a/
    There, I fixed it for you. You're welcome.

    Leave a comment:


  • cl333r
    replied
    Originally posted by oleid View Post

    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?
    You can't create an acceptable implementation with raw pointers, I tried and failed (but don't recall exactly why because it was like 12-18 months ago), if you can provide a viable/usable (not demo) solution with raw pointers I'd be more than happy!

    There are crates that deal with trees, yes, but none which is dynamically (and) mutable at the same time. So here's a virtual code example of a dynamically mutable tree:
    Code:
    class Tag {
    vector<Tag*> children;
    Tag *parent;
    
    // and methods that would tolerate aliased mutability - which is forbidden in Rust. "Safe" blocks don't cancel the borrow checker.
    int CountSize() {
        if (size_ == -1) { // not counted yet, need to count and cache it
           size_ = count my size;
          // size_ also depends on something from children or parents so need to call also into
         // their mutable methods but this isn't allowed. Full Stop.
         // What's worse you can catch this only at compile time because you're using RefCell and what's even worse it might not get triggered
          // until it detects aliased mutability.
        }
    return size_;
    }
    So
    a) you should be able to call mutable (non-const) methods of children or parents from your node's methods.
    b) therefore it should never trigger a runtime error like RefCell does, which is why you can't use it because it's only a matter of time - as your code becomes larger it will start throwing runtime errors and you can't design your code around this.
    Last edited by cl333r; 11 July 2020, 04:30 PM.

    Leave a comment:


  • oleid
    replied
    Originally posted by kpedersen View Post

    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).
    The problem is that a C function signature alone does not tell you which contract you have to adhere to in order to use it correctly. If you're lucky, you'll find everything important in the documentation. But this is meta-information, which of course cannot be used automatically.

    Therefore, bindgen creates _unsafe_ functions, which is in rust-speak "programmer-checked" code.

    Additionally, there is another attempt to create safe interfaces to C++. But it is not entirely automatic. You have to define the interface manually.

    https://github.com/dtolnay/cxx

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • Pajn
    replied
    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<_>`.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • oleid
    replied
    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

    Leave a comment:

Working...
X