Announcement

Collapse
No announcement yet.

Rust UEFI Firmware Targets Promoted To Tier-2 Status

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

  • Rust UEFI Firmware Targets Promoted To Tier-2 Status

    Phoronix: Rust UEFI Firmware Targets Promoted To Tier-2 Status

    Back in September was a proposal to promote Rust's UEFI firmware targets to tier-2. With the current tier-3 designation the Rust UEFI targets they currently lack continuous integration (CI) guarantees and official builds in the Rust release channels, which means users wanting to use Rust for targeting the UEFI binaries need to rely on nightly/unstable compiler builds...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Rust Gnome an KDE when? Rust ffmepg, rust gcc, rust llvm, rust kvm, rust microcode from cpu vendors, rust drivers from GPU vendors, rust for the all drivers, all browsers in rust, dxvk in rust, graphics api in rust etc.

    Oh yes, I forgot games in rust too.

    Comment


    • #3
      Originally posted by Mario Junior View Post
      Rust Gnome an KDE when? Rust ffmepg, rust gcc, rust llvm, rust kvm, rust microcode from cpu vendors, rust drivers from GPU vendors, rust for the all drivers, all browsers in rust, dxvk in rust, graphics api in rust etc.

      Oh yes, I forgot games in rust too.
      Rust kvm exists (I forgot the name).

      Rust Gnome is already here, Gnome uses librsvg which now uses Rust and a small but growing number of Gnome apps are written in Rust (now that Rust has full support for the GObject stack incl. GStreamer).

      Rust drivers are coming, NVMe and M1 are on their way.

      All browsers won't switch to Rust but Firefox already contains substantial Rust code and Chrome is investigating the case for using it too.

      So yeah, it's gonna be a corroded world.
      Last edited by jacob; 03 November 2022, 06:11 PM.

      Comment


      • #4
        Originally posted by jacob View Post
        .... Chrome is investigating the case for using it too.
        Microsoft has also stated they are examining the use cases (with some core Windows functions being used as initial exploratory test cases).

        So yeah, it's gonna be a corroded world.
        Rust is not the right answer for everyone or everything just because it is orange-brown, but oxidation across many environments is certainly going to happen.

        Comment


        • #5
          Originally posted by CommunityMember View Post
          Microsoft has also stated they are examining the use cases (with some core Windows functions being used as initial exploratory test cases).
          Yes, the NT kernel got there before Linux!

          Originally posted by CommunityMember View Post
          Rust is not the right answer for everyone or everything just because it is orange-brown, but oxidation across many environments is certainly going to happen.
          I absolutely agree, for example I don't see much point in using Rust for web applications or microservices, although people are doing it. Go is a better fit for that IMHO. I also think there will still be a place for C for a long time and Rust won't replace it completely in all cases, particularly on small microcontrollers and ultra low-end hardware. Potentially Zig or another language designed along similar lines could challenge C in that niche, but Rust isn't that language for the same reason that C++ wasn't that language.

          Comment


          • #6
            Originally posted by jacob View Post

            Yes, the NT kernel got there before Linux!



            I absolutely agree, for example I don't see much point in using Rust for web applications or microservices, although people are doing it. Go is a better fit for that IMHO. I also think there will still be a place for C for a long time and Rust won't replace it completely in all cases, particularly on small microcontrollers and ultra low-end hardware. Potentially Zig or another language designed along similar lines could challenge C in that niche, but Rust isn't that language for the same reason that C++ wasn't that language.
            Go is great for many such cases BUT it depends how far you want to chase performance. If "ok" performance is good enough sure, but some companies like one behind Discord swapped their server code from Go to Rust because garbage collector from Go didn't scale well at number of messages discord is processing each second.

            I would say C is still gonna stay in places where knowdlege how machine code is produced is useful or on really niche architectures where only C compiler exist. So far neither Zig or C++ or Rust can challenge C in those places - language is vastly more complex so porting compiler is really hard so it is hard to figure out how assembly will look like from compiler (in general it is easy to convert C to asm and asm to C but not the other languages).

            Rust with proper tuning can be also small size but by default isn't.
            Last edited by piotrj3; 03 November 2022, 08:44 PM.

            Comment


            • #7
              Originally posted by piotrj3 View Post
              Go is great for many such cases BUT it depends how far you want to chase performance. If "ok" performance is good enough sure, but some companies like one behind Discord swapped their server code from Go to Rust because garbage collector from Go didn't scale well at number of messages discord is processing each second.
              True, but that's the exception, not the rule. For the most part, this type of development is for the business-y kind of apps where the alternatives are C# or - ehm... - node.js. Rust *could* have advantages there too, but those project managers are obsessed about "agile" development, low hanging fruits, tackling problems "later" (=never) and cheap hiring: the exact antithesis of what Rust brings to the table.

              Originally posted by piotrj3 View Post
              I would say C is still gonna stay in places where knowdlege how machine code is produced is useful or on really niche architectures where only C compiler exist. So far neither Zig or C++ or Rust can challenge C in those places - language is vastly more complex so porting compiler is really hard so it is hard to figure out how assembly will look like from compiler (in general it is easy to convert C to asm and asm to C but not the other languages).

              These two use cases are really one and the same. On a modern amd64 or aarch64 CPU the machine code generated has very little to do with the C source. For example something as simple as a loop to sum up numbers in an array, compiled with Clang, will result in SSE/AVX code that doesn't even iterate in the same order. It's on the very low end MIPS microcontrollers etc where you can expect a more or less 1-to-1 correspondence between your source code and the generated assembly.

              Originally posted by piotrj3 View Post
              Rust with proper tuning can be also small size but by default isn't.
              It's not a matter of tuning, it's because Rust implements generics by monomorphisation (like C++ templates), not by elision like Go (which is basically a glorified form of the C hack that consists in casting everything to void*). The moment you use Option, Result, any kind of container or iterator - that means all the time - the compiler must generate code for your particular type instantiation. It's great for both performance and safety, but it leads to binaries that contain lots of case-specific code. That's one reason why Rust can't be well suited for those use cases. But on the other hand, as even the lowest of the lowest systems get more RAM, the need for using C will diminish.

              Comment


              • #8
                Originally posted by Mario Junior View Post
                Rust Gnome an KDE when? Rust ffmepg, rust gcc, rust llvm, rust kvm, rust microcode from cpu vendors, rust drivers from GPU vendors, rust for the all drivers, all browsers in rust, dxvk in rust, graphics api in rust etc.

                Oh yes, I forgot games in rust too.
                not kvm but redox iirc added their own type1/2 vmm capabilites, and as for ffmpeg I guess maybe rust-av eventually.

                Comment


                • #9
                  Originally posted by Quackdoc View Post

                  not kvm but redox iirc added their own type1/2 vmm capabilites, and as for ffmpeg I guess maybe rust-av eventually.
                  Cloud Hypervisor is an open source Virtual Machine Monitor (VMM) implemented in Rust that focuses on running modern, cloud workloads, with minimal hardware emulation.

                  Comment


                  • #10
                    Originally posted by jacob View Post
                    not quite the same thing, cloud hypervisor would be analogous to qemu, not kvm, but building on this you also have the rust-vmm project (in which iirc there is a degree of overlap thought that might have been firecracker) and crosvm.

                    KVM is the kernel bits that provide acceleration to qemu, crosvm, etc.

                    Comment

                    Working...
                    X