Hacker News Reader

Comment by dijit | Hacker News Reader

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)

View on HN

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

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.

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.

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

Reply on news.ycombinator.com