it involves the "patches-must-be-approved-by-upstream" to still be called Rust clause that Rust inherits from the Mozilla Trademark policy. Its the same policy that led to the creation of IceWeasel/Waterfox etc.
The root issue with Iceweasel was the logo, in my understanding. It was also resolved years ago. Rust does not inherit these problems, and even then, Mozilla will not be holding these trademarks anymore, even though I do not expect our policy will change once ownership changes.
For a desktop app it's understandable, but tons of scripts rely on the existence of rustc and cargo binaries. If the fork has to rename it to not-rustc just because it added e.g. gcc support, then that's going to break all the scripts.
I'm generally in support of rust in the kernel, but in the interest of playing devils advocate: Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers?
The Linux kernel would only compile with GCC for... decades? I think? So it's not really a new thing. It would be really nice if the kernel did have first-class support for LLVM and Clang directly (rather than having to set a bunch of environment variables to set the compiler, the linker to use with that compiler, various variables, etc.
That said, it would certainly be uncomfortable to move from "it compiles with Clang, though it's a pain, or GCC, which works fine" to "it compiles with GCC, if you don't use any of this functionality, or LLVM only, if you want any of these features or anything that depends on them".
Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly fine.
So, we're currently expecting that supporting Rust will not place any requirements on the C compiler you use, unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel).
There was a talk right after ours about LTO! I only half paid attention to it because I was catching up on the chat, but it sounds like Google is doing kernel LTO in prod for their internal systems (and maybe also for Android and CrOS?):
At the moment, I believe the Linux kernel can do LTO with some additional patches, but there are still regular issues. It isn't nearly as well supported as Clang or LLD yet.
Linux currently only compiles on GCC and Clang, and the latter is a recent development. rustc uses LLVM as a backend, just like Clang, and people are working on other backends. Linux maintainers didn't express any concerns about this being an issue.
Also it would be kind of funny. Where the rust parts can only be compiled by the llvm based rust compiler, but clang(llvm) can't build the C parts.
And gcc can only build the C parts but not the rust parts :)
Mozilla’s trademark policies have been annoying enough in the past that Debian used to ship a fork with the branding stripped. Hyperbola continued this practice for a while, but stopped for a variety of reasons in the It’s Foss interview, and switched to a UXP-based browser. I’m writing this from a UXP-based browser because I find it much better than Firefox and I dislike Mozilla in general for more than one reason.
But no, there are other reasons outside of trademarks, some technical ones are in submisson’s article.
