[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72kTh94KiTuUkqJG4Focc-ChpyZruDqAaHo-g34=PbEcBg@mail.gmail.com>
Date: Sun, 6 Apr 2025 23:31:59 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Manish Shakya <msh.shakya@...il.com>, chrisi.schrefl@...il.com, Jamie.Cunliffe@....com,
a.hindborg@...nel.org, alex.gaynor@...il.com, aliceryhl@...gle.com,
andrew@...n.ch, ardb@...nel.org, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, corbet@....net, gary@...yguo.net, guptarud@...il.com,
linus.walleij@...aro.org, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux@...linux.org.uk, ojeda@...nel.org, rust-for-linux@...r.kernel.org,
stappers@...ppers.nl, thesven73@...il.com, tmgross@...ch.edu
Subject: Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7
On Sun, Apr 6, 2025 at 11:17 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>
> Maybe we should rename it to something more discouraging then. Eg
> CONFIG_RUST_BUILD_ASSERT_DISABLE.
To clarify: it doesn't disable them, but rather converts them to runtime checks.
Perhaps it should be _ESCAPE_HATCH or _KEEP_DISABLED or _AT_RUNTIME or
similar -- though changing it now may be even more confusing.
The description already mentions it should not happen, and that is an
escape hatch, and the recommendation and the default is N. So if
someone enables it in production, they really went out of their way to
do so, and even then they are protected by the panics (that they
shouldn't hit at all).
Eventually, we may just want to remove it entirely if we never see a
case failing and/or if we get proper support for those from upstream
Rust for this.
Cheers,
Miguel
Powered by blists - more mailing lists