A first look at Rust in the 6.1 kernel [LWN.net]

A first look at Rust in the 6.1 kernel

Posted Oct 13, 2022 20:21 UTC (Thu) by mathstuf (subscriber, #69389)
Parent article: A first look at Rust in the 6.1 kernel

> The "getting started" page describes how to do this; inevitably, it involves one of those confidence-building "curl|bash" operations. The installer is entirely uninterested in where one might like one's Rust stuff installed (it goes into ~/.cargo) and silently modifies the user's Bash startup scripts to add the new directory into the PATH variable. The end result does work, though, and makes it easy to install the needed dependencies.

Note that it is possible to get a `rustup` that doesn't muck about with one's setup. It does mean doing `curl -O` instead of `| bash` (or did when I set things up years ago; it gets rsync'd around on machine initialization now as it is self-contained at least) and some light editing to neuter global `PATH` editing and rerooting to `~/misc/root/rustup` (for myself). But it isn't a forced treadmill.

> The kernel configuration process looks for the prerequisites on the build system and, if they are not present, silently disables the Rust options so that they will not even show in, for example, make menuconfig.

Ugh, I hate this pattern. I've found "let the user request what they want" and "error if not satisfiable" to be a far better behavior because having a configure line that says `--enable-frobnitz` which turns itself off if it doesn't find the obscure `quuxness` dependency is a wonderful way to frustrate build script authors as new dependencies get added because "it worked last week".

to post comments

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 8:32 UTC (Fri) by geert (subscriber, #98403) [Link] (4 responses)

There's no `--enable-frobnitz` switch that gets silently turned off in kernel builds.
IMHO It's just silly to ask the user about enabling a feature that doesn't make sense for his system, or can't be built anyway. And what about "allmodconfig" build tests and CI?
We already have close to 20000 config symbols, no need to bother users with the useless ones.

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 13:13 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

What happens if I have a config file that specifies "please enable Rust support" on a machine without the prereqs? Is there some notification that I'm not getting the kernel I asked for?

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 13:22 UTC (Fri) by geert (subscriber, #98403) [Link]

In that case the Rust support will be disabled silently.
This behaves the same as when using a config file that has compiler-dependent support enabled which is not supported by your compiler (e.g. UBSAN_TRAP, see `git grep "\$(" -- "*Kconf*"' for more).

I guess that's fair enough for an experimental feature that is not yet supported on all architectures?

Note that personally, I never run "make oldconfig", but always use my "linux-oldconfig" script, which prints a diff of all changes between the old and the new config file.

A first look at Rust in the 6.1 kernel

Posted Oct 16, 2022 15:47 UTC (Sun) by flussence (guest, #85566) [Link]

Rust is a config-time check so I guess it'd be exactly the same as other toolchain probing: you can see the effect if you do `make LLVM=1 oldconfig`; it pops up a bunch of new clang-specific questions but the old gcc-plugin ones silently vanish without warning, and vice versa.

A first look at Rust in the 6.1 kernel

Posted Oct 17, 2022 7:44 UTC (Mon) by mkubecek (guest, #130791) [Link]

> IMHO It's just silly to ask the user about enabling a feature that doesn't make sense for his system, or can't be built anyway.

This logic makes sense for people who are configuring, building and running the kernel on the same system which is mostly kernel developers. For all others - i.e. vast majority - kernel is usually configured on one system, built on another and used on many different. For that use case, the old approach (resolving unusable config options at build time) made more sense than current one (resolving at configure time). To emulate the old approach, one can use the "dummy toolchain", set of scripts in scripts/dummy-tools/ which pretend to be gcc, linker etc. capable of everything needed. People configuring distribution kernels then run "make CROSS_COMPILE=scripts/dummy-tools/ oldconfig" to get reproducible config which works as a superset of what will be actually built. So the solution here would be providing a dummy rust compiler and everything else that is needed.