Message-ID: <20250410151446.GJ9833@noisy.programming.kicks-ass.net>
Date: Thu, 10 Apr 2025 17:14:46 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>,
	Paweł Anikiel <panikiel@...gle.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Kees Cook <kees@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nathan Chancellor <nathan@...nel.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	Matthew Maurer <mmaurer@...gle.com>,
	Ramon de C Valle <rcvalle@...gle.com>
Subject: Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST

On Thu, Apr 10, 2025 at 04:54:20PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 10, 2025 at 4:08 PM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > Maybe I've been living in C/C++ land for too long, but you either expose
> > a full language feature and then everybody can use it, runtime,
> > libraries and user code alike, or you don't.
> 
> I find it unlikely that C++ stdlibs happen to build and work properly
> with compilers they are not tested for. Say, MS' STL with GCC or
> libc++ with MSVC.

Ignoring MSVC, which is a horrible joke of a compiler (or did Sutter
finally cluebat that team into building a sane compiler?), there are
definitely cross compiler STL implementations around.

> At the very least, you need to agree on builtins or `#ifdef` stuff
> manually for magic bits, and you need to avoid to rely on any compiler
> detail (or bug... :) anywhere (say, the non-conforming template
> behavior from old MSVC), and so on. So you need an active effort to
> make it work, I would expect.

Again, with the exception of MSVC, Boost builds on most C++ compilers
and is the staging ground for many new library features.

> And with new complex features like modules, I find it even more
> unlikely the first implementations of a compiler's stdlib would happen
> to work on the first implementation of the feature of another
> compiler...

Sure, shit happens, but... at least they try, it *should* work.

And the old STL (although STL really is far more a library than runtime,
it being fully optional) will most certainly build on a new compiler
from the same family.

And I know Linus hates on C++ something mighty, but in this parallel
universe where he doesn't, I would still recommend the kernel to not use
STL and instead build its own libraries (or borrow some nice pieces here
and there).

> Now, it is true that Rust's `core` uses a lot of internal features,
> precisely because they don't expect to be built by anything else that
> the current (and current - 1) compiler, so they actually take
> advantage of that.

So I don't think this is a good thing. Even builtin stuff should be
more stable than this.

> It would perhaps be nice to split the "really requires magic" in
> `core` from the rest somehow. In this case it wouldn't have helped
> though, since the formatting machinery still uses builtins last time I
> looked.

Right, to the point where we can carry a copy of the non-magic part
locally that matches the minimum version requirement. And no other bits
are to be used by in-tree rust code.

> Relatedly, GCC Rust's goal is to build an old `core` at the moment, so
> that they have a fixed set of things to solve.

Very sensible. The Rust project should have an stable core subset / variant
:-)

Powered by blists - more mailing lists