linux-kernel - Re: [PATCH RESEND] rust: enable slice_flatten feature and abstract it through an extension trait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DDYA3ECFG4D3.1H28762AJJ0Q4@nvidia.com>
Date: Sun, 02 Nov 2025 23:28:45 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>, "Alexandre Courbot"
 <acourbot@...dia.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>,
 "Gary Guo" <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "Danilo Krummrich" <dakr@...nel.org>,
 "Nathan Chancellor" <nathan@...nel.org>, "Nicolas Schier"
 <nicolas.schier@...ux.dev>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH RESEND] rust: enable slice_flatten feature and abstract
 it through an extension trait

On Sun Nov 2, 2025 at 9:00 PM JST, Miguel Ojeda wrote:
> On Sun, Nov 2, 2025 at 3:25 AM Alexandre Courbot <acourbot@...dia.com> wrote:
>>
>> Also not all of these seem to be tied to a feature;
>> `RUSTC_HAS_FILE_AS_C_STR` appears to refer to the
>> `Location::file_as_c_str` method, which is behind the `file_with_nul`
>> feature.
>
> So what happens there is that there are 3 states: "not implemented",
> "unstable" and "unstable but changed". That is, one transition is when
> the stdlib added it and the other when it changed.
>
> Now, normally there are only 2: "not implemented" and "unstable", and
> thus using the feature name makes sense there, because we use the
> Kconfig symbol to enable the feature conditionally, not individual
> methods (and a feature may contain different methods or even language
> features etc.).
>
> There is also the "stable" state of course -- the features don't get
> removed internally when stabilized, and in fact there is a lint that
> tells you about it (using that information), but we allow it, so it
> all works without extra complexity.
>
> In this case, we have 2 states but the other ones: "unstable" and
> "unstable but changed", because `slice_flatten` exists for way longer
> than our MSRV. And for this transition, for the other feature, we used
> the renamed method name, which makes sense since that is what got
> renamed, e.g. it could happen that a feature has 10 methods, and 2 get
> renamed in version X.
>
> So I think what you have in your patch actually makes more sense,
> since you are in the rename transition, not the feature addition one
> (i.e. we unconditionally enable `slice_flatten`).
>
> I guess we could come up with a different naming scheme to distinguish
> both cases or similar. For instance, we could add `FEATURE_` to the
> cases of the first transition. Anyway, it is not a big deal since we
> don't expect to have a ton of these -- quite the opposite, hopefully
> we can get rid them soon. And I wouldn't invert the logic of those
> equations, I think that gets even more confusing.
>
> So apologies for the noise there :) At least I hope it clarifies a bit...

It does - thanks for taking the time to explain!

I'll leave the config option name as it currently then.