Rust Bindings Are Being Worked On For Linux CPUFreq Drivers

[Developer12]

All this mental gymnastics just to not follow MISRA... grim

Come back when you actually know MISRA's requirements.

[Developer12]

nobody needs this

nobody asked for this

people filtered by C will invent a whole new language just so they don't have to run SonarQube, Bullseye, valgrind and gdb

Rust: "Look what they need just to mimic a fraction of our power!"

[NotMine999]

Is Rust being implemented in kernel sections that NEED the memory protections provided by Rust?

Or is Rust being implemented where it is EASIEST to implement ... so as to build up it's footprint within the Linux kernel?

[rmoog]

Is Rust being implemented in kernel sections that NEED the memory protections provided by Rust?

Or is Rust being implemented where it is EASIEST to implement ... so as to build up it's footprint within the Linux kernel?

Nah. As of Linux 6.6, the rust code is just 1-2 drivers and a metric ton of boilerplate to make it integrate with the kernel. I know because I've read it all.

[darkonix]

Is Rust being implemented in kernel sections that NEED the memory protections provided by Rust?

Or is Rust being implemented where it is EASIEST to implement ... so as to build up it's footprint within the Linux kernel?

The second. It is experimental support for modules.

[ssokolow]

Nobody asked for what exactly? Please be more specific.

Sonarqube, bulleyes and valgrind can not provide the exact same guarantees that the Rust compiler provides out of the box. Also they are optional tools that not everyone uses. Still probably they can be used with Rust too. Valgrind surely, not fully sure if the others are compatible with Rust.

GDB is a debugger and can be used with Rust programs, same that with other languages. Not sure why you mentioned it.

SonarQube is a static analyzer system and, given that they already support 27 different languages, I imagine it won't be long before they add a backend that, at minimum, wraps `cargo test` for "unit tests", `cargo clippy` for at least a baseline level of "duplicated code, coding standards, code complexity, comments" and `cargo-audit` for security recommendations.

"Bugs" would be handled by either `cargo test` or `cargo clippy`, since Rust's stance is "If it's unarguably a bug, fail the build. If it's probably a bug, have Clippy complain."

Code coverage may take a little longer since I recently saw the discussion on getting push-button coverage support in Cargo turn in a "let's let the ecosystem iterate a bit longer first" direction.

Bullseye is C++ code coverage, so more or less the same applies, but anything which supports coverage for LLVM Clang (i.e. no special compilation options or requiring options LLVM supports) should do fine. I've used kcov with Rust in the past.

Probably best to also throw in some fuzzing since, as the rust-fuzz trophy case shows, while security-vulnerable fuzzing hits are rare, no practical programming language can guarantee that coders haven't Implemented a reachable "ASSERT: This should be unreachable". (It's one of the reasons I'm willing to tie my code in an extra knot or two to do stuff like using slice patterns in match instead of indexing. The compiler can prove that slice patterns won't silently become reachable panics (or UB-invoking memory accesses in C) during refactoring.)

[ssokolow]

Is Rust being implemented in kernel sections that NEED the memory protections provided by Rust?

Or is Rust being implemented where it is EASIEST to implement ... so as to build up it's footprint within the Linux kernel?

Both, actually. They're adding support for writing drivers in Rust because that's where it's easiest to add, easiest to rip out if the effort is a flop, and will help the most because drivers are both the most numerous and the largest source of hard-to-test code. (If you encountered a Windows crash since Windows XP, it's almost certainly a buggy driver. That's part of why Microsoft has that signing requirement these days. They got fed up with getting blamed for junk drivers from third parties.)

[darkonix]

All this mental gymnastics just to not follow MISRA... grim

I'm not an expert in MISRA but it seems to assume many C shortcomings that simply can not happen in a language like Rust.

[rmoog]

You seem to have a skill issue with Rust

Come back when you actually know MISRA's requirements.

Rust: "Look what they need just to mimic a fraction of our power!"

ok junior

[Nth_man]

I'm not an expert in MISRA but it seems to assume many C shortcomings that simply can not happen in a language like Rust.

rmoog Mmm... It's not like Rust avoids errors:

Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates

https://www.infoq.com/news/2021/11/rudra-rust-safety/

CVEs (Common Vulnerabilities and Exposures) in Rust programs:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust/

If a sound static analyzer were deployed, we could make C code with zero memory safety issues and do it without the hack of compiler added runtime checks that Rust uses to claim memory safety. The aviation and nuclear power industries have been doing this for years. It is a shame that no one is willing to follow their lead and the wider community instead pursues new languages when what it actually needs is better tooling, which at present only exists for C (and C++ if you don't insist on having a formally verified compiler). Those new languages do not have such tooling and need it to reach parity with what is possible with C when using tools like sound static analyzers and formally verified compilers. :/
-- ryao on https://www.phoronix.com/forums/foru...35#post1385835