Announcement

Collapse
No announcement yet.

Rust Porting Begins For Intel's "e1000" Linux Network Driver

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

  • Weasel
    replied
    Originally posted by darkonix View Post
    Basic used the let keyword to assign too. That was in the late '60s. It was not a functional language, no sir.
    Basic was like in all caps so that already makes it a cringe language syntax-wise.

    Leave a comment:


  • Weasel
    replied
    Originally posted by reba View Post
    Since the introducion of "let" (and "const") you should never use " var" anymore in JavaScript as those are block-aware, which "var" is not and thus is garbage. Pretty docs for more info.
    Yeah, but the point was that they used a sane keyword first, "var". Of course they couldn't break backwards compatibility, so they had to use another keyword later.

    Originally posted by reba View Post
    Also using let/var/val is important as it is a variable declaration which should not be mixed/overloaded with a variable definition.
    Writing a definition/initialization/assignment "i = 1;" without a specific declaration "dcl int i;" is just bad code and a programming language that allows this is a bad code language. Always use declarations, even bash does this (keyword "local") and IntelliJ complaining to you if you don't do it (rightfully so)
    I agree, and here C++ has it the best: declare it with the type, or "auto". Not both. Not more than necessary.

    Leave a comment:


  • Weasel
    replied
    Originally posted by bug77 View Post
    Go has worked hard to do away with any unnecessary cruft. And even in Go, you still have to write var i int. Seriously, it's just a style choice, let it go people...
    every language has quirks, if you adapt, you wouldn't be bothered if you had to declare variables using [<###>].
    At least Go uses a sane sounding "var" instead of "let", instant respect points compared to Rust.

    Leave a comment:


  • silmeth
    replied
    Originally posted by ultimA View Post
    Really? A syntax discussion? Please stop. Also, just because one particular user picked on some irrelevant detail, don't generalize that to all critics.
    My gripe is with the unsafes. But to be more specific, it's not just that there are lot's of unsafes, but many are long blocks, spanning 20-50 lines. Just to be followed by yet another unsafe block directly afterwards. Unsafe is supposed to make it easier to locate potentially problematic code. This is not helping much at all in the case of the e1000 driver. If this is how most drivers (will) look in Rust, then the porting effort is questionable. If this is not how most drivers in Rust would look, then the wrong driver was picked to demonstrate the benefits.

    EDIT: Only hope is that some of these can vanish as more and more parts of the kernel framework get ported to Rust. But then effort should currently be concentrated there, as this is only barely useful for drivers in the current form,
    I mostly agree with this, with two remarks:
    1. as the author of the driver notes, “There are many places to use the C bindings directly for now.” – as I understand they are just starting to write the Rust abstractions needed to make those unsafes go away in the main driver code (almost all those unsafe blocks call directly to C FFI bindings);
    2. unsafe Rust is still better than C in that all the non-unsafe operations (ie. everything outside of raw pointer dereferences, unsafe functions calls, and few others rare things) are still fully type-checked (you can’t ignore result from function, use incompatible numeric type, cause UB by signed integer overflow…), including all the borrow checker verification (all the references are still checked) – so it’s still much more strongly checked code.

    As Rust-for-Linux folks noted – the goal is to have all kernel abstractions hidden behind, whenever possible, safe Rust abstractions (and when impossible, unsafe but still idiomatic Rusty ones) so that the drivers written in Rust don’t interface directly with C at all. So yeah, I agree this e1000 driver is not a very good Rust showcase for now.
    Last edited by silmeth; 20 September 2022, 08:01 AM.

    Leave a comment:


  • NobodyXu
    replied
    ultimA I didn't read the source code, but I think the reason for this is that the driver is still in its very early days, the devs are probably working on getting the basics done.
    They will probably change it quickly after that as they might be still doing prototype.

    Leave a comment:


  • silmeth
    replied
    Originally posted by luno View Post

    Direct Rendering Manager
    Asahi Lina writes the Apple M1 GPU driver in Rust and has almost reached rendering (initializing the GPU and sending commands to it work already). For this work, they made some Rust-side infrastructure needed to make this driver. So when it gets merged, DRM will have initial Rust support.

    It’s not a port of the whole subsystem – that’s not the goal with any subsystem in the foreseeable future – but it has the initial bindings needed by new DRM drivers to be written in Rust done. See https://github.com/AsahiLinux/linux/...ust/kernel/drm
    Last edited by silmeth; 20 September 2022, 07:36 AM.

    Leave a comment:


  • ultimA
    replied
    Really? A syntax discussion? Please stop. Also, just because one particular user picked on some irrelevant detail, don't generalize that to all critics.
    My gripe is with the unsafes. But to be more specific, it's not just that there are lot's of unsafes, but many are long blocks, spanning 20-50 lines. Just to be followed by yet another unsafe block directly afterwards. Unsafe is supposed to make it easier to locate potentially problematic code. This is not helping much at all in the case of the e1000 driver. If this is how most drivers (will) look in Rust, then the porting effort is questionable. If this is not how most drivers in Rust would look, then the wrong driver was picked to demonstrate the benefits.

    EDIT: Only hope is that some of these can vanish as more and more parts of the kernel framework get ported to Rust. But then effort should currently be concentrated there, as this is only barely useful for drivers in the current form,
    Last edited by ultimA; 20 September 2022, 07:29 AM.

    Leave a comment:


  • jacob
    replied
    Originally posted by Volta View Post

    So, there's 'auto' keyword already used in those languages or what? If no, then there's no explanation why it cannot be used instead.
    Let has been used literally for decades including in ML. "Auto" in this sense exists only in C++ (there is a little knowm "auto" in C but it's something else entirely). Rust just followed long established terminology.

    Leave a comment:


  • Raka555
    replied
    fucking virus ...

    Leave a comment:


  • luno
    replied
    Originally posted by uid313 View Post
    Cool!

    What driver or subsystem of Linux would you like to see ported to Rust?
    Direct Rendering Manager

    Leave a comment:

Working...
X