LWN: Comments on "Supporting Linux kernel development in Rust"

MIR is a wiser choice

nix — Sat, 12 Sep 2020 14:53:01 +0000

Firefox 79.0 failed to build with Rust 1.45.x+: https://bugzilla.mozilla.org/show_bug.cgi?id=1654465 (seriously misleading bug title because the failure-to-build wasn't clear until halfway down the discussion thread). Now admittedly 1.45 wasn't out at the time FF 79 was released, but still it took over a month to backport the relevant patch from ff trunk...

This is not what I would describe as a showstopper, though, because it only happens with LTO so it's easy to fix by just not using LTO.

Supporting Linux kernel development in Rust

marcH — Tue, 08 Sep 2020 08:36:36 +0000

> There's a reason people who talk about how great C++ is always talk about the need to use a limited subset of the language.

https://www.google.com/search?q=alex+gaynor+holding+it+wrong

You can write bug-free code in any language. It's just orders of magnitude harder with some.

Supporting Linux kernel development in Rust

marcH — Tue, 08 Sep 2020 05:50:59 +0000

> The ubiquitous kmalloc() function, for instance, is defined as __always_inline, meaning that it is inlined into all of its callers and no kmalloc() symbol exists in the kernel symbol table for Rust to link against.

"Inlining" does not imply "no standalone function". These are of course related yet different things. There is a number of cases where a standalone function is created even when the calls are inlined. Simple example from https://gcc.gnu.org/onlinedocs/gcc/Inline.html :

> The function must also be compiled as usual if the program refers to its address, because that cannot be inlined.

Wouldn't a reference to the address of kmalloc() be simpler than "defining a kmalloc_for_rust() symbol containing an un-inlined version"?

MIR is a wiser choice

farnz — Sun, 06 Sep 2020 19:30:09 +0000

#[!deny(warnings)] sounds like a failure to communicate inside the build system; at the rustc level, there's a --cap-lints option to turn "deny" into "warn" or "allow". I know Cargo threads that through to dependencies, but right now, there's no easy way to supply it to cargo build, bar setting the RUSTFLAGS='-A dead_code' environment variable.

MIR is a wiser choice

edomaur — Sun, 06 Sep 2020 07:13:44 +0000

Ah, yes, I forgot Sealed Rust but it's exactly why I meant.

Supporting Linux kernel development in Rust

zlynx — Sun, 06 Sep 2020 03:44:12 +0000

Rust and updating code to handle "edge cases" is exactly what is so great about Rust. Yes, you might have to rewrite 300 lines of code to fix that edge case. And it will be done correctly.

In my 25 years of experience doing C++ (not always full time) the worst bugs are created by the "quick fixes" where somebody makes "just a small change" which seems to work, but in reality has just created a black hole of undefined behavior where tiny code changes in other parts of the code will destroy the storage used by your dangling pointer/reference to a deallocated temporary std::string. Now with bonus C++11 behavior where it depends on how long the string was.

MIR is a wiser choice

roc — Sun, 06 Sep 2020 03:25:00 +0000

Thanks!!!

One issue is due to "#![deny(warnings)]". This is similar to C++, where if you build with -Werror you will break frequently. Libraries need to not use that.

One is a build system issue where the requirements for LTO changed.

The rest seems to be issues in rust-url but I can't see what the actual issues were :-(.

Supporting Linux kernel development in Rust

flussence — Sun, 06 Sep 2020 03:18:17 +0000

C is not simple. It only *looks* simple to you because of survivor bias; the worst crap gets filtered out through the kernel's multiple layers of review and rejection. The same would be true of Rust code.

MIR is a wiser choice

kenmoffat — Sun, 06 Sep 2020 00:19:38 +0000

Mostly, I don't have the details - if the current release fails to build with a newer rust then I don't have the skills to track it down. In generally, when a package FTBFS I hope to not be on the bleeding edge and to find that soemone has already solved the problem. But finding relevant search results is increasingly problematic.

But for seamonkey I eventually discovered they were tracking this and had a series of patches, the bug for tracking current rust versions is at https://bugzilla.mozilla.org/show_bug.cgi?id=1617782 and the first several attachments were needed to enable 2.53.1 to be build with whichever version of rust was current at the time - I hit it in February, it was in March that I found the patches (there was a link from an Arch posting).

I think that bug might have details of how the build failed for each item.

Supporting Linux kernel development in Rust

roc — Sat, 05 Sep 2020 23:38:31 +0000

Yes, adding Rust or anything not-kernel-C adds cognitive load, so that must be part of the cost-benefit analysis.

The cognitive load for Rust is much lower than for C++ though; C++ is a much bigger and hairier language, and demands much more effort from the developer to avoid UB.

> Particularly rust which is quickly becoming a write only language to work around all the edge cases that crop up.

I have no idea what this is about. I read third-party Rust code a lot. If Rust's "edge cases" bother you then C++ must be completely off the table.

MIR is a wiser choice

roc — Sat, 05 Sep 2020 23:32:29 +0000

An hour of work spread over two years is insignificant.

C++ compilers have backwards incompatibilities and just plain compilation bugs at a similar low rate.

MIR is a wiser choice

roc — Sat, 05 Sep 2020 23:28:14 +0000

I'm actually interested in the details of what backwards-incompatibility you encountered in each case.

I'm aware of a couple of soundness fixes that might possibly have affected you but other than that, I'm not aware of any backwards-incompatibilities that hit anything real.

MIR is a wiser choice

kenmoffat — Sat, 05 Sep 2020 09:18:45 +0000

Sorry, I managed to reply in the wrong place - currently just above your question.

MIR is a wiser choice

kenmoffat — Sat, 05 Sep 2020 07:36:46 +0000

Off the top of my head, various issues in the past year or eighteen
months with seamonkey releases, and I think there was one problem with thunderbird. Now that thunderbird is on similar versions to
firefox-esr (for full releases) I don't expect many new problems with that.

For seamonkey the problem was in 2.53.1 when we wanted to move from rustc-1.37.0 to rustc-1.41.0. We want one version of rustc for all the packages in BLFS, so at the moment we are using firefox-esr and rustc-1.42.0 (and the current seamonkey release is fine).

Supporting Linux kernel development in Rust

bored — Fri, 04 Sep 2020 23:31:48 +0000

This is maybe the core of the argument, while rust (and C++) both bring things to the table, there is a lot of crossover between the functionality they provide. Which means mostly your just adding additional cognitive load for people who have to maintain the kernel as a whole. Now a developer has to be an expert in not only C and the compiler's code generation, but rust as well. The kernel is already got python, bash, make, etc i'm not sure it really needs another language. Particularly rust which is quickly becoming a write only language to work around all the edge cases that crop up. Maybe in another ~10 years when its has a lot more developer support and has a proven track record. For all we know at this point rust is going to be just another ada/etc.

MIR is a wiser choice

mathstuf — Fri, 04 Sep 2020 16:19:19 +0000

Most of my experience with it has been dependencies jumping onto new features once they stabilize. These tend to happen in waves as larger features land. Some of the latest points I've seen:

- 2018 edition
- byte accesses on primitive types (to_le(), as_bytes(), etc.)
- code changes to take advantage of NLL
- async/await
- feature(doctest)

These usually have 3-4 releases between them.

If you want to avoid these kinds of things, keep a Cargo.lock and you'll stick with versions that continue to work. Very rarely things do get removed in Rust updates, but these are typically soundness issues that can cause problems if they are used improperly. Luckily crater can be used to fix it across the (FOSS) ecosystem pretty easily. Release notes are well-written and short enough that anyone else can read and follow along.

Supporting Linux kernel development in Rust

mathstuf — Fri, 04 Sep 2020 16:12:45 +0000

> Rust code being hard to compile is an *advantage* for maintainers of large projects like the kernel.

Clarification (since I suspect this is what roc meant): I find Rust code far easier to compile than C or C++. Getting the compiler to accept the code is what is harder :) .

MIR is a wiser choice

tdz — Fri, 04 Sep 2020 13:36:14 +0000

A couple of times within four years is already quite a bit.

Supporting Linux kernel development in Rust

roc — Fri, 04 Sep 2020 09:30:59 +0000

> whenever you have two pieces of unsafe code that individually present a "safe" interface, there is a possibility of an interaction that makes the combination unsafe

The problem in the issue you linked to was JoinGuard assuming safe Rust doesn't leak. In fact, safe Rust is allowed to leak. So this problem wasn't due to an interaction between unsafe code modules, but because one piece of unsafe code assumed a property of safe Rust code that doesn't necessarily hold.

This was an understandable mistake in 2015 because then there wasn't as clear a picture of what the invariants around safe Rust actually are. The picture is clearer now, although still not fully clear. So maybe in the future some invariants will be clarified that invalidate the assumptions made by some unsafe code --- but even then, there is no general problem of "the possibility of an interaction that makes the combination unsafe".

MIR is a wiser choice

roc — Fri, 04 Sep 2020 09:20:43 +0000

Can you give some examples of Mozilla releases that build with stable Rust but are broken by later Rust releases? I have not seen this more than a couple of times in my project over the last four years.

Supporting Linux kernel development in Rust

farnz — Fri, 04 Sep 2020 08:45:17 +0000

Rust has a standard library linked list, and the abstractions for instrusive double-linked list and intrusive single-linked list have been written.

The reason linked lists are discouraged in Rust apply to C and assembly, too - they are fundamentally all about pointer chasing, and that's the hardest thing for a CPU to perform well at; other data structures are normally what you want, but the emphasis on linked lists in formal education (and in languages with "sufficiently smart" compilers like Haskell) means that people reach for them when they're the wrong choice.

Supporting Linux kernel development in Rust

vegard — Fri, 04 Sep 2020 07:04:56 +0000

Just thinking about this some more.

What you say sounds "easy" in a way, but is it really possible at all in most cases?

The Linux kernel is notorious for its use of intrusive doubly-linked lists, and Rust is notorious for the difficulty/discouragement of linked lists. Surely if it was just a matter of finding a safe abstraction in Rust (i.e. wrapper around unsafe code), Rust would also have easy-to-use linked lists?

If I remember correctly, whenever you have two pieces of unsafe code that individually present a "safe" interface, there is a possibility of an interaction that makes the combination unsafe, most famously <https://github.com/rust-lang/rust/issues/24292>. A whole bunch of people have worked on proving that all these safe abstractions are safe in the presence of each other (i.e. the RustBelt project). Wouldn't we need a whole bunch of verification work to make this work for the kernel?

MIR is a wiser choice

roc — Thu, 03 Sep 2020 22:43:57 +0000

Ah yes, you're right about that domain. I guess you're talking about Sealed Rust attempting to meet that need: https://ferrous-systems.com/blog/sealed-rust-the-pitch

MIR is a wiser choice

njs — Thu, 03 Sep 2020 12:47:23 +0000

> My experience is that what builds now in *released* versions of mozilla or ex-mozilla packages (firefox-esr, thunderbird, seamonkey) is often broken by the second or third next rust release.

That's because those programs manually opt-in to unstable/prototype/still-in-development features: https://doc.rust-lang.org/unstable-book/index.html

By the same logic, you could say that C or C++ are unstable, because GCC lets you pass a special flag to opt-in to unstable features that might break in a future release. Quoting the GCC docs:

> C++20 features are available since GCC 8. To enable C++20 support, add the command-line parameter -std=c++20 (use -std=c++2a in GCC 9 and earlier) to your g++ command line. [...] *Important:* Because the ISO C++20 standard is still evolving, GCC's support is experimental. No attempt will be made to maintain backward compatibility with implementations of C++20 features that do not reflect the final standard.

- https://gcc.gnu.org/projects/cxx-status.html

This is totally under control of the project – if the kernel doesn't specifically request unstability, they won't get unstability.

> Meanwhile, I'm reluctant to try newer versions of rust (currently on 1.45.latest) because experiments with the first -rc from the forthcoming llvm showed that rust could no-longer build with system llvm.

Yeah, llvm is a fast-moving project with no API stability, so it's very difficult to use "system llvm" :-/

MIR is a wiser choice

edomaur — Thu, 03 Sep 2020 06:04:20 +0000

> I see no reason why Rust will need long-lived stable branches.

For embedded systems certification it will be needed, specially in telecom and medical areas. For example, some times ago I used Telit GSM modem which had a Python interpreter available inside, but even if the current Python was already 2.7, the provided interpreter had to be a v1.5.8 because of the time it took to pass the certification. And in the medical world it's even worse than that.

To be honest, I think that the Rust community will add an LTS version for the purpose, sometime in the future, but it's not the priority at the moment.

MIR is a wiser choice

kenmoffat — Thu, 03 Sep 2020 05:06:20 +0000

My experience is that what builds now in *released* versions of mozilla or ex-mozilla packages (firefox-esr, thunderbird, seamonkey) is often broken by the second or third next rust release.

At least some of this appears to be that things which used to be permitted are now prohibited.

It gives me little confidence that there is stability in rust and therefore I doubt that using it for the kernel can both produce code which compiles with a three-year-old version of rust (which might be expected towards the end of a long-term kernel's lifetime), and which offers the wonderful guarantees of safety.

I use BLFS and we put rust in /opt with a symlink from /opt/rustc to the running version - to change that is a simple matter of remaking the symlink and running ldconfig. That allows me to use a newer version for building latest firefox, and when something else wants a newer rust (librsvg has been a common pain for that) it lets me test what can easily move to the newer rust, and what cannot. Usually, it is painful for at least one package.

Meanwhile, I'm reluctant to try newer versions of rust (currently on 1.45.latest) because experiments with the first -rc from the forthcoming llvm showed that rust could no-longer build with system llvm. At one time in the past rust would build with system llvm, but miscompile firefox. Generally, when llvm or rust changes I expect pain.

MIR is a wiser choice

himi — Thu, 03 Sep 2020 00:32:21 +0000

Yeah, and on top of that I keep seeing new projects coming along which are starting out with Rust (the one I most recently started using in my workflow is gitui, which is all of six months old but which is already a very useful tool). It's pretty cleat that Rust has a /lot/ of momentum at the moment, and is on a pretty fast growth path. That doesn't mean it's future proof, or ready for all possible use cases, or even a better choice than any given alternative for a particular use case, but it does mean it's far, /far/ past the point where it has one primary sponsor and a bunch of toy projects.

Supporting Linux kernel development in Rust

roc — Wed, 02 Sep 2020 23:15:58 +0000

Rust code being hard to compile is an *advantage* for maintainers of large projects like the kernel.

It's hard to compile because the Rust compiler does a lot more checking. If submitted code doesn't use "unsafe" then the reviewer knows those checks have been satisfied and the code doesn't have hidden data races, hidden memory errors, etc. Rust moves work from the code reviewer to the code contributor. In my experience with the kernel contribution process this is something the kernel maintainers are very much in favour of. (It's actually better for the contributor too, since running the Rust compiler makes a much faster feedback cycle than getting it reviewed by maintainers.)

MIR is a wiser choice

roc — Wed, 02 Sep 2020 22:49:23 +0000

There are large projects where the number of stable branches is very small and and the duration for which they are maintained is not very long. E.g. for Chrome there is only one stable branch and it is maintained for no more than six weeks. For Firefox there are two and the longer one (ESR) is maintained for one year. I believe the Google monorepo never has a stable branch.

I see no reason why Rust will need long-lived stable branches.

Supporting Linux kernel development in Rust

mathstuf — Wed, 02 Sep 2020 17:10:53 +0000

> Due to C's simplicity, it is very easy to get drive-by contributions and get a constant stream of new developers

Sure, for things like typos, whitespace changes, and other changes on a similar level. But that's not language specific in any way. The scheduler, mm, and vfs subsystems being in C doesn't help me making any kind of substantial change.

I'd actually argue that having the ability to spell out better idioms and having things like ownership tracked as part of APIs would make it *easier* to contribute because the compiler can catch the "dumb" mistakes and leave the reviewers just having to look at the actually complicated parts instead of having to worry about "oh, I see a lock here, did you unlock it?" or "this data should be accessed under a lock, did you acquire it properly?" kinds of questions because you can enforce such things in the API directly.

> If the concept of a new language in the kernel is now open, then honestly C++2x would be a much better option.

Ha. I don't think it'd be that much of an improvement. For one, the plain makefiles for building the kernel would almost certainly be insufficient (unless you're going to ban modules).

Supporting Linux kernel development in Rust

rgmoore — Wed, 02 Sep 2020 16:48:20 +0000

If the concept of a new language in the kernel is now open, then honestly C++2x would be a much better option.

It's not likely to happen as long as Linus is in charge. He has been very negative about C++ for a long time, and there's no indication that's going to change. As I understand his view, Linus doesn't see C++ as bringing in any real capabilities that the kernel needs, while it does massively expand the size of the language in a way that makes it very difficult to keep everyone using the same abstractions. There's a reason people who talk about how great C++ is always talk about the need to use a limited subset of the language.

In contrast, Rust brings some capabilities for memory management that are sorely lacking in C and C++. The ability to exclude whole categories of error is potentially really valuable, and one can see why kernel developers would like to add those capabilities to their toolbox.

Supporting Linux kernel development in Rust

edomaur — Wed, 02 Sep 2020 16:34:33 +0000

Yes, as they said there https://blog.rust-lang.org/2020/08/18/laying-the-foundati... :

> Further, it is a common misconception that all of the Mozilla employees who participated in Rust leadership did so as a part of their employment. In fact, many Mozilla
> employees in Rust leadership contributed to Rust in their personal time, not as a part of their job.

Supporting Linux kernel development in Rust

darwi — Wed, 02 Sep 2020 12:23:01 +0000

I'm not convinced this is good for the health of the kernel community. You risk splitting the community, and people squeezing-in every "cool" rust feature under the sun. Due to C's simplicity, it is very easy to get drive-by contributions and get a constant stream of new developers. Meanwhile, it's sometimes quite hard to get the damn rust code to even compile...

If the concept of a new language in the kernel is now open, then honestly C++2x would be a much better option. The whole kernel will be built with one compiler, the benefits can cover the core kernel components (not just things in the margin), and boot-strapping new architectures would still be simple.

MIR is a wiser choice

vomlehn — Wed, 02 Sep 2020 10:39:27 +0000

Every real project I've worked on reached a point where there were specific stability points, e.g. git branches. Only bug fixes get added to the branches. This is the way the kernel stable releases work. I would expect the same to emerge shortly for Rust as pretty much all Rust users are going to required it. It's nothing fundamental to Rust.

MIR is a wiser choice

roc — Wed, 02 Sep 2020 06:42:32 +0000

rustc is different because they don't provide updates to any compiler branches other than the current release, so using a fixed release indefinitely to generate shipping code is not a good idea.

MIR is a wiser choice

edomaur — Wed, 02 Sep 2020 06:07:58 +0000

In fact, it's the same as with GCC : the kernel require a specific version of a compiler, it can/should be the same with rustc, anchoring the Rust kernel code to a specific version.

MIR is a wiser choice

edomaur — Wed, 02 Sep 2020 06:04:01 +0000

The release cycle and the API and ABI stability aren't related : you can chose a target "LTS edition" of the language, incoporated in the rustc compiler, and Rust also support raw identifiers for helping working with older release.

And about the "Firefox and some toy projects" part of your comment, well, it's funny but it's wrong, look again :-) Amazon run it's Lambda system on Firecracker, which they wrote in Rust, Dropbox replaced Python and Go by Rust in their MagicPocket storage system, OVH use it for their custom log application, Cloudflare is pushing new tools and services written in Rust, etc.

Supporting Linux kernel development in Rust

roc — Wed, 02 Sep 2020 04:19:38 +0000

See my comments up above. There are far more people using Rust (in production) outside Mozilla than inside it, and that has been true for years. Claiming that no-one outside Mozilla uses Rust is just weirdly out of touch.

> they are looking for a new home to support and fund them now that Mozilla laid them off.

This is also out of touch. For years Mozilla has been steadily reducing the number of people they pay to work on Rust. For years the vast majority of the work going into Rust has come from the community beyond Mozilla.

MIR is a wiser choice

roc — Wed, 02 Sep 2020 04:15:44 +0000

Hey look, just today:

https://aws.amazon.com/blogs/opensource/announcing-the-ge...

> Large parts of Bottlerocket are written in Rust, a modern programming language that helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities.

"starts to be used for anything but just Firefox and some toy projects" my foot.

A libgccjit codegen for rustc is already work-in-progress

antoyo — Wed, 02 Sep 2020 01:48:33 +0000

I've been working for a while on a libgccjit-based codegen for rustc: it can compile a hello world using the standard library and can generate code for quite a few other features, but many programs won't be compiled correctly yet.

Here's the link to the repository: https://github.com/antoyo/rustc_codegen_gcc