[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjuMrUMceYX01T0SBz4E0yL4Kh2Jb_8qyKxJwwitCG6Zw@mail.gmail.com>
Date: Wed, 25 Sep 2024 10:46:22 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Wedson Almeida Filho <wedsonaf@...il.com>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Rust for 6.12
On Tue, 24 Sept 2024 at 15:11, Miguel Ojeda <ojeda@...nel.org> wrote:
>
> Rust changes for v6.12
So it looks like now the only thing holding Rust testing back for the
allmodconfig case is the MODVERSIONS support (assuming modern enough
tool chains etc).
I'm inclined to just do this:
config MODVERSIONS
bool "Module versioning support"
+ depends on !COMPILE_TEST
help
Usually, you have to use modules compiled with your kernel.
Saying Y here makes it sometimes possible to use modules
in order to have the basic Rust stuff be part of the usual allmodconfig build.
That gets it building for me on x86-64, at least. But at the
maintainer summit I think you said MODVERSIONS support is being worked
on too, no?
On my arm64 box, Rust support is still disabled due to
RUSTC_SUPPORTS_ARM64 not being true (which in turn seems to be due to
SHADOW_CALL_STACK support, and that needs rust 18.2 which I don't
have).
Anyway, just a heads up that I think we'll have more "unintentional"
Rust build test coverage this way.
Linus
Powered by blists - more mailing lists