Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday September 20, @05:04AM   Printer-friendly [Skip to comment(s)]

News and Advice on the World's Latest Innovations:

The Rust in Linux debate is over. The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1."

The Rust programming language entering the Linux kernel has been coming for some time. At the 2020 Linux Plumbers Conference, developers started considering using the Rust language for new Linux inline code. Google, which supports Rust for developing Android -- itself a Linux distro -- began pushing for Rust in the Linux kernel in April 2021.

As Wedson Almeida Filho of Google's Android Team said at the time, "We feel that Rust is now ready to join C as a practical language for implementing the kernel. It can help us reduce the number of potential bugs and security vulnerabilities in privileged code while playing nicely with the core kernel and preserving its performance characteristics."

It took a while to convince the top Linux kernel developers of this. There were concerns about non-standard Rust extensions being needed to get it to work in Linux. For instance, with the new Rust Linux NVMe driver, over 70 extensions needed to be made to Rust to get it working. But, Torvalds had told me in an earlier interview, "We've been using exceptions to standard C for decades."

This was still an issue at the invitation-only Linux Kernel Maintainers Summit. But, in the end, it was decided that Rust is well enough supported in the Clang -- the C language family compiler front end -- to move forward. Besides, as Torvalds had said earlier, "Clang does work, so merging Rust would probably help and not hurt the kernel."

[...] Now, Torvalds warns in this first release, Rust will "just have the core infrastructure (i.e. no serious use case yet)." But, still, this is a major first step for Rust and Linux.


Original Submission

Related Stories

It's Time to Stop Using C and C++ for New Projects, Says Microsoft Azure CTO 107 comments

Arthur T Knackerbracket has processed the following story:

Mark Russinovich, the chief technology office (CTO) of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.

Rust, which hit version 1.0 in 2020 and was born at Mozilla, is now being used within the Android Open Source Project (AOSP), at Meta, at Amazon Web Services, at Microsoft for parts of Windows and Azure, in the Linux kernel, and in many other places. 

Engineers value its "memory safety guarantees", which reduce the need to manually manage a program's memory and, in turn, cut the risk of memory-related security flaws burdening big projects written in "memory unsafe" C or C++, which includes Chrome, Android, the Linux kernel, and Windows. 

Microsoft drove home this point in 2019 after revealing 70% of its patches in the past 12 years were fixes for memory safety bugs due largely to Windows being written mostly in C and C++. Google's Chrome team weighed in with its own findings in 2020, revealing that 70% of all serious security bugs in the Chrome codebase were memory management and safety bugs. It's written mostly in C++.     

"Unless something odd happens, it [Rust] will make it into 6.1," wrote Torvalds, seemingly ending a long-running debate over Rust becoming a second language to C for the Linux kernel. 

This discussion was created by janrinok (52) for logged-in users only. Log in and try again!
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Insightful) by bzipitidoo on Tuesday September 20, @06:57AM (17 children)

    by bzipitidoo (4388) on Tuesday September 20, @06:57AM (#1272515) Journal

    It always seemed strange that the Linux kernel development stuck to C and wouldn't even use C++. It is evidently extremely hard to migrate a tool chain even the relatively small distance from C to C++. But then perhaps C++'s function name mangling, to support templates and all, made it a non-starter for kernels.

    Very impressive that another language has finally made it to this point. Sure hope this move can make libraries more portable.

    • (Score: 5, Insightful) by canopic jug on Tuesday September 20, @07:26AM (2 children)

      by canopic jug (3949) Subscriber Badge on Tuesday September 20, @07:26AM (#1272518) Journal

      Very impressive that another language has finally made it to this point. Sure hope this move can make libraries more portable.

      Culling and refactoring is needed more. Lately the kernel seems to be write-only and growing (bloating) by the hour. If that keeps up then it will eventually cross a threshold where it is too full of holes to deal with any more. Adding multiple languages to the mix just adds to that trouble and to the security-destroying problem of complexity [schneier.com]. There are also the social and legal problems that an additional language will bring with it. Those last two rather over lap.

      There are many definitions of an open standardsd but there is a substantial amount of common aspects. Perhaps the primary shared characteristics of open standard definitions are as follows, with the key point here being about the maintenance:

      • The standard is adopted and will be maintained by a not-for-profit organization with the ongoing development occuring on the basis of an open decision-making procedure available to all interested parties.
      • The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
      • The copyrights and patents possibly present - of (parts of) the standard are made irrevocably available on a royalty-free basis.
      • There are no constraints on the re-use of the standard.

      If I understand correctly, at least C is an open standard. It is maintained by a not-for-profit organization with the ongoing development occuring on the basis of an open decision-making procedure. Specifically the American National Standards Institute (ANSI), ISO/IEC JTC 1/SC 22/WG 14 of the International Organization for Standardization (ISO), and the International Electrotechnical Commission (IEC) handle C.

      There are a still a lot of questions about how Rust is maintained [rust-lang.org], especially since it is all on M$ GitHub at the moment. That is in spite of the sale itself and what M$ has been doing to GitHub since the sale. And given the fights over the CoC [rust-lang.org] and its subsequent abuse, further questions are raised about control, specifically, not just governance.

      --
      Money is not free speech. Elections should not be auctions.
      • (Score: 2) by janrinok on Tuesday September 20, @07:34AM (1 child)

        by janrinok (52) Subscriber Badge on Tuesday September 20, @07:34AM (#1272520) Journal

        It is unfortunate that the link to the roadmap that you provided doesn't seem to have been updated since 2021. I hope this doesn't indicate the way things are going...

    • (Score: 3, Interesting) by janrinok on Tuesday September 20, @07:29AM

      by janrinok (52) Subscriber Badge on Tuesday September 20, @07:29AM (#1272519) Journal

      It might also increase interest in Rust - I know that it was TMB's interest just before he left us. He used it to write several utilities for his own personal use and was keen to have it on his CV.

    • (Score: 5, Informative) by RamiK on Tuesday September 20, @07:44AM (5 children)

      by RamiK (1813) on Tuesday September 20, @07:44AM (#1272521)

      Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling.

      "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.

      "For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier.

      "C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."

      ( https://itwire.com/business-it-news/open-source/rust-support-in-linux-may-be-possible-by-5-14-release-torvalds.html [itwire.com] )

      --
      compiling...
      • (Score: 3, Insightful) by PiMuNu on Tuesday September 20, @05:23PM (4 children)

        by PiMuNu (3823) Subscriber Badge on Tuesday September 20, @05:23PM (#1272589)

        I don't know if I agree with all that stuff - but as someone who has coded in C++ for 20 odd years I think it is a bloated piece of ****.

        • (Score: 2) by RamiK on Tuesday September 20, @06:58PM (3 children)

          by RamiK (1813) on Tuesday September 20, @06:58PM (#1272616)

          I don't know if I agree with all that stuff - but as someone who has coded in C++ for 20 odd years I think it is a bloated piece of ****.

          Bear in mind Torvalds wrote Subsurface in C++ and continues to contribute and use it so he's just as much of a "there's a C++ library for that" victim as the rest of us.

          --
          compiling...
          • (Score: 3, Informative) by PiMuNu on Wednesday September 21, @11:47AM (2 children)

            by PiMuNu (3823) Subscriber Badge on Wednesday September 21, @11:47AM (#1272732)

            It's not the libraries, it's the sheer volume of keywords and cr*p in the core language. Just look at any style guide for a list of anti-features that are not to be used.

            * Implicitly defined initialisers
            * Different syntax for constructors with no arguments and constructors with arguments? WTF?
            * Template syntax altogether is a nightmare
            * and so on

            • (Score: 2) by RamiK on Wednesday September 21, @01:02PM (1 child)

              by RamiK (1813) on Wednesday September 21, @01:02PM (#1272745)

              I meant that despite everything about C++ itself being crap, we're all victims of our dependence on existing C++ libraries and end up using it or stuff made in C++ regardless. e.g. the browser I'm typing in right now...

              --
              compiling...
              • (Score: 2) by PiMuNu on Wednesday September 21, @04:53PM

                by PiMuNu (3823) Subscriber Badge on Wednesday September 21, @04:53PM (#1272807)

                Understood - and agreed...

    • (Score: 5, Interesting) by Rich on Tuesday September 20, @09:44AM (1 child)

      by Rich (945) on Tuesday September 20, @09:44AM (#1272531) Journal

      the relatively small distance from C to C++

      It's a relatively small distance from C++ to C (by adding 'extern "C"'), but it's near insurmountable the other way round. The only way to reliably deal with the entanglement of forwarding exceptions and handling pending destructors is the runtime of a matured C++ compiler. Then there's the issue of C++ not even guaranteeing where something is in memory (read up on when the "offsetof" operator is permitted). Finally, the way templates work leads to bloat you don't want to have in any code that needs to live in small caches for best performance.

      To get clean interaction, you'd have to expose the inner workings of the C++ runtime in C. A massive upgrade to C's setjmp/longjmp for exceptions, including language support for what needs to be "volatile" in that context. For compact code suitable for a kernel, a completely rewritten C++ template library with a single code backend and just templates for type safety sugar on top would be the least. Either will get you a shitstorm from the respective camp for simply mentioning it.

      • (Score: 0) by Anonymous Coward on Wednesday September 21, @05:03PM

        by Anonymous Coward on Wednesday September 21, @05:03PM (#1272811)

        Utter nonsense.

    • (Score: 2) by choose another one on Wednesday September 21, @12:49PM (3 children)

      by choose another one (515) Subscriber Badge on Wednesday September 21, @12:49PM (#1272742)

      Um, as I recall Linux (kernel) development _did_ use C++, back in the early days (just checked - yep 1992).

      The intention of the switch, as I recall, was to benefit from C++ features like stronger type-checking. It failed - mainly, I suspect, because C++ support in gcc/g++ at the time was a crapshoot in a bug-fest. Even in late '90s I personally found it quite a shock to move to the MS/Windows world (for work/gotta-make-a-living reasons) and find that actually pretty much all the "that would be really neat if it worked" stuff in C++ that I was having to kludge around in Linux land, actually _did_ work properly in Visual C++. FOSS compilers remained well behind until gcc/ecgs merge sometime around turn-of-the-century.

      There were other more fundamental issues outside of that though, things that would have to be avoided because would not play nicely with the rest of the in-C-kernel - e.g. memory management, exceptions. Later in the '90s embedded folks developed embedded subsets of C++ for pretty much the same reasons.

      Fast forward 20 years and C++ would be a non-starter I think, simply because of the sheer amount of code that would have to be converted or made at least C++ aware - you can put some C code inside C++ (C libraries are used all the time) and the problems from doing that are known and can be managed (it's what C++ was designed to do) but using some C++ inside C code framework will all go horribly wrong (exceptions, memory management etc). I can easily see that it might be far less work to allow another completely different language to be used in places - C++ is just too close to the internals of C.

      • (Score: 3, Interesting) by bzipitidoo on Wednesday September 21, @02:30PM (2 children)

        by bzipitidoo (4388) on Wednesday September 21, @02:30PM (#1272771) Journal

        C++ in the kernel that long ago? Didn't know that!

        > FOSS compilers remained well behind

        Did you ever use the Borland C++ compiler? Way more broken than g++. One of Borland C++'s worst bugs was its inability to correctly use more than 64k data in the x86 segmented memory model. As long as you kept to piddly little beginning CS assignments, you were okay, but try to work with more than 64k of data, watch out. Had that problem up through version 4.5, and as I recall it still wasn't fixed in 5.x. That was what pushed me to FOSS.

        > There were other more fundamental issues

        Yeah, compiler issues shouldn't be reason to trash a language, unless the language is the cause of those issues.

        I find C++ basically a gateway drug. Every time I've started a project in C, I find myself wishing I could use this and that convenience that works in C++, and end up switching. At first, the code is just C with structures renamed to classes because it's a whole lot easier to point to functions that way. No inheritance, no polymorphism, no templates, and no operator overloading. Still use stdio.h, because everyone knows that iostream has worse performance. (A curious thing about that is that iostream's performance is worse because it defaults to support of stdio. Turn that legacy support off, and ...) But then, you start wishing for such things as the nicer string handling of the STL, and associative arrays and such like, and so, those features, especially templates, creep in. Or at that point, you switch to a language that has native support for that stuff. Depends on several factors, with performance being a big one. I wrote a simple byte value counter in Perl 6 (now called Raku), turned the program loose on a 100M file, and it took 20 minutes. The same program in C took 2 seconds. We're further than ever from One Language To Rule Them All.

        • (Score: 0) by Anonymous Coward on Wednesday September 21, @06:55PM (1 child)

          by Anonymous Coward on Wednesday September 21, @06:55PM (#1272839)
          2 seconds? Why is your C program taking so long to count bytes?

          Have you tried perl5?

          #!/usr/bin/perl -w
          use strict;
          my $path=shift||'';
          my $fh;
          die "unable to open: $path: $!"  unless open($fh,"<$path");
          my $buf='';
          my $bufsize=131072;
          my $total=0;
          while ( my $read = sysread($fh , $buf , $bufsize) )
          {
              $total+= $read;
          }
          print "$total\n";

          time ./t.pl  test.bin
          100000000

          real    0m0.009s
          user    0m0.004s
          sys     0m0.004s

          And this is on a Linux VM running in virtualbox on a Windows 10 ryzen PC.

          • (Score: 2) by bzipitidoo on Wednesday September 21, @11:49PM

            by bzipitidoo (4388) on Wednesday September 21, @11:49PM (#1272916) Journal

            The computer I tested it on had a HDD, not a SSD.

            Here's the Perl6 code I banged out:

            # histogram of bytes in a file.
            use v6;

            my @c;
            my $i = 0;

            loop ($i=255; $i>=0; $i--) {
                @c[$i]=0;
            }

            my $count=0;
            while defined $_ = $*IN.getc {
                $count++;
                $i = ord($_);
                if ($i>255) { $i=255; }
                @c[$i]++;
            }

            $i=0;
            for @c {
                print sprintf("%c %7d ",$i,$_);
                $i++;
                if ($i%8 == 0) { say ""; }
            }

    • (Score: 0) by Anonymous Coward on Wednesday September 21, @05:00PM

      by Anonymous Coward on Wednesday September 21, @05:00PM (#1272809)

      Um, what? name mangling wouldn't affect existing code.

(1)