Rust Developers Move Ahead With Preparing To Upstream More Code Into The Linux Kernel

[rogerx]

Well, for a while we tried doing it loud and obnoxiously, but people seemed to hate that even more, so I'm not exactly sure what you want from us.

Your right, Microsoft did a great job of deprecating technology/software every year or so, forcing everybody to buy newer hardware!

How odd?

[bug77]

You can turn on strict c++ so no extensions are used. Compilers behaving differently is a good thing as long as they follow the c++ standards. What is the issue?

Yes, you can write safe code in C++. You have about as good a chance as the randomly typing monkeys that will come up Shakespeare's sonnets (a little better, tbh). What's your point?

[jacob]

Yes, you can write safe code in C++. You have about as good a chance as the randomly typing monkeys will come up Shakespeare's sonnets (a little better, tbh). What's your point?

Actually no. Safe means provable. It's almost always impossible to prove that a C++ program is safe.

[mdedetrich]

That's one of the thiing rust done right.
Everything of the language, including its specs, RFCs and implementation are public and hosted on github.
Development happens on github and anybody can participate.

The discussion usually happens on zulip and is also publicly available and anybody can join at anytime.

Indeed this is how open source is meant to work. Scala is another language that works this way (I have also personally contributed to Scala) and its liberating to do so.

[bug77]

Actually no. Safe means provable. It's almost always impossible to prove that a C++ program is safe.

It depends. I'm pretty sure it's provable if you look at the generated code directly. Not provable from a compiler's point of view, though, which is pretty much the whole point of Rust.

[cj.wijtmans]

Yes, you can write safe code in C++. You have about as good a chance as the randomly typing monkeys that will come up Shakespeare's sonnets (a little better, tbh). What's your point?

I switch C++ compilers without issue all the time. what is your point? its just rambling about non existing issues.

[jacob]

I switch C++ compilers without issue all the time. what is your point? its just rambling about non existing issues.

Well maybe you happen to be lucky. But that is an exception, not a rule. Postgresql won't build on freebsd with clang-14, Mozilla has been complaining how trying to accommodate 3 different C++ compilers for their official Firefox builds (VC++ for Windows, G++ for Linux, Clang++ for MacOS) generates substantial additional work, Chromium prefers to ship its own clang, Linux won't work with anything but gcc (and now clang too, but that was a MAJOR undertaking), a number of packages written in C or C++ in the BSD ports tree still have a hard requirement on GCC, etc.

The reality is that trying to write code that is compiler independent takes extra effort which is hardly justified. It was another story when there was a much larger number of relevant platforms than today and each had its own proprietary C compiler (or compilers). But for a new programming language that comes with a compiler which is free, that anyone can have, use, port, adapt, fork etc. at will, which already runs on the most important OSes and architectures (although yes, arch support is still a weakness of Rust compared to C), I really don't see the point of demanding multiple subtly different implementations just because reasons. What practical problem would that solve? I don't see any, but I see a number of problems it would introduce.

Let's also not forget another factor: writing pure "standards compliant" code was much less of a problem back in the 80s or even the 90s. But user expectations have moved on since then and software complexity has increased by orders of magnitude - and for good, justified reasons, so KISS is not the answer. By the same token some of the then-standards have became basically immaterial (like POSIX). You can still write "hello world" in pure standards compliant C, but if you are developing say LibreOffice, choosing your compiler for the project is as important as choosing the UI framework it will use. After all, if someone wants to rebuild it himself, telling him "you must use g++" is a perfectly valid choice.

[moltonel]

afaik there is no "other kernel code". Rust will not be in the kernel at all, there are no plans for that currently.

Huh ? Rust in 6.1 is very limited, but the 6.2 PR has interfaces to network and filesystem in addition to pure driver stuff. The longterm goal is to be able to use Rust almost anywhere in the kernel, even if it remains out of mainline for various reasons. Also, Rust is already a popular language to write eBPF programs in.

[moltonel]

Which architectures will be supported? If we see for example some PCIe device drivers or file systems in Rust in the future, I hope some niche architectures are not left without support.

Essentially these, plus any that get added/promoted in future rustc version and minus any that rustforlinux might initially blacklist. The importance of llvm-unsupported platforms is often overblown (you're very unlikely to come across one unless you're a specialized embedded dev), but they do prevent Rust from being used in a mandatory core part of the kernel for now.

I know there is gcc rust compiler in pretty good shape and will be part of GCC 13 officially (so probably May 2023), which does support quite a lot of platforms

Gcc-rs is making good progress, but it is very far away from being usable for everyday rust code or kernel code. Don't expect more than a technology preview in gcc13. And remember that each platform requires some work in the frontend too, gcc will not magically support all the same platforms for Rust as for C/C++.

On the other hand, rustc's gcc backend (rustc_codegen_gcc aka cg_gcc) can already compile most rust code, including kernel code. It's getting close to being a simple to install/use backend for rustc. It's a much more pragmatic answer to the platform support question, with much less controversy.

not sure what Kernel will use by default.

If you're targeting a niche arch, you don't really care about the default way to build Linux. The most common way will remain to use Gcc or Clang (much more common than most people think, even before Rust came into the picture) for the C code, and rustc (with its llvm backend) for the Rust code.

I had various issues with standard rustc compiler, not playing nicely with some tools.

That describes every language I've ever used, especially C and C++.

[bug77]

Huh ? Rust in 6.1 is very limited, but the 6.2 PR has interfaces to network and filesystem in addition to pure driver stuff. The longterm goal is to be able to use Rust almost anywhere in the kernel, even if it remains out of mainline for various reasons. Also, Rust is already a popular language to write eBPF programs in.

Can you elaborate a little, please? I was under the impression Rust drivers would use the existing APIs (if wrapped inside unsafe blocks).