Hacker News Reader

Comment by jcranmer | Hacker News Reader

If I'm understanding correctly, the only reason for not using Rust is... Rust is trademarked?

Wait till we tell them that Linux is a trademark of Linus Torvalds.

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.

We do also, you know, give permission.

Here is the core of the issue:

https://lwn.net/Articles/118279/

Debian wanted to allow anyone to patch their firefox. Mozilla said OK, but not with our name attached to it.

And this makes sense on some level : No project wants to provide support for someone else's bugs.

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?

I can see why people would be opposed to that.

I'm thinking about LLVM (and, obviously, rustc)

Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers?

Like GCC?

Your point is certainly valid, but I'm not sure it's a new problem.

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.

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).

> 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).

Does Linux even work with LTO right now? It seems to do a lot of weird-linking-magic things that I wouldn't expect to work well with LTO.

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.

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?):

https://linuxplumbersconf.org/event/7/contributions/798/ (slide link at the bottom)

https://youtu.be/FFjV9f_Ub9o?t=3844

ICYMI, Microsoft is putting a lot of eggs into the LTO/PGO basket to try to improve Linux performance: https://www.phoronix.com/scan.php?page=news_item&px=Microsof...

Article discussing LTO (Link Time Optimizations, used by Google Pixel) and PGO (Profile Guided Optimizations): https://www.phoronix.com/scan.php?page=news_item&px=Microsof...

There is the mrustc compiler https://github.com/thepowersgang/mrustc

It's not fully complete. But there is no reason why it couldn't be.

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.

Reply on news.ycombinator.com