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

[jacob]

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.

[ultimA]

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,

[silmeth]

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

[NobodyXu]

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.

[silmeth]

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.

[Weasel]

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.

[Weasel]

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.

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.

[Weasel]

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.

[bug77]

What wasn't said in this thread (at least I didn't notice) this 'let' word is more helpful to compiler rather than humans. In this context it makes more sense.

Exactly. Straight from the official docs:

if let Some(x) = Some(123) {
    // code
} else {
    // something else
}​

Without let, it's hard for the compiler to tell it's dealing with a variable declaration here. And a keyword just for if (and while) would just be more confusing.

[zexelon]

Exactly. Straight from the official docs:

if let Some(x) = Some(123) {
// code
} else {
// something else
}​

Without let, it's hard for the compiler to tell it's dealing with a variable declaration here. And a keyword just for if (and while) would just be more confusing.

But for some reason this code style just feel so dirty!