Announcement

Collapse
No announcement yet.

Rust Bindings Are Being Worked On For Linux CPUFreq Drivers

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

  • #11
    Originally posted by rmoog View Post

    All this mental gymnastics just to not follow MISRA... grim
    Come back when you actually know MISRA's requirements.

    Comment


    • #12
      Originally posted by rmoog View Post
      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!"

      Comment


      • #13
        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?

        Comment


        • #14
          Originally posted by NotMine999 View Post
          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.

          Comment


          • #15
            Originally posted by NotMine999 View Post
            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.

            Comment


            • #16
              Originally posted by darkonix View Post

              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.)
              Last edited by ssokolow; 07 April 2024, 09:25 PM.

              Comment


              • #17
                Originally posted by NotMine999 View Post
                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.)

                Comment


                • #18
                  Originally posted by rmoog View Post

                  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.

                  Comment


                  • #19
                    Originally posted by vextium View Post

                    You seem to have a skill issue with Rust
                    Originally posted by Developer12 View Post

                    Come back when you actually know MISRA's requirements.
                    Originally posted by Developer12 View Post

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

                    Comment


                    • #20
                      Originally posted by darkonix View Post

                      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
                      Developed at the Georgia Institute of Technology, Rudra is a static analyzer able to report potential memory safety bugs in Rust programs. Rudra has been used to scan the entire Rust package registry and identified 264 new memory safety bugs.


                      CVEs (Common Vulnerabilities and Exposures) in Rust programs:
                      The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.


                      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

                      ​

                      Comment

                      Working...
                      X