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

A first look at Rust in the 6.1 kernel

Posted Oct 14, 2022 8:32 UTC (Fri) by geert (subscriber, #98403)
In reply to: A first look at Rust in the 6.1 kernel by mathstuf
Parent article: A first look at Rust in the 6.1 kernel

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.

to post comments

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.