Announcement

Collapse
No announcement yet.

Updated Rust Code For Linux Kernel Patches Posted

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

  • #31
    Originally posted by evasb View Post
    I don't know why the hurry to implement Rust if GCC-RS is not completed yet.
    Gcc-rs is not a prerequisite, there are plenty of contexts where the current LLVM-based tooling is sufficient (sometimes even preferred), and no reason for those to wait for the gcc-only contexts to be ready.

    Compiling Rust with Gcc is indeed an important milestone feature, but rustc_codegen_gcc will certainly achieve it earlier, with less bugs and in a more sustainable way than gcc-rs.

    Comment


    • #32
      Originally posted by uid313 View Post
      There are some problems with the Rust language:
      • Long compile times / slow build
      True, but not too different from C++. And it is getting faster.

      Originally posted by uid313 View Post
      • The resulting binary produced is large
      That depends on your dependencies. In-kernel usage will be different that desktop usage.


      Originally posted by uid313 View Post
      • You cannot declare async functions inside a trait
      That will be possible eventually.

      Originally posted by uid313 View Post
      • Libraries built using a async runtime are incompatible with other libraries built using a different async runtime
      No issue for kernel usage. And not a language problem, but a library problem.

      Comment


      • #33
        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 fact that I'm only hearing about this now goes to show how necessary it is to contribute to the kernel.

        Comment


        • #34
          Originally posted by cl333r View Post

          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.
          This problem has been raised and also has been substantially resolved. See the allocator returning errors now to make it possible to handle errors without panicking:

          https://doc.rust-lang.org/std/boxed/...method.try_new

          And it's not that the kernel has no problem detection code that results in the kernel panics. Such code exists and is no different than assert!() in Rust. The only difference is when it triggers. The user-space Rust assumes memory allocation never fails (or rather, it just assumes it can kill the process in such a case) which is understandable, but for kernel Rust it needs to handle memory allocation errors. As shown above, this problem has already been tackled and mostly (if not fully) resolved.

          Other logic errors are similar between Rust and Kernel C - you check them and then kill the system if something is wrong. You can't handle graciously all of the logic errors, that would be a huge burden on developers (and another way to compromise the kernel, if the mitigation code path is buggy). Again, that has nothing to do with Rust.

          Comment


          • #35
            Poke Poke. I'm seeing a post somehow having broken the layout of the page template.

            And almost of things written in rust is "unsafe". The "muuhhh rust is more safe bla bla bla" is just a fucking meme.
            Even if that were true, just having sum types (A.K.A. data-bearing enum)(A.K.A. first-class support for tagged unions) supported to the same level as product types (struct) would be a huge improvement on C.

            Rust also inserts panicking code instead handing the problem over to the user. I remember Linus raising this issue.
            Rust defaults to unwrap-based handling of code paths that invoke the panic! macro. It's a simple flag to the compiler to switch to abort-based panics and those can be tied into the kernel's existing panic handler as part of the build target definition.

            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.
            That's always been the standard library doing that. Just like with Linux having its own klibc instead of the userland libc, they're developing a kernelspace replacement for the parts of Rust's standard library that are only suited to userland. If anything, Rust is more suited to kernel development because the standard library is already split into core (stuff that doesn't require userland features like an allocator and threads and a filesystem and such) and std (the userland standard library).

            Comment


            • #36
              They will eventually put Firefox into kernel.

              Comment


              • #37
                Originally posted by xerom62 View Post
                The fact that I'm only hearing about this now goes to show how necessary it is to contribute to the kernel.
                There is more to it. Yes sparse extends C to allow detecting lock faults and other thing. The Linux kernel mainline has serous issues with compiler generated warning as well.

                Linux Kernel C is basically set of standards on top of C standard that result in something way less defective. This also means non mainline drivers for Linux kernel may not be up to what is mandated in C quality to submit code mainline. Heck not even close enough to go into Linux kernel staging section.

                The quality of the C code in the Linux kernel is not your average C code. Yes the high quality requirements of the Linux kernel C was one of the arguments against C++ code in the Linux kernel.

                Comment


                • #38
                  Originally posted by ssokolow View Post
                  Even if that were true, just having sum types (A.K.A. data-bearing enum)(A.K.A. first-class support for tagged unions) supported to the same level as product types (struct) would be a huge improvement on C.
                  Tagged unions is in fact supported by sparse. Rust has to do quite a bit to provide higher grade result than mainline Linux kernel stuff mandates on the Linux kernel version of C.

                  There is a downside of course to rust vs Linux kernel C. Linux kernel C you can build without sparse enabled for a fast build time and rust ends up being slower than this because you cannot turn the same amount of validation off. Yes this is true double side sword where the advantage on both side is also a disadvantage on both sides.

                  Everything is a trade off here. Rust is a lot better than general C code but the Linux kernel has a stack of standard on top if it C that makes it behavour not the same as general C code.

                  Rust in unsafe mode at this stage is still a slower build that Linux kernel C with sparse enabled so it better not be lower quality than using Linux kernel c with sparse enabled.

                  Some of the slow down with getting rust patches ready was the developer who started the idea of rust kernel modules in Linux having it pointed out all the different things sparce in fact checks for and that rust in the Linux kernel really could not be worse at any point with final binary that what the Linux kernel C standards would generate. So a higher bar to get over.

                  Yes those developer bringing rust to the Linux kernel are having a lot more work than make include system and call it a day due to there being such thing as Linux kernel C and that is what they have to be better than. This higher standard explains why its taking so long even that the developers wanting rust kernel modules are doing lots of work.

                  Comment


                  • #39
                    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.
                    Wherever did you get that BS from?

                    Comment


                    • #40
                      Originally posted by Wielkie G View Post
                      So what exactly does Rust do now when memory allocation fails?

                      Comment

                      Working...
                      X