Announcement

Collapse
No announcement yet.

Updated Rust Code For Linux Kernel Patches Posted

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

  • #21
    Originally posted by oiaohm View Post

    When it comes to the Linux kernel there is such thing as Linux kernel C.
    https://www.kernel.org/doc/html/late...ls/sparse.html

    Yes you have a static analyser with the Linux kernel that you have to add annotations to your C code so your C code is acceptable. Yes those annotations for sparse can at times make it tricker to take code from the Linux kernel and put them in a different OS that is general C kernel.

    Yes there are quite a few faults that you can code in general C that when you run builds with Linux with sparse on come build failures with the Linux kernel. So mainline Linux kernel C does not have the same list of failures as normal C and part because the Linux kernel C is extended.
    The mere fact that those hoops even exist for you to jump through, is a testament to C's shortcomings. I don't want tot talk down C, it has carried us for half a century. That in itself ensures it will be forever remembered - and it's not done yet, it's got at least a couple more decades of life left in it. But with half a century of hardware and software/compiler advancements, I'm not surprised it may be time to move on.

    Comment


    • #22
      Originally posted by oiaohm View Post
      But there is still the problem of needing C developers going forwards to maintain core parts and nothing of these changes so far will make that code more readable to developers who are skilled in rust but not C. Time will tell if rust long term for the linux kernel is a benefit or harm.
      The kernel is a vast project with many different areas that require specific knowledge, regardless of the implementation language. Nobody is skilled enough to touch everything, and most contributors are productive while understanding only a small subset. The same will be true for Rust contributors, they are likely to focus on particular subsystems. That doesn't reduce the amount of contributors to other C-only subsystems, this isn't a zero-sum game.

      Really I would have liked to see sparse the static checking program of the Linux kernel over C parts gain more and more ways to checking for faults in the Linux kernel version of C that rust forbids. Yes this would lead to more rust like annotation in the C code so making it simple for rust developer to understand the C code.
      The introduction of Rust doesn't stop other kernel hardening projects, there is a huge investment in Linux security, Rust is just one aspect of it.

      Comment


      • #23
        Originally posted by bug77 View Post
        Originally posted by intelfx
        This is simply due to the fact that the Rust standard library is always linked statically <...>
        It's actually because Rust statically links stdlib. <...>
        I believe this is exactly what I said?

        Comment


        • #24
          Originally posted by phoronix View Post
          Phoronix: Updated Rust Code For Linux Kernel Patches Posted

          ...Linus Torvalds is not opposed to it,...

          https://www.phoronix.com/scan.php?pa...t-For-Linux-v2
          Ferry is opposed to it.

          Comment


          • #25
            Originally posted by uid313 View Post
            There are some problems with the Rust language:
            • Long compile times / slow build
            • The resulting binary produced is large
            • You cannot declare async functions inside a trait
            • Libraries built using a async runtime are incompatible with other libraries built using a different async runtime
            And almost of things written in rust is "unsafe". The "muuhhh rust is more safe bla bla bla" is just a fucking meme.

            Comment


            • #26
              Originally posted by uid313 View Post
              There are some problems with the Rust language:
              • Long compile times / slow build
              • The resulting binary produced is large
              • You cannot declare async functions inside a trait
              • Libraries built using a async runtime are incompatible with other libraries built using a different async runtime
              • Slow build is mostly a perception because it builds all dependencies from sources rather than links binaries. If you let your C or C++ project to fully compile all those 3rd-party modules the build times will be an order of magnitude higher (especially for stuff like Boost).
              • This is true only for small or trivial projects which are often used to compare binary sizes. Rust links it's standard library statically. C and C++ usually links everything dynamically. For larger apps the difference is not that big. Static linking has a lot of pros (and certainly cons).
              • Yes, this is one of the most wanted feature. I think it's being worked on. You can though with `async_trait` but it uses boxing.
              • Many runtimes provide compatibility layers


              Rgds

              Comment


              • #27
                Originally posted by Mario Junior View Post

                And almost of things written in rust is "unsafe". The "muuhhh rust is more safe bla bla bla" is just a fucking meme.
                Not really. Unsafe code is isolated with `unsafe` keyword whereas the entire C/C++ app is unsafe. Most of things written in Rust and published on crates.io are just the opposite, e.g. safe.

                Comment


                • #28
                  Originally posted by uid313 View Post
                  There are some problems with the Rust language:
                  • Long compile times / slow build
                  • The resulting binary produced is large
                  • You cannot declare async functions inside a trait
                  • Libraries built using a async runtime are incompatible with other libraries built using a different async runtime
                  Rust also inserts panicking code instead handing the problem over to the user. I remember Linus raising this issue.
                  Also, did Rust solve its memory allocation behavior - when it fails to allocate memory to an object it shouldn't panic, the user should handle it graciously.

                  Comment


                  • #29
                    Originally posted by uid313 View Post
                    There are some problems with the Rust language:
                    • Long compile times / slow build
                    • This is because Rust has to compile every crate/library for some unknown reason. Would be nice to have a cache though...

                      Originally posted by uid313 View Post
                    • The resulting binary produced is large
                    This is because Rust pretty much statically links everything unlike C/C++ in where the standard library is supposed to be present in the system.

                    Originally posted by uid313 View Post
                  • You cannot declare async functions inside a trait
                  • Libraries built using a async runtime are incompatible with other libraries built using a different async runtime
                  What happened to threads?

                  Comment


                  • #30
                    Originally posted by uid313 View Post
                    [*]Long compile times / slow build
                    Indeed.
                    Originally posted by uid313 View Post
                    [*]The resulting binary produced is large
                    There are two reasons for that:
                    1. Crates are linked in statically. This doesn't change anything in the case of the kernel since it obviously doesn't use shared libs in C either;
                    2. The monomorphisation of generic code. My guess is that this won't affect the kernel much since it won't be using this d party generic code anyway
                    Originally posted by uid313 View Post
                    [*]You cannot declare async functions inside a trait
                    This issue is being worked on, although I don't know how far off it is atm
                    Originally posted by uid313 View Post
                    [*]Libraries built using a async runtime are incompatible with other libraries built using a different async runtime
                    This is moot in the case of the kernel. Being able to use async code sounds like an intriguing possibility but if it happens, there will be a kernel async runtime, period.

                    Comment

                    • Working...
                      X