Announcement

Collapse
No announcement yet.

Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

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

  • #11
    Originally posted by archkde View Post

    Still it's a very large paradigm shift. All kernel code (which includes drivers btw, Linux is a monolithic kernel) was only permitted to use C for the entire history of Linux
    Not quite the case. Linux kernel always had some amount of assembly in addition to C. However it is true that adding Rust is a major change. Keep in mind however this is all experimental and being merged with the notion that the only way to kick the tires and really try it out is to merge it. I don't expect this to happen but kernel developers may yet decide that it wasn't worth it and pull back later.

    Comment


    • #12
      1. Linux doesn't use semver.
      2. Rust is not a breaking change, it's an addition.

      Comment


      • #13
        Originally posted by archkde View Post

        Linux does not use semantic versioning. The major version changes when the minor gets too big for Linus' taste. All releases may break the kernel ABI, and none may break the userspace ABI.
        It'd be pretty weird if kernel broke the userspace ABI lol

        Comment


        • #14
          Originally posted by RahulSundaram View Post

          Not quite the case. Linux kernel always had some amount of assembly in addition to C. However it is true that adding Rust is a major change. Keep in mind however this is all experimental and being merged with the notion that the only way to kick the tires and really try it out is to merge it. I don't expect this to happen but kernel developers may yet decide that it wasn't worth it and pull back later.
          Uh, that's quite nitpicking, Assembly is just an intermediary step. C code is turned into Assembly by the compiler. So is Rust code at one point, for that matter. Because that's how native code is made, you literally use your CPU's instructions, instead of one provided by a virtual machine, like JVM. So having inline ASM wasn't really a different language, more like a different level.

          Comment


          • #15
            Should merge only with GCC-RS completed and merged on upstream GCC.

            Comment


            • #16
              Hmh, would like to rewrite my 20 year old C driver for a industry infrared camera and flash I used for monitoring a chicken coop in Rust.

              Just to see what it's like if done in Rust. I didn't dally much in kernel code, but this sounds like something which could be done.

              Though, the chicken coop monitor and gate opener/closer long got replaced by more modern stuff by now which run on Linux out of the box.

              By the way, we thought it was a fox and wondered how got over/past the fence... It actually was a Hawk going after the Chickens in daylight.

              Comment


              • #17
                Originally posted by anarki2 View Post

                C code is turned into Assembly by the compiler...

                So having inline ASM wasn't really a different language, more like a different level.
                C code doesn't always gets turned into assembly, it just depends on the compiler

                We disagree on that view.
                Last edited by RahulSundaram; 21 June 2022, 02:57 PM.

                Comment


                • #18
                  Originally posted by anarki2 View Post

                  Uh, that's quite nitpicking, Assembly is just an intermediary step. C code is turned into Assembly by the compiler. So is Rust code at one point, for that matter. Because that's how native code is made, you literally use your CPU's instructions, instead of one provided by a virtual machine, like JVM. So having inline ASM wasn't really a different language, more like a different level.
                  At one level or another, every peice of code goes "mov eax ebx", thus it would make more sense if we consider two parts of one project to be in different languages based on their aesthetics. Another point is that if someone can read and write C, even kernel level C, they cannot necessarily do assembly that is worth the extra effort they put in.

                  Comment


                  • #19
                    Originally posted by archkde View Post

                    Use the async-trait crate for the first issue. The second issue is a bit annoying, but I think things settle on tokio nowadays.
                    It depends on what you are doing. Tokio is far from ideal for single threaded async. And not an option for microcontroller.

                    Comment


                    • #20
                      Originally posted by er888kh View Post
                      At one level or another, every peice of code goes "mov eax ebx", thus it would make more sense if we consider two parts of one project to be in different languages based on their aesthetics. Another point is that if someone can read and write C, even kernel level C, they cannot necessarily do assembly that is worth the extra effort they put in.
                      If we're pedantic about it, no, not really. 'mov eax ebx', or assembly, is a pnemonic that can be skipped for direct bytecode. If we're not pedantic, then we don't count middle steps as using the language, so inline assembly is technically using a different language.

                      Originally posted by archkde View Post
                      All releases may break the kernel ABI, and none may break the userspace ABI.
                      Just to add on this, pretty much all releases add new APIs of one or another kind, so minor would change in all releases except for LTS, which don't have a linear history compared to mainline anyway.
                      It doesn't really make sense at any level for the kernel.

                      Comment

                      Working...
                      X