Announcement

Collapse
No announcement yet.

Linux Developers May Discuss Allowing Rust Code Within The Kernel

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

  • #21
    Originally posted by szymon_g View Post
    so... when will Python be allowed in?
    Well, it already is (sort of) in a number of the tooling and profiling directories (but those are not part of the running kernel)..

    Comment


    • #22
      Originally posted by CommunityMember View Post

      Some of the biggest (in terms of shipped numbers) vendors uses LLVM for their kernel. Historically there have been a number of gcc-isms that have entered the kernel (which was itself badness), but at this point the gcc-isms have been eliminated, and various test infrastructure prevents new ones from getting into the kernel.

      And more than once LLVM compiled code correctly that GCC failed miserable on. All compilers have specific issues, but what, exactly, are the issues in your alleged can?
      Well, first you are talking about Clang(Compiler) not LLVM(Virtual Machine aka JIT) and no vendor provide kernel level uses for LLVM, only Clang.(not trying to be an ass just putting terminology straight).

      Second Clang/LLVM QA is very questionable at best which is why most vendors have private forks/specifically tested releases and don't rely on upstream Clang(at least APPLE for sure).

      Third, there is no such thing as "gcc-isms", GCC actually support GNUC-version that have very specific differences with C-version(the ISO version) while Clang mostly support only ISO(hence the issues), additionally through the years GCC gain some extra non-standard glue that was requested from kernel devs at some point(i guess at the time was necessary) and GCC still have all of those, the fixes are done at kernel code level(check the patches).(not trying to be an ass just putting terminology straight).

      Now my issues:

      1.) LLVM/Clang tend to accept huge patches upstream randomly(i honestly don't understand the process if there is any) that are completely broken with an astonishing frequency, to the point that my daily builds has become bi-weekly simply because some patch utterly broke LLVM either at compile or runtime every couple of days.

      2.) I've been keeping an eye on a full Clang Gentoo build but i honestly always end up with a unbootable broken system more often than not depending the clang version but well someone told me migration from 9 to 10 was not that bad outside of some userspace app sigsegv due something broken on libc++ or lld(don't remember) but my GCC Gentoo has never broken like that and i respect that.

      3.) Clang has lost a lot of its speed advantage against GCC 10 and OpenMP is still a mess, so i'm not so sure it worth the effort anymore.

      4.) up to C++14 clang had the upper hand in features but GCC got its act together and now is kinda reverse most of my C++17/20 compile perfectly in GCC but Clang10/git(at least a month ago or so, i have all days merged with this quarantine thing) gives up. This last don't apply i guess since i'm not sure this segment of the common code affects rust side in llvm

      Don't get me wrong, Clang can be a good compiler depending the use and i love its tooling and use them everyday but i simply don't trust it enough to stich something depending on LLVM inside the kernel, which is a huge red flag for me at least in this point in time.

      Comment


      • #23
        Originally posted by discordian View Post
        Maintainers dont want to learn any other language (thats the primary one, symbol mangling would be an actual technical reason). It would be enough if they would use some features of C++ to lose some ugly macro magic.

        Rust is particularly stupid for not following the dominant syntax type then name, but using something close but not similar to math statements.
        ie.:
        let i: u32 = "42".parse()
        Dominant doesn't means superior. Unless you really like most vexing parse.

        Comment


        • #24
          Originally posted by CommunityMember View Post

          That might be ideal. But do you trust that 100% of the developers in your organization write good code?
          In this specific case I do trust Linus to not merge bad code.

          Comment


          • #25
            Originally posted by Templar82 View Post

            In this specific case I do trust Linus to not merge bad code.
            This hasn't worked out well in practice because one person cannot possibly read millions of code and said person cannot scale and you have a bus factor of one. You need a more systematic solution. Not just one person however competent they may be.

            Comment


            • #26
              Originally posted by RahulSundaram View Post

              This hasn't worked out well in practice because one person cannot possibly read millions of code and said person cannot scale and you have a bus factor of one. You need a more systematic solution. Not just one person however competent they may be.
              Well it has worked very well in practice(not perfect) considering is probably one of the most stable projects around while been this massive, also Linus don't work alone, he has a whole tree of maintainers that filter a lot of the crappy code too.

              An honestly Rust claim a lot but Webrender still hangs randomly and no other project use it massively enough to say is battle tested and will avoid/fix well enough to be more trustworthy than the current system.

              Time will tell

              Comment


              • #27
                Originally posted by jrch2k8 View Post
                Third, there is no such thing as "gcc-isms", GCC actually support GNUC-version that have very specific differences with C-version
                That is the very definition of a gcc-ism. It is non-standard. And while for experimental purposes it might be useful under the appropriate "ACCEPT-NONSTANDARD" flag, it is ultimately broken. Get it into the standard, or abandon it. There is zero excuse to not standardize except it you intentionally want to be special in order to be special (in other words, you quite explicitly do not want to play well with others).

                Comment


                • #28
                  I saw the comments of "write good C code" but the whole point of Rust is that even with great coders, eventually your code will do something with memory that you never expected. If you hate seeing memory errors then maybe you'd like to hear what they have to say.

                  Also, the Rust compiler is amazing.

                  Comment


                  • #29
                    It is cool that Rust helps people write better code, hopefully. However I think if Rust code can be translated to C by automated tooling, then the C code will have better chance to be accepted to Linux kernel. Personally I like many ideas of Rust but the syntax looks like C + perl mixture to me sometimes. Maybe not easy to maintain in the long run. Of course just my remote impression.

                    Comment


                    • #30
                      Originally posted by discordian View Post
                      Rust is particularly stupid for not following the dominant syntax type then name, but using something close but not similar to math statements.
                      ie.:
                      let i: u32 = "42".parse()

                      I don't understand your objection.... I really like the `name:type`syntax, as this enables type inference (`let v = "hello world"`) and prevents namespace collisions between types and variable names. `"42".parse()` feels very natural coming from an OO background (which is the dominant form of programming).

                      Comment

                      Working...
                      X